Analiz felci ile nasıl baş edebilirim?

Çok sık, en iyi tasarım kararını seçerken sıkışıp kaldım. İşlev tanımları, kontrol akışı ve değişken adları gibi küçük ayrıntılar için bile, seçimlerimin yararlarını ve değişimlerini inceleyerek alışılmadık derecede uzun süreler geçiriyorum.

Saatlerimi bunun gibi önemsiz detaylara harcayarak çok fazla verimlilik kaybediyor gibi hissediyorum. Mevcut tasarımım işe yaramazsa bunları değiştirebileceğimi bildiğim halde, tek bir seçeneğe kesin karar vermekte zorlanıyorum.

Bu sorunla mücadele etmek için ne yapmalıyım?

İki basit kural:

1. İşe yarayabilecek en basit şeyi yap.
2. Sürekli refaktör.

Bunların her birini yapmaya başladığınızda, daha sonra değişime cevap verme yeteneğinizden ödün vermeden basit kararlar alabileceğinize güven kazanacaksınız.

Gelecekteki prova kodunun kodun değiştirilmesini kolaylaştıracağını, kodunuzun değişmesi gereken her olası yolu öngörmeye çalışmak anlamına gelmediğini unutmayın.

Genellikle bu şekilde hissettiğimde denemek zorunda olduğum anlamına gelir:

1. Ayağa kalk, dolaş ve tüm biyolojinin iyi çalıştığından emin ol.
2. Bir beyaz tahtaya gidip kendine güven hissedene kadar çizin.
3. Sadece sorunu çözebileceğiniz bir "tasarım şikayeti arkadaşı" bulun.

Sorun sözdizimi ve küçük parçalar içeriyorsa, o zaman:

1. Kendinizi, çirkin olsa bile, bir yerde güzel bir şekilde kapsüllenmiş olduğunu ve tamamen yerel bir kederi temsil ettiğini kabul edin.
2. TODO belirteçleri veya kodun sizi neden rahatsız ettiğini açıklayan yorumlar ekleyin .
3. Bir sonraki göreve geç.

Kendinizi hareketsizlik içinde düşünmek çok kolaydır. Bir şekilde, şu anda projeyi tamamlamadan önce kolayca değiştirilebilecek en iyi çözümü bulmayı başarsanız bile , peki ne olacak?

İyi bir çözüm seçmek ve onunla birlikte çalışmak, en iyi çözümün ne olacağı üzerine oturmaktan ve ondan uzaklaşmaktan iyidir . En iyi çözüm zor ve daha kötü, özneldir. Gereksinimler biraz değişse bile, çözümünüz o zamanlar en iyisi olmadığı için attığınız bir çözümden daha kötü olabilir.

Analiz paralizisinden de kaçınmayı öğrendim, bu yüzden bize kudos =) Bu, genellikle "en iyi tasarım" yapmak istediğimiz için olur. Gerçekte, "en iyi" bakanın gözündedir . Analiz felsefesinden kaçınmak için olan formülüm, yeterince iyi tasarım ilkesini uygulamaktır. Bunu nasıl yaparım? Kaliteden ödün vermeden zaman kısıtlamaları, zamanlama ve zamanlama gibi değişkenler getirip kendime işin en kolay tasarımını yapmanın (bu en kolay anlamına gelmez) ne olduğunu kendime soruyorum, ancak aynı zamanda test edilebilir ve değişiklik için kapalı bir uzantı için açık (OCP)yanı sıra tasarım. Test edilebilir ve OCP ile ne demek istiyorum? En iyisini düşündüğüm şeyi aramak yerine, işler kötüye gittiğinde bana söyleyebilecek bir tasarım olarak düşündüm ve daha sonra refactor ve daha iyi hale getirmeme izin verecek kadar kod yapmaya çalışıyorum. Ayrıca, değişecek kodu aynı kalan kodla ayırmaya çalışın. Yeniden yapılanma daha kolay hale gelir, çünkü değişmemesi gereken kod gelecekten sizin veya bir başkasından daha güvenlidir.

Bağırsak hissinin seçeneklerden birine karar vermesine izin vermeye ne dersin ? Bu oldukça hızlı bir şekilde ilerlemeli ve cep telefonunun da teklif ettiği timeboxing ile iyi uyum sağlamalıdır . Seçenekler önceden belirlenmişse 1 dakika, önce bunları tanımlamanız gerekirse 2 dakika sürebilir. Ya da uygun görünen her şey (önceden tanımlanmış). İçgüdülerinizi dinlemeyi öğrenirken, sezgisel seçiminiz pratikle daha hızlı ve daha iyi hale gelecektir .

Mükemmel olmayan bir seçim yapma ihtimalinden endişe duyuyorsanız, işte size hitap eden bazı düşünceler:

• Diğerleri üzerinde net bir kenarı olan bir seçenek olsaydı, hangisini seçeceğinizi kendinize sormazdınız. Bu nedenle, bu gerekçe ile, ne zaman çok karmaşık olmayan bir konuda bir seçim konusunda kararsızsanız, bu seçeneklerin hepsinin tamamen eşit olduğunu gösterir; Bu yüzden, sadece herhangi birini seçerek kaybedecek pek bir şey yok .
• Olduğu söyleniyor, sezgi hiç rastgele değil, ama en uygun çözüm için oldukça iyi, eğitimli bir tahmin . Çoğunlukla, sınırsız telaşla karşılaşarak ortaya çıkacak olandan daha iyi.
• Mükemmeliyetçiliğe karşı çıkıldığında, birinin performansının yarı bilinçli bir şekilde değerlendirilmesi durumunda kararın süratli olması tercih edilen iyilik derecesinden daha yüksek olabilir . Bu, önemsiz seçeneklerle tam anlamıyla anlamlıdır, ancak akılda tutulması önemsiz değildir.

İyi şanslar! :)

Bence biraz tecrübe ile ortadan kayboluyor. Paralizimin çoğu gerçekleşiyor çünkü kod üssünün neye benzediğinden daha ileride neye benzeyeceğini hayal etmeye çalışıyorum çünkü üstesinden gelmek için çalışacak ve sonra devam edecek en basit şeyi yapıyorum. Proje kesin bir şekle sahip olduğunda, tekrarlayan kod birimleri göze çarpmaya başlar ve tekrarlayan kalıpları soyutlamak ve kodu basitleştirmek için yeterince kolaydır.

Karar verme konusundaki isteksizliğin üstesinden gelmek için, zaman çizelgesini uygula : birkaç dakika içinde çalması için bir alarm saati ayarla; o zamana kadar zihninizi eziyet edin, ancak alarm çaldığında, o zamana kadar bulduğunuz en iyi seçeneği seçin.

Bir prototip oluşturun. Unutmayın, bir prototip atılmak için yapılır, bu yüzden hangi fonksiyonları, değişken ismi veya hatta kullandığınız büyük mimariyi fark etmez. Sadece işe yaradığını ispatlamak için inşa ediyorsun.

Bir kez yaratıp attıktan sonra, bu kararları almak için daha kolay bir zamanınız olacağına bahse girerim.

Ben de bu sorundan muzdaripim. Söyleyeceğim şey, yeterince tamamlama teşvikiniz olmadığı.

Örneğin, oluşturma kodu yazarken, büyük bir tamamlama teşviki aldım, çünkü bildirebilirsem, sistemi çalışırken görebilir ve dörtlü yapı için ne kadar harika olduğumu düşünürdüm. veya bir verteyi dönüştürmek. Ama şimdi yeniden faktoring yaptığım için (deneme 4, bilmek istersen) o zaman acı çekiyorum çünkü çok işim var ve bitirsem bile aynı eski dörtlüyü göreceğim. Ve ben gerçekten tekrar kırmak zorunda kalmak istemiyorum ve aynı eski dörtlüyü tekrar tekrar görmekten bıktım ve artık benim için bir ödül değil.

Bileşenlere ayırmanız ve bunları bitirmek için kendinizi ödüllendirmeniz gerekiyor, sadece çalıştığını gösteren bir konsol g / ç olsa bile.

Ben sorunuzu okuyordum ve diğer afişlerin çizgisinde bir şeyler düşünüyordum: bu işe uygun değilsin; kendinize bir zaman sınırı verin; bir an için başka bir şey yapın. Bazı yansımalardan sonra, cevapların hiçbirinin gerçekten bu kadar yardımcı olduğundan emin değilim.

Bunun gibi zihinsel sorunların sorunu, çözülmesi kolay olmadıkları, sizin bir parçanız olduğu ve açıkça işinizle (belki de çok fazla) ilgilendiğiniz, kendinizle aynı fikirde olmak için kendinize güvenmediğinizdir. ilk tercihinizin doğru olduğunu düşünmeye deneyimsizdim, ya da mükemmel şekilde doğru yapmak için çok fazla strese maruz kalın. Başka neden böyle önemsizlikler için endişeleniyorsun ?!

Şimdi benzer sorunlar var, ama kod çok değil .. genellikle akşam yemeği için ne olması gerekir .. pizza veya köri .. hmm ... pizza ama sonra köri güzel, ama bir köri gibi hissediyorum, pizza daha ucuz , ama o zaman daha çok köri olur, ama ... :)

Bu yüzden düşündüm - neden kodlama ile benzer problemlerim yok ve bunun basitçe kullandığı bir düzen var. Bir fonksiyon tanımlamasına ihtiyacım olursa, kolay .. Kodladığım diğer tüm fonksiyon tanımlarıyla aynı damarda olacak. Bir kontrol akışına ihtiyacım olursa, önce bir for döngüsüne veya bir süre döngüsüne ihtiyacım olup olmadığına karar veririm ve sonra en son kullandığım eski koddan bunlardan birine ihtiyacım olur. Aynı şey her şey için geçerli, sıra mı istiyorum? Sure - 'standart' sıra kodumu kesip yapıştıralım (üzerinde çalıştığım son projeden ya da bunlardan birini kullanarak hatırlayabildiğim herhangi birinden). Sonuç ... Sadece yeni şeylerden korkuyorum ve dürüst olmak gerekirse, bu bir zevk.

Bu yüzden benim tavsiyem bir kod pasajı kütüphanesi oluşturmaya başlamaktır - bunları kendime e-posta ile gönderir ve bir klasöre koyardım, ancak ne yaparsanız çalışın en iyisidir - ve o zaman her zaman ne yapacağınızı öğrenmeye başlarsınız. Her zaman yazdığınız eski koda gidersiniz ve problemi ortadan kaldırırsınız, bir sonraki problem için hazır olursunuz. Daha hızlı bir geliştirici olduğunuzu göreceksiniz (ciddi anlamda, programcı verimliliğini kazanmanın tek yolu budur) ve umarım çoktan çözdüğünüz sıkıcı günlük işler için eğlenceli bitler için zaman bulacaksınız. bitmiş.

Tabii ki, bunların son kısmı da önemlidir - ne kadar çok işiniz olursa o kadar az lüks düşünmek zorunda kalırsınız.

İşte Rein Henrichs ( basit, refactor ) ve cephane ( timeboxing ) ' in önerilerini birleştiren bir strateji :

1. Sadece işe yarayan ilk çözüm için kendinize oldukça katı bir zaman sınırı verin . Değişken adı için 30 saniye. Önce böyle bir şeyle gelebilir x, sonra da rafine edebilir string, sonra zaman namedoluncaya kadar.
2. Ardından belirli bir süre, örneğin 10 dakika boyunca diğer görevlere geçin .
3. Ancak o zaman kararınızı daha da geliştirmek için kendinize başka bir zaman çizelgesi verin.userHandle

Bu yaklaşımın olası faydaları :

• Buna daha sonra geri dönme bilgisi, şimdilik problemden vazgeçmeyi kolaylaştırabilir
• diğer görevleri sürdürürken, zaman alan iş kaybı olmadan sadece tatmin edici bir çözüm bulabilirsin
• 1. adımdan sonra bırakıp 2. adımın akışına girdikten sonra , 2. adıma devam etmek istediğiniz için 3. adımı gerçekten hızlı tutmak kolay olabilir ve bu nedenle mutlu bir şekilde tek bir iyi çözüm seçin ve kabul edin

Araştırmayı yaptığımda ve net bir en iyi seçeneğim kalmayacağı zaman, kendime bir tane seçmek için kendime bir zaman sınırı (genellikle 5 dakika) veriyorum, sonra sadece ilerlemeye devam ediyorum . Engellerle karşılaşsanız bile, bu noktada, garanti yoktur, farklı bir karar vererek eşit bir engele çarpmazsınız. Kararım için pişmanlık duyduğum bir zamanı düşünemiyorum.

Genelde karar verememenizin nedeni aradaki farkın önemsiz olması veya yeterli bilgiye sahip olmamaktır.

Durumda a) Göz önünde bulundurulması gereken makul seçeneklerin ortaya çıkması için bir zaman sınırı belirleyin. Hangisine henüz karar verme. Sürenin sonunda, belirlenen seçeneklerden birini (net bir ön tercih yoksa rastgele) ve bir başka zaman sınırı seçin. Zamanın sonunda net bir karar alınmazsa, zaten seçilen karardır. Eğer açıkça yanlış anladıysanız, kodlamaya başlayın ve yeniden yönlendirici. Patron nedenini sorarsa, "yazı tura attım, daha iyi bir yolun var mı?"

B) durumunda - daha fazla bilgiye ihtiyacın var, ve büyük şişman A'nın üzerinde oturup ... bütün gün bunu sağlamayacak. Tasarım modundan çıkın ve bilgi toplama moduna geçin. Prototipler, soru sormak, teknik dergileri okumak. Ne yaparsan yap, çok uzun süre uyuma.

Genellikle, en iyi çözüm kararınızı bir meslektaşınıza açıklamaya çalışmaktır. Ancak, bunu çok sık yapmak istemediğiniz için, bir sonraki en iyi şey kağıt üzerinde düşünmek - ya bir kâğıt / kalem ya da boş bir not defteri penceresi.

Kesinlikle bir şeyler yazarak başlayın - sadece yazma ritmine girmek için. Bir not defteri penceresinde sadece "Kağıt üzerinde düşünüyorum" yazıp ardından bir bilinç akışı ile devam edebilirsiniz. Birkaç saniye sonra yazma ritminde olacaksınız, bu yüzden birkaç kez enter tuşuna basın ve ikileminizi açıklamaya başlayın.

Sorunu, ardından olası çözümleri, her biri için neyin iyi olduğunu vb. Belirtin.

Her zaman işe yaramasa da, düşüncelerinizi kafanızdan (RAM) ve harici ortama (not defteri belgesi) alma işlemi size yeni bağlantılar kurma ve kararı farklı açılardan görme konusunda daha fazla özgürlük verir.

Ben de aynı problemden muzdaripim. Küçük problemler için, bununla başa çıkmaya çalışmamın yolu aptalca olmadığını düşündüğüm ilk tasarıma geçmektir. Optimal bir tasarım bulmaya çalışmanın bir anlamı yok; Yazmadan düşünebileceğiniz tüm tasarımların nüanslarını düşünmek imkansız değilse de zor. Kod olarak, küçük geliştirmeler yapabileceğinizi göreceksiniz. Doğru yapıldığında, bu şekilde oldukça iyi bir çözüme yakınlaşmanın oldukça kolay olduğunu düşünüyorum.

Daha büyük problemler için, ilk önce seçenekleriniz üzerinde düşünmenin bir yararı olduğunu düşünüyorum ama zaman çizelgesini kullanın. Büyük problemlerin büyük çözüm alanları var, her olasılığı değerlendiremezsiniz, ne denemelisiniz.

TLDR; Makul bir çözüm seçin, ilerledikçe geliştirin.

Bu aynı zamanda ilgilidir:

Seramik öğretmeni açılış gününde sınıfı iki gruba böldüğünü açıkladı. Stüdyonun sol tarafındaki herkes, yalnızca sağladıkları işin miktarına, sadece sağdakilerin kalitesine göre derecelendirileceğini söyledi. Prosedürü basitti: sınıfın son gününde banyo terazisini getirip "miktar" grubunun çalışmalarını tartıştıracaktı: "A" olarak değerlendirilen elli pound pound, "B", vb. Bununla birlikte, "kalite" ile derecelendirilenlerin, "A" almak için yalnızca bir tane, hatta mükemmel bir tane bile pot üretmesi gerekiyordu.

Eh, sınıflandırma zamanı geldi ve merak uyandıran bir gerçek ortaya çıktı: en yüksek kalitede çalışmaların tümü, miktar için derecelendirilen grup tarafından üretildi. Görünüşe göre, "nicelik" grubu iş yığınlarını yoğun bir şekilde çalkalarken - ve onların hatalarından ders alırken - "kalite" grubunun mükemmellik konusunda teorisyen oturduğu ve sonunda çabaları için görkemli teorilerden daha az gösterdiği ve ölü kil yığını.

dan http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Bunu asla anlamadım. Ben eğitmenken şöyle bir şey söylerdim:

"OK, create an integer variable and assign the return value of strlen() to it."

Çok karmaşık değil, düşünebilirsiniz ve insanların% 95'i şöyle bir şey yazdı:

int x;   // or y, or len, or whatever
x = strlen( s );

Ancak ara sıra farlarda felç gibi bir tavşan gibi oturan biri olurdu. Sorunun ne olduğunu sempatik bir şekilde sorardım ve "Ne diyeceğimi bilemiyorum" derlerdi.

Bunlar başka bir kariyere bakması gereken insanlar. Belki de yapman gerektiği gibi.