Python Kodlama standartları ve üretkenlik karşılaştırması


18

Büyük bir insani yardım kuruluşu için, gıda dağıtımını hızlandırarak acil durumlarda hayat kurtarmaya yardımcı olabilecek bir proje oluşturma yazılımı üzerinde çalışıyorum. Birçok STK, yazılımımıza umutsuzca ihtiyaç duyuyor ve programın gerisinde haftalar geride kalıyoruz.

Bu projede beni endişelendiren bir şey, bence kodlama standartlarına aşırı odaklanmak. Python / django'da yazıyoruz ve çeşitli değişiklikler ile PEP0008'in bir sürümünü kullanıyoruz, örneğin satır uzunlukları 160 karaktere kadar çıkabilir ve tüm satırlar bu kadar uzun sürebilir, ithalatlar arasında boş satırlar yok, yalnızca belirli türler için geçerli olan satır sarma kuralları bir sorunu çözmenin en iyi yolu olmasa bile, kullanmamız gereken çok sayıda şablon vb.

Bir çekirdek geliştirici, yeni kodlama standartlarını karşılamak için sistemin büyük bir bölümünü yeniden yazmak için bir hafta geçirdi ve yeniden yazma 'geçersiz' anlamına geldiği için süreçteki çeşitli test paketlerini attı. Kaybolan tüm işlevleri yeniden yazmak ve hataları düzeltmek için iki hafta geçirdik. O baş geliştiricidir ve sözcüğü ağırlık taşır, bu yüzden proje yöneticisini bu standartların gerekli olduğuna ikna etti. Junior devs söylendiği gibi yapar. Proje yöneticisinin tüm bunlar hakkında güçlü bir bilişsel uyumsuzluk hissine sahip olduğunu hissediyorum, ancak yine de başka ne yapacağından emin olmadığından şiddetle kabul ediyor.

Bugün ciddi bir sorun yaşadım çünkü bir anahtar kelime argümanında virgüllerden sonra boşluk bırakmayı unutmuştum. Bir Skype çağrısı sırasında tam anlamıyla iki geliştirici ve proje yöneticisi tarafından bağırıldım. Şahsen kodlama standartlarının önemli olduğunu düşünüyorum ama aynı zamanda onlara takıntılı çok zaman harcadığımızı düşünüyorum ve sözlü ifade ettiğimde öfkeyi kışkırttı. Takımda baş belası, başarısızlıkları için günah keçisi arayan bir takım olarak görüyorum. Kodlama standartlarının getirilmesinden bu yana, ekibin verimliliği ölçülebilir bir şekilde düştü, ancak bu sadece saplantıyı güçlendiriyor, yani kurşun geliştirici, ilerleme eksikliği standartlarına uymamamızı suçluyor. Sözleşmelere uymazsak birbirimizin kodunu okuyamayacağımıza inanıyor.

Bu yapışkan olmaya başlıyor. Şimdi çeşitli komut dosyalarını değiştirmeye çalışıyorum, autopep8, pep8ify ve PythonTidy sözleşmeleri eşleştirmeye çalışıyor. Ayrıca pep8'i kaynak koduna karşı çalıştırıyoruz, ancak standardımızda o kadar çok örtülü değişiklik var ki hepsini izlemek zor. Lead dev simple, pep8 komut dosyasının bir sonraki stand-up toplantısında bize ulaşmadığını ve bağırmadığını gösterir. Her hafta, mevcut, çalışan, test edilmiş kodu yeniden yazmaya zorlayan kodlama standartlarına yeni eklemeler var. Cennete şükürler olsun ki hala testlerimiz var (bazı taahhütleri geri aldım ve kaldırdıklarından bir demet düzelttim)

Bu sırada son teslim tarihine ulaşmak için artan baskı var.

Temel bir meselenin, öncü geliştiricinin ve başka bir temel geliştiricinin, diğer geliştiricilere işlerini yapmaları için güvenmeyi reddetmeleri olduğuna inanıyorum. Ama bununla nasıl başa çıkılır? İşimizi yapamayız çünkü her şeyi yeniden yazmakla çok meşgulüz.

Bir yazılım mühendisliği ekibinde bu dinamiğe hiç rastlamadım. Kodlama standartlarına bağlılıklarını sorgulamak yanlış mıyım? Başka biri benzer bir durum yaşadı mı ve bu durumla nasıl başarılı bir şekilde başa çıktılar? (Sadece insanların bulduğu gerçek çözümler hakkında bir tartışma aramıyorum)


4
Kodlama standartlarının uzun vadeli verimliliği artırmayı amaçladığını unutmayın. Eğer mevcut proje uzun süredir herhangi bir standardı takip etmiyorsa, bu kısa vadeli bir üretkenlik maliyetine neden olur.
Arseni Mourzenko

1
Kodunuzu standartlara göre otomatik olarak biçimlendirmek için Eclipse ve PyDev'i programlamanız yeterlidir. Birkaç iletişim kutusunu doldurmak meselesi.
user16764

1
@DemianBrecht - işbirliği tüm kodlayıcılar tarafından tanımlanmış ve anlaşılmış standartlar kodlama yazmış olduğu iyi bir şey ve edebilirsiniz uzun vadeli verimliliğini artırmak. Otoriter kodlama standardı, ekipten katılım olmadan yukarıdan dayatılan büyük bir zaman kaybıdır ve kod geliştirdiği için testleri geliştiren sözde baş geliştirici tarafından örneklendirildiği gibi, bir projeyi durgunluk ve hatta regresyona mahkum edebilir . yeni standart bu testlerde başarısız oldu. Dürüst olmak gerekirse WTF?
Mark Booth

1
@MarkBooth: Herkesi memnun edemezsiniz. Sadece yukarıdan dayatılmışsa, diğer üyelerden satın almanın daha zor olduğunu, ancak yine de "büyük bir zaman kaybı" olmadığını kabul ediyorum. Standartların yerine getirilmesiyle, kod çok daha tutarlı olmalıdır ve bu nedenle bir proje boyunca kodda daha az çeşitlilikle karşılaşırsınız, bu da okunabilirliği artırır. Ama evet .. Standartlar nedeniyle testleri atmak, kaputun altında daha büyük sorunların olduğuna inanmamı sağlayacaktı.
Demian Brecht

1
@Demian Brecht: Bu sorudaki temel noktanın kodlama standardı olmadığından eminim, ancak kodla ilgili kozmetik sorunların temelde geç ve yüksek önemi olan bir projedeki diğer her şeyden daha yüksek önceliğe sahip olması .
Buhb

Yanıtlar:


27

Kodlama standartları sorun değil. Sorun, yönetimin sorunun ne olduğunu çözememesidir. Bu, "Bir şey yapın ... her şey!" modu. Rasyonel bir çözüm arıyorsunuz, ancak bu mantıksız bir problem. Yapabileceğiniz en iyi şey:

  • Fikirlerine yapıcı bir eleştiri verin, ancak karar verildikten sonra sürekli olarak sızlanmayın.
  • Yeniden yazma işlemlerini kolaylaştırmak için elinizden geleni yapın.
  • Stresi durdurun. Kaçırılan son tarihler sizin değil yönetimin sorunudur. Elinizden gelenin en iyisini yapın, ancak kötü kararları için sorumluluk almayın.
  • Eğer yardımcı olabilecek bir şey biliyorsanız onlara söyleyin. Standups'tan bahsettiğinizde, çevik yapmaya çalıştığınız gibi görünüyor, ancak geri kalanı çok çevik görünmüyor. Her şeyle birlikte büyük bir son teslim tarihini karşılamak yerine sınırlı işlevsellik sunup sunamayacağınızı görün. Yeniden yazma işlemleri için kullanıcı öykülerini oluşturun, böylece birikmiş işlerini nasıl etkilediklerini netleştirin.
  • Başka bir iş aramaya başlayın. Ciddi anlamda. Böyle bir eyaletteki şirketler insanları kovmaya başlamaktan çok uzak değil.
  • Bazı "sana öyle söyledi" t-shirt basılı olsun :-)

Güzel nokta. Aslında kodlama standartlarına karşı değilim, örneğin, son toplantı sırasında standartlara yeni ekleme, her sınıf ve işlev hakkında öğretileri zorunlu kılmaktı, ki bu bana mantıklı geliyor ve çoğunlukla bunu zaten yapıyorum. Para başka bir iş aramak için çok iyi. Kod geliştiricileri denedim, ancak ekibin lider geliştiricilerin kullanımını yasakladığını önermeme rağmen. Uzaktan çalışıyorum ve bu kural uygulanamıyor, bu yüzden pep8ify kullanacak olanı buluyorum çünkü kodu sadece standardı geçiyor, bu yüzden insan düzenlemelerine benziyor. Yani minimal değişiklik yapar.
Shroatmeister

1
Ben son tarih olduğunu eklersiniz olacak neredeyse kesin, kaçırılmaması gereken. Bu bir ölüm yürüyüşü ve birisi seni suçlamaya çalışacak. Her şeyi belgelediğinizden emin olun: her görev için ne kadar zaman harcadığınızı takip edin, tüm postaları ve / veya sohbet günlüklerini arşivleyin, böylece kendinizi savunabilirsiniz.
coredump

7

Birisinin kodlama standartlarına gönderim veya köleliğe bağlılığın gerçek öncelik olup olmadığına karar vermesi gerekir. Tercihimin ne olacağını biliyorum; birim ve kabul testlerini geçiyorsa gemi diyorum. Bir kez gemi, şirket teknik borç düzeltmek için zaman ve para harcamak isteyip istemediğine karar verebilir.

Virgül sonrası boşluklarla ilgili sorunlar bir kod önleme aracı ile kolayca çözülebilir. Tüm kodlama kurallarınızı uygulayan bir araç bulun ve oluşturma ve test gerçekleştirilmeden önce bu aracı değiştirilmiş tüm kodlarda çalıştırın. Kodu yazarken iyi IDE zaten bunu yapıyor .


Pep8ify'ı bu yeniden biçimlendirme için yararlı buldum. Standartları karşılamak için minimum değişiklik yapıyor gibi görünüyor ve komut satırı yapılandırılabilirliği biraz sınırlı olmasına rağmen, kodun değiştirilmesi kolaydır.
Shroatmeister

4

Kodlama standartlarına bağlılıklarını sorgulamak yanlış mıyım?

Gruba bağlıdır. Şahsen , her şeyin sorgulanması gerektiğini düşünüyorum. Bazı insanlar bu sorgulamayı bir hakaret olarak görür; onlara güvenmiyorum.

Başka biri benzer bir durum yaşadı mı ve bu durumla nasıl başarılı bir şekilde başa çıktılar?

Bu standartların verimliliği nasıl artırdığını sordum. 'İşleri yaptırmak' ve standartlara uymak için harcadığım zamanı ölçtüm. Sonunda, standartlara uymaya karar verilen güçler. Olur. İşleri yapmama nedenim olduğunda normalden daha yüksek sesle şikayet ettim, ama başka türlü işimi yapmaya odaklandım. Sürekli bir şeylerle savaşmak verimlilik için de iyi değil ...

Dediğiniz gibi, standartlar nedeniyle işler ölçülebilir derecede kötüyse, standartlara uymak liderin argümanını geçersiz kılmalı ve sizinkini bırakmalıdır. İnsanlar standardın uygulanması ile verimlilikteki düşüş arasındaki (büyük ölçüde) nesnel korelasyonu göremiyorsa, yapabileceğiniz daha fazla bir şey yoktur. Bununla başa çıkmayı öğrenin ve yapamıyorsanız daha az bürokratik bir yer arayın.


3

Standartlar, son teslim tarihi ile geç projeye konulmaması gereken bir şeydir. Bu, projenin başlangıcında ya da (potansiyel olarak) büyük suç işlemeyen kod refactoru için proje çizelgesinde (tercihen ilk gemi sonrası) bir kenara bırakılması gereken bir şeydi.

Eğer bu aslında projenin sonlarına geçtiyse, bu sizin lideriniz (IMHO) tarafından yapılan bir hatadır.

Bununla birlikte , bu, ipucuna katılmamanız halinde, sadece isyan ile ilerlemeniz gerektiği anlamına gelmez. Bu senin işin . Takım olarak çalışıyorsun . Bir ipucun var . Takımda kesinlikle belli bir düzeyde demokrasi olmalı, ama sonunda lider diktatör. Bir şey yaptığını söylüyorsa, sen yaparsın.

Sonunda, isteklerine ve standartlarına uyarak, eksik son tarihler için ona kolay bir günah keçisi sağlamazsınız.

Ayrıca, kodlama standartlarının büyük bir savunucusuyum (özellikle bir ekibin büyüklüğü büyüdükçe), ancak mantıklı olduğunda uygulanmaları gerekir.


1

Sorunuz '' Kodlama standartlarına bağlılıklarını sorgulamakta yanlış mıyım? ' http://c0x.coding-guidelines.com/Introduction.pdf (C programlama dili için) kodlama yönergelerinin değeri ile ilgili bazı referanslı çalışmalara sahiptir. Bkz. Bölüm 9, sayfa 39.

Kodlama standartları bir nedenle uygulanır. Orijinal sorudan eksik görünen bir şey, belirli bir projede (veya belirli bir organizasyonda) bu belirli standartların nedeninin anlaşılmasıdır. Bunları mevcut kod üzerinde uygulama kararı bazı mantığa dayanıyordu. Mantığı bilmeden, bu kararın “iyiliği” hakkında yorum yapmak zordur.

Birisinin, standartların 'uzun vadeli üretkenlik' için uygulandığını söylediklerinden ikincisini alacağım - kodun sürdürülebilirliği gibi konular. Belki de karışıklık ve yanlış yorumlama nedeniyle projeyi ciddi şekilde geri alan bir olay meydana geldi.

Her iki tarafta da çok fazla duygu var gibi görünüyor - mantıklı tartışmaya girmeye çalışın.


1

Muhtemelen diğer cevaplar ve yorumlar tarafından gördüğünüz gibi, projenizin büyük sorunları var, bu yüzden önereceğim şey büyük bir başarı şansına sahip değil, ancak bu konuda çok büyük bir risk olmadan deneyebileceğiniz bir şey kendi cildinizi.

Baş geliştiricinizle dört göz arasında bir toplantı isteyin. Kodlama standardına bu kadar katı olmanın faydalarını ve kod tabanının onları tanıtmadan önce neden bu kadar kötü durumda olduğunu anlamak istediğinizi varsayalım. Bu tartışma sırasında çok açık ve "öğrenmeye çalışıyorum" tutumunu sürdürmeniz çok önemlidir. Baş geliştiriciniz muhtemelen sizden veya ekibinizdeki herhangi bir kişiden daha fazla stres altındadır ve bazı eleştiriler duyduğu anda muhtemelen çok savunmacı olacaktır.

Tartışmayı ortak hedefinize ulaşmanın yollarını anlamaya çalışma yönüne sürüklemeye çalışın; çalışma ve bakımı kolay yazılımları derhal teslim etmek.

Örneğin, bazı düşük asılı meyveler, kodlama yönergelerine daha fazla bir şey eklememektir. Her seferinde, daha önce yönergelere bağlı olan kod artık kullanılmaz ve bunun sonucunda kod parçalarını yeniden yazmanız gerekir. Umarım lider geliştiriciniz, eklenen kural değer eklese bile (onun bakış açısından), zaten geç projenin bu aşamasında yeniden yazmayı motive etmek kadar iyi olmayabileceğini görebilir.

Bu işe yararsa, bazı araçlarla otomatik olarak biçimlendirilemeyen daha keyfi kuralları kaldırmasını deneyebilirsiniz.


-2

Kodlama standartları iyidir. Kodlama standartlarını değiştirmek pahalıdır (daha az izin verirseniz pahalıdır; eğer standartta yapılan bir değişiklik mevcut tüm kodları hala uyumlu bırakırsa, bu bir problem değildir), bu yüzden sadece kesinlikle gerekli olduğunda yapılmalıdır.

Bir şey, belki de, mevcut araç zinciri otomatik olarak kontrol edemiyor gibi göründüğü için, standardın uygun olduğundan emin olmak için herhangi bir taahhüt / birleştirme / herhangi bir şeyden önce tüm kodu kontrol etmesini sağlamaktır.


-3

gıda dağıtımını hızlandırarak acil durumlarda hayat kurtarmaya yardımcı olabilecek yazılım

İyi kodlama standartlarına inanıyorum, ancak hayat kurtarmanın çok daha önemli olduğuna da inanıyorum .

En büyük önceliğiniz insanların hayatını kurtarmak olmalıdır . Bu yazılımın ailenize veya ekibinize yiyecek dağıtıp dağıtmadığını düşünün. Bir sonraki şey gelebilir.

İyi haber: testleriniz var. Testler, işlevselliği bozmadan kodlama standartlarınıza uymanıza yardımcı olacaktır, ancak bu göndermeden sonra değil, daha önce değil.


1
Sevkıyattan sonra ne olmalı? İşlevi bozmadan kodlama standartlarına uygun mu? Testleriniz mi var?
Martijn Pieters

Gönderdikten sonra, kodlama standardını takip etmek için çalışmalıdır.
Mohammad Tayseer
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.