Büyük “açık kod” uygulamalarından uzak kodlara sahipken büyük açık kaynak kodlu kütüphaneler nasıl korunur?

Hala yüksek kaliteli kod yazma konusunda deneyimsizim, bu yüzden Robert C. Martin tarafından Temiz Kod gibi konulara yönelik kitapları okudum ve becerilerimi geliştirmek için iyi bilinen kütüphanelerin kodlarını kontrol etmeye devam ediyorum.

Birçok açık kaynak kütüphanesi yıllarca korunmasına rağmen, doğru yolda olmadıklarının çok düşük olmaları anlamına gelir, çoğu koddaki kodları temiz kod yazma ilkelerinden uzak buldum - örn. yüzlerce kod satırı.

Öyleyse sorum şu: Temiz kodun ilkeleri çok kısıtlı mı ve bunlar gibi birçok kütüphanede onlarsız yapabiliriz? Olmazsa, büyük kütüphaneler bu ilkeleri göz önünde bulundurmadan nasıl korunurlar?

Kısa bir açıklama için teşekkür edeceğim. Soru acemilerden birinin aptal göründüğü için özür dilerim.

DÜZENLE

Bu kontrol örneği de BUTTERKNIFE kütüphanesinde - Android topluluğunda en iyi bildiği kütüphanelerinden birine.

Burada zaten iyi bir cevap, ancak butterknife örneğiniz hakkında bir şey söyleyeyim : kodun ne yaptığı hakkında hiçbir fikrim yok, ancak ilk bakışta, bu benim için gerçekten anlaşılmaz görünmüyor. Değişkenler ve yöntem adları bilerek seçildi, kod uygun şekilde girintili ve biçimlendirilmiş, bazı yorumlar ve uzun yöntemler en azından bazı blok yapılarını gösteriyor.

Evet, Bob Amca'nın "temiz kodu" kurallarına uymuyor ve yöntemlerin bazıları çok uzun (muhtemelen tüm sınıf). Ancak koda bakarken hala yeterince yapı görüyorum, böylece bu blokları kendi başlarına yöntemlere ekleyerek kolayca "temizlenebilir" (yeniden düzenleme araçlarını kullanırken hata yapma riski düşük).

Bu kodla ilgili asıl sorun, bir blok, bir başka blok ve bir başka blok eklenmesi, bazen yıllar boyunca bir dereceye kadar işe yaramaktadır. Ancak, kodun her gün biraz gelişmesi zorlaşıyor ve değiştirilmesi ve test edilmesi biraz daha uzun sürüyor. Ve “başka bir blok ekleyerek” çözülemeyen bir şeyi gerçekten değiştirmeniz gerekiyorsa, ancak yeniden yapılandırılması gerekiyorsa, o zaman birinin daha erken kodu temizlemeye başlamasını isteyeceksiniz.

"Temiz Kod" da belirtilen prensipler her zaman genel olarak üzerinde anlaşmaya varılmaz. Çoğu sağduyulu, ancak yazarın bazı görüşleri oldukça tartışmalı ve herkes tarafından paylaşılmıyor.

Özellikle, kısa yöntemlerin tercihine herkes tarafından karar verilmez. Daha uzun bir yöntemdeki kod başka bir yerde tekrarlanmazsa, bir kısmını ayrı bir yönteme çıkarmak (bu nedenle birden fazla kısa yöntem elde etmek), genel karmaşıklığı artırır, çünkü bu yöntemler artık bunları önemsememesi gereken diğer yöntemler için görülebilir. Dolayısıyla bu bir takas, objektif bir gelişme değil.

Kitaptaki tavsiyeler ayrıca (tüm tavsiyeler gibi) belirli bir yazılım türüne yöneliktir: Kurumsal uygulamalar. Oyunlar veya işletim sistemleri gibi diğer yazılım türlerinin kurumsal yazılımlardan farklı kısıtlamaları vardır, bu nedenle farklı desenler ve tasarım ilkeleri kullanılmaktadır.

Dil aynı zamanda bir faktördür: Clean Code, Java ya da benzer bir dili varsayar - C veya Lisp kullanıyorsanız, bu tavsiyelerin çoğu geçerli değildir.

Kısacası, kitap belli bir yazılım sınıfı hakkında görüşlerini açıklayan tek kişidir. Her yere uygulanmaz.

Açık kaynaklı projelere gelince, kod kalitesi berbattan zekice değişiyor. Sonuçta, herkes kodunu açık kaynak olarak yayınlayabilir. Ancak, birden fazla katkıda bulunanla birlikte olgun ve başarılı bir açık kaynaklı projeye bakarsanız, bilinçli olarak onlar için işe yarayan bir tarza yerleştiğinden emin olabilirsiniz. Eğer bu tarz bir fikre veya kılavuza aykırıysa, (açık şekilde söylemek gerekirse) çalışma kodu fikirleri trump ettiğinden yanlış veya alakasız bir kılavuzdur.

özet

JacquesB'nin yazdığı gibi, herkes Robert C. Martin'in “Temiz Kodu” ile aynı fikirde değildir.

Beklediğiniz ilkeleri “ihlal ettiğini” belirlediğiniz açık kaynaklı projeler, muhtemelen başka ilkelere sahip olacak gibi görünüyor.

Benim bakış açım

Robert C. Martin'in ilkelerine çok bağlı birçok kod üssünü denetliyorum. Ancak, gerçekten haklı olduklarını iddia etmiyorum , sadece bizim için iyi çalıştıklarını söyleyebilirim - ve "biz" aslında en azından ...

• Ürünlerimizin kapsamı ve mimarisi,
• hedef pazar / müşteri beklentileri,
• ürünlerin ne kadar süreyle tutulduğu,
• kullandığımız geliştirme metodolojisi,
• Şirketimizin organizasyon yapısı ve
• geliştiricilerimizin alışkanlıkları, görüşleri ve geçmiş deneyimleri.

Temel olarak, bu aşağı kaynar: Her takım (bir şirket, bir departman veya açık kaynaklı bir proje olabilir) benzersizdir. Farklı öncelikleri ve farklı bakış açıları olacak ve elbette farklı değişimler yapacaklar. Bu değişimler ve sonuçta ortaya koydukları kod tarzı büyük ölçüde bir zevk meselesidir ve "yanlış" veya "doğru" olduğu kanıtlanamaz. Ekipler sadece "bunu bizim için çalıştığı için yapıyoruz" veya "bunu bizim için çalışmadığı için değiştirmeliyiz" diyebilirler.

Bununla birlikte, büyük kod tabanlarını yıllar boyu başarıyla koruyabilmem için, her ekibin yukarıda belirtilen hususlara uygun olduğunu düşündükleri bir dizi kod sözleşmesi konusunda hemfikir olduğuna inanıyorum. Bu, Robert C. Martin tarafından uygulamaları başka bir yazar tarafından benimsemek veya kendi icatlarını kullanmak anlamına gelebilir; onları resmi olarak yazmak veya "örnek olarak" belgelemek anlamına gelebilir. Ama var olmalılar.

Örnek

"Kodu uzun bir yöntemden birkaç özel yönteme bölme" pratiğini düşünün.

Basitleştirilmiş bir örnek olarak, bir kamu yöntem muhtemelen yalnızca gibi özel yöntemlere çağrılar oluşacak - Robert C. Martin bu tarz soyutlama biri düzeyine her bir yöntemin içeriğini sınırlamak için izin verdiğini söylüyor verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)ve son olarak sendJsonToClient(...), ve bu yöntemler olurdu uygulama detayları.

• Bazı insanlar böyledir, çünkü okuyucular yüksek seviyeli adımlara hızlı bir şekilde göz atabilir ve hangi ayrıntıları okumak istediklerini seçebilir.
• Bazı insanlar bundan hoşlanmaz, çünkü tüm detayları bilmek istediğinizde, sınıfın içinde yürütme akışını takip etmek için atlamak zorunda kalırsınız (bu, JacquesB'nin karmaşıklık eklemek için yazdığı zaman bahsettiği şeydir).

Ders şudur: hepsi haklıdır, çünkü fikir sahibi olma hakkına sahiptirler.

Açık kaynak kodlu kitaplıkların çoğu aslında nesnel olarak zayıf kodlama uygulamalarından muzdariptir ve kodun en sık tuttukları kısımları çok iyi bildikleri için zayıf okunabilirlikle başa çıkabilecek küçük bir uzun vadeli katılımcı grubu tarafından zorluklarla karşılanmaktadır. . Gerçekten sonra okunabilirliği artırmak için kodu yeniden düzenlemek genellikle Herkül'ün bir çabasıdır çünkü herkes aynı sayfada olmak zorundadır, eğlenceli değildir ve yeni özellikler uygulanmadığı için ödeme yapmaz.

Başkalarının söylediği gibi, herhangi bir şeyi belirten temiz kod hakkındaki herhangi bir kitap, mutlaka evrensel olarak üzerinde anlaşmaya varılmayan tavsiyeler içerir. Özellikle, hemen hemen her kural, okunabilirlik problemini bir başkasıyla değiştirerek aşırı bir gayretle izlenebilir.

Şahsen, eğer onlar için iyi bir isme sahip değilsem, adlandırılmış işlevler oluşturmaktan kaçınırım. Ve iyi bir isim kısa olmalı ve fonksiyonun dış dünyaya ne yaptığını sadık bir şekilde tanımlamalıdır. Bu aynı zamanda mümkün olduğunca az fonksiyon argümanına sahip olmaya ve dünya çapında yazılabilir bir veriye sahip olmaya çalışmakla da bağlantılıdır. Çok karmaşık bir işlevi daha küçük işlevlere bölmeye çalışmak, genellikle işlev gerçekten karmaşık olduğunda çok uzun argüman listelerine neden olur . Okunabilir kodu oluşturmak ve sürdürmek, birbiriyle çelişen sağduyulu kurallar arasındaki dengede bir alıştırmadır. Kitap okumak iyidir, ancak yalnızca deneyim size gerçek okunabilirliğin kazanıldığı yanlış karmaşıklığı nasıl bulacağınızı öğretecektir .

Açık kaynaklı projelerin çoğu kötü yönetiliyor. Açıkçası bunun istisnaları var, ancak açık kaynaklı dünyada çok fazla önemsiz bulacaksınız.

Bu, projelerinden bahsettiğim tüm proje sahiplerinin / yöneticilerinin eleştirisi değildir, sadece zaman meselesidir. Bu insanlar, gerçek ücretli işlerinde olduğu gibi zamanlarıyla ilgili daha iyi şeylere sahipler.

Başlangıçta kod bir kişinin işidir ve muhtemelen küçüktür. Küçük kodun da temiz olması gerekmez. Ya da kodu temizlemek için gereken çaba faydadan daha büyüktür.

Zaman geçtikçe, kod birçok farklı insan tarafından daha çok yamalar yığınıdır. Yama yazarları kodun sahipliğini hissetmiyor, yalnızca bu özelliğin eklenmesini veya bu hatayı en kolay şekilde düzeltilmesini istiyorlar.

Sahibi, işleri temizlemek için zamana sahip değil ve kimsenin umrunda değil.

Ve kod büyüyor. Ve çirkin.

Kod içinde yolunuzu bulmak gittikçe zorlaşırken, insanlar yanlış yere özellikler eklemeye başlarlar. Ve hataları düzeltmek yerine, koddaki diğer yerlere geçici çözümler eklerler.

Bu noktada, sadece insanların umrunda değil, bir şeyleri parçalamaktan korktukları için artık temizlik yapmaya cesaret edemiyorlar .

Kod üslerini "zalim ve sıradışı ceza" olarak tanımlayan insanlar oldu.

Kişisel deneyimlerim o kadar kötü değil, ama çok garip şeyler gördüm.

Bana öyle geliyor ki, kimse yapması gerekeni yapmıyorsa , bu işlerin nasıl yürüdüğünü soruyorsunuz . Eğer işe yararsa, neden böyle şeyler yapmamız gerekiyor ?

Cevap, IMHO, “ daha kötüsü daha iyi ” felsefesi olarak da bilinen “yeterince iyi ” çalışıyor . Temel olarak, açık kaynak ile Bill Gates arasındaki kayalık tarihe rağmen, ikisi de fiili olarak aynı fikre sahipti, çoğu insanın hatalara değil, özelliklere önem verdiğini de kabul etti .

Bu tabii ki de bize gösterdiği " sapma normalleştirme gibi durumlara yol açar" Heartbleed soru, kitlesel, cevap kesin sanki, büyümüş spagetti yığını olarak adlandırılan açık kaynak kod OpenSSL gitti " temizlenmemiş gibi bir şey için" on yıl bir ile sarma masif güvenlik kusur etkileyen milyonlarca insanın binlerce .

Solüsyon denilen yepyeni bir sistemi icat etmekti LibreSSL edildi temizlik imsi kodunu kullanacağız ve tabii ki neredeyse kimse bunu kullanır .

Peki kötü kodlanmış büyük açık kaynaklı projeler nasıl korunur? Cevap soruda. Bir çoğu temiz durumda tutulmaz. Onlar edilir rastgele yamalı tarafından farklı binlerce insan kapsayacak şekilde çeşitli garip makinelerde kullanım durumları ve durumlar geliştiriciler üzerinde test etmek erişime sahip olmadı. Kod "yeterince iyi" çalıştığını kadar öyle değil , herkes panikler ve karar verdiğinde sorun para atmak .

Öyleyse , başka kimse yoksa neden “ doğru şekilde ” bir şey yapmakla uğraşmıyorsunuz ?

Cevap, yapmamalısın. Ya yaparsın ya da yapmazsın , ve dünya ne olursa olsun dönmeye devam eder , çünkü insan doğası insan yaşamı ölçeğinde değişmez . Şahsen ben sadece temiz kod yazmaya çalışıyorum çünkü yapmaktan hoşlanıyorum.

İyi kodu oluşturan şey içeriğe bağlıdır ve sizi yönlendiren klasik kitaplar, açık kaynak tartışmak için çok yaşlı değilse de, kötü kurum içi kod tabanlarına karşı devam eden savaşı yöneten bir geleneğin en azından bir kısmıdır. Bu nedenle kütüphanelerin tamamen farklı amaçlara sahip olduğu gerçeğini göz ardı etmek kolay ve buna göre yazılmışlar. Aşağıdaki hususları özel bir sıra ile düşünmeyin:

• Bir kütüphaneyi veya bir kütüphaneden içe aktarırken, muhtemelen üzerinde çalıştığım şey için neye ihtiyaç duyduğumda, alet takımının tam olarak ne kadar küçük bir kısmını ihtiyaç duyduğumu bilmek için iç yapısında uzman değilim. Stack Exchange cevabı yapmamı söyledi. Bu yüzden yazmaya başladım from A import(Python ise, söyleyin) ve ne olduğunu görün. Ancak listelediğim gördüğüm şeyin ödünç almam gereken mantıksal görevleri yansıtması ve kod tabanında olması gerektiği anlamına geliyor. Bunu kısaltan sayısız yardımcı yöntem sadece kafamı karıştırır.
• Bazı kişilerin algoritmasını kullanmaya çalışan en yeteneksiz programcılar için kütüphaneler var, çoğu insan sadece belli belirsiz duyuyor. Dış belgelere ihtiyaçları var ve bu, kısa yöntemi ve bir şeyi yapanları mutlu etmek için her şeyi yeniden düzenlemeye devam edersek yapamayacağımız kodu tam olarak yansıtması gerekiyor.
• İnsanların ödünç aldığı her kütüphane yöntemi, ele geçirilse veya hatta yeniden adlandırıldığında, felaket sonuçlarla dünyayı kodlayabilir. Tabii, Sklearn'ün Calinski-Harabasz'daki yazım hatasını düzeltmesini diliyorum , ancak bu başka bir sol-sol olayına neden olabilir . Aslında, benim deneyimlerime göre, kütüphane evrimi ile ilgili en büyük sorun, her şeyi nasıl yapılandırdıklarına ilişkin bazı iyi kodlu yeni bir "iyileştirme" benimsemek için çok çaba sarf etmeleridir.
• Kurum içi, yorumlar büyük ölçüde en azından gerekli bir kötülüktür, her türlü nedenden dolayı yetersiz kalmamamı gerektiriyor (bu noktalar biraz abartıyor olsa da). İyi bir yorum kodun neden çalıştığını değil nasıl çalıştığını söylüyor. Ancak kütüphaneler, okuyucularının, bir kağıt poşetten çıktıkları şekilde lineer cebir yazamayan yetenekli programcılar olduğunu biliyorlar. Başka bir deyişle, her şeyin yeniden yorumlanması gerekir: neden işe yarıyor! (Tamam, bu başka bir abartıdır.) Bu yüzden, imza satırını, 100 satır yorum bloğunu, tam anlamıyla imza satırına gidebilecek 1 satır kod (tabii ki izin verilir) görüyorsunuz.
• Diyelim ki Github hakkında bir şeyler güncelleyin ve kodunuzun kabul edilip edilmeyeceğini görmek için bekleyin. Kod değişikliğinin neden işe yaradığı açık olmalıdır. Kamp alanını işlevsel bir taahhüdün bir parçası olarak daha temiz hale getirmek için yapılan yeniden yapılanmanın, maaşsızlık hakeminin işini zorlaştıran ve diğer sorunlara neden olan çoğu zaman tasarruf etme, yeniden düzenleme ve yeniden adlandırma anlamına geldiğini biliyorum.

Eminim benden daha fazla deneyime sahip insanlar diğer noktalardan bahsedebilir.

Çok sayıda iyi cevap var - Açık kaynak kodlu bir bakıcının bakış açısını vermek istiyorum.

Benim bakış açım

Büyük kodlardan daha az bu tür projelerin sahibiyim. Bazen kütüphaneler her hafta milyonlarca kez indirildiğinden uyumluluk kaygıları nedeniyle bu kodu geliştirmem bile engelleniyor.

Node.js çekirdek üyesi olarak kodun bir kısmını dokunmaktan korktuğum kısımlar var ama ne olursa olsun yapacak çok iş var ve insanlar platformu başarıyla kullanıyor ve bundan zevk alıyor. En önemli şey işe yarıyor olmasıdır.

Okunabilir kodunda

Dediğinde:

Kodun birçoğunda temiz kod yazmanın prensiplerinden uzak olduğunu gördüm - örneğin yüzlerce kod satırı içeren yöntemler.

Kod satırları, ne kadar okunabilir olduğunun büyük bir ölçütü değildir . Linux çekirdeğine bağlanan çalışmada, bir programcı araştırması "normal" kod (insanların temelde beklediği kod) ve tutarlı kodun "temiz" koddan anlaşılabilirlikte daha iyi olduğunu saptadı. Bu aynı zamanda kişisel deneyimlerime de uyuyor.

Bazı açık kaynaklı projeler çok hoş karşılanmıyor

Linus "ünlü olarak" , linux'un yerleşik bir hata ayıklayıcıya sahip olmaması gerektiğini çünkü hata ayıklayıcıları kullanan kişilerin linux üzerinde çalışmak için yeterince iyi olmadıklarını ve daha fazla çekmek istemediklerini söyledi.

Şahsen ben kesinlikle orada duruşuna katılmıyorum - ama aynı zamanda insanların yaptığı bir şey.

Açık kaynaklı yazılım mutlaka birden fazla yazarın dahil olduğu anlamına gelmez. Bir yazılım (veya yazılım birimi) tek bir yazar tarafından yazıldığında, uzun işlevler sıklıkla görünür.

Bu gelişme sürecinin doğasından gelir. Basit bir yöntem zamanla genişletilir, yeni özellikler eklenir ve hatalar giderilir.

Uzun yöntemler, yeni yazarlar için işlevsellik anlayışını ciddi şekilde azaltır. Ancak, tek bir yazar ile bu nadiren bir problemdir ve problem göz ardı edilme eğilimindedir. Açık kaynağın bir başka özelliği, birçok yazılımın aktif olarak geliştirilmemesidir, bu nedenle, örneğin karmaşık yöntemleri çoklu basit yöntemlere bölen yeniden düzenleme çalışması yoktur.

Herhangi bir örnek göstermediniz ama benim anladığım kadarıyla bu aynı zamanda geliştirme diliyle de bağlantılı. Bazı diller, başlangıç ​​ve ağır ünite testlerinden (hatta TDD'den) katı kural koyma kuralları uygular. Hem astarlama hem de ünite testleri genellikle bu sorunu önler (karmaşık / uzun metotlar için ünite testi zordur).

Genel olarak, yazılım tek bir yazar tarafından geliştiriliyorsa ve diğer katılımcılar yalnızca küçük sorunları düzeltirse, kodu temizlemek daha zordur.