Saya mengerjakan sebuah proyek tiga bulan lalu, dan kemudian tiba-tiba proyek mendesak lainnya muncul dan saya diminta untuk mengalihkan perhatian saya.

Mulai besok, saya akan kembali ke proyek lama. Saya menyadari bahwa saya tidak ingat apa yang sebenarnya saya lakukan. Saya tidak tahu harus mulai dari mana.

Bagaimana saya bisa mendokumentasikan suatu proyek sehingga setiap kali saya melihat ke belakang tidak perlu lebih dari beberapa menit untuk pergi dari mana pun saya pergi. Apakah ada praktik terbaik?

Saya hanya ingin menyumbangkan beberapa saran yang tidak akan berguna dalam situasi Anda saat ini, tetapi Anda dapat mulai menerapkannya sekarang untuk membantu di masa depan.

Tentu saja ada kandidat yang jelas seperti daftar todo dan masalah log; melihat masalah yang baru ditambahkan akan memberi Anda petunjuk tentang apa yang Anda lakukan ketika Anda ditarik keluar dari proyek.

Pada proyek-proyek sebelumnya yang telah saya kerjakan, orang-orang diharapkan menyimpan log proyek sebagai bagian dari proses manajemen kualitas. Isinya tidak ditentukan secara jelas, tetapi idenya adalah untuk menyimpan catatan harian tentang hal-hal yang berkaitan dengan proyek yang mungkin berguna untuk pekerjaan lanjutan di masa depan atau untuk meninjau kegiatan pada penyelesaian; sebagai contoh:

• Pengamatan tentang kualitas proyek

  kode ini dapat menggunakan beberapa refactoring

  melakukan implementasi cepat untuk mendapatkan ini berfungsi tetapi ABC akan lebih baik.

• Sekarang item / masalah yang Anda tidak ingin merekam secara resmi dalam pelacak masalah

  "Harus membuat metode ini berfungsi x < 0tetapi itu saat ini di luar jangkauan.

• Merancang keputusan - terutama yang tidak sepele.

  Fungsi penyortiran standar kami melakukan penyortiran cepat, tetapi itu tidak mempertahankan urutan item yang sama di bawah kondisi penyortiran, yang kami butuhkan di sini.

  Algoritma yang jelas akan menjadi ABC tetapi gagal di sini karena xbisa jadi negatif sehingga kita perlu bentuk umum ( tautan Wikipedia ).

• Terjadi masalah dan bagaimana Anda menyelesaikannya. Yang sangat penting, menurut pendapat pribadi saya: setiap kali Anda mengalami masalah catat di log.

  Memeriksa kode tetapi memberikan kesalahan XYZ0123, ternyata saya pertama kali harus memutakhirkan komponen C ke versi 1.2 atau lebih tinggi.

Dua poin terakhir ini sangat penting. Saya sering menghadapi situasi atau masalah yang sama - kadang-kadang dalam proyek yang sama sekali berbeda - dan berpikir "hmm, saya ingat menghabiskan satu hari untuk ini, tetapi apa solusinya lagi?"

Ketika Anda kembali ke suatu proyek setelah beberapa saat, membaca kembali log proyek (apakah itu milik Anda atau pengembang terbaru) akan membuat Anda kembali ke aliran yang Anda miliki ketika Anda pergi, dan memperingatkan Anda tentang beberapa jebakan yang Anda miliki. dapat jatuh ke dalam lagi.

Daftar tugas itu ajaib. Secara umum Anda perlu menyimpan daftar pekerjaan yang harus dilakukan untuk setiap proyek dan bahkan ketika Anda sedang sibuk pemrograman, jika Anda memikirkan sesuatu yang harus dilakukan dan Anda tidak dapat segera melakukannya, maka ia masuk daftar. Simpan daftar ini di tempat yang terkenal, baik dalam spreadsheet atau file teks dalam folder proyek secara elektronik, atau di buku catatan kertas Anda.

Juga, setiap kali Anda meninggalkan proyek untuk bermalam (atau selama akhir pekan), ambil catatan post-it dan tulis hal berikutnya yang akan Anda lakukan pada catatan itu, dan tempelkan ke monitor. Itu membuatnya lebih mungkin Anda akan kembali dengan cepat keesokan paginya.

Edit :

Saya harus menyebutkan bahwa to-do list (daftar to-do yang diprioritaskan khusus yang dipisahkan oleh tempat dan proyek) adalah bagian penting dari buku Getting Things Done , yang menurut saya sangat berpengaruh.

Apa yang harus dilakukan sekarang?

Sekarang, mulai besok saya akan kembali ke proyek lama saya dan saya menyadari bahwa saya tidak ingat apa yang sebenarnya saya lakukan dan mulai dari mana!

Dugaan saya adalah Anda belum melakukan bagian selanjutnya. Jadi mencari daftar tugas tidak akan berhasil.

1. Blokir periode waktu. Letakkan ini di kalender Anda dan habiskan waktu meninjau proyek. Ini mungkin meninjau dokumentasi, kode, persyaratan, dll.
2. Menerima itu akan membutuhkan waktu untuk kembali ke kecepatan. Pastikan semua yang terlibat menyadari hal ini. Pastikan Anda menyadari hal ini.
3. Mulailah dengan tugas kecil. Bangun kembali rasa percaya diri Anda dengan melakukan sesuatu yang kecil. Jika Anda memiliki daftar item baru, kerjakan item yang lebih kecil terlebih dahulu. Ini tidak hanya membangun kembali kepercayaan diri Anda tetapi juga membantu memperkenalkan kembali diri Anda dengan proyek tersebut.

Bagaimana cara membuat ini lebih baik untuk diri sendiri di masa depan?

Saya ingin tahu cara mendokumentasikan proyek sehingga kapan pun saya melihat ke belakang tidak perlu lebih dari beberapa menit untuk pergi dari mana pun saya pergi!

Pertama, Anda harus memiliki sistem untuk melacak anak todos Anda. Apakah Anda memiliki sistem seperti itu sekarang? Bagaimana Anda mengelola proyek Anda saat ini?

Saya bisa ditabrak bus besok dan tim saya akan memiliki ide bagus tentang lebih dari 90% item tindakan saya. Ini karena saya memiliki sistem yang kohesif untuk mendokumentasikan:

• Balita langsung (item <1 minggu)
• "Senang memiliki" todos
• Tonggak sejarah dan makro makro (di mana spesifik tidak berarti)
• Persyaratan / catatan pertemuan

Plus, saya menggunakan VCS dan mengomentari kode saya yang sesuai.

Ini bekerja untuk saya dan tim saya karena saya adalah pengembang utama. Anda dapat menggunakan semacam sistem pelacakan masalah untuk suatu tim. Atau jaminan saat bekerja dengan Agile. Ada banyak pilihan. Jika Anda benar-benar tertarik dengan ini, baca tentang Getting Things Done atau metodologi manajemen tugas lain yang relevan, yang ada hampir persis karena apa yang Anda gambarkan.

Apa gunanya?

Spesifikasi sistem kurang relevan daripada itu adalah sistem kohesif dan Anda menggunakannya . Dan Anda menggunakannya. Dan gunakan itu. Ini penting. Lebih penting daripada sistem sempurna bagus yang tidak Anda gunakan. Jangan lakukan "dengan baik sebagian besar pekerjaan saya ada di sini, tetapi ada beberapa yang ada di kepala saya" atau Anda akan membenci diri Anda sendiri untuk kembali ke proyek.

Juga, pastikan komentar Anda menjelaskan "mengapa" daripada hanya "apa" untuk kode. Jauh lebih mudah untuk membaca "ini untuk memperbaiki bug dengan IE8" dan mengingat kembali apa yang dilakukan oleh kode daripada komentar yang hanya menjelaskan rincian teknis.

Menurut pendapat saya, ada dua bagian untuk "melanjutkan" proyek kode:

1. Menentukan di mana Anda tinggalkan
2. Mengingat apa yang tersisa yang harus Anda lakukan

Ini adalah salah satu hal yang, saya pikir, jika Anda melakukan kontrol versi dengan cara yang benar itu akan menjadi "otak lain" Anda.

Di mana Anda pergi ? Selama Anda sering melakukan kode, lihat perubahan terakhir Anda. Kemungkinan besar akan melintas sesuatu di pikiran Anda. Jika tidak, lihat beberapa yang lalu, mulai dengan komitmen tertua dan pemutaran ulang.

Adapun apa yang tersisa yang harus Anda lakukan , jaminan simpanan harus memenuhi tujuan itu (atau daftar yang harus dilakukan, atau apa pun yang ingin Anda beri nama. Pada dasarnya item untuk masa depan).

Saya bukan pengembang perangkat lunak penuh waktu. Saya seorang programmer yang meretas pada malam dan akhir pekan. Karena itu, ketika pekerjaan atau hal-hal non-pemrograman lainnya mengambil prioritas yang lebih tinggi, kadang-kadang saya bisa pergi berhari-hari dan berminggu-minggu bahkan tanpa menarik kode saya dengan pandangan sekilas. Di atas telah terbukti sangat efektif.

Ini tidak dimaksudkan untuk menjadi jawaban yang lengkap — sudah ada beberapa yang sangat bagus yang menyebutkan hal-hal penting seperti bagaimana menggunakan VCS Anda dan perangkat lunak manajemen proyek Anda — melainkan tambahan yang menambahkan beberapa poin yang tidak saya lihat di tempat lain, yang saya lihat merasa sangat membantu, dan yang saya harap orang lain juga bisa membantu.

1. Tidak ada tugas yang terlalu cepat atau terlalu kecil untuk dituliskan

Orang-orang biasanya membuat daftar TODO untuk hal-hal yang mereka rencanakan untuk dilakukan di masa depan , tetapi karena pemrograman membutuhkan konsentrasi, dan karena kita dapat terganggu setiap saat , saya merasa terbantu untuk menuliskan bahkan apa yang sedang saya lakukan sekarang, atau apa yang saya akan dimulai dalam hitungan detik . Anda mungkin merasa Anda berada di zona dan Anda mungkin tidak bisa melupakan solusi yang hanya memukul Anda dalam aha saat, tetapi ketika rekan kerja Anda mampir kubus Anda menampilkan gambar jari kaki yang terinfeksi nya , dan Anda hanya akhirnya bisa menyingkirkannya dengan mulai menggerogoti lengan Anda sendiri , Anda mungkin berharap Anda telah menulis catatan cepat, bahkan jika hanya pada catatan Post-It ™.

Tentu saja beberapa media lain yang lebih gigih mungkin lebih baik (saya sangat menyukai OmniFocus ), tetapi intinya adalah setidaknya memilikinya di suatu tempat , bahkan jika Anda akan selesai dalam 20 menit dan kemudian membuang Post-It ™. Meskipun Anda mungkin menemukan bahwa informasi itu berguna, untuk mengenakan lembar waktu atau faktur kepada klien, atau ketika bos / klien Anda bertanya apa yang sedang Anda kerjakan dan Anda tidak dapat mengingatnya. Jika Anda meletakkan semua catatan ini dalam kotak atau laci atau folder, maka ketika gangguan besar menghantam — proyek yang mengganggu — maka Anda dapat meliriknya dan mengingat banyak hal yang Anda lakukan untuk mendapatkan kode Anda ke titik di mana Anda temukan ketika Anda kembali ke proyek.

2. Gunakan papan tulis di meja Anda untuk menangkap ide gambaran besar

Saya memiliki papan tulis 3 "x 4" di sebelah meja saya, jadi ketika saya memulai suatu proyek saya dapat melakukan brainstorming solusi untuk semua masalah yang saya rasakan dalam suatu proyek. Ini bisa berupa diagram arsitektural, kasus penggunaan, daftar risiko dan hambatan, atau apa pun yang tampaknya relevan bagi Anda.

Beberapa pendekatan yang lebih formal mengharuskan Anda untuk menghasilkan diagram dan menggunakan kasus dan sebagainya sebagai "hasil" dalam beberapa kertas atau format elektronik, tetapi saya menemukan bahwa itu dapat membuat banyak pekerjaan tambahan, dan hanya menjadi serangkaian sub proyek yang berakhir naik bercerai dari tujuan sebenarnya dari proyek utama, dan hanya bagian dari proses formal yang harus Anda lakukan tetapi tidak ada yang memperhatikan. Papan tulis adalah hal paling sederhana yang benar-benar berfungsi, setidaknya dalam pengalaman saya. Ini sekuat yang Anda inginkan (dengan kamera) dan yang paling penting memungkinkan Anda untuk mendapatkan ide-ide Anda segera.

Saya berpikir lebih baik dengan pena di tangan saya, sehingga membuang pikiran saya ke permukaan putih datang secara alami kepada saya, tetapi jika Anda tidak menemukan itu menjadi masalah bagi Anda, berikut adalah beberapa pertanyaan yang dapat membantu Anda memutuskan apa yang relevan :

• Jika saya adalah pengembang utama, akan berbulan madu selama 3 bulan sementara pengembang lain menyelesaikan proyek, arahan umum apa yang ingin saya berikan kepada mereka? Gagasan apa yang ingin saya pastikan mereka tahu, atau pendekatan yang ingin saya pastikan mereka ambil? Perpustakaan apa atau solusi bermanfaat lainnya yang ingin saya pastikan mereka ketahui?
• Jika proyek ini adalah ide jutaan dolar yang saya tahu akan memastikan kemandirian finansial masa depan saya, tetapi saya dijadwalkan untuk operasi kritis yang akan melumpuhkan saya selama 3 bulan, apa yang saya inginkan untuk masa depan saya, untuk memastikan penyelesaian yang sukses dari proyek?

(Ketika saya pertama kali menuliskan ide-ide, saya hanya khawatir ide-ide itu masuk akal bagi diri saya saat ini. Begitu ide-ide saya turun, saya dapat melihat lebih kritis pada mereka dan membuat perubahan untuk memastikan ide-ide itu masuk akal bagi diri saya di masa depan atau orang lain. Terlalu khawatir. tentang berkomunikasi dengan orang lain saat Anda menuliskannya pada awalnya dapat menyebabkan blok penulis — pikiran tersumbat oleh tujuan yang bersaing. Dapatkan terlebih dahulu, khawatir tentang kejelasan nanti)

Saya sarankan Anda menghabiskan uang untuk membeli papan tulis yang layak, setidaknya 3 "x 4", dan menggantungnya di ruang tempat Anda biasanya bekerja. Ada banyak keuntungan papan tulis fisik dibandingkan sistem virtual mana pun.

• Itu besar. Dengan mengambil banyak ruang, itu membuat kehadirannya terasa, dan rencana di atasnya terasa seperti bagian dari ruang kerja Anda, membantu mengarahkan Anda ke arah yang benar sepanjang waktu.
• Itu ada di sana terus-menerus: Anda tidak harus meluncurkan aplikasi atau situs web tertentu untuk mengaksesnya, dan Anda tidak akan mengambil risiko lupa bagaimana untuk sampai ke sana, atau lupa bahwa itu ada di sana.
• Ini langsung dapat diakses ketika Anda memiliki ide yang ingin Anda pikirkan.

Anda kehilangan banyak manfaat jika Anda hanya menggunakan papan tulis di ruang rapat, dan kemudian mengambil foto dengan telepon Anda. Jika Anda menghasilkan uang dengan pemrograman, itu sepadan dengan biaya papan tulis yang layak.

Jika Anda memiliki proyek lain mengganggu salah satu yang telah mengisi papan tulis Anda, Anda mungkin perlu untuk menggunakan snapshot pada ponsel Anda, tapi setidaknya Anda akan memiliki yang dalam 3 bulan ketika "mendesak" proyek selesai dan Anda harus kembali ke yang lain. Jika Anda ingin membuatnya kembali di papan tulis, mungkin hanya butuh 15 menit, dan Anda mungkin bisa memperbaikinya dalam proses ini, yang membuat investasi waktu yang kecil itu sangat berharga.

3. Buat pemangku kepentingan sadar akan biaya mengganggu proyek

Saya menemukan metafora sebuah pesawat membantu: memulai dan menyelesaikan suatu proyek seperti menerbangkan pesawat. Jika Anda menebus pertengahan jalan melalui penerbangan, pesawat tidak akan hanya duduk di sana menunggu Anda untuk kembali ke sana, dan Anda perlu beberapa cara untuk melakukan perjalanan dari proyek saat ini / penerbangan ke yang berikutnya. Bahkan jika Anda berada di tengah penerbangan dari Phoenix ke Fargo dan Anda diberitahu bahwa Anda perlu menghentikan penerbangan itu untuk mengambil pesawat lain dari Denver ke Detroit, Anda harus mendaratkan pesawat pertama di Denver (yang untungnya tidak jauh dari jalur penerbangan Anda — tidak selalu halnya dengan interupsi nyata) dan seseorang harus mencari tahu apa yang harus dilakukan dengan kargo dan penumpang. Mereka tidak akan hanya duduk dan menunggu selamanya.

Inti dari proyek ini adalah bahwa peralihan dari satu proyek ke proyek lainnya menghabiskan banyak waktu dan menyisakan banyak jalan keluar yang harus diatasi.

Dalam sebuah proyek jelas ada dan pasti banyak yang terjadi di kepala Anda sementara Anda bekerja dan tidak setiap pikiran dapat serial ke media tertulis, dan tidak setiap sedikitpun pikiran-pikiran yang sedang serial akan tetap ketika deserialized. Meskipun kita dapat menangkap sebagian pemikiran kita secara tertulis, ini adalah format yang sangat merugi.

Masalahnya (seperti yang saya lihat) adalah bahwa manajer proyek dan pebisnis lain menganggap proyek sebagai serangkaian langkah yang sering dapat disusun ulang sesuka hati (kecuali jika ada ketergantungan eksplisit pada grafik Gantt mereka) dan dapat dengan mudah didistribusikan di antara orang-orang. atau ditunda sampai paling nyaman untuk bisnis.

Siapa pun yang telah melakukan sejumlah pemrograman tahu bahwa proyek perangkat lunak tidak dapat diperlakukan seperti blok Lego untuk dipindahkan sesuai keinginan Anda. Saya menemukan metafora perjalanan udara setidaknya memberikan sesuatu yang konkret kepada para pemangku kepentingan yang dapat mereka pikirkan yang jelas tidak dapat diperlakukan sebagai serangkaian langkah yang berbeda untuk disusun kembali atas kemauan. Setidaknya membuatnya mudah untuk memahami poin Anda bahwa ada biaya untuk gangguan seperti itu. Tentu saja itu masih keputusan mereka, tetapi Anda ingin membuat mereka mengetahui hal ini sebelum mereka menyela satu proyek untuk memberi Anda yang lain. Jangan bersikap agresif, tetapi tawarkan informasi yang bermanfaat dan perspektif pengembang yang membantu, siap untuk melakukan apa pun yang mereka butuhkan dari Anda, tetapi hanya menawarkan informasi yang mungkin tidak mereka sadari jika Anda tidak memberi tahu mereka.

Pendeknya:

1. Tuliskan semua yang Anda tentang untuk dilakukan, bahkan jika Anda tidak berpikir Anda dapat pernah mungkin perlu ditulis. Bahkan pensil pendek dapat mengalahkan ingatan yang panjang.
2. Brainstorming gambar besar di papan tulis fisik yang Anda punya akses terus-menerus.
3. Anda mungkin menghindari gangguan proyek jika Anda membuat pengambil keputusan sadar bahwa ada biaya untuk gangguan tersebut, dan setidaknya Anda akan menetapkan harapan sehingga mereka tahu proyek akan memakan waktu sedikit lebih lama ketika Anda melanjutkannya.

Anda dapat melihat riwayat proyek di perangkat lunak kontrol versi Anda dari tiga bulan lalu. Baca pesan komit Anda dan perbedaan terbaru untuk mendapatkan gagasan tentang apa yang sedang Anda kerjakan.

Menggunakan sistem kontrol sumber dengan strategi percabangan dan penggabungan yang tepat, bersamaan dengan sistem pelacakan masalah (seperti Redmine , atau GitHub ) membantu Anda mengelompokkan perubahan yang telah Anda buat, memberi mereka arahan, dan mendokumentasikan 'konteks' Anda yang hilang sebagai bagian alami dari alur kerja.

1. Sebelum Anda memulai perubahan kode, pastikan ada 'masalah' yang dicatat dalam sistem pelacakan masalah Anda. Itu mencakup bagian yang hilang dari pekerjaan Anda.
2. Buat cabang di sistem kontrol sumber Anda, dan pastikan perubahan Anda di cabang itu HANYA terkait dengan masalah yang disebutkan sebelumnya. Ini akan membantu Anda mengisolasi perubahan, dan memberi Anda sejarah perubahan, menjawab pertanyaan "di mana saya tinggalkan?" setelah Anda kembali mengerjakannya nanti.
3. Setelah selesai, gabungkan kembali ke bagasi Anda, dan tutup masalahnya.

Ada banyak jawaban panjang. Ini adalah singkat tentang apa yang paling membantu saya:

• Kode bersih.
• Kode bersih.
• Kode bersih.
• Kontrol versi (berbeda dan komit komentar).
• Catatan Post-It atau Todo-List atau Kanban-Board (lihat misalnya Trello dan Evernote)

Namun, Diffs, komentar Komit, catatan Post-It, Todo-Lists atau Kanban-Board dapat disalahartikan dari waktu ke waktu karena kurangnya konteks. Jadi, inilah satu hal yang paling penting:

KODE BERSIH.

Bagaimana saya bisa mendokumentasikan suatu proyek sehingga setiap kali saya melihat ke belakang tidak perlu lebih dari beberapa menit untuk pergi dari mana pun saya pergi.

Pertama, ini menyiratkan ada beberapa deskripsi tingkat tinggi dan struktur kode dalam proyek yang Anda dapat dengan mudah memahami dalam beberapa menit - sebagai lawan dari jutaan baris kode tanpa struktur yang jelas dan tidak ada komentar.

Apakah ada praktik terbaik?

Berikut ini adalah praktik terbaik yang saya adopsi sepanjang 20+ tahun karir dalam proyek yang sangat kecil hingga sangat besar dan mereka telah melayani saya dan tim saya dengan baik. Terapkan dalam urutan yang tercantum sebagai proyek Anda tumbuh:

1. Gunakan kontrol versi ini memberi Anda rekam jejak gratis tentang apa yang terjadi, kapan dan siapa yang menerapkan perubahan. Ini juga memberi Anda kemudahan untuk kembali ke versi sebelumnya kapan saja.

2. Modularisasi kode Anda (tergantung pada bahasa dan lingkungan pemrograman, gunakan kelas, modul, paket, komponen).

3. Dokumentasikan kode Anda. Ini termasuk dokumentasi ringkasan di bagian atas setiap file (apa fungsinya? Mengapa? Bagaimana menggunakannya?), Dan komentar khusus pada tingkat fungsi, prosedur, kelas dan metode (apa fungsinya? Argumen dan nilai pengembalian / jenis? efek samping?).

4. Tambahkan TODOdan FIXMEkomentar saat Anda membuat kode. Ini membantu untuk mengingat mengapa dan bagaimana kebiasaan yang tidak terhindarkan akan memasuki basis kode Anda dan bahwa nantinya Anda akan meminta WTF ?! . Misalnya:

   //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. Biasakan menggambar diagram untuk mendokumentasikan struktur dan perilaku kompleks seperti urutan panggilan antara modul / objek / sistem dll. Secara pribadi saya lebih suka UMLet karena cepat digunakan, membuat grafik yang bagus, dan yang paling penting tidak menghalangi Anda . Tetapi tentu saja Anda harus menggunakan alat gambar apa pun yang Anda temukan berfungsi. Ingatlah bahwa tujuan dari gambar semacam itu adalah untuk berkomunikasi secara ringkas, bukan untuk menentukan sistem secara mendetail (!!).

6. Tambahkan tes unit sejak dini. Tes unit tidak hanya bagus untuk pengujian regresi, tetapi juga merupakan bentuk dokumentasi penggunaan untuk modul Anda.

7. Tambahkan dokumentasi kode-eksternal sejak dini. Mulailah dengan README yang menjelaskan dependensi yang diperlukan untuk menjalankan dan mengembangkan proyek, cara menginstalnya, cara menjalankannya.

8. Biasakan mengotomatiskan tugas yang berulang . Misalnya mengkompilasi / membangun / menguji siklus harus dituliskan dengan beberapa bentuk (misalnya dalam penggunaan JavaScript grunt, dalam Python fabric, di Jawa Maven). Ini akan membantu Anda untuk mempercepat dengan cepat ketika Anda kembali.

9. Saat proyek Anda berkembang, tambahkan lebih banyak dokumentasi dengan membuat dokumen kode sumber (menggunakan beberapa bentuk komentar gaya JavaDoc dan alat yang sesuai untuk menghasilkan HTML atau PDF dari itu).

10. Jika proyek Anda berkembang di luar satu komponen dan memiliki penyebaran yang lebih kompleks, pastikan untuk menambahkan dokumentasi desain dan arsitektur . Sekali lagi perhatikan bahwa tujuan dari ini adalah untuk mengkomunikasikan struktur dan dependensi daripada detail kecil.

Selain saran tentang pelacakan proyek, daftar ToDo, Trello, dll, sesuatu yang saya baca sekali yang membantu jika Anda berlatih TDD adalah untuk selalu menjauh dari proyek Anda dengan tes gagal baru untuk diterapkan kapan pun Anda kembali ke proyek (besok) , minggu depan, atau bulan depan)

Duduk, lakukan 'Jalankan Tes', dan ambil di mana Anda tinggalkan.

Selain komentar / daftar agenda / komitmen, penting untuk bersikap realistis.

Bergantung pada ukuran, kompleksitas, dan keadaan Anda meninggalkan pekerjaan Anda, memulai kembali pada suatu proyek bisa memakan waktu cukup lama. Untuk basis kode yang substansial dari banyak komponen yang berinteraksi, mungkin perlu berhari-hari untuk mencapai kecepatan penuh.

Kesabaran lama yang baik akan bermanfaat.

Ketika kewalahan setelah kembali ke proyek setelah beberapa saat, saya biasanya mengambil unit tugas yang paling sederhana dan terkecil dan mengimplementasikannya. Itu membuat saya tidak tersesat mencoba mengingat banyak hal sekaligus dan sedikit meningkatkan kepercayaan diri. Lebih sering daripada tidak, saya menemukan diri saya secara otomatis mengambil tugas yang semakin besar dalam beberapa jam.

Saya membuat jurnal harian tentang pekerjaan yang saya lakukan. Apa yang saya lakukan hari ini, apa yang sulit hari ini, apa langkah selanjutnya, ide apa yang saya miliki hari ini untuk masa depan. Saya juga menambahkan sedikit narasi tentang seperti apa hari itu: apakah ada percakapan atau pertemuan yang menarik? Apakah ada yang marah atau senang? Ini membantu menempatkan segala sesuatu ke dalam perspektif ketika saya nanti membaca jurnal saya.

Ketika saya kembali ke proyek setelah beberapa saat, saya membaca beberapa entri terakhir dalam jurnal untuk mempercepat proyek. Semua detail kecil sehari-hari itu sangat penting untuk mengingat proses pengembangan. Mereka benar-benar membuat banyak perbedaan dibandingkan dengan daftar todo atau dokumentasi proyek biasa, karena mereka mengingatkan Anda bagaimana rasanya bekerja pada proyek, dan bukan hanya bagaimana menggunakan produk.

Bagi saya, saya menemukan metode paling sederhana untuk melanjutkan proyek hanya dengan menyimpan catatan konstan pada pekerjaan Anda. Saya menemukan bahwa Microsoft 'OneNote' sangat baik untuk menyimpan dan mengelompokkan halaman catatan. Secara khusus, bilah pencarian membuatnya sangat mudah untuk menemukan catatan Anda dengan cepat pada sesuatu.

Berikut adalah beberapa hal yang saya lakukan dalam OneNote yang membantu saya untuk melanjutkan kemajuan proyek:

• Log Harian / Mingguan - Menyimpan catatan kemajuan harian atau mingguan untuk membantu Anda mengetahui kemajuan yang telah Anda buat dengan sebuah proyek.

• Daftar agenda - Saya memiliki daftar tugas umum, tetapi saya juga menyimpan daftar tugas yang harus dilakukan untuk proyek yang saya kerjakan sehingga saya ingat hal-hal apa yang belum saya lakukan untuk sebuah proyek. Terkadang saya juga meninggalkan // TODO: item dalam kode saya.

• Catatan Proyek - Hal-hal yang saya catat termasuk tautan ke masalah / item pelacakan proyek, potongan kode, masalah yang dihadapi, keputusan yang dibuat, rencana dan deskripsi solusi potensial, daftar perubahan kode, tautan ke direktori repositori kode, email untuk proyek dan tautan ke dokumentasi proyek.

Jadi, setiap kali saya kembali ke proyek saya dapat membuka catatan saya dan hampir seketika saya dapat melihat berapa banyak kemajuan yang dibuat pada proyek, berapa banyak pekerjaan yang tersisa untuk dilakukan dan bahkan melihat pemikiran saya.

Untuk proyek sederhana, saya melakukan ini:

1. File README sederhana di direktori root (yang, karenanya, juga akan berakhir di kontrol versi) tempat saya mencatat apa saja yang muncul saat mengembangkan: hal-hal yang harus dilakukan, bug, perbaikan / ide. Itu adalah file pertama yang akan saya baca seandainya saya harus meletakkan proyek di belakang burner.
2. Komentar TODO / FIXME / XXX
3. Saya sering juga menggunakan ToDoList