Görüş: Yazılım geliştirme bir sanat değil
Amerikan bilgi teknolojisi Donald E. Knuth'tan harika bir fanboy olduğumu itiraf ediyorum. 1938'de doğdu ve olmasa da birinde çalıştı Dem Bilgisayar biliminin mükemmelliğinin en büyük edebi eseri, yani “Bilgisayar Programlama Sanatı”. Belki de ona geri dönen sayısız alıntılardan biri nedeniyle onu da tanıyorsunuz, örneğin:
“Yukarıdaki koddaki hatalara dikkat edin. Sadece doğru olduğunu gösterdim, ama test etmedim.”
Aynı zamanda eğlenceli, derin ve zeki olan bazıları var. Yoğun bir şekilde ele aldığı bir soru ve hala: Sonunda yazılımın gelişimi gerçekten karakterize ediyor? Bir sanat mı yoksa daha çok bir mühendislik bilimi mi?
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Şöminenin önündeki kodu okuyun
Donald E. Knuth'un bir alıntısından bahsetmiştim, ama benim için şahsen en güzel olan, yani:
“En son ne zaman şöminenin önünde rahat ve iyi bir kod okudun?”
Muhtemelen daha önce hiç yapmadığınızdan şüpheleniyorum – evet, muhtemelen gerçekten yapabileceğinizi düşünmediniz. Soru ortaya çıkıyor: Geliştiriciler olarak, kodu her gün sabahtan akşama her gün yönetiriz, kodun çoğumuz için İngilizce veya Fransızca gibi bir dil olduğu ve kod yazmak için çok zaman harcadığımız yerde, neden yeterli dikkat ve yardımsever takdirle okumak için zaman ayırmıyoruz?
Ve itiraf edin: Başlangıçta bunu yapmak çok garip görünüyor. Ancak bilgisayar bilimi okuduysanız, her zaman çalışmalarınız sırasında zarif ve güzel çözümler aramanız gerektiği hakkında konuştuğumuzu hatırlayabilirsiniz. Ayrıca, matematik gibi diğer bilimsel disiplinlerden de biliyoruz: her zaman güzel ve zarif kanıtlardan bahsediyoruz. Yani, algoritmalar veya testler bir estetiğin doğasında varsa, neden bilinçli olarak algılamak için zaman ayırmıyoruz ve gerekirse, özellikle başarıya sahipseniz, buna göre hayran olmak için?
Sanat olarak kod mu?
Belki şimdi bunun çok akademik ve çok geri çekildiğini söylüyorsunuz, ancak kısaca “hacker” kelimesini düşünüyor. Bugün, kötü niyetleri olan ve verileri çalan veya yok eden bilgisayarlara giren birini tarif ediyoruz. Bir hacker bugün bir jakuzi, bir suçlu. Ama her zaman böyle değildi. Kelime 1980'lerde ve 90'ların başında ortaya çıktığında, akıllı, zeki ve basit bir yolu çözebilecek veya karmaşık ve karmaşık problemler kodda zarif ve güzel çözümler uyandırabilecek birini tanımladı. Başka bir deyişle, kod sanatçılarına huşu duyduğumuz bir zaman vardı.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Yazılım geliştirme bir sanat değil
Ve eğer Knuth'un anıtsal çalışmasının başlığını göz önünde bulundurursanız, o zaman dikkat: buna ” Tip Bilgisayar programlama “, sadece” bilgisayar programlama “veya benzeri değil.” Sanat “ile ilgilidir, bu nedenle bu konuda Sanat programlama. Ve Knuth gerçekten tam olarak bu şekilde anlamak istiyor, çünkü çeşitli farklı yolların programlanmasını, örneğin müziğin bileşimi veya bunların hepsinin güzelliğin yaratıldığı estetik deneyimler olduğu yoğunluk ile karşılaştırdı. Şahsen, kodu yazma konusundaki bu perspektifi düşünmeyi olağanüstü buluyorum.
Mühendislik bilimi olarak yazılım geliştirme
Bunu günlük yaşamda ve çoğu geliştiricinin çalışmalarında olanlarla karşılaştırırsak, genellikle sanattan uzaktır. Diğer şeylerin yanı sıra, kendimizi kuşattığımız terimlerden çok hızlı görebilirsiniz: bunlar yazılımMühendislikBunlar yazılımFabrikalarOlduğu gibi Mühendislik Bilimleri Tahmin edilebilir, yerleştirilebilir ve deterministik olmalıdır. Başka bir deyişle, bu şaşırtıcı (veya bakış açısına bağlı olarak korkutucu) sanatsal bir vizyondan çok uzaktır.
Bu nedenle soru otomatik olarak ortaya çıkıyor: şimdi kim var? Aslında nedir? Doğa nedir ve bütünün çekirdeği nedir?
Sektöre bir bakış yolculuğunun nereye gittiğini gösterir: test? Genellikle ihmal edilirler, gereksiz yere maliyetlerdir ve çok önemli değildirler. Biliyorsunuz: Daha küçük testler aracılığıyla daha ucuz yazılım alın. Belgeler? Birisi bile buna ihtiyaç duymaz, paraya mal olur ve her şeyden önce. Temiz kod? Eğer kesinlikle olmak zorundaysanız, bir hafta boyunca bir yeniden düzenleme sprint yapabiliriz, ancak lütfen tekrar yeni özellikler yazmalıyız, çünkü müşteri temiz kod için ödeme yapmaz. Müşteri genellikle kodu ödemez, çünkü umursamıyor. Gerçekte, müşteri bunun yerine pragmatik ve verimli bir problemi çözdüğümüzü ödüyor. Ve bunu bir tornavida ile değil, kodla yaptığımız en iyi ihtimalle üçüncü bölümün bir yan yönüdür.
70.000 satır PHP kodu
Şaşırtıcı olan şey, işe yaramasıdır. Birkaç yıl önce büyük bir grupta sadece kart için analiz yazılımı üzerinde çalışan biriyle tanıştım. Kodu (ve bu hikaye aslında doğrudur ve şaka yok), tek bir (!) Dosyasında 70.000 satıra bir PHP kodundan oluşuyordu. Tek bir otomatik test, otomatik dağılım yok, CI/CD boru hatları veya benzerleri yoktu. Bir sürüm yönetimi ile bile çalışmadı, ancak VI ile üretken sunucudaki PHP dosyasını doğrudan değiştirdi.
Ve aslında bunun iyi bir şey olduğunu düşündü, çünkü: Sonunda saatlerce değişiklikten sonra bir dosya kaydetmiş olsaydı, uygulama hemen dağıtıldı. En kötüsü, ait olduğu ekibin en istikrarlı ve güvenilir yazılımı olan o olmasıydı. Tüm bunlar üzerine krema: PHP komut dosyasına farklı sembolik bağlantılarla erişilebilir ve nasıl adlandırıldığına bağlı olarak farklı davrandı. Tavsiye onu sevdi, ancak takımdaki diğerleri onu lanetledi ve her tatile gittiğinde ya da hastalandığında titredi.
Tutarsızlık nereden geliyor?
Harici bir danışman olarak, bu ekibi finanse ettiğimde, birim testleri, entegrasyon testi, statik kodun analizi, versiyonların yönetimi, konteyner, sürekli entegrasyon, sürekli bir prosedür ve uzun süren kodun iyi kalitesi için iletmek istediğiniz en iyi uygulamalarla oradasınız.
Ve bu vizyon beni bir perspektiften rahatsız ediyorsa, ise itiraf etmeliyim ki: Evet, üretim sunucusundaki 70.000 satır PHP kodu ile, altta yatan sorunu çözdü ve güvenilir bir şekilde karta teslim etti. Bu önemliydi (en azından belirli bir perspektiften). Ancak, hiç biriyle tanışmadım (ve eğer bir geliştirici veya yönetici ise), “Vay canına, harika! O yüzden bundan sonra yapacağız!”
Çünkü sonunda herkes kalite ve co. Açısından daha fazla güvenilirliğe sahip olmak istiyor, çünkü her şeyden önce, her konferansta, her toplantıda, her blogda veya YouTube'da benim gibi insanlar da dahil olmak üzere söylenenler. Ancak, sorunu çözmeyi amaçlayan pragmatizm ve gelişimin reddedilemeyeceğini de itiraf etmeliyim. Verimli. Ama neden kimse bunu tavsiye etmiyor? Bu tutarsızlık nereden geliyor?
İşletmeye Karşı Sanat
Sonunda, bunun iki karşıt bakış açısının burada çarpıştığını düşünüyorum: burada sanat iş ile buluşuyor. Ve sonunda, bilgisayar bilimi aynı anda, bilgisayar bilimi ikiliktir. Bu ikiliğin günlük yaşamdaki etkilerini sürekli olarak deneyimledik, çünkü her gün bu iki dünyanın ve bu iki perspektifin birbirleriyle çatıştığı sürtünme noktaları var. Bu, çaba için bir saygı sağlamak istediğiniz zamanla başlar. Şahsen her zaman düşünüyorum: “XY için ne kadar süre ihtiyacım olacağını ne biliyorum?”
Sonuçta, buna yazılım deniyorgelişim Ve yazılım değilüretmeVe etkinliği önceden gerçekleştirmiş olsaydım çabayı tahmin edebilirim, ancak daha sonra kodu önceki uygulamadan kopyalayabilirim ve gelişmemeliydim. Ve bunu yapmanın tek yolu bu değil, bu çok sayıda geliştiricinin durumu, bu yüzden kişisel olarak nispeten önemsiz olma çabasının takdirini görüyorum.
Sonunda, bir geliştiriciden çaba için bir saygınlık isterseniz, Picasso'ya bir timsah imajına ne kadar süre ihtiyacı olacağını tahmin edip edemeyeceğini soruyormuşum gibi, sonuçta, sadece Dachshund'un sadece bir çizgisi olduğunu ve en fazla beş dakika talep edebileceğini tahmin edip edemeyeceğini sorar. Ama gerçek şu ki: sanat takdir edilemez. Aksine, işteki sonuçları planlayabileceğinizi ve görebileceğinizi ve görebileceğinizi de anlayabiliyorum: eğer bir ev inşa edersem, yaklaşık korumanın henüz bitmediğini bilmek istemiyorum çünkü “Üstat'ın eli, yakalamayı yürütmek için doğru salınım ve bir hafta boyunca doğru ilham değil”.
Merdiven alır
Bununla birlikte, bu iki bakış açısı da iki uçtur ve her zaman olduğu gibi, iki uç varsa, kutuplar arasında da bir şey vardır. Bu, sonunda tüm sorunun bir merdivenden bahsettiğimiz anlamına geliyor. Bir tarafta, yazılım ve kodu kendi içinde bir amaç olarak gören saf sanat, “Art Pour l'Rant” dır. Ölçeğin diğer ucunda, tamamen pragmatik iş, sadece sorunları mümkün olan en verimli ve ekonomik şekilde çözme meselesidir ve çalışmaz (Dikkat, Worldwitz). Kod ve yazılım bir amaç için saf bir araçtır.
Gerçek, ortada bir yerde olduğundan şüpheleniyorum, çünkü uygulamasız sanat fildişi kulesinden çıkmıyor. Ancak sanatsız uygulamanın ruhu yoktur. Ve önemli soru şu: Bu ölçekte neredesin?
Eğer daha fazla geliştirici bu soruyu düşünür ve bir bakış açısı tanımlarsa ve şirketler aynı şeyi yaparsa ve eğer ilgili değerler sistemi hakkında konuşuyorlarsa, kalkınmanın kendisinin doğası hakkında daha az çatışma ve yanlış anlama olduğu için gelişmenin çok daha iyi ve daha kolay olacağına inanıyorum.
Ve sonra, sonunda, yazılımın geliştirilmesi aslında tam olarak olabilir: sanat yok.
(RME)