Ne yaptığımı ve neden üç ay önce bir projede olduğumu nasıl hatırlamalıyım?


72

Üç ay önce bir proje üzerinde çalışıyordum ve sonra aniden bir başka acil proje ortaya çıktı ve dikkatimi değiştirmem istendi.

Yarından itibaren eski projeye geri döneceğim. Tam olarak ne yaptığımı hatırlamadığımı fark ettim. Nereden başlayacağımı bilmiyorum.

Bir projeyi nasıl geri döndüğümü nasıl belgeleyebilirim, bıraktığım yerden gitmem birkaç dakikadan fazla sürmemelidir. En iyi uygulamalar var mı?


98
yorum yapın ve mesajları gönderin, insanların onları bırakmanızı söylemesinin bir nedeni var
cırcır ucube

5
Bu gerçekten projeyi ilk etapta nasıl takip ettiğinize bağlı değil mi? Her şeyi bellekten yaptığınızı ve başka hiçbir belge olmadığını varsaymalı mıyız?
JeffO

4
@ratchetfreak Aynı prensibi herhangi bir şeye uygulayabileceğinizi fark edene kadar "Bu sadece geliştiriciler için yararlı" demek üzereydim. Çoğu belge deposunda bir notlar bölümü veya bir açıklama bulunur; e-posta üzerinden teslim edilebilecek ileti gövdeleri vardır (genellikle yoksayılır). Belgeler değişiklikleri ve ek açıklamaları izleyebilir. PM dünyasında da bir tür yorum ekosistemi ve mesaj mesajı var! </epiphany>
corsiKa

6
Sürüm kontrol sistemini, en son ne yaptığımı hatırlatmak için kullanıyorum ve hala yapılması gerekenleri bulmak için bir hata takipçisi kullanıyorum.
Lie Ryan,

2
Evet, işten üç ay ara verdikten sonra, son projemi tanımlamak için bir iş görüşmesi istendi. Yaptım, ama ayrıntılar istediklerinde, hayatım boyunca onları hatırlayamadım. Beni geri çevirdiler çünkü görünüşe göre ben bir sahtekarım, eğer hatırlayamıyorsam. Bu yaklaşık 15 yıl önce oldu, ama hala hatırlıyorum.
Andrew Savinykh

Yanıtlar:


35

Sadece şu anki durumunuz için faydalı olmayacak bazı tavsiyelere katkıda bulunmak istedim, ancak gelecekte yardımcı olmak için şimdi uygulamaya başlayabilirsiniz.

Tabii ki yapılacaklar listesi ve düzenleme kayıtları gibi açık adaylar var; Yeni eklenen konulara bakmak, projeden çekilirken ne yaptığınız konusunda size bir ipucu vermelidir.

Çalıştığım önceki projelerde, insanların kalite yönetimi sürecinin bir parçası olarak bir proje günlüğü tutmaları bekleniyordu. İçindekiler çok açık bir şekilde belirtilmemiştir, ancak fikir gelecekteki çalışmalara devam etmek veya bitirme konusundaki çalışmaları gözden geçirmek için faydalı olabilecek projeyle ilgili günlük bir şeyler tutmak; Örneğin:

  • Projenin kalitesi ile ilgili gözlemler

    bu kod bazı refactoring kullanabilir

    Bunu işe almak için hızlı bir uygulama yaptım ama ABC daha iyi olurdu.

  • Bir sorun izleyicide resmi olarak kaydetmek istemeyeceğiniz öğeler / sorunlar

    "bu yöntemin işe yaramasını sağlamalı, x < 0ancak şu anda kapsam dışında.

  • Tasarım kararları - özellikle önemsiz kararlar .

    Standart sıralama işlevimiz hızlı bir sıralama gerçekleştirir, ancak burada gereksinim duyduğumuz sıralama koşulu altında eşit olan öğelerin sırasını korumaz.

    Açıkça görülen algoritma ABC olacaktır ancak bu başarısız olur çünkü xnegatif olabilir, bu yüzden genelleştirilmiş forma ihtiyacımız var ( Wikipedia link ).

  • Karşılaştığınız sorunlar ve bunları nasıl çözdüğünüz. Çok önemli bir tane, benim görüşüme göre: Ne zaman bir sorunla karşılaşırsanız kayıt defterine yazınız.

    Kodu teslim aldım ancak hata XYZ0123 verdi, ilk önce C bileşenini sürüm 1.2 ya da daha üstüne yükseltmek zorunda kaldım.

İkinci iki nokta çok önemlidir. Sık sık benzer bir durumla ya da problemle karşılaştım - bazen tamamen farklı bir projede - ve "hmm, bunun için bir gün geçirdiğimi hatırlıyorum, ancak çözüm neydi?" Diye düşündüm.

Bir süre sonra bir projeye geri döndüğünüzde, proje günlüğünü geri okumak (kendi veya en son geliştiricisinin) sizi bıraktığınız zamanki akışa geri döndürmeli ve sizi bıraktığınız bazı tuzaklar konusunda uyarmalıdır. Aksi takdirde tekrar içine düşebilir.


68

Yapılacaklar listeleri sihirlidir. Genel olarak, her proje için ve programlama yapmakla meşgul olsanız bile, yapılması gereken bir şeyi düşünüyorsanız ve hemen yapamazsanız, o zaman listeye girer. Bu listeyi, elektronik olarak proje dosyasındaki bir elektronik tabloda veya metin dosyasında veya kağıt kayıt defterinizde iyi bilinen bir yerde saklayın.

Ayrıca, projeyi bir gece (veya haftasonu boyunca) ne zaman terk ederseniz, bir not alın ve bir sonraki notu notun üzerine yazın ve monitöre yapıştırın. Bu, ertesi sabah hızlı bir şekilde geri dönme olasılığını artırır.

Düzenle :

Yapılacaklar listelerinin (özellikle, mekan ve proje tarafından ayrılmış öncelikli yapılacaklar listelerinin) son derece etkili bulduğum İşler Başlarken kitabının önemli bir parçası olduğunu söylemeliyim .


22
Küçük görevlere sahip çevik bir proje üzerinde çalışıyorsanız, backlog, bu proje için birincil yapılacaklar listeniz olmalıdır.
Bart van Ingen Schenau,

1
Geçenlerde son paragrafta bahsettiğin şeyi yapmaya başladım ve bu sabah gitmeme büyük yardım etti.
TMH,

5
Aslında. Her zaman yokuş aşağı park edin. Bu bir alışkanlık meselesi. Daha sonra ne yapacağım konusunda kendim için kodda veya yapılacaklar listemde not almadan asla bir kod tabanı bırakmam. Ayrıca yapmak zorunda olduğumu bildiğim her şeyin kaynağında yapılacak bir iş olup olmadığından emin oluyorum (TODO: konvansiyonu IDE'm'in tespit edip listeleyebileceği yorumlarda kullanıyorum) veya ayrı yapılacaklar listemde (I Tüm projeler için sadece bir tane var, ama kategorize ve öncelikli).
Joeri Sebrechts

3
Koddaki TODO'lar mükemmel, ama ufacık küçük şeyler için bile onları yerleştirme konusunda gayretli olmalısınız. todoMakefile dosyasında onları döken bir hedefin olması da yararlıdır.
Blrfl

4
trello.com bir hayat kurtarıcıdır. Geçen hafta ne yaptığımı ve bu hafta üzerinde ne yapmam gerektiğini hatırlamakta zorlandığım Pazartesi Monring ekibi toplantıları için bile. Onun da ücretsiz.
SimonGates,

33

Şimdi ne yapmalı?

Şimdi, yarından itibaren eski projeme geri döneceğim ve tam olarak ne yaptığımı ve nereden başlayacağımı hatırlamadığımı fark ettim!

Benim tahminim bir sonraki bölümün hiçbirini yapmadığınızdır. Yani yapılacaklar listesine bakmak işe yaramaz.

  1. Bir süre engelleyin. Bunu takviminize ekleyin ve projeyi gözden geçirmek için zaman ayırın. Bu, dokümantasyonu, kodu, gereksinimleri vb. Gözden geçiriyor olabilir.
  2. Hızlanmak için biraz zaman alacağınızı kabul edin. Tüm katılımcıların bunu gerçekleştirdiğinden emin olun. Bunu anladığına emin ol .
  3. Küçük bir görevle başlayın. Küçük bir şey yaparak güveninizi yeniden oluşturun. Yeni öğelerin bir listesine sahipseniz, önce küçük olanlarla çalışın. Bu sadece güveninizi yeniden inşa etmekle kalmaz, aynı zamanda proje ile kendinizi yeniden canlandırmanıza yardımcı olur.

Bunu gelecekte kendiniz için nasıl daha iyi hale getirebilirim?

Projeyi nasıl belgeleyeceğimi bilmek istiyorum, geriye dönüp baktığımda, bıraktığım yerden gitmem birkaç dakikadan fazla sürmemeli!

İlk olarak, todoslarınızı takip etmek için bir sisteme ihtiyacınız var. Şimdi böyle bir sisteminiz var mı? Mevcut projenizi nasıl yönetiyorsunuz?

Ben alabilir bir otobüs yarın çarptı ve ekibim benim işlem öğelerinin aşkın% 90 iyi bir fikir olurdu. Bunun nedeni, belgelendirmek için uyumlu bir sisteme sahip olmamdır:

  • Acil todos (<1 hafta ürün)
  • Todos "olması güzel"
  • Kilometre taşları ve makro todos (özelliklerin anlamlı olmadığı yerlerde)
  • Gereksinimler / toplantı notları

Artı, bir VCS kullanıyorum ve uygun olduğunda kodumu yorumluyorum.

Bu benim için ve ekibim için işe yarıyor. Bir takım için bir çeşit sorun takip sistemi kullanabilirsiniz. Veya Agile ile çalışırken bir biriktirme listesi. Bir sürü seçenek var. Bununla gerçekten ilgileniyorsanız, tarif ettiğiniz şeyler nedeniyle neredeyse kesin olarak var olan İşleri Tamamlama veya diğer ilgili görev yönetimi yöntemlerini okuyun.

Amaç ne?

Sistemin özellikleri, uyumlu sistem olduğundan daha az ilgilidir ve siz onu kullanırsınız . Ve onu kullandın. Ve kullan. Bu önemli. Kullanmadığınız güzel ve mükemmel bir sistemden daha önemlidir. "İşimin çoğu burada, ama bazıları kafamın içinde" değil mi, yoksa bir projeye geri dönmekten nefret edersin.

Ayrıca, yorumlarınızın yalnızca kod için "ne" yerine "neden" i açıkladığından emin olun. "Bu, IE8 ile bir hatayı düzeltmek için" okumak ve kodun sadece teknik ayrıntıları açıklayan bir yorumdan başka ne yaptığını hatırlamak çok daha kolaydır.


@TheIndependentAquarius sorun değil, yardımcı oldu sevindim. Bu durum çok zor olabilir.
enderland

@InInependentAquarius muhtemeldir, çünkü genellikle yorumlar post-it / stickies şeklindedir. Stack Exchange'in "bu cevap harikaydı" deme biçimini belirleme yöntemi ya bir yanıtı ya kabul ediyor ya da kabul ediyor. Buradaki yorumların mutlaka devam etmesi amaçlanmamıştır.
enderland

Bu "yapılacaklar" listesinin çok daha düzenli bir versiyonu, bir sorun takip sistemi kullanmaktır. Mevcut birçok ücretsiz sistem vardır ve birçok ücretsiz Git sağlayıcı, hizmetlerinde yerleşik bir sisteme sahiptir (bkz: GitHub).
BTownTKD

@BTownTKD Benim cevabım :) :)
enderland

Onun iyi bir cevap; vurgu için eklendi.
BTownTKD

14

Bence bir kod projesini "devam ettirmek" için iki bölüm var:

  1. Nerede kaldığını belirleme
  2. Ne yaptığını hatırlamak zorundasın.

Bu, bence, sürüm kontrolü doğru şekilde yapıyorsanız, “diğer beyniniz” olacak şekilde düşünüyorum.

Nereden ayrıldın ? Sık sık kod işlediğiniz sürece, son değişiklik kümenize bakın. Büyük olasılıkla aklınızda bir şey dürtmek olacaktır. Değilse, en eskiden başlayarak ve tekrar eden taahhütlerden başlayarak geçmiş birkaç kişiye bakın.

Ne bırakmanız gerektiğine gelince , bir birikim bu amaca hizmet etmelidir (veya yapılacaklar listesi veya ne şekilde isimlendirmek istiyorsanız. Gelecek için temel öğeler).

Tam zamanlı bir yazılım geliştiricisi değilim. Ben geceleri ve hafta sonları hackleyen bir programcıyım. Bu nedenle, iş veya diğer programlama dışı şeyler daha yüksek önceliğe sahipken, bazen kodumu bir bakışta bile incelemeden günler ve haftalar boyunca gidebilirim. Yukarıdakilerin oldukça etkili olduğu kanıtlanmıştır.


10

Bu, tam bir cevap niteliğinde değildir - VCS'nizi ve proje yönetimi yazılımınızı nasıl kullanacağınız gibi önemli şeylerden bahseden çok iyi birkaç tane var - ama başka hiçbir yerde görmediğim birkaç nokta ekleyen bir zeyilname çok yararlı olduğunu ve diğer insanların da yardımcı olacağını umuyorum.

1. Hiçbir görev yazmak için çok erken ya da çok küçük

İnsanlar genellikle YAPILACAK yaptıkları plan şeyler için listeler yapmak gelecekte , ancak programlama konsantrasyon gerektirir çünkü biz kesilebilir beri ve her an , ben yazmak için yararlı buldum , şu anda yapıyorum bile neyi ya da birkaç saniye içinde başlamak üzere olduğum şeyi . Sen bölgesindesin hissedebilirsiniz ve muhtemelen sadece size isabet çözümü unutamadı aha an, ama İş arkadaşınız size onun enfekte ayak resmini göstermek için küp tarafından düştüğünde , ve siz Sadece kendi kolunu kemirmeye başlayarak ondan kurtulabilmen için, yalnızca bir Post-It ™ notunda olsa bile, kısa bir not yazmak isteyebilirsiniz.

Elbette, daha kalıcı başka bir ortam daha iyi olabilir (özellikle OmniFocus'a düşkünüm ), ancak asıl konu , 20 dakika içinde bitirip Post-It ™ 'i atmanız durumunda bile, en azından bir yerde olması. Bu bilgilerin yararlı olduğunu keşfedebilseniz de, müşteriye zaman çizelgeleri veya faturalar koymak için veya patronunuz / müşteriniz size üzerinde çalıştığınız şeyi sorduğunda ve hatırlayamıyorsanız. Tüm bu notları bir kutuya veya çekmeceye ya da klasöre bırakırsanız, büyük bir kesinti çarptığında - kesen bir proje - o zaman onlara göz atabilir ve kodunuzu almak istediğiniz noktaya getirmek için yaptığınız birçok şeyi hatırlayabilirsiniz. Projeye döndüğünde bul.

2. Büyük resimli fikirleri yakalamak için masanızda bir beyaz tahta kullanın.

Masamın yanında 3 "x 4" boyutunda bir beyaz tahta var, bu yüzden bir projeye başladığımda, bir projede algıladığım tüm sorunların çözümlerini beyin fırtınası yapabilirim. Mimari şemalar, kullanım durumları, risk listeleri ve engel listeleri veya sizinle alakalı görünen herhangi bir şey olabilir.

Bazı daha resmi yaklaşımlar, bazı kâğıt veya elektronik formatta diyagramlar oluşturmanızı ve vakalar ve daha fazlasını "teslim edilebilirler" olarak kullanmanızı gerektiriyor, ancak bunun çok fazladan fazla iş yaratabileceğini ve sadece sona erecek bir dizi alt proje haline gelebileceğini düşünüyorum ana projenin asıl amacından boşanmak ve yapmanız gereken ancak hiç kimsenin çok fazla ilgilenmediği resmi bir sürecin sadece bir parçası. Bir beyaz tahta, en azından benim deneyimimde gerçekten işe yarayan en basit şey. İstediğiniz kadar ısrarcı (kameralı) ve en önemlisi fikirlerinizi derhal indirmenize izin veriyor.

Elimde bir kalemle daha iyi düşünüyorum, bu yüzden düşüncelerimi beyaz bir yüzeye dökmek doğal olarak bana geliyor, ancak bunun sizin için uygun olduğunu bulamazsanız, burada neyin uygun olduğuna karar vermenize yardımcı olabilecek bazı sorular var. :

  • Lider geliştirici olsaydım, diğer geliştiriciler projeyi tamamlarken 3 ay boyunca bir balayına çıkmak üzereydim, onlara hangi genel yönü vermek isterdim? Hangi fikirleri bildiklerinden emin olmak isterdim ya da yaklaşımlarını aldıklarından emin olmak isterdim? Hangi kütüphanelerin veya diğer yararlı çözümlerin farkında olduklarından emin olmak isterdim?
  • Eğer bu proje milyon dolarlık bir fikrim olsaydı gelecekteki finansal bağımsızlığımı sağlayacağını biliyordum, ancak 3 ay boyunca beni aciz edecek kritik bir ameliyat için planlanmıştım. proje?

(Fikirleri ilk yazdığımda, sadece şimdiki zamanlarıma mantıklı geldikleri için endişeleniyorum. Aşağı düştüklerinde, onlara daha eleştirel bakabilir ve geleceğime veya başkalarına anlamlı gelmelerini sağlamak için değişiklikler yapabilirim. diğerlerine yaklaşık olarak . hedeflerini yarışarak tıkanmış yazarlar blok-bir zihin yol açabilir başlangıçta bunları yaz önce onu Eğil, daha sonra netlik dert).

Parayı en az 3 "x 4" değerinde bir beyaz tahta almak için harcamanızı ve normalde çalıştığınız alana asmanızı öneririm. Fiziksel bir beyaz tahtanın herhangi bir sanal sisteme göre birçok avantajı vardır.

  • Büyük. Çok fazla yer kaplayarak varlığını hissettiriyor ve üzerindeki planlar çalışma alanınızın bir parçası gibi hissediyor ve sizi her zaman doğru yöne yönlendirmeye yardımcı oluyor.
  • Israrla var: erişmek için belirli bir uygulama veya web sitesi başlatmadınız ve nasıl ulaşacağınızı veya orada olduğunu unutmayı riske atmayacaksınız.
  • Düşünmek istediğiniz bir fikriniz olduğunda hemen erişilebilir.

Toplantı odasında yalnızca bir beyaz tahta kullanıyorsanız ve ardından telefonunuzla anlık bir görüntü çekiyorsanız, birçok avantajı kaybedersiniz. Programlayarak para kazanıyorsanız, iyi bir beyaz tahtanın maliyetine değer.

Başka bir proje varsa telefonunuzda anlık başvurmak gerekebilir, sizin beyaz tahta doldurdu birini kesmek, ama en azından gerekecek o 3 ay içinde "acil" projesi bittiğinde ve bunu yapmak zorunda diğerine dönün. O zaman beyaz tahtanızda yeniden oluşturmak istiyorsanız, muhtemelen sadece 15 dakikanızı alır ve bu süreçte çok daha fazla geliştirebileceğinizi görebilirsiniz, bu da zamanın küçük yatırımını çok değerli kılar.

3. Paydaşları bir projeyi durdurmanın maliyetinin farkında olma

Bir uçağın metaforunu faydalı buluyorum: bir projeyi başlatmak ve tamamlamak bir uçağı uçurmak gibidir. Uçuşun tam ortasından ayrılırsanız, uçak oraya geri dönmenizi bekleyen havada oturacak ve mevcut projeden / uçuştan diğerine seyahat etmek için bir yola ihtiyacınız olacaktır. Aslında, Phoenix'ten Fargo'ya bir uçuşun ortasındaysanız ve Denver'dan Detroit'e başka bir uçağa binmek için bu uçuşu durdurmanız gerektiği söylenirse, Denver'daki ilk uçağı inmeniz gerekir (ki bu Neyse ki uçuş rotanızdan uzakta değil - her zaman gerçek kesintilerde söz konusu değil) ve birinin kargo ve yolcularla ne yapması gerektiğini çözmesi gerekiyor. Sadece oturup sonsuza dek beklemeyecekler.

Projeler için bunun amacı, bir projeden diğerine geçişin büyük bir zaman harcaması ve ele alınması gereken çok fazla kaybedilen sonuç bırakmasıdır.

Bir projede çalışmak ve yaparken aklından bir sürü besbelli ve kaçınılmaz olarak orada değil her düşünce bu düşüncelerin en ufak bir yazılı orta tefrika değil edilebilir olan serileştirilemezse zaman kalacaktır tefrika. Düşüncelerimizi kısmen yazılı olarak yakalayabilmemize rağmen, bu çok kayıplı bir formattır.

Sorun (gördüğüm gibi), proje yöneticileri ve diğer iş adamlarının, projeleri (genellikle kendi Gantt şemalarına açık bir bağımlılık olmadıkça) istedikleri şekilde yeniden düzenlenebilecek bir adım olarak düşündükleri ve insanlar arasında kolayca dağılabildikleridir. veya iş için en uygun olana kadar ertelendi.

Herhangi bir miktarda programlama yapmış olan herhangi bir kişi, yazılım projelerine dilediğiniz gibi hareket ettirilmek üzere Lego blokları gibi davranılmayacağını bilir. En azından hava yolculuğu metaforunun paydaşlara, bir hevesle yeniden sıralanacak bir dizi farklı adım olarak değerlendirilemeyeceği konusunda düşünebilecekleri somut bir şey verdiğini düşünüyorum. En azından bu kesintilerin bir bedeli olduğu noktasını anlamayı kolaylaştırıyor . Tabii ki hala onların kararıdır, ancak bir projeyi size bir başkasını vermek için kesmeden önce, bunun farkında olmalarını istersiniz. Mücadele etmeyin, ancak yararlı bilgiler ve geliştiricinin yararlı perspektifini sunun, sizden ne gerekiyorsa yapmaya hazırsınız, ancak onlara söylemeyince farkında olmayabilecekleri bilgiler sunun.


Kısacası:

  1. Sen her şeyi yazın yaklaşık sen hiç muhtemelen aşağı yazılı gerek sanmıyorum bile yapmak. Kısa bir kalem bile uzun bir hafızayı atıyor.
  2. Büyük resme, ısrarla erişebildiğiniz fiziksel bir beyaz tahta üzerinde beyin fırtınası yapın.
  3. Sen belki böyle kesintileri için bir maliyet olduğunu karar verici farkında yaparsanız proje kesintilerini önlemek ve onlar bunu sürdürmek zaman proje biraz daha uzun sürecektir biliyorum en azından beklentilerini şekillendirmeye sahip olacaktır.

1
Paydaşlar, kodunu yorumlayan ve belgeleyen profesyonel bir geliştiriciye ödeme yaptıklarını, böylece (daha sonra) veya başka birisinin (herhangi bir zamanda) projeyi devralabileceğini varsaymaktadır. Elbette varsayımları çoğu zaman yanlıştır.
JeffO

Ve yorum yapmalı ve belgelendirmelisiniz! Umarım aksi önerdiğimi düşünmedin. (Bu arada yorumunuzla aynı fikirdeyim.)
iconoclast

2

Projenin geçmişini sürüm kontrol yazılımınızda üç ay öncesinden arayabilirsiniz. Üzerinde çalıştığınız şey hakkında bir fikir edinmek için taahhüt mesajlarınızı ve en son değişikliklerinizi okuyun.


Bu cevabın yenilenmemesine şaşırdım. Sürüm kontrol günlüğü, projenin geçici olarak askıya alındığı birkaç ay önce birinin nerede olduğunu bilmek için mükemmel bir yoldur. Sil günlük mesajları çok yardımcı olur. Değiştirilen dosyaların farklılıkları ve listeleri, askıya alınmadan önce projede neler olup bittiğinin bir resmini elde etmenin ek bir yoludur. Son olarak, değerli bu cevabı yapar (ya da basit bir yapılacaklar listesi) bir hata takip sistemi kullanmak geliştiriciler sayısı karşılaştırıldığında bir versiyon kontrolünü kullanan geliştiriciler vardır daha fazla kişiye Scott tarafından son derece upvoted cevaba göre Whitlock.
Arseni Mourzenko,

2

Bir sorun takip sistemiyle ( Redmine veya GitHub gibi ) uygun bir şekilde dallanma ve birleştirme stratejileri içeren bir kaynak kontrol sisteminin kullanılması , yaptığınız değişiklikleri bölümlere ayırmanıza, yön vermenize ve eksik 'bağlamınızı' belgelemenize yardımcı olur. iş akışının doğal bir parçası.

  1. Bir kod değişikliğine başlamadan önce, sorun takip sisteminizde kayıtlı bir 'sorun' olduğundan emin olun. Bu, çalışmanızın eksik "ne yapıyorum" bölümünü kapsıyor.
  2. Kaynak kontrol sisteminizde bir şube oluşturun ve bu branştaki değişikliklerin SADECE yukarıda belirtilen konu ile ilgili olduğundan emin olun. Bu, değişiklikleri yalıtmanıza yardımcı olacak ve "nereye bıraktım?" Sorusuna cevap vererek size değişikliğin tarihçesini verecektir. Bir kez daha üzerinde çalışmak için geri döndün.
  3. Değişikliği tamamladığınızda, bagajınıza geri koyun ve sorunu kapatın.

1

Çok uzun cevaplar var. Bu bana en çok neyin yardım edeceğine dair kısa bir şey:

  • Temiz kodu.
  • Temiz kodu.
  • Temiz kodu.
  • Sürüm kontrolü (farklılıklar ve yorum yapma).
  • Bir Post-It notu veya bir Todo-List veya Kanban-Board (bakınız örneğin Trello ve Evernote)

Bununla birlikte, Diffler, Yorum yaz, Post-it notları, Todo-Listeler veya Kanban-Board, zaman içinde bağlam eksikliği nedeniyle yanlış yorumlanabilir. İşte burada en önemli olan şey:

TEMİZ KOD.


Ne şekilde tam olarak yapar temiz kod temiz kod temiz kod yardımı ile bir " nasıl yaptığını ve neden bir proje üzerinde üç ay geriye? Ne hatırlamalıyız ve bağlam cevapsız geri alma"? Temiz mimarlık temiz mimarlık temiz mimarlık çok daha fazla yardımcı olmaz mıydı ? Biri ilk önce ayrıntılara dalmaz. Detayları incelemeden önce büyük resmi çekmekle ilgili. Her yerde hazır bulunan amca, maalesef, bu konuda size yardımcı olmayacak. Yine de kesinlikle diğer iki kurşunla aynı fikirdeyim.
JensG

@JensG: Kod mimarisidir. İyi yazılmış bir programda, program mimarisinin üstünü, mainoldukça büyük bir program için oldukça soyut olacak olan fonksiyonda görebilirim . Daha sonra daha derine dalabilir ve örneğin programın kendini nasıl temizlediğinin mimarisini görebilirim. Dahası, temiz kod, işlevler / değişkenler / vb. Anlamına gelir. anlamlı ve anlamlarıyla ilgili açıklama yapan isimler var. Bunun yerine, Spagetti / Yalnızca Yazma kodunu yazarsam, ertesi sabah / ay / yıl sık sık uyanır, koduma bakarım ve tek düşünce wtf-did-i-do-orada olacak. Aynı şey ..
phresnel

... kitap okumak ya da yazmak: Flesch-Kincaid okunabilirlik endeksi 10, muazzam ifadeler, çok karmaşık kelime yapılarıyla okuyucunun anlambilim yerine sözdizimine odaklanmasına izin veriyor mu, yoksa okunması kolay mı? yaklaşık 80 endeksi ile öykünün kendisinde olmamak.
phresnel

Temiz kodun değerini görürsem (ve hiçbir şekilde şüphe duymazsam da) kodun mimarisi olmasına şiddetle karşı çıkıyorum. Kod tüm standartlara göre mükemmel bir şekilde temizlenebilir ve okunabilir ancak yine de büyük resmi göremediğiniz şekilde yazılabilir. Daha sonra soru, " Ne yaptığımı nasıl hatırlamalıyım " ve " Nereden başlayacağımı bilmiyorum " idi. (Temiz) kodun şu anki durumu ile OP'nin aradığı şey arasında herhangi bir kesişme göremiyorum : fikirden ürüne giden süreçte tam yol noktası .
JensG

@JensG: Amacınızı tanıyorum. Bence sadece "Tam olarak ne yaptığımı hatırlamadığımı fark ettim" i farklı yorumluyoruz. Bu bana daha çok "Kulağa hangi algoritmaları ve veri yapılarını hatırladığımı hatırlayamadığımı ve bunları nasıl genişletebileceğimi hatırlamıyorum" gibi geliyordu. tam olarak uygulamaya ve hedefini uygulamaya çalışıyordum. " Belirsiz insan dili. ...
phresnel

1

Bir projeyi nasıl geri döndüğümü nasıl belgeleyebilirim, bıraktığım yerden gitmem birkaç dakikadan fazla sürmemelidir.

Öncelikle, bu, görünür bir yapı ve yorum içermeyen bir zilyon kod satırının aksine, birkaç dakika içinde kolayca kavrayabileceğiniz bazı üst düzey açıklama ve kod yapıları bulunduğunu gösterir.

En iyi uygulamalar var mı?

Aşağıdakiler 20+ yıl boyunca kariyeri boyunca çok küçük ve çok büyük projelerde benimsediğim en iyi uygulamalardır ve bana ve ekiplerime iyi hizmet ettiler. Projeniz büyüdükçe listelenen sıraya göre uygulayın:

  1. Sürüm kontrolünü kullanın , size ne olduğunu, ne zaman ve değişiklikleri uygulayanların ücretsiz bir kaydını verin. Ayrıca, herhangi bir zamanda önceki bir sürüme kolayca geri dönmenizi sağlar.

  2. Kodunuzu modülerleştirin (dile ve programlama ortamına bağlı olarak sınıfları, modülleri, paketleri, bileşenleri kullanın).

  3. Kodunuzu belgeleyin . Bu, her bir dosyanın en üstünde yer alan özet belgeleri (bu ne yapar? Neden? Nasıl kullanılır?) Ve işlevler, prosedürler, sınıflar ve yöntemler düzeyindeki özel yorumlar (ne yapar? Argümanlar ve dönüş değerleri / türleri? yan etkiler?).

  4. TODOFIXMEKodlama yaparken yorumlarınızı ekleyin ve yorumlar . Bu, kaçınılmaz olarak kod tabanınıza girecek olan ve daha sonra WTF'ye soracağınız olan tuhaflıkların nedenlerini ve hatırlamalarını hatırlamaya yardımcı olur. . Örneğin:

    //TODO shall actually compute X and return it
    ... some code that does not compute X yet (maybe returns a fixed value instead)
    
    //FIXME make this constant time instead of n^2 as it is now 
    ... some code that works but is not efficient yet
    
  5. Yapıları ve modüller / nesneler / sistemler arasındaki çağrıların dizileri gibi karmaşık davranışları belgelemek için diyagramlar çizme alışkanlığı kazanın . Kullanımı hızlı olduğu, güzel grafikler oluşturduğu ve en önemlisi yoluna girmediği için şahsen UMLet'i tercih ederim . . Ama elbette işi bulduğunuz herhangi bir çizim aracını kullanmalısınız. Unutmayın ki, bu tür çizimlerin amacı, bir sistemi ayrıntılı olarak belirtmemek için (!!) özlü bir şekilde iletişim kurmaktır.

  6. Erken test üniteleri ekleyin . Birim testleri, sadece regresyon testi için mükemmel değildir, aynı zamanda modülleriniz için bir kullanım belgesidir.

  7. Daha önce kod harici belgeleri ekleyin . Projeyi çalıştırmak ve geliştirmek, nasıl yükleneceği, nasıl çalıştırılacağı konusunda gerekli bağımlılıkları tanımlayan bir README ile başlayın.

  8. Tekrarlayan görevleri otomatikleştirme alışkanlığı edinin . Örneğin, derleme / derleme / test döngüleri bir biçimde yazılmalıdır (örneğin, JavaScript kullanımında grunt, Python'da fabric, Java'da Maven). Bu, geri döndüğünüzde hızlı bir şekilde hızlanmanıza yardımcı olacaktır.

  9. Projeniz büyüdükçe, kaynak kodlu dokümanlar oluşturarak daha fazla dokümantasyon ekleyin (bir miktar JavaDoc tarzı yorum ve ondan HTML veya PDF oluşturmak için uygun bir araç kullanarak).

  10. Projeniz tek bir bileşenin ötesinde büyüyorsa ve daha karmaşık bir konuşlandırmaya sahipse, tasarım ve mimari belgeleri eklediğinizden emin olun . Yine bunun amacının, küçük ayrıntılardan ziyade yapı ve bağımlılıkları iletmek olduğunu unutmayın.


0

Proje takibi ile ilgili önerilere ek olarak, Yapılacaklar listesi, Trello, vb. TDD'yi uygularsanız, projeye geri döndüğünüzde uygulamak için yeni bir başarısızlık testi ile projenizden daima uzak durmak için yardımcı olacak bir kez okuduğum bir şey. gelecek hafta veya gelecek ay

Oturun, 'Testleri Çalıştır'ı yapın ve kaldığınız yerden devam edin.


1
Bunun iki dezavantajı var. İlk olarak, eğer sürekli entegrasyon kullanıyorsanız, bilinçli olarak başarısız bir testi yapmak söz konusu değildir. İkincisi, birden fazla kişiden oluşan bir ekibin içindeyseniz, başarısız bir test yaparsanız diğer insanlar takdir edemeyebilir.
Arseni Mourzenko,

1
@MainMa taahhüt etmedim demedim. Sadece yerel olarak.
Pete,

Herhangi bir geliştiriciye önerim, bir proje üzerinde birkaç günlüğüne bile çalışmadığı zaman taahhüt etmektir. Olur böyle şeyler. Bilgisayarınız çalınmış olabilir veya RAID denetleyicisi arızalı olduğu için yarın önyükleme yapamayabilirsiniz. Projeyi bırakabilirsiniz ve diğer geliştirici sizin yerinizi alabilir. Bir otobüs çarpmış olabilir. Projeyi yerel olarak silebilirsiniz çünkü çok fazla yer kaplıyor ya da virüs işletim sisteminizi öldürdüğü için. Yani hayır, kabul edilmemiş bir koda güvenmek bir seçenek değildir.
Arseni Mourzenko,

1
@MainMa sonra işlemek ve adında bir dalına itin next-steps. Revizyon kontrol yaklaşımının özellikleriyle ilgili endişelerinizin, bir şeye geri dönerken beyninizi tekmelemeye yardımcı olacak bir başarısızlık testinin temel önermesi ile ne yapması gerektiğinden emin değilim. Yine, bu, backlogs, yapılacaklar listesi vb. Standart yaklaşımlara ek olarak önerildi.
Pete

2
@MainMa: sürüm kontrolü, yedekleme ile ortak çok olabilir, ancak bu birincil amacı değil. Bir yedekleme sistemine ihtiyacınız varsa ve sürüm denetimini kullanma şekliniz bu amacı yerine getirmesini engelliyorsa, Time Capsule veya benzeri bir şey edinin. Sen gerektiğini asla zamanından önce sadece yedek olarak hizmet etmek için VCS zorlamak için taahhüt etmek zorunda. Ayrıca hiçbir zaman başka bir işe yarar bir şey yapmanıza engel olmamanız gerekir çünkü “hemen her şeyi yap” politikasını izliyorsunuzdur.
iconoclast

0

Yorumlar / yapılacaklar listesine / taahhütlere ek olarak, gerçekçi olmak önemlidir.

Büyüklük, karmaşıklık ve çalışmanızı bıraktığınız duruma bağlı olarak, bir projeye yeniden başlamak biraz zaman alabilir. Etkileşen birçok bileşenin kod kodları için tam hıza ulaşması günler alabilir.

Eski güzel sabır faydalı olacaktır.

Bir süre sonra bir projeye geri döndükten sonra boğulmuşken, genellikle en basit ve en küçük görev birimini seçer ve uygularım. Aynı anda bir çok şeyi hatırlamaya çalışarak kaybolmamı engelliyor ve güvene biraz katlanıyor. Sık sık, kendimi birkaç saat içinde gittikçe daha büyük işleri otomatik olarak toplarken buluyorum.


0

Günlük yaptığım işin günlüğünü tutuyorum. Bugün ne yaptım, bugün ne zordu, bir sonraki adım ne, gelecek için bugün ne tür fikirlerim vardı. Ayrıca günün nasıl bir şey olduğunu anlatan bir açıklama ekledim: ilginç bir sohbet ya da toplantı mı vardı? Bir şey mi sinirlendiriyor, zevk mi? Bu daha sonra günlüğümü okuduğumda bazı şeyleri perspektife sokmaya yardımcı oluyor.

Bir süre sonra bir projeye döndüğümde, projeye ayak uydurmak için dergideki son birkaç girişi okudum. Bütün bu küçük günlük detaylar, gelişim sürecini hatırlamak için inanılmaz derecede önemlidir. Yapılacaklar listesine veya düzenli proje belgelerine kıyasla gerçekten çok fazla fark yaratıyorlar, çünkü size projede çalışmanın nasıl bir şey olduğunu hatırlatıyorlar, sadece ürünün nasıl kullanılacağını değil.


Bu, önceki 11
cevapta

0

Benim için projelere devam etmenin en basit yönteminin çalışmanızla ilgili sürekli bir not tutmak olduğunu düşünüyorum. Microsoft'un 'OneNote'unun özellikle not sayfalarını tutmak ve gruplamak için iyi olduğunu düşünüyorum. Özellikle, arama çubuğu notlarınızı hızlı bir şekilde bulmayı son derece kolaylaştırır.

İşte OneNote'ta yaptığım projelerdeki ilerlememe devam etmeme yardımcı olan bazı şeyler:

  • Günlük / Haftalık Günlükleri - Bir projeyle yaptığınız ilerlemeyi bulmanız için günlük veya haftalık bir ilerleme günlüğü tutun.

  • Yapılacaklar listesi - Genel bir yapılacaklar listem var, ancak üzerinde çalıştığım projeler için ayrı bir yapılacaklar listesi tutuyorum, böylece henüz bir proje için yapmam gereken işleri hatırlıyorum. Bazen de // TODO: öğeleri kodumda bırakıyorum.

  • Proje Notları - Not ettiğim şeyler arasında sorun / proje izleme öğelerine bağlantılar, kod parçacıkları, karşılaşılan sorunlar, alınan kararlar, olası çözümlerin planları ve açıklamaları, kod değişikliklerinin listesi, kod havuz dizinine bağlantılar, proje için e-postalar ve Proje belgeleri.

Bu yüzden ne zaman bir projeye geri dönersem, notlarımı açabilirim ve neredeyse anında projede ne kadar ilerleme kaydedildiğini, ne kadar çalışmam gerektiğini görebilir ve hatta düşünce trenimi görebilirim.


-2

Basit projeler için şunu yapıyorum:

  1. Kök dizindeki basit bir README dosyası (bu nedenle sürüm kontrolü ile sonuçlanacak) gelişirken neyin ortaya çıktığını not ediyorum: yapılacak şeyler, hatalar, iyileştirmeler / fikirler. Projeyi arka ocağa koymak zorunda kalmam gerekecekse okuyacağım ilk dosya bu.
  2. TODO / FIXME / XXX yorum
  3. ToDoList'i de sıklıkla kullanırım
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.