Kötü kod yazmak zorunda kalıyorum. Yüzümü nasıl kurtarırım? [kapalı]


69

Ben sadece küçük bir geliştiriciyim ama işim beni gerçekten korkunç bir PHP kodu ile çalışmaya zorluyor (gördüğünüz en kötü PHP kodunu düşünün; daha sonra kodu iki kat daha kötü düşünün). Genelde hataları düzeltmeye ve yeni özellikler eklemek için kod temeli ile savaşmaya çalışırım. Bazen, en kısa sürede kirli hackler içermeyen işlere devam etmem isteniyor.

Ürün önceden açık kaynaklıydı ve gelecekte açık kaynaklı olabileceğinden endişe duyuyorum. Birisi (özellikle potansiyel işverenler) adımı bazı değişiklik setlerinin yanında bulabilirlerse utanırdım. İyi adımı korumak için ne yapabilirim?

Bunun alakalı olup olmadığından emin değilim ama ne patronumun ne de meslektaşlarımın kodun kötü olduğunu kabul etmek istemeyeceğini ekleyeceğim, ancak bunun için onları suçlayabileceğimden emin değilim - çoğu için bu onların ilk iş.


21
Kötü kod yazmak için nasıl zorlanıyorsunuz? Neden ayağa kalkıp, isminizi kötü koda koymaktan vazgeçemiyorsunuz ve sorunu, çözümü, zaman, emek ve para açısından maliyeti ve sorunları şimdi üstlerinize çözmenin faydalarını açıklamıyorsunuz?
Thomas Owens

17
"Hızlı ve kirli kesmeleri teşvik etmek"? Teşvik edici? Hangisi daha kötü. Gururunuz (ve yeni bir iş bulmak) ya da bu mesleğe bağlı kalmak. Neyin doğru olduğunu ayağa kaldırmak kötü olmayabilir. Seni ne durduruyor? Şiddetin tehditleri? Şantaj? Cezai takibat? Ciddi anlamda. İyi kod yazmanı engelleyen ne? Lütfen spesifik ol . Ve dürüst.
S.Lott

113
Teselli olacaksa, bugün yazdığınız iyi kodlar bile beş yıl içinde size kötü gelecektir.
Kyralessa

7
PHP tarafından "hızlı ve kirli" teşvik Şunu kabul değil bunu caydırıcı olduğu ve PHP, belki Perl hariç "Qucik ve kirli" diğer dillere göre daha iyi üstünlük söyleyebilirim aslında d konuda kolay yapma o ivme öyle sağlandıktan sonra özellikle yönetim de davranışı teşvik ediyorsa, durması zor. İşlevsel görünen kodun sonunda, uygulamalardan bağımsız olarak şirket için kod kullanılmamasından daha değerlidir.

7
Üzgünüz , kod yazmanın doğru ve yanlış yolları var. Doğru yol standart endüstri uygulamalarını kullanır; Kötü yol, birlikte saçma sapan ve "işe yaradığını" söylüyor.
Wayne Molina,

Yanıtlar:


132

Roma bir günde inşa edilmedi, ama iyi bir 'İzci İzi' olabilirsin. Her koda dokunduğunuzda, eskisinden daha iyi bırakın. Mantıklı işlev adları, iyi kodlama standartları kullanmak ve çalıştığınız zaman iyi yorumlar koymak için olağanüstü bir zaman harcamazsınız.

Bence tehlike, tamamen ya da hiç olmadığını düşünüyor. Sırf şık kod yazmak için zaman harcayamıyor olmanız, tamamen vazgeçip çöp yazmanız gerektiği anlamına gelmez.


2
+1. Hızlıca bir düzeltme yapmak için inandığın her şeyi feda etmek zorunda değilsin.
tdammers

4
+1: Hepsi ya da hiçbiri için - çok doğru.
Umber Ferrule,

3
Yanlış eldeki Çocuk İzci kuralı tam olarak soruna neden olabilir, çünkü üstbilgisinin 'algılanabilir işlev adı' tanımı 'bolChkLst' olabilir (stil stilini karşılamak için macar notasyonu, CheckList yerine ChkLst, çünkü daha kısadır) '). İşte ben denedim farklı işlerde karşılaşılan bazı izci Kural uygulaması şunlardır değil takip etmek: 'fonksiyonları Üyelik mümkün olduğunca az olması', '3 çağrıları aracılığıyla argümanları dont'taşımak yerine globalsi kullanmak' görünümlerinde, 'kullanım satır içi SQL için daha hızlı hale getirmek '
keppla

40
+1 içinEvery time you touch the code, leave it better than it was before.
Qwerky

3
+1. Çok sayıda açık iyileştirmeleriniz varsa, katkılarınıza gerçekten bakan herhangi biri sizin kötü bir programcı olduğunuzu düşünmez. Proje berbat olduğunuzu varsayan potansiyel işverenler çünkü proje berbatsınız, çalışmak istediğiniz insanlar değil.
Matthew

59

S.Lott ile yorumlardan * anlaşın (bir kereliğine :) Hiç kimse sizi kötü kod yazmaya zorlamaz. Sorun şu ki küçük dev. sık sık (bu site de bunun için suçlanıyor) en iyi uygulamalarda kaybolmak, "güzel kod", ... ne demek istersen ... ve çok fazla şey yapmazlar; veya hallettiler ama çok zaman harcıyorlar. Onlara kötü kod yazmalarını söyleyerek (ki aynı zamanda çalışan koddur) "bunun içinden" gelir, sadece bir şeyleri teslim etmelerini sağlar. Zaman geçtikçe, sonuç olarak (artık :) bir genç dev, hızlı ve kirli bir çözümle çok hızlı bir şekilde ortaya çıkıyor, fakat zamanın geri kalanını onu geliştirmek için harcıyor. Zaman geçtikçe daha fazla şey öğrenirsiniz ve bir noktada gerçekten iyi kod olan hızlı ve kirli çözümler sunmaya başlarsınız.

Ancak, yolunuza gidip en baştan mükemmel bir kod yazmaya çalıştıysanız, büyük olasılıkla çok zaman harcadınız ve neredeyse hiçbir şey yapmadınız.

Yani ... kötü kod yaz, ... çok ... zorlukla çalışan kod ve sonra İTERATE. Her yineleme biraz daha iyi!

İlk defa hiç kimse mükemmel çözümü yazmadı.

* Bu, daha kısa bir yorum olurdu.


1
+1 Bu cevaba kesinlikle katılıyorum. Seni iki kere affettim.
Vitor Py,

3
Katılıyorum. Bu, bir soruna "mükemmel" çözüme ulaşmaya çalışırken tutabileceğiniz "analiz felsefesi" ni kesmenin harika bir yoludur. StackOverflow'ta benzer bir şey yazdım .
Kyralessa

4
+1. Bunu zaten programcıların üzerinde okudum (ancak kaynağı bilmiyoruz): iki grup belirli bir zaman diliminde çanak çömlek yapmakla görevlendirildi. Biri mümkün olan en iyi kalitede bir ürün ve diğeri de mümkün olduğunca fazla ürün oluşturmak. Sonunda, ikinci grup daha iyi kalitede ürünler verdi, çünkü tekrarlama ustalığa giden yoldur. Tefekkür tek başına seni hiçbir yere götürmez. Sonunda hepimiz yaparak öğreniriz ve yanlış bir şey yapma korkusuyla denememize engel olan şey, muhtemelen başarısız olmak, ama kesinlikle hatalarımızdan ders almaktır.
back2dos,

1
Sonuç olarak, bir depo kullanın! Kendi kişisel makinende kurduğun kişisel bir şey olsa bile. Onları kullanmaya başladıktan sonra, bir sürü değişiklik yapmanın, işe yaramadığını fark etmenin ve geri dönmenin ne kadar özgürleştirici olduğunu fark edersiniz. Kişisel favorim fosildir
Spencer Rathbun

“Yani ... kötü kod yaz, ... çok ... zorlukla çalışan kod ve sonra İTERATE. Her yineleme biraz daha iyi!” Peki ya hiç bir zaman yinelemeyin, çünkü yeni projeler devam etmeye devam eder ... ve alfa olarak dışarı attığınız şeyin proje sona erene kadar yapışma eğiliminde olduğunun farkına varırsınız. İlk olarak boktan kod ve güncelleme eksikliğinden dolayı elbette hangisi hızlandı? Sanırım birçok genç devin başından beri "güzel kod" yazmaları gerektiğini düşünerek bu tür durumları kaybediyorlar ...
Serhiy

40

Kod yorumları burada senin arkadaşın.

Ne zaman kendiniz baskı yüzünden ucuz bir kesmek zorunda kalırsanız, "Bu kod zaman kısıtlamaları nedeniyle X'i yapar. İdeal olarak, yerine Y yapardım. - Ashamed One, 5 Temmuz 2011"

O zaman potansiyel işverenler bunu görürse, iyi bir kod yazmayı tercih ettiğinizi anlarlar, ancak kodlama stilinizi işletme gereksinimlerine göre ayarlamak istersiniz. Çoğu işveren ikisini de iyi şeyler olarak görecektir.


4
Kesinlikle. Yorumlar ve taahhüt mesajları da. Bunu hiç yapmadım, ancak bazı geliştiricilerin bazı vcs’lerde atfedilen açıklamalı değişiklikler dışında hiçbir şeye dayanarak değerlendirmek ilginç olacaktır.
timdev

iyi, yorum yapan "düzeltilmiş", "yapılan", "blahblahblah" olan biri hakkında bir şeyler söyleyebilirsin :)
gbjbaanb

+1 Bunu birkaç kez yaptım ve meslektaş geliştiricileri durumunda işe yarıyor.
Jacek Prucia

7
Genelde böyle yorumlar yapıp ne zaman rastlarsam silerim. TODO veya GELECEĞİ GELİŞTİRME olarak işaretlenmiş bir yorum kalmayı hak edebilir, ancak özürler sadece çöptür.
Kristopher Johnson,

1
Neden optimal bir çözümden daha azının uygulandığına (ve bu çözümün ne olabileceğine) bir açıklama eklemeyi kabul ediyorum Bunu zaman zaman yapıyorum. Ancak utanılacak veya özür dileyecek bir şey olduğunu sanmıyorum. Bu sadece, o kod parçası üzerinde çalıştığınız sırada yapılacak daha önemli şeyler olduğu ve verilen uygulamanın yeterli olduğu anlamına gelir.
Justin Ohms,

10

Bu seni nasıl zorladıklarına bağlı.

Deneyimlerime göre, iki olasılık var:

Sıkı bir program, eski kod vb.

Bu durumda, diğer cevapların çoğunun zaten söylediği gibi, 'serinlik için optimize etmek' size kalmış. Sen MVC için kod tabanına yeniden yazmak için zaman olmayabilir, ama ilk adım olarak, örneğin, elle senin SQL yapıştırma bırakıp, güzel yazabilir execute_sql($query, $params), böyle soyutlamalar için temel atar fetch_customer($filter_params)vb hatırla, bütün iyi Sonunda patronlar daha önce bir ürün alır, bu yüzden şimdiki zamana karşı geleceğe ne kadar zaman harcayacağına dair bir çelişki var.

Doğru içeriği belirlediğinizde ('6 ay içinde, fazladan zaman almadan, yekpare kodu MVC'ye yeniden yansıttım'), adınızı kodun üzerinde bırakmalı ve bir inme kurbanı öğreten bir terapist gibi gurur duymaya çalışmalısınız. tekrar tek kelime söyle.

Sizin uygun olmadığını düşündüğünüz bir şekilde uygulamanız istenir

Modeli modelden ayırma denemesi incelemede başarılı olamıyor, çünkü 'çok karmaşık, neden sadece düz sql sorguları yapmıyorsunuz?' Sizin execute_sql'disiplin ile kodlayıcı buna ihtiyacı yok' çünkü konserve alır.

Bu dava çok kötü. Tecrübelerime göre, genellikle başarıları için değil, politik nedenlerden dolayı terfi eden mikro yönetim ve takım liderleriyle geliyor. Asıl sorun, kontrol edemediğiniz bir şeyden (kod) sorumlu olmanızdır (kendi yolunu yapmanız gerekir). En iyi çözüm kök nedenini çözmek olacaktır (yani, büyük bir muamele görmüşsünüz). En iyi ikinci (ve benim tecrübeme göre, olağan) çözüm, işten çıkmaktır.

Sonunda, bu senaryoda, adınızın zaten yayınlanmayacak olması muhtemeldir, çünkü takım lideri tüm başarılar için kredi alır.


8

Patronunun hızlı bir şey yapmanı istediğinden eminim, ama kasıtlı olarak kötü yapmak için fazladan çaba sarf etmene gerek yok. Bu, ne zaman gerçekten kötü kod ile biraz daha az kötü kod arasında bir seçim yapsanız ve her iki seçeneğin de aynı derecede uzun sürmesi durumunda, biraz daha az kötü seçeneğe gidersiniz. Bu kısa vadeli bir çözüm ve hiç çaba gerektirmiyor.

Uzun vadede patronunla konuş. Burada 15 dakikalık bir yatırımın burada saatlerce nasıl tasarruf sağlayabileceğini açıklayın. İkna edici örneklere sahip olduğunuzdan emin olun - "bunu yapsaydım ve buradaki buradaysa, umudum gelecek yıl başka bir şey yapabileceğimi" değil, daha doğrusu "bak, burada bu şeyi yaptım ve çünkü buradaki sorunu bulmam üç saatimi aldı, eğer böyle yapsaydım ve böylesi bir hata ortaya çıkardı. " Burada bir uyarı: şık ve bakımı kolay kod çok daha iyi ve daha verimli hissediyor olsa da, bazen değil. Özensiz bir hızlı düzeltmenin mükemmel bir şekilde gerekçelendirildiği durumlar vardır: bazen tek kullanımlık kodlar yazıyorsunuz, bazen eskimiş bir şeyi bekletmek için eski bir hurdalık parçasını canlı tutuyorsunuz; bazen uygun bir çözümün faydası olmaz

Hepsi başarısız olursa, git başka bir iş bul.


3

Kimse seni kötü kod yazmaya zorlamaz. Bu durumu tersine çevirebilir ve olumlu hale getirebilirsiniz. Politikalar ve prosedürlerde öncü değişim. Ve sen de her zaman "evet" erkek / kadın olamazsın. Günün sonuna kadar x işlevselliğine ihtiyaçları olduğunu söylerlerse , bunun mümkün olmadığını söyleyin, ancak bunun neden olmadığına dair gerekçeler verin. Bir problem olduğunda, çözümler sunun. Sadece kör bir göz değil, daha da kötüsü ... buna ekleyerek.

Geliştirilmiş dükkanınız, kesin tarihlere sahip olan ilk kişi değil, yine de iyi tasarlanmış bir kod sağlama arzusuna sahip.


4
-1: ABD’de, patronunuz “Hızlı kod yaz” yazıyorsa ve bunu yapmayı reddederseniz, sizi kovabilirler. Yasal bir şeyi yapmak için doğrudan bir talimata uymamak, istem dışı fesih nedenidir. Yani bu sizi “zorlamak” olmasa da, patronunuzun söylediklerini yapmanın alternatifleri çok daha kötü olabilir.
Bob Murphy

Hepsi senin yaklaşımına bağlı. İdeal olarak, uzmanlığınıza değer verecek üstün bir rakam elde edersiniz ve değerlendirmeleriniz dikkate alınmalıdır. Çoğu zaman zaman çizelgelerini dikte eden insanlar geliştirici değildir ve neyin mümkün olup neyin olmadığını dikkate almalıdırlar. Elbette, kapakların altına "crappy" kodu yazabilirsiniz, ancak geri çekme yeterli olabilir, böylece herkes mutlu olabilir: iyi koddan iyi sonuçlar.

1
Gerçekten çalışmadığınız ideal üst düzey figürler harika, ancak maaşınızı imzalayan kişi, memnun etmeniz gereken kişi. Fatura tahsildarlarının işsiz olduğunuzda her saat aramasını sağlamak gerçekten çok kötü.
Bob Murphy

1
Ham kişisel ilgiden daha fazlası var. Bir yönetici ve girişimci oldum ve sizi temin ederim ki, tüm müşteri için para ödüyorsa hızlı ve kirliyse, para kaybedecek iyi bir iş yapmanın insanların işten çıkarılmasına yol açacağını garanti ederim. Bir keresinde bütün bir şirketi işten çıkarmak zorunda kaldım ve bir daha asla yapmak istemedim. Bu yüzden kesinlikle ahlaki duruşlar almayı tercih ederken ... berbat kod yazmak genellikle ahlaki bir mesele değildir ve bir noktada kişisel tercih ile iş sahibi olan veya olmayan kişilerin pratik meseleleri arasında bir seçim yapmak zorundadır.
Bob Murphy

1
Neredeyse hiç bir zaman büyük bir sistemin yeniden yazılmasını savunmuyordum, ama bu gelecekte yazdığınız kodun korkunç olması gerektiği anlamına gelmiyor.
PeterAllenWebb

3

Her şirket, mükemmel kodlar yazmak, kapsamlı dokümantasyon ve birim testleri ile ürünlerin makul bir bütçe ve zaman aralığında piyasaya sürülmesi arasında bir denge kurmaya ihtiyaç duyar.

Dünyadaki en iyi kod, piyasaya sürülmeden önce eski olması önemli değil.

Pragmatik olmak, bu dengeyi bulmaya çalışmakla ilgilidir. Hızlı bir şekilde sabitlenen özelliklere sahip olmak şu anda ticari açıdan çok önemli olabilir, her zaman olacağı anlamına gelmez.

Bu dengeyi sağlamak için çok fazla tecrübe gerekir (çoğu kodlayıcının çoğundan daha fazla). Her iki uç için de gitmek çok kolaydır. Orta yol bulmak daha zor.

Patronunun haklı olduğunu söylemiyorum. Bir kodlayıcı olarak, sürekli olarak ticari olarak uygun olmayan güzel kodlar oluşturmaya çalışmanın cazibesi vardır. Bu ayartmalara dikkat etmek, bu saldırıların bazılarının çok kötü olmadığını fark etmenize yardımcı olabilir.

Yeterli zamandan sonraki çoğu kod, genel bir çerçeveye yeniden yansıtmanın çok maliyetli olduğu özel durumlar için keseler içerecektir.


2

Şu an yaptığınız gibi devam etmemeniz, hiçbir şey söylememeniz ve hacklemeniz ve hacklemeniz gerektiğini eklemek isterim.

Ayağa kalkıp somut kodları göstermeli ve onlara neyin berbat olduğunu söylemelisiniz. Belirli olun ve taleplerinizi yedeklemek için kod ölçümlerini kullanın. Hiçbir şey bir kodun kötü olduğunu iddia etmekten daha utanç verici olamaz, aslında ne yapılıyorsa, ne yapıldığını anlamadınız.

PHP kod analizi için kullanılabilecek ücretsiz birçok araç olduğuna eminim: http://en.wikipedia.org/wiki/Code_analysis

Ayrıca, elbette bu http://en.wikipedia.org/wiki/Code_smell

Okuyun, uygulamanızda neler bulabileceğinizi toplayın ve elbette alternatifleri listeler . Sadece ayağa kalkmak ve "Bunun nasıl yapılmasından hoşlanmıyorum" diye alternatif bir uygulama yapmak için (tercihen) daha iyi bir yol sunmadan kötü bir uygulama.

Hızlı kesmek paraya mal olur. Ve bunu tamamen olumsuz olarak görmeyin - Şimdi bu işten çok şey öğrenebilir ve bir sonraki için yaptığınız deneyimlerden yararlanabilirsiniz.

hth


0

Her şeyden önce, bir tür kaynak kontrolü kullanıyorsunuz, değil mi? Eğer değilse, oradan başlayın. İlk önce size yardımcı olacak ve ekibin geri kalanı tarafından hızlıca benimsenecektir.

Kaynak kontrolünüz varsa, isminizi koda yazmamalısınız, sadece şirketinizin adını yazmalısınız. Hatalı kodlarda, dosyaların başında yer alan yorumlarda gözden geçirme geçmişi koymak yaygındır, bu durum kaynak denetimine daha iyi verilir.

Şimdi, kod kalitesiyle ilgili olarak, bunu büyük patlama yaklaşımı olarak değiştiremezsiniz. Yavaş yavaş, tek tek, farklı sorunlara yeni yaklaşımlar ekleyin. Doğru yaparsanız, bir süre TASARRUF EDECEKTİR ve genel kaliteyi daha iyi hale getirmek için kullanacaksınız.

Size bir örnek vermek gerekirse, bir keresinde tüm HTML kodunda bulunan bir Perl / CGI uygulaması olan bir projenin ortasına geldim. Tüm uygulama net bir yapıya sahip olmayan tek bir dosyadaydı. Hiçbir şey versiyonlanmamıştı. Bir CVS deposu (şu anda mevcut SVN yok) yapılandırarak müşteri için bir web arayüzü kurdum. İlk önce, işleri meslektaşlarımdan kendim almıştım. Daha sonra tüm yöntemleri farklı modüllerde (dosyalarda) böldüm. Bu noktada meslektaşları CVS'yi kabul etmeye başladı. Sonra HTML'yi kodun dışına taşıdım. Sonra, kodun bir bölümünde bir değişiklik yapmak zorunda kaldığımda, bir kısmını yeniden düzenlemek için biraz zaman harcadım. Sonunda, geliştirme hızı o kadar artmıştı ki müşteri çok mutlu oldu. Kozmetik bir değişiklik isterlerdi ve bize "2 gün sürecek" diyerek

Bununla birlikte, bu yaklaşım yalnızca genel kodu yeterince iyi bir şekilde ustalaştırdığınızda işe yarar. Büyük resmi anlamadıysanız, uygulamanın bazı kısımları anlaşılmaz kalırsa, işinizi gerçekten zorlaştıracaktır.

Son bir şey, tam bir yeniden yazma bazen tek çözümdür ancak maliyetini yönetime doğrulamak çok zordur.


0

Küçük bir geliştirici olduğunuzdan, bu aslında iyi bir şey. Büyük bir ol 'kod karmaşasının ortasına atılmak, ne yapmamamız gerektiği konusunda sadece' temiz 'bir kod üzerinde çalışmaktan çok daha fazlasını öğretecektir. Durumdan yararlanın ve kötü kodu nasıl yeniden ele geçireceğinizi ve yavaşça daha yönetilebilir bir şeye nasıl dönüştüreceğinizi öğrenin. Ve en kısa zamanda olması gerektiğinden şikayet etmeyin. Mesele şu ki - sıkı bir tarihte işlerle uğraşırken kodu yeniden düzenlemeyi ve temizlemeyi öğren. Sonuçta, eğer süreleri boşsa, herkes mükemmel bir kod yazabilir.

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.