“Çok fazla bilmek” nedeniyle sıkışmış [kapalı]

Daha fazla tartışma için http://news.ycombinator.com/item?id=4037794

Göreceli olarak basit bir geliştirme görevim var, ama her saldırmaya çalıştığımda, derin düşüncelere dalmaya başladım - geleceği nasıl genişletebilir, 2. nesil müşterilerin ihtiyaç duyacağı şey, "işlevsel olmayan" ı nasıl etkileyebilir? Yönleri (örneğin, Performans, yetkilendirme ...), değişime izin vermek için mimar yapmanın en iyi yolu ...

Bir süre önce kendimi hatırlıyorum, daha genç ve belki daha istekli. "Ben" o zamanlar hakkında hiçbir şey düşünmemiştim - devam edecekti ve bir şeyler yazmış, sonra yeniden yazmış, sonra tekrar yazmıştı (ve tekrar ...). Bugün "ben" daha tereddütlü, daha dikkatli.

Bugün oturup başkalarını insanlara işlerin nasıl yapılacağına dair talimat vermeyi ve talimat vermeyi çok daha kolay buluyorum. - ama klavyede her oturduğumda, aynı sinir bozucu yerde kalıyorum.

Bu yanlış mı? Bu doğal bir evrim mi, yoksa kendimi bir sıkıntıya mı soktum?

Adil açıklama - Geçmişte bir geliştiriciydim, bugün iş ünvanım bir "sistem mimarı" dır. Ne anlama geldiğini anlamada iyi şanslar - ama bu başlık.

Vay. Dürüst olmak gerekirse, bu sorunun çok fazla yanıt üretmesini beklemiyordum. Özetlemeye çalışacağım.

Nedenleri:

1. Analiz felci / Aşırı mühendislik / altın kaplama / (başka herhangi bir "çok fazla fazla düşünmeden seni incitebilir").
2. Verilen görev için çok fazla deneyim.
3. Neyin önemli olduğuna odaklanmamak.
4. Yeterince tecrübe yok (ve bunu anlıyoruz).

Çözümler (nedenlerle eşleştirilmez):

1. İlk test.
2. Kodlamaya başla (eğlenmek için +)
3. Atılacak bir tane (+ atılacak bir API).
4. Zaman kısıtlamalarını ayarlayın.
5. Havayı soyun, eşyalarla kalın.
6. Esnek kod yapın ("atılacak biri" nin tersi, hayır?).

Herkese teşekkürler - Bence buradaki en büyük yarar, bu deneyimde yalnız olmadığımı fark etmekti. Aslında kodlamaya başladım ve çok büyük şeylerin bazıları doğal olarak düştü.

Bu soru kapalı olduğundan, bugünden itibaren en çok oyu alan cevabı kabul edeceğim. Ne zaman / değişirse - takip etmeye çalışacağım.

Bu şeyleri düşünmek kesinlikle iyidir, ancak ilerlemenizi durdurmasına izin vermeyin.

Gerçekten iyi işleyen bir yaklaşım (özellikle yinelemeli gelişim ile), basit bir çözümü uygulamak ve daha sonra gerektiğinde yeniden tasarlamaktır. Bu, kodu mümkün olduğunca basit tutar ve fazla mühendislikten kaçınır. Düşündüğünüz performans veya mimari değişikliklerin çoğu muhtemelen yine de gerekli olmayacak, bu yüzden resmi olarak gerekli hale gelinceye kadar bunları yazmayın. Örneğin, bir profiler size performansı artırmanın zamanı geldiğini söyleyene kadar performans konusunda endişelenmeyin.

Ayarlamanıza yardımcı olmak için yapabileceğiniz bir şey, kod yazmadan önce bir şey hakkında ne kadar düşündüğünüze zor bir zaman sınırı koymaktır. Bir süredir düşünürseniz, yazarsanız, hatalarınızı fark ederseniz ve bunları yeniden gözden geçirerek düzeltirseniz, kod çoğu zaman daha iyi hale gelir.

Burada atılması gereken bir denge var. İlk önce sadece zıplamamalı ve sonuçları düşünmemelisiniz, aynı zamanda kodunuzu da fazla geliştirmeyi denememelisiniz.

Vikipedi yazılımda "Analiz felci" olarak adlandırıyor. Tarif çevik metodolojilere bağlı kalmaktır. Yani, herhangi bir faaliyet veya bireysel eylem, uygulama veya politika oluşturma girişiminden çok daha değerlidir. Takımdaki her katılımcı, kişinin yeteneklerinin mimari ideallere ne kadar iyi ya da kötü olduğu önemli değildir. Çevik, bireyler, egolar ilk, politikalar son.

En sevdiğim cevabı "Mimarlık fiil" dir. Düşünmeyi bırak, harekete başla, sen ve ekibin ne kadar kusurlu ve verimsiz olduğuna bakılmaksızın. Belki de ilk eylemler uygunsuz politikaları ortadan kaldırıyor olabilir.

40 yıl önce Fred Brooks, "Atmak için bir tane yaz, nasıl olsa yapacaksın" hakkında yazdı. Hiçbir şey değişmedi........

Bu yanlış mı? Bu doğal bir evrim mi, yoksa kendimi bir sıkıntıya mı soktum?

Değişir. Bu, geliştiricinin yolu boyunca ortak bir adım olma eğilimindedir.

1. Beraber fırlatmaya başla, kıçından ısır
2. Yaşayan her şeyi cehennemden atmaya başla, YAGNI'nin farkına var.
3. Kolay malzemelerin bir araya getirildiği ve sert / değişmesi muhtemel maddelere çalışmayı / değiştirmeyi kolaylaştıracak kadar mühendislik verildiği pragmatik bir orta zemine yerleşin.

Sadece 2 numarada kalırsanız bir rut.

Aklımda tutmayı hep sevdiğim şeylerden biri, "geleceği eskisi gibi değil" demektir.

Belli bir tecrübe ile geleceği tahmin edebileceğinize inanmak cazip hale gelir, fakat yapamazsınız. Gelecekteki müşterilerin / kullanıcıların / istediklerinin ne istediğini düşünmek kolaydır, ancak bu onları hemen isteyecekleri anlamına gelmez. Ayrıca, onları başka çelişen bir özellikten isteyecekleri anlamına gelmez. Bu yüzden, bugün gelecek için planlama yapmak için harcadığınız zamanı sınırlamanız gerekiyor. Özellikle gelecekte sadece gelecekte kullanılabilecek olan şeyleri inşa etmek için harcadığınız zamanı sınırlamanız gerekir.

Bana sorduğum soru, beni dürüst ve dar tutuyor "şu anda bu özelliği desteklemekten daha bu özelliği geliştirmek ne kadar zor olacak?" Genellikle, cevap şu ki, gelecekteki çaba aynı ya da iki kez şimdi yapmanın ne olacağıyla ilgili. Bu durumda, geleceği tahmin edemediğim için, şimdi inşa etmekte sorun yaşamadım. Cevap 10x veya daha fazla olursa, o zaman insanların gelecek veya iki yıl içinde buna ihtiyaç duyacağımızın ne kadar muhtemel olduğunu düşünmeye başlayacağım. O zaman bile, yaygın bir anlaşma olmadıkça, gelecekte bu hedefe ulaşmak için bugün yaptığımız şeyleri geri almanın gerekli olmadığından emin olma konusunda kendimi sınırlandırdım.

Örneğin, Hibernate'i daha sonra veri erişimi olarak kullandığımız gerçeğini özetleyerek çok fazla zaman harcadığımız birkaç projede çalıştım. (Hibernate üzerine inşa edilmiş bir projeyi kullanmayı hiç görmedim, kullanmayı bıraktım, bu yüzden başlamak için zaman kaybıydı, ancak bunu bir kenara koyalım.) Daha sonra değiştirmek isteyebileceğimiz makul bir olasılık olsa bile, çünkü Ayrıca bir veri erişim nesnesi deseni kullanıyorduk; Hazırda Bekletme modunu değiştirmek ve baştan değiştirmek için ihtiyaç duyduğumuzda aynı anda değiştirmek için esneklik oluşturmak zor değildi. Şimdi böyle bir durumla karşı karşıya kaldım, gerçekten ihtiyacımız olana kadar bu esnekliğe sahip oldum.

Büyük bir şirket için stratejik planlama yapmadığınız sürece, iki ya da üç yıldan daha uzun bir süredir mimari meseleler hakkında düşünmek bile değmez, çünkü teknoloji çok çabuk değişiyor. Bugün inşa etmeyi düşündüğünüz özellik, iki veya üç yıl içinde açık kaynaklarda serbestçe kullanılabilir. Neredeyse kesinlikle maliyet-fayda analizi değişmiş olacak.

Bugün ihtiyaç duyduğunuz, gurur duyduğunuz ve bir sonraki değişiklik turunda ne olursa olsun birkaç ay içinde çalışmaktan mutluluk duyacağınız bir sistem kurmaya kendinizi sınırlayın. Gerçekten yapabileceğinin en iyisi bu.

İşte (ilk sürümlerinde) pratik olmayan ve bir projeye iş perspektifinden zarar verebilecek çılgın müthiş tasarımları benim kişisel çıkarma sürecim.

1. Merkez üssü tanımlayın : Projenizi bir sosisli standı olarak düşünün, merkez üssü sosisli olur. Diğer baharat / sosu / sebzeleri standınızdan çıkarabilir ve yine de sosisli sandviç satabilirsiniz. Yazılımınızın asıl amacı nedir? Diğer her ilaveyi ve / veya katma değeri ondan ayırın ve önce merkez üssü üzerine odaklanın.
2. Kendinize “daha ​​sonra yapmak daha iyi yapmak demektir” diye tekrarlamaya devam edin : mantıklı olanı görün ve biraz "sonradan" not alın. İyi yaparsanız ve onun gerçek dünyadaki kullanımı hakkında düşünürseniz, aynı tasarıma sahip olursunuz ancak bir yol haritasına öncelik verirsiniz.
3. Diminish-Decouple-Discard : Yaptığınız modül tasarımı ne olursa olsun, olabildiğince basit / gerekli / saf / evrensel hale getirin (bazen bu, özellikleri bile kaldırmadan gerçekleştirilebilir). Daha da basitleştiremezseniz, kendi başlarına yaşayabilecek ve bir amacı olabilecek ayrıştırma elemanlarına başlayın. Sonunda, eğer hala orada biraz yağ varsa, onu tamamen kesebileceksiniz.
4. "Kütüphane kodunu" "üretim kodundan" ayırın : Her zaman yeniden kullanılamayan bir kod olacaktır, ancak her zaman tasarıma gürültü ekler. Bu kod, iş kurallarını içeren koddur. Bazen bazı işletme kurallarının , sağlam bir tasarıma göre değişimden ( çok önemli ) daha kolay ve daha hızlı olduğunu göreceksiniz . Güvenebileceğiniz bir kod bulacaksınız ve müşterinin gelecekte değiştirmesi veya yeniden düzenlemesi için ihtiyaç duyduğu kodu bulacaksınız. Bunların mümkün olduğunca ayrı tutulmasını isteyeceksiniz.

Ve BTW, adım 0: "tasarıma deli oluyor". Bu, sistemimden çıkarmama ve sık sık yeni uygulamalar, gizli gereksinimler ve hatta ortaya çıkan özellikler bulmama yardımcı oluyor.

Rework'dan 1 ve 2 aldım .

Testleri yaz. Testlerin hepsi geçtiğinde bitirdiniz: önceden değil ve kesinlikle mühendisliğin epik bir aşamasında çok geçmeden. Yazdığınız kod için bir test paketine sahip olmak size ne zaman durabileceğinizi söyleyen bağımsız, tarafsız bir gözlemci verecektir.

Gençken, risk görmüyorsunuz (muhtemelen genç politikacıların korkutucu olmasının nedeni), ancak yaşlandıkça kötü deneyimleriniz sizi her fırsatta felç ediyor (muhtemelen üst düzey politikacıların durgun olmasının nedeni). Bir Occam'ın jilet kılavuzlu yaklaşımını benimseyin - en az ihtiyacı olan çözümü bulun ve sonra oradan evrimleşin.

Yazılım yazarken ve tasarlarken akılda tutmanız gereken sadece iki şey var: bakım ve doğruluk.

Doğruluk en önemli kısa vadelidir ve testlerle kolayca kanıtlanabilir.

Bakım, geliştirme sürecinde daha sonra yardımcı olacaktır, ancak tespit etmek daha zordur.

Şu anki stratejim, yekpare bir kavram kanıtı oluşturmak ve sonra UI'nin modelden ayrılmasını sağlamaktır (modelin UI hakkında hiçbir şey bilmemesini sağlamak), uygulanabilir olduğuna emin olduğumda. Bu adım için çok uzun süre beklersem, elde edilemez bir şey bulurum. Ayrılmış katmanlarla başlarsam, UI'nin model hakkında bilmesi gerekenlere takılıp kaldığım için başlayacağım gibi görünmüyor.

Bu gibi durumlarda şaşırıp kaldığımda, inatçı bir şekilde, önemsiz bir şeyi yapmak için hipotetik programı kullanan bir son kullanıcı olduğumu hayal etmenin yardımcı olduğunu buldum. Sonra, bu eylemleri desteklemek için gereken programatik giriş noktalarının, sistemin diğer yönlerini görmezden gelmek için mümkün olduğunca çabalamaya odaklanmaya çalışıyorum. Buradan, bitmiş sistemin özelliklerinin (küçük) bir “dilek listesini” oluşturmak ve bunu uygulamaya başlayan gerçekçi olmayan bir kod yazmak çoğu zaman mümkündür . Bu egzersizden sonra genellikle başladım ve sistemin geri kalanı daha net olmaya başladı. Her şey giriş noktasıyla ilgili - ve tüm yazılımların büyük çoğunluğunun giriş noktası, son kullanıcıların bir programla ilk eylemleri.

Yaptığınız işlerin sizin için kolay olmasının bir sendrom olduğunu düşünüyorum.

Birkaç yıl önce size verilen zorluk verilen görevi yerine getirecek bir kod yazmaktı. Aklını tamamen meşgul eden buydu. Şimdi, zihniniz (deneyiminiz vb.) Daha etkili çalışıyor ve aynı işi yapmak, daha önce ihtiyaç duyulan enerjinin yalnızca bir kısmını gerektiriyor. Bu yüzden derin düşüncelerin sarmalına son veriyorsun. Zihnin kendini rutinden koruyor ve meydan okumak için savaşıyor.

Bence işini değiştirmeyi düşünmelisin. Belki de yeni bir programlama dili öğrenmelisin.

Aynı sorunu 15 yıl önce yaşadım. Çözümü gereğinden çok daha karmaşık hale getiren kusursuz, yeniden kullanılabilir, evrensel, ... kodlar yazmak istedim. Bugün bunu Altın kaplama olarak görüyorum . Bana çok yardımcı olan bir meslektaşımın tavsiyesiydi:

• Eğer işlevselliği geliştirebilecek bir fikriniz varsa, onu daha ünvansal hale getirin, ... Bu fikri ayrı bir "file.txt" dosyasına yazın ama şimdi uygulamayın .
• acil görevleri yerine getirmeye devam et.
• altı ay sonra, "ideas.txt" dosyanızı gözden geçirin ve bu değişikliklerden hangisinin projeye gerçekten fayda sağlayacağını analiz edin.

Bu sadece analiz ile felçtir. Birçok alanda birçok insana olur. Bunu kırabilirsin.

Cevap - SADECE IT İLE OLSUN ;-)

Bir spor forumuna yazıyorum ve birçok kişi farklı rutinler hakkında yazı yazıyor, onlar için en uygun olanı bulmaya çalışıyorlar. Bu yüzden onlara sadece eğitime başlamalarını ve ilerledikçe çalışmalarını söyleyelim. Daha güçlü olmak, bazı güçlü egzersizler yapmak ve daha sonra işleri değiştirmeye çalışıyorsunuz.

Büyük bir programınız varsa ve beyniniz fazla mesai yapıyorsa, önce basit vakaları kodlayın. Başlangıçta çalıştırmalısınız programı, daha sonra vs. girişi almalıdır
Buradaki zorluk güncellemek ve daha sonra planı ayrı ama eldeki görevi yapmak olması gereken çok kod no daha karmaşık OLMALIDIR kolay şeyler bırakmaktır.

Gelecekte, yeni öncelikleri yerine getirmek için refactor kodunun uygun olduğunu unutmayın. Hepsini önceden tahmin edemezsiniz, o yüzden denemeyin.

Bir sonraki görev için kod - SADECE. Kod basit ve iyidir, bu nedenle gerekirse yeniden yapılandırmanız kolaydır. Programın çalıştığından emin olun. Tekrar et.

Aşırı düşünme olasılığı olan son kullanıcı kullanım senaryosu senaryoları "sıkışıp kaldığınızdan", bir API yayınlayacaksanız ve sizin tarafınızdan bilinmeyen kişilerin bu API'yi kullanmasını beklediğinizde burada göz önünde bulundurmanız gereken bir şey vardır. Bir API yayınlandıktan sonra, ilk sürümünüzün ne kadar kötü olduğunu fark etseniz de, ya da muhtemelen sizin tarafınızdan bilinmeyen herkesin kodunu kırmanız gerekir, bu nedenle yabancılaşmayı tehlikeye atarsınız. gelecekteki tüm zaman için onları.

Standart çözüm, kullanıcılarınızın ihtiyaç duyduğu şeyin ne olduğunu ve API tüketicilerinin ne yaptığını anlayana kadar herhangi bir zamanda API’nin herhangi bir şekilde değişebileceği şartı ile yayınlamaktır.

Bu çözümde kendi çözümün olduğunu düşünüyorum. Bir veya iki şeyi yapan, belki de sadece tamam olan küçük bir şey yazın, yaptığınız herhangi bir şeyin gelecekte değişebileceği konusundaki anlayışı saklayın.

Her şeyi düzeltmek mümkün değil, hatta bazı durumlarda doğru bile olsa, başladığınızda tasarım gerçekten bir keşif yolculuğudur; ortaya çıkan ilk şey, yapılacak ilk şey değil.

Bir API'yi hemen tasarlayamazsınız ve asla müşterilerinize ayırmak zorunda kalmazsınız. Neden olduğunu anladın. Aynı şekilde yazılım yazamazsınız ve hepsini bir kenara atmanız ve yeni bir yaklaşımla baştan başlamanız gerekmez.

Yanlışlıkla daha az yaratıcı, üretken veya arzulanan bir şeye dönüşmüş olmanız anlamında bir sorunun olduğunu sanmıyorum. Bence durumunuza yanlış bir şekilde uyduğunuz yüksek standartlara sahip olduğunuzu düşünüyorum - herkesin düşündüğü gibi yaygın bir hata.

Sinik bir her şeyi bilen, her şeyi bilen olmadıysanız ve bu sizin durumunuzun tam tersi gibi gelmiyorsa, deneyim asla size karşı sayılmaz.

Büyüdüğümde aklımda tuttuğum birkaç görüntü var. Biri Lego ile oynuyor. Bir araya getirdim ve isteme ayırdım. Yapmaya başladığım şey, yaptığım şey olmayabilir. Sörf yapıyorum ve ilerlerken aklıma gelen olasılıklar konusunda kendimi ilerletiyorum, çoğu zaman hedeflerimi tamamen ilham aldığım bir yerde yeniden yaratıyorum ... yaratıcılık budur.

Diğer görüntü, gerçek bilim yapmayı tanımladığını duyduğum bir benzetmedir. Karanlık bir odada, orada bulunamayan bir kara kedi için etrafa el atıyorsun. Kendini o kediyi bulamamak için bir başarısızlık olarak kabul edersen sinir bozucu olur. Kara kedileri bulmanın başka yolu yok. Onları bulan tek faaliyet bu. Başka bir şey, iddia ettiği şeyi zaten almanın bir biçimi.

Çok fazla şey bilmiyorsun; Yeterince bilmiyorsun! Ve bunu daha yeni farkettin.

Tasarım seçimlerinizi “doğru” olarak almanız gereken bir şey olarak düşünmeyin, çünkü “doğru” yoktur - birçok “yanlış” vardır, ancak aynı zamanda tradeoflar da vardır (yürütme hızında, kodlamayı tamamlama zamanı) görev, genişletilebilirlik vb.). İyi tasarlanmışsa yazdığınız kodun hala çeşitli güçlü ve zayıf yanları olacaktır.

Amaç, bu güçlü ve zayıf yönlerin mevcut ve gelecekteki kullanım ve bakım bağlamında anlaşılmasının, ilk başta kod yazmanın çok daha zor olmadığı bir noktaya gelmelidir.

Öyleyse derin düşüncelerden kaçının, ancak bu tür bir tasarımda usta olmak için yalnızca düşündüğünüz gibi deneyime ihtiyacınız olmadığını unutmayın. Belirli bir seçimden emin olmadığınız bir noktaya ulaşana kadar düşünün, sonra en iyisini umduğunuz şeyi uygulayın, deneyin ve nasıl gittiğini öğrenin.

Kodlama alıştırması yapın. Alıştırmalar yapın veya çevrimiçi olarak bulun ve mümkün olduğunca çabuk doğru şekilde bitirmeye çalışın. Hızınızı arttırdığınızda, bakım ve performans gibi hususlar ekleyin. Üretime girmeyen şeyleri kodlamanın canlandırıcı olduğunu fark edeceksiniz ve kodlama korkunuzdan kurtulmanıza yardımcı olabilir.

Boş zamanlarınızda, 10 yıl önce yaptığınız gibi daha az endişe ve sadece eğlence ile kodlama yapın.

Bir takım yöneticisi ve doğrudan genç geliştiriciler olun - şu an 10 yıl önce sizinle aynı zihinsel durumdaydı.

Hayır, henüz yeterince bilginiz yok.

Bilginizi, örneğin bu basit kurallarla zenginleştirin:

• ÖPÜCÜK: Küçük ve basit tutun.
• YAGNI: Buna ihtiyacın olmayacak.
• Daha da kötüsü iyidir: Bazı kötü çözümler aslında bakım açısından daha iyidir.

Fazla mühendislik yapmayın. Yeniden düzenleme becerilerine sahip olarak değişime hazır olun, ancak koddaki her olası değişikliği kodlamayın. Zamanla bunu görürseniz, bir sınıf veya işlev çok büyürse, değiştirin. Böl ve fethet. Arabirimleri kullanın, daha fazla işlev kullanın. Çok fazla bölündüğünüzü hissediyorsanız (yani, bir şekilde meraklı hale geldi, ancak daha az okunabilir hale geldi), son değişikliklerinizi geri alın.

Özetle: Kodunuzu yeterince esnek hale getirin ancak daha fazlasını yapmayın. Bunun yerine, kendinizi esnek hale getirin, yeniden düzenlemeyle ilgili bir kitap alın.

İki şey:

1. Çok fazla şey bilmek yeterli değil. Neyin uygulanmaya değer olduğu hakkında fikir sahibi olmalısınız. TDD'yi kişisel olarak kötü mimariyi sağlayan bir koltuk değneği olarak görüyorum. Bu konuda bana karşı çıkacak çok fazla miktarda popüler görüş verilse de, muhtemelen yanılıyorum, fakat TDD'yi JavaScript'te uygulamak olup olmadığını, düşündüğüm bir sorun değil, çünkü hata ayıklama benim için hiç büyük bir baş ağrısı olmadı ve kalkınma topluluğundaki popüler görüşün, yıllar sonra kusurlu olarak görüldüğü ilk kez olmazdı. Yani kibirli bir hıyar olmayı öğren. En azından içeride. Yanlış olabilirsiniz ama en azından sizin için işe yarayan şeylere bağlı kalmayacaksınız.

2. Mikro ile başlıyor gibisin. Makro ile başlayın. Öncelikle uygulamanızın yapması gereken şeyleri yapmanız için gereken araçlar. Bu kısım yeterince kolay gelmeli. Ardından mimari / arayüz endişeleriyle başlayın. Sıhhi tesisatın nasıl bağlandığı ve neye bağlandığı, gerçekten sadece bir kenara çekip bir hevesle değiştirebileceğiniz her şeyin üstünde dayanıksız bitler olmalıdır. Aynı şekilde işlerin nasıl yapıldığına dair detaylarla. Düzgün bir şekilde sarıldığında bunlar kolayca değiştirilebilir / düzenlenebilir.

ama ona her saldırmaya çalıştığımda, derin düşüncelere dalmaya başladım.

Yanlış bir şey yok. Siz sadece sürecinizi iyileştirmenin zamanının geldiğini fark ettiniz: bu durumda, düşünme süreciniz.

Pek çok insan analizde kaybolur veya başka şekillerde saldırıya uğrar ve asla farketmez. Farkındaydınız, böylece takip etme yolunda kalmak için düşünme sürecinizi değiştirebilirsiniz.

Bunun için birçok çözüm var ve yukarıda gördüğüm en iyisi zaman kısıtlaması oluşturmak. Başlamadan önce, ne kadar süre (1 saat?) Onu analiz etmeye ve düşünmeye adayacağınıza karar verin. Bir zamanlayıcı ayarlayın.

Ardından, zamanlayıcı kapandığında, kodlamaya başlayın. Kendinizi tekrar uzun süre düşündüğünüz bir şey bulursanız, hemen bir karar verin. O anda karar verdiğiniz şey doğru karardır. Daha sonra her zaman değişiklik ve iyileştirmeler yapabilirsiniz.

Ayrıca çevremiz daima değişiyor. Yeni gereklilikleri, yeni teknolojiyi, yeni donanımı, dili ve sistem güncellemelerini vb. İşlemek için sıklıkla kodumuzu güncellememiz gerekir.

Evet, bu kodlama korkusu benim için bile oluyor. Yığın Taşması ile çarpılıyor. Küçük bir uygulama için ayrıntılı kodlama. Ancak, dış kaynaklı bir proje olduğunda, zaman kısıtlamaları nedeniyle fazla zaman yemez. Ayrıca bir grup yeni insanla çalışmak bunun üstesinden gelebilir, diye düşünüyorum.

Sen acımasız değilsin

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

Düzenleme: Bu makalenin amacı, geliştirirken küçük ayrıntılara dikkat etmek olsa da, en basit ve en verimli çözümü bulmak ve sadece işin üstesinden gelmek için basit veya karmaşık bir göreve acımasız bir tavırla yaklaşmanın yardımcı olduğunu buldum.