Kod tutarlılığı ve kod geliştirme arasındaki doğru denge nedir?

Son zamanlarda bir meslektaşımla kod tarzı hakkında bir tartışma yaptım. API kullanmanızın ve kullandığınız genel kalıpların, kod kodunun tamamı olmasa bile, kod görünümüyle (kodlama konumlandırma, büyük harf vb.) Yaptığınız gibi, çevre koduyla mümkün olduğu kadar benzer olması gerektiğini savunuyordu. . Örneğin, C #'daki bir DAO sınıfına bir yöntem ekliyor olsaydım, bu sınıftaki diğer yöntemlerden hiçbiri kullanmasa bile kodumu temiz ve bakımı kolay hale getirmek için uygun olan yerlerde LINQ kullanmaya çalışırdım. Ancak meslektaşım, bu durumda kullanmamam gerektiğini çünkü o sınıfın mevcut tarzına aykırı olacağını ve böylece anlaşılmasının zor olacağını savunuyordu.

İlk başta pozisyonunu oldukça uç buldum, fakat bir süre düşündükten sonra amacını görmeye başladım. Varsayımsal LINQ örneğinde, belki de bu sınıf onu içermiyor çünkü meslektaşlarım LINQ’a yabancı. Eğer öyleyse, kullanmamış olsam kodum geliştiricilerim için daha sürdürülebilir olmaz mıydı? Öte yandan, böyle bir tekniğin kullanılmasının daha temiz kodla sonuçlanacağına gerçekten inanıyorsam, onu çevre kodundan çok farklı olsa bile kullanmamalı mıyım?

Bence meslektaşımın argümanının özü, hepimiz benzer bir işlevi bir kod tabanında farklı şekillerde uygulamaya devam edersek ve her birimiz yolumuzun "en iyi" olduğunu düşünürsek, sonunda kodun bir bütün olarak zorlaştığını düşünüyoruz. anlamak. Ancak şu anda hala mevcut kodu çok fazla takip edersek kalitenin zamanla yavaşça çüreceğini düşünüyorum.

Öyleyse, kalıplar kod stilinin ne derece parçasıdır ve tutarlı kalmak ve iyileştirmeler yapmak arasındaki çizgiyi nereye çekmeliyiz?

Daha genel bir cevap vermek için:

Böyle bir durumda, birbirinize zıt olan iki programlama "en iyi uygulaması" vardır: kod tutarlılığı önemlidir, ancak görevinizi yerine getirmek için mümkün olan en iyi yöntemi seçmek de önemlidir. Bu ikileme tek bir doğru cevap yok; birkaç faktöre bağlıdır:

• "Doğru" yol ne kadar faydalı?

  • Bazen yeni ve geliştirilmiş en iyi uygulama performansı önemli ölçüde artıracak, hataları ortadan kaldıracak, programlanması çok daha kolay, vb. Olabilir. Böyle bir durumda, yeni yöntemi kullanmaya yoğun bir şekilde eğilirim. Öte yandan , "doğru yol", sözdizimsel şekerden biraz daha fazla olabilir, ya da gerçekten üstün olmayan bir şeyi yapmanın kararlaştırılmış bir deyimsel yöntemi olabilir. Bu durumda, kod tutarlılığı muhtemelen daha önemlidir.

• Bir problemin ne kadar büyük tutarsızlığı yaratır?

  • Yeni kodun eski kodla bağlantısı nedir? Yeni kodunuz bir kütüphanenin parçası mı? Programın birçok yerine geçen bir nesne yaratıyor mu? Bu gibi durumlarda tutarlılık çok önemlidir. Yeni bir API veya genel olarak bir şeyler yapmanın yeni bir yolunu kullanmak, programınızın herhangi bir yerinde varsayımları ihlal eden çok farklı sonuçlar yaratabilir. Öte yandan , oldukça yalıtılmış bir kod yazıyorsanız, tutarsızlığın bir sorun olma olasılığı daha düşüktür.
  • Kod tabanınız ne kadar büyük ve ne kadar olgun? Kaç geliştiricinin bunu anlaması ve üzerinde çalışması gerekiyor? Kabul edilmiş, tutarlı standartlar daha büyük projeler için çok daha önemlidir.
  • Kodun, en yeni özellikleri desteklemeyen eski ortamlarda çalışması gerekiyor mu?

Bu sorunların dengesine dayanarak, hangi rotanın seçileceği konusunda doğru seçimi yapmanız gerekir. Tutarlılık uğruna tutarlılık konusunda kişisel olarak çok az değer görüyorum ve bunu yapmak için önemli bir maliyet olmadıkça en son, en iyi yöntemleri kullanmayı tercih ediyorum.

Elbette, üçüncü bir seçenek var: mevcut kodu en iyi yöntemleri kullanması ve tutarlı olması için yeniden yazmak . Bunun gerekli olduğu zamanlar vardır, ancak bunun maliyeti yüksektir.

Tutarlı kalmak, benim bakış açımda çok az değere sahip; Sürekli iyileştirmeler yapmak şarttır.

Meslektaşınızın pozisyonu gerçekten inovasyonu engelliyor. Tutarlılık argümanı sizi, örneğin tüm kodları LINQ kullanmak için geçirirseniz LINQ kullanabileceğiniz bir duruma götürür . Ve bunun için zamanımız yok, değil mi?

Bazı kodların hala foreachArrayLists üzerinde yaptığı yerlerde tutarsızlığa sahip olmayı tercih ediyorum ve diğer bölümler IEnumerable<T>zamanın sonuna kadar işleri yapmanın en eski yoluna bağlı kalmak yerine LINQ kullanıyor .

İlgili kalmak ve yeni şeyler yapmanın yeni yollarını öğrenmek meslektaşlarınızın sorumluluğundadır.

API tutarlılığı, hem genel hem de dahili API'ler için çok önemlidir.

Kod biçimlendirme tutarlılığı önemlidir ve ideal olarak herkes için aynı biçimlendirme kurallarına sahip otomatik biçimlendirme aracıyla uygulanmalıdır. Paylaşılan sürüm kontrollü kod temeli ile yaşamayı kolaylaştırır.

Adlandırma kuralları, yerel değişkenler vb. İçin de tutarlı olmalıdır.

Statik analiz araçları bazı diğer sözleşmeleri ve iyi uygulamaları zorlamak için kullanılmalıdır (ancak bu tür bir aracın varsayılanlarını kör bir şekilde takip etmeyin, varsayılanlar bazen delice sınırlanabilir), ancak bir şey isterse bazılarını devre dışı bırakmaktan korkmayın haklı çıkarabilirseniz, geçici olarak (bir yorum içinde bir direktif ile) kontrol edin.

Ne olur iç işlevleri / yöntemleri dışında yukarıda listelenen kadarıyla, sürece kendi başına iyi bir koddur olarak, herhangi bir şekilde tutarlı olması gerekmez . İyi, anlaşılabilir, iyi yorumlanmış kod çok önemlidir, ancak bundan sonra, derleyici ve statik analiz araçları tutarlı bir kod olduğunu düşünüyorsanız, bu yeterli tutarlıdır.

LINQ (yeni, tam olarak yeni değil) gibi yeni dil özellikleri hakkında, göz önünde bulundurulması gereken tek şey , kodun kullanılacağı her yerde, dil / kitaplıkların yeterince yeni sürümünün kullanılması mı olacak? Şüphe durumunda, uyumlu olduğu bilinen özelliklere bağlı kalın. Bu elbette sistem genelinde sürüm yükseltmesini zorlamanıza engel olmaz, böylece yeni güzel şeyleri kullanmaya başlayabilirsiniz.

Kodla çalışan her geliştirici güncel kalmalıdır, bu nedenle herhangi bir .NET geliştiricisi LINQ'yi bilmeli ve eğer istemezlerse öğrenmeye zorlanmalı, kendi iyilikleri için (ne zaman yeni bir şey arayacağınızı asla bilemezsiniz) bu işte çalışmak, bir nedenden ötürü.

Bunun cevabı basittir.

Tutarlılık çok önemlidir.

ama bir ihtarla geliyor ...

Siz ve iş arkadaşınız büyük olasılıkla yanlış tutarlılık türüne takıntılısınız.

Uygulamalar tek kullanımlıktır. Test takımının kalitesine ve anlaşılırlığına bağlı olarak çeşitli derecelerde kolaylıkla yenilenebilirler. "Bu bir özellik mi olmalı?" şüpheli değerde. Tüm ölçümleri uygulama seviyesindeki tutarlılık değerine bağlamak zordur. Bu seviyede sorulacak daha iyi bir soru "Bu kod tanıtıldığı gibi çalışıyor mu?" TL; DR uygulama tutarlılığı “küçük beyinler” in hobgoblin'leri kullandığı yerdir.

Neden tutarlılık bu kadar önemli değil? Uygulamaların genellikle az sayıda katkısı vardır. Çoğu yöntem yazılır ve bir daha asla dokunulmaz. Kalan koddan iki katkısı olan yöntemlerin sayısı neredeyse kesinlikle çoğunluktur. Bu kalıp adinituma devam ediyor . Bu bağlamda tutarlılık sadece önemli değil. Kuralların raf ömrü oldukça küçükse ( birkaç yıl ) agresif tutarlılıktan kazançlar büyük olasılıkla bir faktör değildir.

Bu, uygulamalarınızda delirmeniz gerektiğini söylemek değildir. Bunun yerine, güzel, temiz, basit bir tasarımın, varsayımsal geleceğiniz için aptal kazan plakası tutarlılık yöntemine göre metottan daha değerli olduğu söylenebilir. Bu bizi gerçek noktaya götürür ...

API'ler tek kullanımlık değildir.

Bunların hepsi API kod seviyesi, web servisleri, SDK'lar vb. Bunlar tutarlı olmalı, GEREKİR. Bu çeşitlilikteki tutarlılıktan elde edilen üretkenlik birçok nedenden ötürü çok büyüktür:

Entegrasyon Testleri:

API'nizi tutarlı tutarsanız entegrasyon testlerinin takımlarını oluşturabilirsiniz. Bu, geliştiricilerin uygulama ayrıntılarını serbestçe değiştirmelerini ve derhal doğrulanmalarını sağlar. Ortak çalışma saçmalıklarını LINQ ile değiştirmek ister misin? Entegrasyon testleri çalışıyor mu? Ayrıca üretime geçmeye hazırlanırken doğrulama sağlar. Bilgisayarlar hızlı olduğu için, tek bir dizüstü bilgisayar sıradan görevleri yerine getiren bin testçinin çalışmasını önceden yapabilir. Kuruluşunuzun çalışan sayısının önemli ölçüde artması esastır.

verimlilik

API'ler tutarlı olduğunda, yalnızca API'nin diğer bölümlerini kullanma hakkında öğrendiklerinizi takip ederek bir API'nin nasıl kullanılacağı hakkında tahminlerde bulunabilirsiniz. Bunun nedeni, API'nin doğal, tutarlı bir "görünüm ve his" sağlamasıdır. Bu, müşterinizin dokümantasyon yoluyla eleme yapmak için daha az zaman harcadığı anlamına gelir. Gemiye binmek daha kolay ve ucuzdur. API'yi geliştiren kişilere daha az soru sorulur. Tutarlılık herkesin kazanmasını sağlar

Bu senaryoda tutarlılık neden önemlidir? Çünkü API'lerin tam tersi uygulama problemleri var. Bunları kullanan insanların sayısı, uygulamalarına katkıda bulunan kişilerin sayısından genellikle daha fazladır. Küçük bir tutarlılıktan elde edilen küçük kazançlar çarpılır ve bu tutarlılığın sağlanmasının maliyetleri itfa edilir.

Sonuç

Tutarlılık pahalıdır. Yüzünde verimliliği düşürüyor. Geliştiricileri kısıtlar ve hayatlarını zorlaştırır. Bir problemi çözme şekillerine, bazen onları optimal olmayan bir yolla çözmeye zorlar. Bu, genellikle anlamadıkları, yanlış gebe kaldıkları veya mahrem olmadıkları (sözleşmeler, daha büyük organizasyonel veya organizasyonlar arası politikalar) nedeniyledir.

Raymond Hettinger, Pycon 2015'teki konuşmasında python programcılarının ekipleri için PEP8 stil rehberinin kullanılmasıyla ilgili bazı mükemmel puanlar aldı. Bir kod parçasında stilistik tutarlılık saplantısının, kod eleştirmenlerinin ciddi mantık ve tasarım kusurlarını özlemesine neden olduğunu gösterdi. Onun hipotezi, stilistik tutarsızlıkları bulmak kolay olduğu için özetlenebilir ; bir kod parçasının gerçek kalitesini belirlemek zordur

Buradaki nokta kritik. Tutarlılığın nerede önemli olduğunu belirleyin ve agresif bir şekilde koruyun. Önemli olmadığı zaman, zamanınızı boşa harcamayın. Tutarlılık değerini ölçmenin nesnel bir yolunu sağlayamıyorsanız (yukarıdaki durumlarda "etkin çalışan sayısı", verimliliğin bir fonksiyonu olarak maliyet) ve getirilerin önemli olduğunu gösteremezseniz, muhtemelen kuruluşunuz.

LINQ hakkında bilginiz yok mu? Eğer öyleyse, kullanmamış olsam kodum geliştiricilerim için daha sürdürülebilir olmaz mıydı?

C # dili hala gelişmektedir. İnsanlar C # 1’deki değişiklikleri öğrenmedilerse, eksik kalacaklar:

• Jenerik
• partials
• Anonim yöntemler
• yineleyiciler
• Null türleri
• Otomatik özellikleri
• Anonim türleri
• Uzatma yöntemleri
• Ling
• Lambda'lar
• Asenkron yöntemler

Bu Vikipedi makalesinde bulunan ortak özelliklerden sadece küçük bir seçimdir. Yaptığım nokta, geliştiriciler öğrenmezse kodbazının boşlukta kalacağıdır. Birincisi, geliştiricilerinizin sürekli olarak iyileştirilmesi ve kod tabanının eksiksiz bir test paketi tarafından desteklenen geliştiğini ummaktır. Özellikleri el ile uygulamanın .NET 1 ile ne kadar kötü olduğunu hatırlıyor musunuz?

Linq hayatı kolaylaştırır. Kullanabildiğin yerde kullan. Takım üyelerinizi motive edebilirsiniz.

Öyleyse, kalıplar kod stilinin ne derece parçasıdır ve tutarlı kalmak ve iyileştirmeler yapmak arasındaki çizgiyi nereye çekmeliyiz?

İyileştirmeler kademeli. Bana göre, daha az okunabilir ve daha az bakım gerektirebilecek eski stil kodunu saklamak mantıklı değil. Takım üyeleriniz en azından ne olduğunu yazabiliyor olsalar bile, ne olduğunu çözebilmeli.

Tutarlı olmalısınız, ancak eski kodla mutlaka değil. Başka bir deyişle, ekibiniz bir şeyler yapmanın doğru yolu üzerinde anlaşmalı ve yeni kod yazıldığında veya önemli değişiklikler yapıldığında bu şekilde kullanılmalıdır.

Bu şekilde, tutarlılığın faydalarının çoğunu elde edersiniz (özellikle kodu kimin yazdığı önemli değildir), ancak takım başka şeyler yaparak net bir fayda görürse, yine de iyileşebilirsiniz.

İdeal bir dünyada, tüm eski kodları yeni doğru yola uyacak şekilde yeniden yazardık. Bu ekonomik olarak uygun olmasa da, teknik anlam ifade etmeli (ya da yeni yol daha iyi bir yol değil) ve uzun vadeli planınız onu geliştirmek olmalıdır. Buna değmiyorsa, yeni yolla uğraşmayın. Başka bir deyişle, onu doğru olarak ilan etmenin yeni yolunun açık bir avantajı olmalıdır.

Bir projede bir kod stili izlemenin önemli olduğunu düşünüyorum, örneğin. adlandırma kuralları, girintiler vb.

Meslektaşlarınızın onları anlamadığı veya projede daha önce kullanılmadığı için yeni dil yapıları veya tasarım kalıplarını kullanmakla sınırlı olmanız konusunda hemfikir değilim.

Elbette, bu şeyleri kullanmak için iyi sebepler olmalı, örneğin uygunsa performans veya kısalık.

Mevcut tasarım kalıplarını takip ederken çok dikkatli davranırdım. Tabii ki, kayda değer bir dezavantajı olmadığında, kişi daima kod tabanındaki benzer modelleri izlemeye çalışmalıdır.

Ancak, geliştiricilerin çoğunluğunun, iyi geliştiricilerin kötü, sürdürülemez kodlar yazdığı durumlara yol açan mevcut kötü kalıpları takip etmenin "en iyi uygulama" olduğunu düşündüğü koşullara girmek çok kolaydır.

Öte yandan, tutarlılık önemlidir. Muazzam kod tabanlarıyla uğraşırken, benzer kalıpları takip etmeye çalışmak son derece kullanışlıdır, böylece geliştiriciler kod tabanının her santimini okumamış olsalar da, ne bekleyeceklerini bilirler.

Bu nedenle, geliştiricilerin mümkünse hangi kalıpları izlemesi gerektiği hakkında kılavuz ilkeler oluşturmanın ve güncellemenin en iyisi olduğuna inanıyorum. Bu şekilde, herhangi bir yeni kod diğer yeni kodlarla tutarlıdır.

Birimizin yapabileceği düzenli, oldukça gayri resmi, teknik toplantılarımız var. Yeni bir teknik bulursak onu toplantıda sunarız. Genelde fikrin iş arkadaşlarınız tarafından ne kadar iyi kabul edildiği ve anlaşıldığı konusunda iyi bir fikir sahibi olursunuz. Bu, kodunuza eklemenin akıllıca olup olmadığına karar vermenize yardımcı olur, yaparsanız diğerlerinin deşifre etmesine yardımcı olur ve başkalarının o stille yardıma ihtiyacı olursa 'gideceğiniz' kişiyi belirler. Kimse tekerleği yeniden icat etmediyse, hala kütükler üzerinde bir şeyler sürüklüyor olurduk.