Mükemmeliyetçilik programlamada iyi ve kötü olabilir.
Lütfen soru net değilse yorum yapın.
Yanıtlar:
KISS ve YAGNI , özellikle YAGNI.
Sadece yakında ihtiyaç duyacağınız şeyler için bir çözüm üretin. İhtiyaç duyduğunuz şeyler için iki yıl boyunca mühendislik yapmayın, çünkü büyük olasılıkla çok farklı şeylere ihtiyacınız olacak ve yine de yeniden inşa etmeniz gerekecek.
"Gelecekte bir noktada bu tasarımla X yapabiliriz, hatta Y bile" diyebiliriz, "bu tasarım bir sonraki sürümde müşteri ihtiyacını Z yapmamıza izin veriyor" yerine bahsetmeye başladığınız an mimarlık astronomi içine.
Yorumlara cevap olarak:
YAGNIBugüne kadar hiç duymadım .
Yinelemeli bir yaklaşım kullanın ve bu sorun çoğunlukla ortadan kalkar. Kodunuz ilk günden ve hemen hemen her gün çalıştırılmalıdır. Önce minimum gereksinimleri karşılayın ve vaktiniz olduğunda daha fazlasını ekleyin. Kodunuzu uzun süre çalıştıramayacağınız büyük değişikliklerden asla vazgeçmeyin.
Tamamlanması için harcanan fazladan zamanın, daha sonra doğal olarak ne zaman iyileştirileceği / değiştirileceği üzerine olan kolay çözümün bittiği zamanki olası olumsuz etkisinden daha değerli olduğu bir çözüm fazladır.
Temelde şimdi daha sonra zaman ile işlem zamanı. Şimdi daha fazla zaman harcıyorsanız, daha sonra tasarruf edersiniz, yanlış yaparsınız. Eğer gerçekten mühendisliğin üzerindeyseniz, daha sonra ne kadar zaman harcadığınızı (hatta daha fazlasını yapmanıza) etki etmeyen, şimdi zaman harcıyorsunuz.
Sahip olduğunuz daha fazla deneyimi çözmek için bu konuda daha iyi olursunuz. Bir şeyler hakkında gitmenin en iyi yolu (deneyimlerime göre) şu anda ihtiyacınız olanı yapmaktır, ancak daha kolay bir şekilde arttırılabilecek bir şekilde daha sonra gereksinimler talep etmelidir. Bunun nasıl yapıldığını çalışmak zor bir şey.
Çok mükemmeliyetçiydim (çözüm üretmek için çerçeveler oluşturmak için zaman harcamak).
Ancak üretimimi hızlandırmama gerçekten yardımcı olan şey dışarısı da dahil olmak üzere BDD / TDD ilkelerini öğrenmek ve takip etmekti (benimsemeyi özellikle öğrenmeyi zor buldum).
Bu gerçekten bir test yapmadan önce tek bir kod satırı yazmamamı öğretti. Ancak birim testleri ya bunun için bir kabul testi yapılmadan önce mevcut değildir. Ve kabul testleri gerçek kullanıcı ihtiyaçlarından gelir.
Bu nedenle, tüm kod satırları gerçek bir kullanıcı ihtiyacından kaynaklanmaktadır.
Dışardaki prensiplere aşina değilseniz, alt katmanların davranışını simüle etmek için test çiftlerini kullanarak uygulamanızdaki en dış katman için testler yazmaya başlayın (yani, neredeyse her durumda GUI). Daha sonra testleri geçmesi için yeterli bir şekilde uygularsınız. Üst katmanın bu uygulaması, uygulamanızın alt katmanına ulaşana kadar bir sonraki katman için yazmanız gereken testleri belirler.
Tecrübeyle bu konuda daha iyi olduğumu fark ettim.
(Çok) gençken her zaman en mükemmel çözüme gittim, ödün vermedim. Şimdi bütçe ve zaman gibi şeyleri aklımda tutmada daha iyiyim.
Zaman sınırı bu çizgiyi oldukça açık bir şekilde çiziyor.
Patronum aslında :)
Daha iyi olduğumu itiraf etmeliyim ama yine de uzlaşma için çok fazla değilim. Neyse ki beni dizginlemek için patronum var;)
Mühendisliğin tespit edilmesi oldukça kolay olduğu için, mühendislikten başka bir problem ortaya çıkarmak isterim.
Asıl sorunum refactoring ile ilgili. Sorun şu ki, çoğu zaman kodu elimden geldiğince iyi yazmaya çalışmama rağmen, şimdi bildiklerimi bilmiyordum (daha fazla kod, daha fazla kalıp, yeni deyimler, yeni sorunlar, yeni çözeltiler). Ve işe yaramasına rağmen, şimdi daha iyi yapmanın yollarını biliyorum:
Ancak, olduğu gibi çalışıyor ve bu nedenle onu yeniden yapılandırmak bir öncelik değil ve gerçek şu ki bana dırdır ediyor; Ekonomik nedenleri anlıyorum ve müşteri beklentilerini (kodu görmüyorlar ve yeni özellikleri ve hata düzeltmelerini tercih ediyorlar) anlıyorum, ancak üzerinde çalışacak zamanım olmasını diliyorum.
Şimdilik sadece patronumun sırasını takip ediyorum, ancak üretime verilen kodun şu ana kadar bulabildiğim en iyi kod olmadığını bildiğim için kendimi rahat hissetmediğimi itiraf etmeliyim. Mükemmeliyetçilik, sanırım.
Hem profesyonel hem de kişisel olarak, kendime uygulamaya çalıştığım standart şudur:
Kazanmaktan memnun olun.
Kodum sorunu çözüyorsa ve herhangi bir yeni sorun yaratmıyorsa * çözerse, devam etmesi çok muhtemeldir. Çıtayı ayarlanması gerektiği kadar yükseğe ayarlamayı öğrendiğinizde, "Yeterince iyi" yeterli olur.
Mükemmellik, ışığın hızı gibidir: asla oraya ulaşamazsınız, ancak denemeyi harcayabileceğiniz enerjide bir sınır yoktur.
(* - "Buggy" ve "Bakımı zor" un her ikisinin de "Yeni problemler" başlığı altında kaldığına dikkat edin. Bu nedenle, kod test edilinceye kadar gereksiz bitler kesilmiş ve Yorumlar / API belgeleri gündeme getirildi.)
Tecrübeyle, mükemmeliyetçiliğin belirli bir bağlamda (dil, çerçeve, platform, standart) en az birkaç yıl geçirene kadar mümkün olmadığını farkettim. Bir acemi olarak orada olacak sen (kaçan, öncelik saklıdır sözler, sözdizimsel şeker, zaman aşımları, asenkron çağrılar, belgesiz özellikleri ve böcek), sadece iyi bir çözüm için denemek böylece, tüm farkında olmayacak huyların her türlü olmak mümkün olduğunca öğrenirken. Önemlisi, her zaman sonucu yeniden düzenlemeyi basitleştirmeye çalışırım - Modüler mimari, gereken yerlerde yorumlar ve akıllıca numaralar yok .
Diğer birçok programcı gibi, sürdürülmesi gereken çok sayıda eski kod var. Her şeyi yinelemenin cazibesi her zaman orada olacak, fakat temelde onu bir ilkeye indirdim:
Ben (veya başkasının) bunu tekrar çözmem gerekecek mi?
Bu genellikle daha fazla yönetilebilir spagetti-chunk koduna dönüşen çok sayıda spagetti koduyla ilgilenir. Parçaların bir kısmını soyutlayın, testlerinizi yapın ve şimdi mükemmelliğe ihtiyaç duymayacak kadar görünmüyor.