Bagaimana saya harus mengingat apa yang saya lakukan dan mengapa dalam sebuah proyek tiga bulan yang lalu?


72

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?


98
komentar dan komit pesan, ada alasan orang menyuruh Anda meninggalkannya
ratchet freak

5
Bukankah ini benar-benar tergantung pada bagaimana Anda melacak proyek sejak awal? Haruskah kami menganggap Anda melakukan semuanya dari memori dan tidak ada dokumentasi lain?
JeffO

4
@ratchetfreak saya hampir mengatakan "Itu hanya berguna untuk pengembang" sampai saya menyadari bahwa Anda dapat menerapkan prinsip yang sama untuk apa pun. Kebanyakan repositori dokumen memiliki bagian catatan atau deskripsi; kiriman melalui email memiliki badan pesan (sering diabaikan). Dokumen dapat melacak perubahan dan anotasi. Ada seluruh ekosistem komentar dan komit pesan di dunia PM juga! </epiphany>
corsiKa

6
Saya menggunakan sistem kontrol versi untuk mengingatkan saya apa yang saya lakukan terakhir kali, dan pelacak bug untuk mencari tahu apa yang masih perlu dilakukan.
Lie Ryan

2
Oh ya, sekali setelah istirahat tiga bulan dari pekerjaan, saya diminta wawancara pekerjaan untuk menggambarkan proyek terakhir saya. Saya melakukannya, tetapi ketika mereka meminta detail, saya tidak bisa mengingat kehidupan saya. Mereka menolak saya karena ternyata saya palsu kalau tidak bisa mengingatnya. Ini terjadi sekitar 15 tahun yang lalu, tetapi saya masih mengingatnya.
Andrew Savinykh

Jawaban:


35

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.


68

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.


22
Dan jika Anda mengerjakan proyek yang gesit dengan tugas-tugas kecil, simpanan harus menjadi daftar tugas utama Anda untuk proyek itu.
Bart van Ingen Schenau

1
Saya baru-baru ini mulai melakukan apa yang Anda sebutkan di paragraf terakhir dan itu sangat membantu saya pergi di pagi hari.
TMH

5
Memang. Selalu parkir menuruni bukit. Ini masalah kebiasaan. Saya tidak pernah meninggalkan basis kode tanpa membuat catatan untuk saya sendiri dalam kode atau dalam daftar agenda saya tentang apa yang harus dilakukan selanjutnya. Saya juga memastikan bahwa semua yang saya tahu masih harus saya lakukan adalah dalam todo baik di sumbernya (saya menggunakan TODO: konvensi dalam komentar yang IDE saya dapat mendeteksi dan hadir sebagai daftar), atau dalam daftar todo terpisah saya (saya hanya memiliki satu untuk semua proyek, tetapi dikategorikan dan diprioritaskan).
Joeri Sebrechts

3
TODO dalam kode sangat bagus, tetapi Anda harus rajin meletakkannya di sana, bahkan untuk hal-hal kecil. Memiliki todotarget di makefile Anda yang membuangnya juga berguna.
Blrfl

4
trello.com adalah penyelamat. Bahkan untuk pertemuan tim Senin Monring di mana saya berjuang untuk mengingat apa yang saya lakukan minggu lalu dan apa yang harus saya kerjakan pada minggu ini. Ini juga gratis.
SimonGates

33

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.


@TheIndependentAquarius tidak masalah, senang itu membantu. Situasi itu bisa luar biasa.
enderland

@TheIndependentAquarius mungkin karena umumnya komentar dimaksudkan untuk lebih atau kurang post-its / stickies. Cara Stack Exchange mengatur hal-hal untuk mengatakan, "jawaban ini hebat" adalah baik meningkatkan atau menerima jawaban. Komentar di sini belum tentu dimaksudkan untuk bertahan lama.
enderland

Versi yang jauh lebih ramping dari daftar "yang harus dilakukan" ini adalah menggunakan sistem pelacakan masalah. Ada banyak sistem gratis yang tersedia, dan banyak penyedia Git gratis memiliki sistem seperti itu untuk layanan mereka (lihat: GitHub).
BTownTKD

@BTownTKD Saya mengatakan itu dalam jawaban saya :)
enderland

Itu jawaban yang bagus; ditambahkan untuk penekanan.
BTownTKD

14

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.


10

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.

1
Stakeholder menganggap mereka membayar pengembang profesional yang berkomentar & mendokumentasikan kode sehingga dia (nanti) atau orang lain (kapan saja) dapat mengambil alih proyek. Tentu saja anggapan mereka keliru sebagian besar waktu.
JeffO

Dan Anda harus berkomentar dan mendokumentasikan! Saya harap Anda tidak berpikir saya menyarankan sebaliknya. (Dan omong-omong saya setuju dengan komentar Anda.)
iconoclast

2

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.


Saya terkejut jawaban ini tidak dibatalkan. Log kontrol versi adalah cara terbaik untuk mengetahui di mana seseorang berada beberapa bulan yang lalu ketika proyek itu ditangguhkan sementara. Hapus pesan log sangat membantu. Diffs dan daftar file yang diubah adalah cara tambahan untuk mendapatkan gambar tentang apa yang terjadi dengan proyek sebelum penangguhan. Akhirnya, ada lebih banyak pengembang yang menggunakan kontrol versi dibandingkan dengan jumlah pengembang yang menggunakan sistem pelacakan bug (atau bahkan daftar tugas yang harus dilakukan), yang menjadikan jawaban ini berharga bagi lebih banyak orang dibandingkan dengan jawaban yang sangat terangkat oleh Scott Whitlock.
Arseni Mourzenko

2

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.

1

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.


Dengan cara apa tepatnya kode clean code clean code membantu seseorang dengan " Bagaimana saya harus mengingat apa yang saya lakukan dan mengapa pada proyek tiga bulan yang lalu? " Dan mendapatkan kembali konteks yang terlewat? Bukankah arsitektur bersih arsitektur bersih arsitektur bersih membantu lebih banyak? Seseorang biasanya tidak merinci lebih dulu. Ini tentang mendapatkan gambaran besar sebelum memeriksa detailnya. Sayangnya, paman yang maha hadir tidak akan membantu Anda dengan itu. Meskipun demikian saya sangat setuju dengan dua poin lainnya.
JensG

@JensG: Kode adalah arsitekturnya. Dalam program yang ditulis dengan baik, saya dapat melihat bagian atas arsitektur program-fungsi main, yang untuk program berukuran signifikan akan agak abstrak. Saya kemudian bisa menyelam lebih dalam, dan melihat arsitektur bagaimana program membersihkan dirinya sendiri, misalnya. Selanjutnya, kode bersih berarti fungsi / variabel / dll. memiliki nama yang masuk akal dan membuat pernyataan tentang artinya. Jika saya, sebagai gantinya, menulis Spaghetti / Write-Only-code, saya akan sering terbangun keesokan paginya / bulan / tahun, melihat kode saya, dan satu-satunya pikiran adalah wtf-did-i-do-there. Itu sama ketika ..
saluran

... membaca atau menulis buku: Apakah itu omong kosong dengan indeks keterbacaan Flesch-Kincaid 10, dengan frasa besar, banyak konstruk kata yang rumit, membiarkan pembaca fokus pada sintaks daripada semantik, atau apakah mudah dibaca dengan indeks sekitar 80, dan tidak menghalangi jalan cerita itu sendiri.
phresnel

Sementara saya melihat (dan jangan ragu dengan cara apa pun) nilai kode bersih saya sangat tidak setuju dengan kode menjadi arsitektur. Kode dapat dibersihkan dengan sempurna dan dapat dibaca oleh semua standar tetapi masih ditulis dengan cara di mana Anda tidak mendapatkan gambaran besar. Selanjutnya, pertanyaannya adalah " bagaimana saya harus mengingat apa yang saya lakukan " dan " Saya tidak tahu harus mulai dari mana ". Saya tidak bisa melihat persimpangan antara kondisi saat ini dari kode (bersih) dan apa yang dicari OP: titik arah yang tepat dalam proses yang mengarah dari ide ke produk.
JensG

@JensG: Saya tahu maksud Anda. Saya pikir kita hanya menafsirkan "Saya menyadari bahwa saya tidak ingat apa yang sebenarnya saya lakukan" secara berbeda. Bagi saya ini terdengar lebih seperti "Saya menyadari bahwa saya tidak ingat algoritma dan struktur data mana yang saya kodekan dan bagaimana saya dapat memperluasnya", bagi Anda, itu (saya kira) lebih seperti "Saya menyadari bahwa saya tidak ingat apa tepatnya saya sedang berusaha mengimplementasikan dan targetnya ". Bahasa manusia yang ambigu. ...
phresnel

1

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.


0

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.


1
Ini memiliki dua kelemahan. Pertama, jika Anda menggunakan integrasi terus-menerus, secara sadar melakukan tes yang gagal tidak diragukan lagi. Kedua, jika Anda berada di tim yang terdiri lebih dari satu, orang lain mungkin tidak akan menghargai jika Anda melakukan tes yang gagal.
Arseni Mourzenko

1
@MainMa saya tidak mengatakan komit. Hanya secara lokal.
Pete

Saran saya kepada pengembang mana pun adalah berkomitmen ketika ia tidak akan mengerjakan suatu proyek bahkan selama beberapa hari. Sesuatu terjadi. PC Anda dapat dicuri, atau Anda mungkin tidak dapat menjalankan bootnya besok karena pengontrol RAID gagal. Anda dapat meninggalkan proyek dan pengembang lain dapat mengambil tempat Anda. Anda mungkin ditabrak bus. Anda dapat menghapus proyek secara lokal karena terlalu banyak memakan tempat atau karena virus membunuh OS Anda. Jadi tidak, mengandalkan kode yang tidak dikomit bukanlah pilihan.
Arseni Mourzenko

1
@MainMa kemudian komit dan dorong ke cabang bernama next-steps. Saya tidak yakin apa yang menjadi keprihatinan Anda tentang hal spesifik dari pendekatan kontrol revisi berkaitan dengan premis dasar dari tes yang gagal sebagai bantuan dalam memulai otak Anda ketika kembali ke sesuatu. Sekali lagi, ini diusulkan sebagai tambahan untuk pendekatan standar seperti jaminan simpanan, daftar pekerjaan, dll.
Pete

2
@ MainMa: kontrol versi mungkin memiliki banyak kesamaan dengan cadangan, tapi itu bukan tujuan utamanya. Jika Anda memerlukan sistem cadangan, dan cara Anda menggunakan kontrol versi mencegahnya memenuhi tujuan itu, maka dapatkan Time Capsule atau yang serupa. Anda seharusnya tidak pernah dipaksa untuk melakukan prematur hanya untuk memaksa VCS Anda berfungsi sebagai cadangan. Dan Anda tidak boleh dicegah melakukan sesuatu yang bermanfaat karena Anda mengikuti kebijakan "segera lakukan semuanya".
iconoclast

0

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.


0

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.


ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 11 jawaban sebelumnya
agas

0

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.


-2

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
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.