Kodlama standartlarına ilişkin proje önceliğiyle anlaşmazlık [kapalı]

Bu yüzden son 1 yıldır proje liderimle birlikte yeni bir proje üzerinde çalışıyorum.

Başlangıçta ayrı git depolarında bulunan kendi alt projelerimiz vardı, koduyla çok az etkileşime girdim, bu yüzden kod kokusu beni rahatsız etmedi. Yaklaşık 6 ay sonra projede daha büyük bir rol oynadığım için kodunu korumaya ve özellikler eklemeye başladım.

Şimdi her iki alt projenin de baş geliştiricisiyim (büyümek üzere olan takım; hala üstümde), bu şeyler beni rahatsız ediyor ve bunlarla ilgilenmek istedim, ancak reddedildi:

1. Hiçbir kıvırcık parantez, büyük harf fonksiyonları, karışık tırnak kullanımı (çift ve tek w / gizli mantık), === kullanmadan, büyük fonksiyonları ile büyük sınıflar. Sonuç olarak, daha iyi olabilir.
2. PHP'nin uyarıları / uyarıları kapatma seçeneğine güvenme. Kod, değişkenlerin ve dizi anahtarlarının denetlenmeyen kullanımlarıyla doludur. Değişkenler ifs içinde tanımlanır.

Yukarıdaki 2 konuya ilişkin argümanlar:

1. İnsanlar için bir kodlama tarzı uygulamak istememek.
2. Daha kısa / daha verimli koda izin veren bir dil özelliği olarak kabul edilir.

Bazı kurallara uyulması ve kodun savunmacı olması gerektiğine inanıyorum. Biçimlendirme için PHPStorm'un varsayılan ayarlarını kullanmayı, süslü parantezleri ve topluluk tarafından kabul edilen bir adlandırma kuralını kullanmayı teklif ettim.

Her iki projeyi de ayrılmaz oldukları için aynı yönergeleri kullanacak şekilde hizalamak istiyorum.

Yanlış mıyım? Kişisel tercihlerimi dayatıyorum mu?

Sizinkinin neden daha iyi olduğuna (ve onu kullanırken hangi büyük sorunların ortaya çıkabileceğine) karşı güçlü bir dava açabiliyorsanız, kişisel tercihi dayatmıyorsunuz, bunun yerine başarı için bir proje oluşturmaya çalışıyorsunuz.

Eğer onun neden daha iyi olduğunu ve seninkinin yapamayacağını ne tür problemlerle karşılaştıracağına dair daha güçlü bir dava oluşturabilirse, o zaman seni terk eder.

İyi bir üst yönetim bunun değerini görmelidir, ancak bunlar önem vereceği (ve yapması gereken) noktalardır: geliştiriciler için daha kolay mı yoksa "herkesi bir robot gibi çalışmaya zorlamak istemiyorsanız" ( gülünç bir nokta, ama üst yönetimin acı noktası olarak kullanmayın). Projenin devam eden istikrarını önemsemelidirler.

Yukarıdaki yorumuma göre:

Eğer proje lideri ise, bunun temelde onun çağrısı olduğu anlaşılıyor.

Benim düşüncem buydu. Standardı değiştirmek istiyorsanız, ancak üzerinde durmuyorsa, a) onun üzerine nasıl çıkacağınızı öğrenin, b) çalışmak için başka bir yere gidin veya c) onu rahatsız etmeden ne kadar küçük şeyler yapabileceğinizi deneyin çok fazla.

Onun üstesinden gelmek, neden daha iyi standartlar olması gerektiğine dair güçlü bir dava açarsanız işe yarayacaktır .

Temelde:

• Eğer yok gibi onun kodlama stili. Bu senin hakkın.
• o bunu bulur Tamam ne olduğunu ve buluntular gün / hafta / daha adil stilini ayarlar bir olduğunu harcama gibi vakit kaybı . Bu onun hakkı.

Kendini onun yerine koy. Şirketinize çok fazla para (maaşınız) ödemenin yanı sıra, çabalarınızın faydaları nelerdir? Hep bu kadar zalim mi? Şu anda yapılacak daha önemli şeyler olduğunu görmüyor mu?

Temel olarak, yaşayabileceğiniz bir tür uzlaşma bulmanız gerekir , aksi takdirde ilişkiniz ekşi olur. Aynı zamanda onunla nasıl iletişim kurduğunuza da bağlıdır. Son olarak ona bir şeyler soruyorsun çünkü ... kenara ego koyun ve yardımcı olmaya çalışıyorum sen içeri çıkarı olduğunu şey değil istiyorum. Başka bir deyişle, ona bir iyilik istiyoruz .

Bu aynı zamanda nasıl sorduğunuza da bağlıdır . Örnekler:

Ne istiyorsunuz:

kodu daha güzel yapmak

Ne söylenemez:

kodunuz olduğu gibi berbat

Ne demeli:

Her iki projeyi de tutarlı hale getirebilseydim gerçekten çok memnun olurum, sadece temel bilgiler, ve bu sadece bir günümü alacak.

Ne istiyorsunuz:

artık kontrol edilmeyen uyarı yok

Ne söylenemez:

kodunuz olduğu gibi berbat

Ne demeli:

Bundan ve bu uyarıdan kurtulmanın hızlı bir yolunu biliyorum. Daha sonra, bunları yeniden etkinleştirerek, gelecekte bir şeyin kırılıp kırılmadığını daha hızlı tespit edebiliriz.

Ve son olarak:

Bunun bir öncelik olmadığını biliyorum. Bu yüzden ilk önce yüksek öncelikli şeyler masadan çıktığında memnuniyetle yapabilirim.

Veya bu işe yaramazsa veya onunla kötü bir ilişkiniz varsa, ayrılmayı düşünün. Eğer şimdi işleri halledemezseniz, gelecekte daha iyi olmak ve egonuzu bir kenara bırakmak mümkün değildir.

Kenar notu

Bence yaşlı insanların daha hoşgörülü olmaları daha yaygın. Kodun on veya iki yıl içinde çöpe atılacağını biliyorlar (çünkü teknoloji değişiyor, API'ler de, ekipler, iş ortakları, gereksinimler, küresel kararlar, her neyse ...). Daha az egosu var ve mükemmel olmaktan ziyade çalışmasına odaklanıyorlar. Kendimi mükemmelleştirmeye eğilimli olmama rağmen, onları suçlayamam.

Bu muhtemelen tartışmalı olacak ama ...

Görüşmedik ve katılmamaya karar verdik ve daha üst yönetime yükselttik

Asla. Hiç. Yapmak. Bu. HİÇ. Bunu her yaptığınızda, hepimizi on yıl geriye götürür. Bunun nasıl oynanacağı:

• Üst düzey yönetici 1: "Bu konuyla başa çıkmamız istendi blah, blah, blah, kodlama standartları ve zaman kaybı hakkında bir şeyler."

• Üst düzey yönetici 2: "Ve bizden inek çim savaşlarını çözmemizi istiyorlar, çünkü?"

• Üst düzey yönetici 3: "Çünkü iletişim kuramayan ve iş değerinin ne olduğunu umursamayan / anlamayan mızmız bebekler? *"

• Kıdemli yönetici 2: "Öyle olmalı. Golf için kim var?"

Sonra siz ve patronunuzun performans inceleme zamanı gelir:

"[patronunuzun kıdemli yöneticisi]: Üzgünüm, ancak doğrudan raporlarınızı yönetemediğiniz konusunda bazı endişeler var ve en iyi uygulamaları takip etmiyor olabilirsiniz (bazı mumbo jumbo yazın dışında ne yaptığınız hakkında hiçbir fikrim olmasa bile) yazılımı çalışır hale getirir) "

"[size üst düzey yönetici]: Üzgünüm ama akranlarınızla iyi bir ilişki kurmamanız ve derhal amirinizin talimatlarını takip etmekte zorlanmanız konusunda endişeleriniz var."

Bu yüzden yarattığımız değere kıyasla çoğunlukla daha az ücret alıyoruz. **

A) üstesinden gelmeniz veya B) standartların beğeninize biraz daha yakın ayarlanmış bir dükkana geçmeniz gerekir. FWIW, B yaparım (ve umarım bu tür zulümlere izin vermeyen bir dile geçersiniz). Ancak, yasadışı veya potansiyel olarak yıkıcı bir şey içermediği sürece (boşluk güvenlik boşluğu) teknik bir anlaşmazlığı asla davalara iletmeyin. Sadece sinir bozucu kesmiyor ***.

* Bunu okuyacak ve yanlış anlayacak insanlar uğruna, OP ve patronunun böyle olduğunu söylemiyorum (Kod kalitesinin / okunabilirliğinin işletmenin alt çizgisi üzerinde doğrudan bir etkisi olduğunu anlıyorum) diyorum teknik olmayan yönetim tarafından bu şekilde algılanacakları .

** Üst yönetim portresimin clueless delikler olduğunu düşünen insanlar için gerçekçi değil, yöneticilerin (ideal olarak) kodları yönetmeye önem verdiğimiz kişileri yönetmeyi önemsediğini anlayın . Teknik konularda clueless olabilirler, ancak insanları tanıyorlar ve bu, A) muhtemelen çözme konusunda nitelikli olmadıkları ve B) ikinizin tartışmasız yardım almadan çözebilmesi gerektiği konusunda bir anlaşmazlık getirmesinin daha fazla nedeni. seni kötü gösterir.

*** Evet, teknik borcun işi batırma noktasına kadar yükselebileceğinin farkındayım. Kıvırcık parantezlerin sizi kurtaracağını sanmıyorum (bu söyleniyor, parantezleri asla atlamıyorum ve başkalarının da yapmamasını şiddetle tercih ediyorum).

IMHO, 'işe yarıyor' bir geliştiriciyle karşı karşıyasınız, bir sonraki işin peşinde olacak biri değil. Argümanları değersizdir.

Kodu hakkında söylediğiniz her şey onun için sadece ham tembelliktir. Aynı kodlama standardını takip eden projelere sahip olmak titizlikle ilgilidir. Sen robot değilsin; siz mühendissiniz; titiz olmalısın.

Bazı örneklerle, kodunu okuduktan sonra zorlandığınızı ve bunun sizin için büyük bir verimlilik kaybı olduğunu gösterebilirsiniz, ancak bunu ona nasıl getireceğime dair gerçek bir fikrim yok.

Ama muhtemelen size bir şey tonu cevaplayacağım:

Çalışıyor, değişmenin anlamı yok

Benim tavsiyem: eğer gerçekten künt ve hiçbir şeye yönelmek istemiyorsa, bırakın. Projesinde hataların / hataların / evrimin gerçekleşmesini bekleyin. Geldiğinde, değiştirilen / eklenen kodun parçasını uygun bir şekilde düzeltin ve yeniden yazın; onun hakkında hiçbir şey söylemek için ona gitme. Zaten bir robot olmadığın için sana kodlama tarzını dayatmayacak ...

Bir proje üzerinde çalışırken öncelikleri ayarlamanız gerekir.

Öncelik # 1 iş arkadaşlarınızla iyi geçinmektir. Öncelik # 1'i büyük bir boşluk izliyor. Daha sonra kod gibi işler, test edilebilir, test edilir, belgelenir, bakım yapılabilir vb.

Mevcut kodun yeni kodlama standartlarına uyacak şekilde değiştirilmesi öncelik listesinde gerçekten düşüktür.

PS. "Mikro-optimizasyon" ve "süper hızlı bilgisayarlar": Tamamen yanlış argüman. Mikro optimizasyona karşı argüman, bilgisayarların hızlı olması değil, argüman, mikro optimizasyonlarda harcanan zamanın, gerçek tasarruflardan sonra zamanınız olmadığı anlamına geliyor .

PS. Kodun size daha iyi görünmesini sağlayacak değişiklikler yapmanız yalnızca bir gün sürüyor, ancak iş arkadaşınızı rahatsız ediyor ve sizi düşman yapıyorsa, o zaman sadece karşı üretken bir şey için boşa harcadınız.

PHP mesleğimizdeki en seçkin grup değildir. Aslında onun zor kazanılmış yazılım sistemini eleştiriyorsunuz. Profesyonel standardınız onunki kadar yüksek.

Sorumluluklarınız altında kodu geliştirmek için herhangi bir yolunuz yoksa, son tek bir çözüm var: devam edin .

Bulunduğunuz yerdeki PHP pazarı hakkında bir fikrim yok, ama önce biraz çeşitlenebilirsiniz. Bazı hype dil veya C # gibi bir niş öğrenin.

Böyle güzel bir iş bulamayabilirsiniz, ancak profesyonel olarak daha da ileri gideceksiniz. Sabırlı olun ve biraz kendi kendine çalışma yapın. Güvenli para. O zaman projelerinizde biraz boşluk isteyin veya bir iş teklifi alın.

Kodlama standartlarını değiştirmek istememek için gerçek sebebinin # 1 olduğuna inanmak zor. Kod tabanına sahipseniz, sizin (ve diğer geliştiricilerin) kabul ettiğiniz kodlama standartlarını uygulayabilmeniz gerekir. Diğer geliştiricilerle fikir birliğine ulaşırsanız (öncünün artık herhangi bir geliştirme işi yapmadığını varsayarsak), bunun dışında gerçekten bakım yapmasının bir nedeni yoktur:

Kod tabanının stilini düzeltmek şu anda zamanınızın en iyi kullanımı mı?

Eminim teslimatlarınız vardır. Diğer kod tabanındaki her yerde stili geliştirmek ve geliştirmek için ne kadar zamana mal olacak? Stili yanlış düzelterek hataları getirirseniz ne olur? Gönderen Amca Bob:

Tabii ki kötü kod temizlenebilir. Ama çok pahalı. Kod çürüklerken, modüller kendilerini bir araya getirerek çok sayıda gizli ve karışık bağımlılık yaratır. Eski bağımlılıkları bulmak ve kırmak uzun ve zorlu bir iştir.

Bunun gibi kod stilini geliştirmek neredeyse hiçbir zaman bağımsız bir sprint öğesi olarak iyi bir zaman kullanımı değildir . Bu tür iyileştirmeler yapmaktan hoşlandığım yol, "İyi Komşu Politikası" olarak adlandırdığım şeydir: bulabileceğiniz tüm stil ve mantık yapısını düzeltmek için uğraşmayın, çünkü muhtemelen istediğiniz kadar zaman harcıyorsunuz ve hala yapılmaz. Bunun yerine: kodun bir bölümünde değişiklik yaptığınızda, stili oradayken düzeltin ve bulduğunuzdan daha iyi bırakın. Kod kötü bir şekilde tasarlandığından bir özelliği uygulamakta zorlanıyorsanız, başınızı ona çarpmak yerine stili engellemeyi kaldırmak için düzeltin.

Bu şekilde, her değişiklik:

1. Teknik mükemmeliyetçilik motivasyonuna ek olarak iş motivasyonu vardır
2. Büyük bir zaman yatırımı olarak görülmeyecek (çünkü değil!)
3. Tam stilistik alışkanlıklar kuracaksınız çünkü siz ve ekibiniz bunu zaman içinde yapıyorsunuz
4. Aynı anda çok fazla değişiklik yapmadığınız için kod tabanına büyük bir risk oluşturmaz

Bundan birkaç ay sonra “korkunç paket” in artık o kadar da kötü olmadığını göreceksiniz ve patronunuz ekibinin daha mutlu olduğunu görecek. Ancak doğrudan bir çatışma olmadığı için zaten yapılacaktır ve şikayet edecek bir şeyleri olmayacaktır çünkü yapılacaklar listesine büyük bir yeniden düzenleme projesi ekleyerek zamanını (zihninde) boşa harcamadınız. Muhtemelen size asla haklı olduğunuzu söylemeyecektir, ama yine de hedef bu değil (değil mi?).

Potansiyel müşterileriniz hakkında bu soruları sorun.

• Yalnız mı yoksa çok küçük bir ekiple mi çalışıyorlar?
• Çoğunlukla bu dükkanda kodlanmışlar mı?
• Karar almaya alışkınlar mı?
• "Sadece halletmeye" mi alışıklar?
• Kodun çoğunu yazdılar mı?

Cevaplar "evet" ise, o zaman belirli bir tür programcının resmini çizeceğim. Deneyimlediklerinizle uyuşuyorsa, belki de kafalarına girmenize yardımcı olacaktır. Değilse, bu yanıtı dikkate almayın .

Bu, ilk günden beri orada olan, aynı işte yıllarını aynı kod tabanı üzerinde çalışmış, yollarına alışkın ve başka yollarla fazla deneyime sahip olmayan biri.

Kod yazarken başkalarını düşünmezler çünkü hepsi için mantıklıdır. Elbette öyle, yazdılar ya da yıllarca bunu anlamak için harcadılar.

Kodlama stilini, bakım ve hataları azaltmak için bir araç değil, kişisel bir tercih olarak görürler. Kodlama stilini tartışırken argümanlarınızı duymak için mücadele edeceklerdir, çünkü muhtemelen bir şeyleri neden bu şekilde yaptıklarını hiç düşünmemişlerdir. Duydukları şey "Benim istediğim gibi yapmak istiyorum" ya da "Yeni, süslü, modaya uygun bir şekilde yapmak istiyorum".

Onlar kendi yollarına yerleştirilmişlerdir. Çünkü bunu uzun zamandır aynı şekilde yapıyorlar, tüm araçları ve editörleri ve beyinleri tam olarak stillerine göre mikro yapılandırılmış. Bu tarzdan herhangi bir sapma, dikkatlice düzenlenmiş ancak çok kırılgan bir çalışma şekliyle çelişecektir. Değişiklik denemeleri editörleri, araçları, çalışma biçimleri veya "okuması zor" olmaları hakkında şikayetler çekecektir. Değişimi reddediyorlar çünkü kendilerini statükoya o kadar sıkı sarmışlar ki değiştiremezler.

Bu, yazılım mühendisliğini ve yazılım mimarisini daha önce hiç öğrenmemiş biri. Ne işe yarıyorsa, bir çeşit patlama yaparlar

İnsanların problemi var, teknolojik değil.

Olası satışınızı yeniden eğitmeniz gerekecek, ya da bırakmanız gerekecek.

Yönetime gitmek son çare . Her ikisi de @JaredSmith'in nedenlerinden dolayı ve kaybedeceğiniz için. Bu adam onlar için para kazanmak için yıllar harcadı. Şirketlerini yazdı. Çok sayıda yangın çıkardı. Sana spagetti yapan bir kovboy şefi. Onlara göre o şirketi inşa eden ve kurtaran bir kahraman.

Yeniden eğitmek için ...

• Güvenini kazan.
• Nasıl düşündüğünü anlayın.
• Değişim konusundaki korkularını ele alın.
• Değişimi kolaylaştırın.
• Bunun onun için daha iyi olduğunu göster .

Tarzını ciddiye al ve kafasının içine gir. Ona sor. Neden işleri olduğu gibi yapıyor? Okuduğunda ne görüyor? Araçları ile nasıl etkileşime giriyor? Kodda nasıl hareket ediyor? Tüm bunları bilmek onun itirazlarını anlamanıza ve çözmenize izin verecektir.

Sübjektif itirazlarının nesnel kökenini bulun, onları harekete geçirin. “Okumak zor” özneldir ve size hiçbir bilgi vermez. Bu konuda hiçbir şey yapamazsınız. "Ben renk körüyüm ve sözdizimi vurgulama işe yaramaz" objektiftir, size bilgi verir ve bu konuda bir şeyler yapabilirsiniz. Bununla ilgili daha fazla bilgi için Getting To Yes adlı bir kitap öneriyorum .

Kök sorununa, karşılaştığı asıl soruna ulaştıktan sonra, sorunu düzeltebileceğinizi veya azaltabileceğinizi görün. O zaman sorun değil. Muhtemelen hala değişimle ilgili duygusal sorunları olacak, ama en azından artık bunun gerçek bir sorun olduğunu iddia edemiyorlar.

Her seferinde biraz yap. Bu, yıllardır aynı şekilde davranan biri. Koddaki belirli kalıpları görmeye ve anlamak için kullanıyor. Birden bu kalıpları değiştirmek kafa karıştırıcı olacaktır. Bilinen iyi uygulamalarla onları yavaşça hızlandırmak olacak kadar sinir bozucu olduğu için, onu içinden yürümek zorundasınız.

Standart bir topluluk tarzını savunun. Bu, kişisel tercih ile ilgili tartışmayı ortadan kaldırır ve farklı tarzlarının neden bu kadar iyi olduğunu haklı çıkarmak için onlara baskı uygular. İşe alınmayı planlıyorsanız, yeni işe alımları entegre etmeyi kolaylaştırır.

Otomatik kod stilini savun. Doğru stili takip ederek bir düğmeye basın. Standart bir stille başlayan, zevkinize göre yapılandırmanıza izin veren ve bir düğmeye basarak kodu yeniden düzenleyebileceğiniz bir araç kullanın. Stili takip etmeyi mümkün olduğunca kolaylaştırmak, takip etmenin ne kadar zor olacağına dair birçok argümanı kaldırır. İstedikleri gibi kod yazabilirler ve bittiğinde bir düğmeye basarlar ve başkalarının okuyabileceği bir stil izlerler.

Bu kişi başkaları hakkında düşünme zihninde olmadığından, bu değişikliklerin onlara nasıl fayda sağladığını göstermeniz gerekecek. "Bu artık standart olduğu için, işe aldığınız bir sonraki kişiyle bu kavgadan tekrar geçmek zorunda kalmayacaksınız" kadar basit olabilir. Veya "testlerimiz varsa, kodu değiştirmek konusunda daha agresif olabilirsiniz ve bazı şeyleri değiştirmek konusunda daha az endişe edebilirsiniz". Veya "iyi dokümanlar varsa, insanların kodun nasıl çalıştığıyla ilgili soruları rahatsız etmeleri gerekmez". Bunun etkili olabilmesi için ne istediklerini bilmeniz gerekecek - bazı insanlar rahatsız edilmeyi sever, bu onları önemli hissettirir.

Uzun, uzun bir yol. Patronunuzu yönetmek ve yeniden eğitmek için sabrınız olup olmadığına karar vermelisiniz . Kendinizi öğretmenleri olarak hayal kırıklığına uğramış altlarından daha fazla düşünün ve kendinizi daha iyi hissedebilirsiniz.

Yanlış mıyım?

PHP bilmiyorum, bu yüzden doğrudan bir karar veremem, ama argüman uğruna, tercih ettiğiniz kodlama stilinin karşılaştığınız koddan "daha iyi" olduğunu varsayalım. mevcut otomatik araçlarla.

O zaman kodlama stilinde iyileştirmeler önermek yanlış olmaz.

Alt satırda, kod değil çalışmak istiyorum

Tercih ettiğiniz standartları karşılamayan kodlarla çalışmayı reddetmek yanlış olabilir, ancak yalnızca şirket için çalışarak ilk olarak kodlarıyla çalışmayı kabul ettiğiniz ölçüde. Nihayetinde, sizin isteğinize göre olmayan talepleriniz varsa işinizi bırakmak "yanlış" değildir, çünkü bu sizin hakkınızdır ve sonuç olarak daha iyi bir iş bulabilirsiniz.

Kişisel tercihlerimi dayatıyorum mu?

Hayýr. O proje lideri ve sen deđilsin. Bu onun çağrısı, ancak bu durumda "yukarı doğru delege edilmiş" olmasına rağmen.

Ayrıca, alt projelerin baş geliştiricisi olarak size aşağı doğru delege etmeye karar verebilir ve ileride üzerinde çalışacak olan bu alt projeler ve meslektaşları için kodlama standartlarını belirlemede size serbest el verebilir. Ama hangi sebeple olursa olsun, standartlaşmamanız gerektiğini oldukça güçlü hissediyor. Kodlama stiliyle ilgili yanlış olsa bile, size izin vermediği bir otorite talep edemezsiniz.

Ancak, "Kodlama stillerini zorunlu kılmak istemiyorum" dediğinden, en azından tercih ettiğiniz stilde yeni kod yazabilirsiniz (ve bunu yapmışsınızdır). Sonuçta bu, tarzınızın nesnel faydalarını gösterme fırsatlarıyla sonuçlanabilir. Davanýza ikinci bir bakým yapmak için iyi bir zaman.

Ayrıca (bence) makul bir şekilde dosyaları düzenleyen insanlardan, dosyanın zaten yazıldığı tarzda yapmasını isteyebilirsiniz. Bu, yazdığınız dosyalarda standartları korumanıza izin verir. Ne yazık ki, bunun çevirme tarafı, yazdığı dosyaları tarzına benzer bir şeyde düzenlemeniz gerektiğidir.

Gerçekten iyi bir test takımına sahip olduğunuzu ve bu nedenle göreceli güvenlik açısından yeniden düzenleyebileceğinizi varsayarsak bile, tüm dosyaları gözden geçirmemek ve yeniden şekillendirmemek için hala (kabul edilebilir derecede marjinal) nedenler vardır. Ana olan, büyük bir yapısal değişiklikten önce ve sonra yapılan değişiklikleri birleştirmeye, yeniden sıralamaya veya geri almaya çalışan bir kabus olmasıdır. Ancak bu özel projede neredeyse hiç olmayan şey olabilir.

[Yöneticim, kodlama stillerini insanlara zorlamaktan hoşlanmadığını söylüyor] çünkü biz robot değiliz.

Kaynak kodunu derledikten sonra neden atmadığımızı hiç merak ettiniz mi ve tüm testleri geçiyor mu? Kaynak kodu insanlar içindir ve sadece insanların yazması değil, aynı zamanda okumasıdır .

Er ya da geç, birinin geri dönüp kodu okumak için bir nedeni olacak. Belki değiştirmek zorunda kalacaklar, belki belgeleyecekler, belki de tekrar kullanacaklar. Her neyse. Bu olacak ve kodun tamamı tutarlı bir stilde ise okumak ve çalışmak çok daha kolay olacak.

Kötü bir stil bile hiç stilden daha iyidir.