Görüş: Yazılım geliştirme bir sanat değildir
Amerikalı bilgisayar bilimcisi Donald E. Knuth'un büyük bir hayranı olduğumu itiraf etmeliyim. 1938'de doğdu ve onlarca yıldır bir tanesi üzerinde çalışıyor. dem bilgisayar bilimleri alanındaki en büyük edebi eser: “Bilgisayar Programlama Sanatı”. Belki onu, geçmişi o zamana kadar uzanan sayısız alıntıdan birinden de tanıyorsunuzdur, örneğin:
Duyuru
“Yukarıdaki koddaki hatalara dikkat edin. Sadece doğru olduğunu kanıtladım ama test etmedim.”
Aynı zamanda komik, derin ve zekice olan pek çok alıntısı var. Yoğun bir şekilde ve tekrar tekrar yanıtladığı soru şu: Yazılım geliştirmeyi nihai olarak karakterize eden şey nedir? Bu bir sanat mı yoksa daha çok mühendislik bilimi mi?
Golo Roden, native web GmbH'nin kurucusu ve CTO'sudur. Etkinlik ve hizmet odaklı dağıtılmış mimarilere odaklanarak web ve bulut uygulamaları ile API'lerin tasarımı ve geliştirilmesiyle ilgilenmektedir. Yol gösterici ilkesi, yazılım geliştirmenin kendi başına bir amaç olmadığı, her zaman temeldeki profesyonelliği takip etmesi gerektiğidir.
Kodu şöminenin önünde okuyun
Daha önce Donald E. Knuth'tan bir alıntı yapmıştım ama benim için açık ara en güzel olan başka bir alıntı daha var:
“En son ne zaman şöminenin önünde kıvrılıp güzel bir kod parçası okudun?”
Muhtemelen bunu daha önce hiç yapmadığınızdan şüpheleniyorum, aslında bunun gerçekten yapılabileceği gerçeğini muhtemelen hiç düşünmediniz bile. Şu soru ortaya çıkıyor: Biz geliştiriciler her gün sabahtan akşama kadar kodla çalıştığımız, çoğumuz için kodun İngilizce veya Fransızca gibi bir dil olduğu ve kod yazmaya bu kadar çok zaman harcadığımız bir yerde, neden okumaya zaman ayırmıyoruz? gerekli dikkat ve anlayışlı takdirle mi?
Ve itiraf etmeliyim ki ilk başta bunu yapmak oldukça tuhaf geliyor. Ancak bilgisayar bilimleri okuduysanız, eğitiminiz sırasında hep zarif ve güzel çözümler aramaktan bahsettiğimizi hatırlarsınız. Ve bunu matematik gibi diğer bilimsel disiplinlerden de biliyoruz: Orada da her zaman güzel ve zarif gösterilerden bahsediyoruz. Öyleyse, eğer algoritmalar veya gösteriler doğal bir estetiğe sahipse, neden onları bilinçli olarak algılamak için zaman ayırmıyoruz ve eğer özellikle başarılılarsa, buna göre onlara hayranlık duymuyoruz?
Sanat olarak kod mu?
Bunun sizin için çok akademik ve abartılı olduğunu düşünebilirsiniz, ancak bir an için “hacker” kelimesini düşünün. Bugün bu terimi, kötü niyetli olarak bilgisayarlara giren ve verileri çalan veya yok eden birini tanımlamak için kullanıyoruz. Bugünün hacker'ı bir vandal, bir suçludur. Ama her zaman böyle değildi. Kelime 1980'lerde ve 1990'ların başında ortaya çıktığında, karmaşık, karmaşık sorunları akıllı, zekice, basit yöntemlerle çözebilen ve kodda zarif, güzel çözümler üretebilen birini ifade ediyordu. Yani kod sanatçılarına hayranlık duyduğumuz bir dönem vardı.
Önerilen editoryal içerik
İzniniz doğrultusunda harici bir YouTube videosu (Google Ireland Limited) buraya yüklenecektir.
Her zaman YouTube videolarını yükle
YouTube videosunu şimdi indirin
Yazılım geliştirme sanat değildir
Knuth'un anıtsal eserinin ismine tekrar bakarsanız şunu fark edeceksiniz: Adı “The Sanat “Bilgisayar Programcılığı”, sadece “Bilgisayar Programlama” veya benzeri bir şey değil. Bu “sanat” ile ilgilidir, yani Sanat programlama. Ve Knuth aslında bunun bu şekilde anlaşılmasını istiyor çünkü birçok kez programlamayı örneğin müzik bestelemek veya şiir yazmakla karşılaştırdı ve bunların hepsinin güzelliğin yaratıldığı estetik deneyimler olduğunu söyledi. Ben kişisel olarak kod yazmayı bu perspektiften düşünmeyi şaşırtıcı buluyorum.
Bir 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, o zaman bu genellikle sanatla ilgili değildir. Bunu, diğer şeylerin yanı sıra, kendimizi çevreleyen terimlerde çok çabuk fark ediyorsunuz: bu yazılımla ilgili.Mühendislikbu yazılımla ilgiliFabrikalarBT şu şekilde mevcuttur: Mühendislik bilimleri öngörülebilir, planlanabilir ve deterministik olmalıdır. Başka bir deyişle, bu sanatsal açıdan yaratıcı bir bakış açısından o kadar uzak ki şaşırtıcı (veya bakış açınıza bağlı olarak korkutucu).
O zaman şu soru kendiliğinden ortaya çıkıyor: Kim haklı? Gerçekten bilgisayar bilimi nedir? Bütün bunların özü ve özü nedir?
Sektöre bakıldığında yolculuğun nereye doğru gittiği görülüyor: Test mi? Çoğunlukla hariç tutulurlar, gereksiz yere maliyetlidirler ve o kadar da önemli değildirler. Daha az testle daha ucuz yazılım alabileceğinizi hepimiz biliyoruz. Belgeler? Kimsenin buna ihtiyacı yok, bu sadece paraya ve daha da önemlisi zamana mal oluyor. Kodu temizle? Gerçekten mecbur kalırsak belki haftada bir yeniden düzenleme çalışması yapabiliriz, ancak bundan sonra yeni özellikleri tekrar yazmanız gerekecek çünkü sonuçta müşteri temiz kod için para ödemez. Müşteri genelde koda para ödemiyor, hiç umursamıyor. Gerçekte müşteri bunun yerine, bir sorunu pragmatik ve verimli bir şekilde çözmemiz için bize para ödüyor. Ve bunu bir tornavidayla değil kodla yapıyor olmamız, en iyi ihtimalle ikincil bir noktadır.
70.000 satırlık PHP kodu
Tüm bunların şaşırtıcı yanı işe yaramasıdır. Birkaç yıl önce büyük bir şirkette yönetim kurulu için analiz yazılımı üzerinde tek başına çalışan biriyle tanıştım. Onun kodu (ve bu hikaye gerçektir, şaka değildir) tek bir (!) dosyada 70.000 satırlık PHP kodundan oluşuyordu. Tek bir otomatik test, otomatik dağıtım, CI/CD hattı veya buna benzer bir şey yoktu. Sürüm yönetimiyle bile çalışmadı, ancak VI'yı kullanarak üretim sunucusundaki tek PHP dosyasını doğrudan düzenledi.
Ve aslında bunun iyi bir şey olduğunu düşündü, çünkü saatlerce süren düzenlemenin ardından nihayet bu dosyayı kaydettiğinde, uygulama hemen yeniden dağıtıldı. En kötüsü de parçası olduğu ekipte açık ara en istikrarlı ve güvenilir yazılımı yazan kişinin kendisi olmasıydı. Tüm bunların pastanın kreması: PHP betiğine birden fazla sembolik bağlantı aracılığıyla erişilebiliyordu ve ismine bağlı olarak farklı davranıyordu. Yönetim kurulu onu seviyordu ama takımdaki herkes ne zaman tatile çıksa ya da hastalansa ona küfrediyor ve ona titriyordu.
Farklılık nereden kaynaklanıyor?
O zamanlar bu ekip için yaptığım harici bir danışman olarak, iyi kod kalitesi için iletmek istediğiniz birim testi, entegrasyon testi, statik kod analizi, sürüm yönetimi, kapsayıcıya alma gibi tüm en iyi uygulamalarla oradasınız. sürekli entegrasyon, sürekli dağıtım vb. ve size her şeyin yolunda olduğu ancak her şeyin mükemmel çalıştığı ve mevcut prosedürdeki herhangi bir şeyi değiştirmenin yalnızca kesintiye neden olacağı söylenir.
Ve bu vizyon bir yandan beni ne kadar rahatsız etse de, diğer yandan da itiraf etmeliyim: evet, üretim sunucusundaki 70.000 satırlık PHP koduyla temel sorunu çözdü ve anakarta istediklerini güvenilir bir şekilde sağladı. ve zamanında Numaralar teslim edildi. Önemli olan da buydu (en azından belli bir bakış açısından). Ancak bu hikayeyi anlattığımda, “Vay canına, bu harika! Bundan sonra bunu yapacağız!” diyen (geliştirici veya yönetici olsun) hiç kimseyle tanışmadım.
Çünkü sonuçta herkes kalite vb. açısından daha fazla güvenilirliğe sahip olmak istiyor, özellikle de her konferansta, her toplantıda, her blogda veya YouTube'da, hatta benim gibi insanlar tarafından bile söylenen bu olduğu için. Ancak şunu da kabul etmeliyim ki, yalnızca sorunu çözmeye yönelik pragmatizmin ve kalkınmanın a priori göz ardı edilemeyeceği. Verimlidir. Ama neden kimse bunu önermiyor? Bu tutarsızlık nereden geliyor?
Sanat ve iş dünyası
Sonuçta bunun iki karşıt bakış açısının çarpışmasından kaynaklandığına inanıyorum: sanatın iş ile buluştuğu yer burasıdır. Ve sonuçta bilgisayar bilimi aynı anda her ikisidir; Bu ikiliğin etkilerini günlük yaşamda sürekli yaşıyoruz, çünkü her gün bu iki dünyanın ve bu iki bakış açısının çatıştığı sürtünme noktaları oluyor. Bir efor tahmini sağlamanız gerektiğinde başlar. Ben şahsen her zaman kendi kendime şunu düşünürüm: “XY'yi yapmamın ne kadar süreceğini ne kadar zaman biliyorum?”
Sonuçta buna yazılım denirgelişim ve yazılım değilüretme, ve eğer görevi zaten aynı şekilde veya en azından benzer bir şekilde daha önce tamamlamış olsaydım, çabayı tam olarak tahmin edebilirdim, ancak daha sonra kodu önceki uygulamadan kopyalayabilirdim ve onu tekrar geliştirmek zorunda kalmayabilirdim. Ve bu sadece ben için değil, birçok geliştirici için de aynı; bu yüzden kişisel olarak efor tahmininin nispeten işe yaramaz olduğunu düşünüyorum.
Sonuçta, bir geliştiriciden bir çaba tahmini istemek, Picasso'ya bir timsah resmi yapmasının ne kadar süreceğini tahmin edip edemeyeceğini sormak gibidir; sonuçta onun dachshund'unun resmi sadece bir satırdı ve en fazla beş dakika sürebilirdi. . Ama gerçek şu ki, sanat takdir edilemez. Tam tersine, iş hayatında plan yapabilmek ve sonuçları görmek istediğinizi de anlayabiliyorum: Bir ev inşa ederken, kaba sıvanın henüz bitmediğini hissetmek istemiyorum çünkü “ustanın eli” henüz bitmedi” Bir haftaya doğru kişi değildim “Malayı kullanmak için doğru ivmeyi ve ilhamı bulun”.
Bir merdiven gerekli
Ancak bu iki bakış açısı aynı zamanda iki uçtur ve her zaman olduğu gibi iki uç olduğunda kutupların arasında da bir şeyler vardır. Demek ki sonuçta meselenin bir ölçüsü var. Bir yanda yazılım ve kodu başlı başına bir amaç olarak gören saf sanat, deyim yerindeyse “l'art pour l'art” var. Terazinin diğer ucunda, sorunları olabildiğince verimli ve ucuz bir şekilde çözmek ve (dikkat edin, kelime oyunu yapmak niyetiyle) yapay olmamakla ilgili olan tamamen pragmatik iş vardır. Kod ve yazılım tamamen amaca yönelik bir araçtır.
Gerçeğin ortada olduğundan şüpheleniyorum, çünkü uygulama olmadan sanat fildişi kulesinden çıkamaz. Ama sanatsız uygulamanın ruhu yoktur. Ve en önemli soru şu: Bu ölçeğin neresindesiniz?
İnanıyorum ki, daha fazla geliştirici bu soru hakkında düşünse ve kendileri için bir bakış açısı tanımlasa ve şirketler de aynısını yapıp birbirlerinin değer sistemi hakkında konuşsa, o zaman gelişme çok daha iyi ve sorunsuz ilerleyebilir, çünkü daha az çatışma olur. ve gelişimin doğası hakkındaki yanlış anlamalar.
Ve sonra yazılım geliştirme tam da bu hale gelebilir: sanat değil.
(kendim)