Apa yang Anda lihat pada awalnya: kode atau desain?

Jika Anda baru saja diperkenalkan dengan proyek baru, apa hal pertama yang Anda cari untuk mendapatkan ide tentang cara kerjanya?

Apakah Anda mencari desain terlebih dahulu? Jika ada desain, apa yang Anda cari di dalamnya? Diagram kelas atau diagram penempatan atau diagram urutan atau yang lainnya?

Atau apakah Anda langsung mencari kode? Jika demikian, bagaimana Anda memahami bagaimana berbagai lapisan berinteraksi?

Saya mulai dengan kode. Dokumen desain yang terpisah, jika ada, kemungkinan besar salah atau salah dipahami. Jadi, saya mulai dengan mencoba melacak beberapa aliran sederhana melalui kode; jika itu adalah webapp, itu bisa berupa permintaan atau urutan permintaan, misalnya. Setelah saya selesai melakukannya, saya memiliki semacam kerangka untuk menggantung lebih banyak pemahaman. Kemudian, saya mungkin kembali dan membaca desain atau dokumentasi lain, tetapi pada saat itu, saya memiliki sesuatu yang konkret untuk menghubungkannya, dan untuk memvalidasi mereka, sehingga saya dapat mendeteksi informasi duff. Atau saya mungkin hanya meneruskan membaca kode, atau menguji kasus, dll.

Saya akan mulai di level yang lebih tinggi. Jika ada pengguna yang menghadapi dokumentasi - panduan pengguna atau panduan. Gagal yang kemudian melihat spesifikasi persyaratan sehingga Anda memiliki beberapa gagasan tentang apa yang seharusnya dilakukan oleh perangkat lunak. Saya akan melihat desain dan mencoba memetakannya ke file kode. Semoga ini terstruktur ke dalam folder dengan cara yang masuk akal. Saya kemudian akan memilih bagian dari desain dan masuk ke file untuk mengikuti aliran kode tanpa terlalu macet ke detail halus.

Saya mulai dengan mengatur sistem pengembang. Saya menggunakan prosedur yang didokumentasikan. Ini memungkinkan kucing keluar dari tas tentang seberapa banyak dokumentasi itu sinkron dengan kenyataan.

Ini juga memberi tahu saya apa dependensi itu. Ini penting.

Sekarang saya sudah punya setup pengembang, (dan saya menandai dokumen setup dengan koreksi saat saya pergi) saya membangun versi. Saya akhirnya mengajukan pertanyaan sepanjang fase ini.

Sekarang sudah dibangun, saya melakukan latihan pengantar dari buku petunjuk. Ini memberi tahu saya kira-kira apa yang sebenarnya dilakukan sistem.

Sekarang saya memiliki petunjuk parsial tentang sistem, saya membaca dokumen desain, yang sekarang saya percaya sebanding dengan betapa salahnya dokumen sejauh ini.

Begitu saya sampai pada dokumentasi perilaku aktual, saya dapat mulai melihat ke dalam kode dan melihat apa yang sebenarnya ada. Mereka tidak pernah berbaris, tetapi saya sekarang tahu seberapa banyak yang harus dipercaya.

Lalu saya melihat output IDE untuk komentar "todo" dan "fixme". Hal-hal seperti "memperbaiki dalam versi 2.0" juga merupakan tip-off.

Jadi ini semua tentang mempelajari kejujuran, dan seperti yang ditunjukkan orang, dokumen desain terpisah jarang mutakhir atau benar, tetapi itu memberi tahu Anda apa yang dipikirkan orang pada satu titik waktu. Dan tentu saja, orang-orang itu mungkin tidak ada untuk diinterogasi.

Preferensi saya adalah mulai dengan desain untuk mendapatkan gambaran umum proyek dan mencoba memahami beberapa fitur dan / atau struktur utamanya sebelum menggali detailnya.

Selalu desain. Dengan kode, ada baiknya melalui langkah-langkah pengaturan pengembang (memeriksa sumber, membangun proyek, membuat perubahan konfigurasi yang diperlukan) tetapi tidak ada gunanya mencoba mempelajari struktur aplikasi dari kodenya. Itu hanya memberi tahu Anda apa strukturnya, bukan mengapa struktur itu atau apa yang dipikirkan pengembang lain tentang hal-hal penting dan buruk dari arsitektur. Yang Anda pelajari dari diagram papan tulis dan obrolan dengan pengembang.

Untuk perangkat lunak yang kompleks, saya akan mendekatinya secara kasar seolah-olah itu adalah proyek pengembangan baru. Mulailah dengan ide-ide besar - visi, konteks, ruang lingkup, pemangku kepentingan. Baca beberapa dokumentasi pengguna dan dapatkan ide bagaimana menggunakannya. Dapatkan beberapa pelatihan pengguna dengan perangkat lunak jika memungkinkan (atau berlaku). Kemudian mulailah mencari ke dalam persyaratan dan desain dokumentasi untuk mendapatkan ide tentang cara kerjanya pada tingkat tinggi. Bicaralah dengan desainer jika masih ada. Lihatlah arsitektur sistem dalam berbagai perspektif. Dari sana, mulailah menggali fungsionalitas inti dan melihat beberapa kode, kembali ke persyaratan dan desain sesuai kebutuhan. Saat Anda melihat kode, jalankan perangkat lunak untuk melihatnya beraksi. Sementara itu, kompilasi beberapa dokumentasi ringkasan untuk referensi di masa mendatang - Anda memiliki Cliffs Notes. Cabang sampai Anda memiliki ide yang cukup bagus tentang bagaimana semuanya bekerja dan cocok bersama, tetapi berkonsentrasi pada bagian yang akan Anda kerjakan. Sekarang Anda memiliki pemahaman top-to-bottom dari seluruh sistem, atau setidaknya bagian-bagian yang berlaku untuk Anda.

Tentu saja, di dunia nyata Anda mungkin tidak punya waktu untuk menjalani semua ini sebelum Anda harus mulai mengotori tangan Anda, terutama pada proyek yang lebih besar. Tetapi ini adalah bagaimana saya akan melakukannya jika itu terserah saya.

Anda harus bekerja bolak-balik antara kode itu sendiri dan dokumen desain apa pun.

• Anda bisa mulai dari kode atau desain, dan itu tidak terlalu penting. Baca kode hingga Anda benar dan benar-benar bingung, lalu periksa dokumen desain. Atau, baca dokumen desain untuk mendapatkan gambar tingkat tinggi lalu lihat kode untuk melihat seperti apa tampilannya. Ulangi hampir tanpa batas waktu selama Anda bekerja dengan kode tersebut.

• Sadarilah bahwa dokumen desain hampir selalu ketinggalan zaman, dan tidak benar dalam banyak hal. Namun, selama Anda tetap mengingat poin-poin ini, dokumen yang ketinggalan zaman masih membantu Anda memahami pikiran penulis di beberapa titik di masa lalu. Banyak masalah dan masalah tingkat tinggi masih akan valid, dan Anda kemungkinan besar akan dapat lebih cepat memahami bagaimana kode itu sampai ke tempatnya, jika Anda bahkan mendapatkan gambaran tanggal di mana penulis awalnya berpikir akan melakukannya. Pergilah.

• Ketika Anda bekerja melalui kode dan desain, buat dokumen Anda sendiri yang menggambarkan pemahaman Anda tentang kode hari ini. Mungkin dokumen-dokumen ini adalah satu atau dua sketsa sederhana, mungkin mereka ditulis dalam wiki, mungkin dokumen lain. Jangan membuatnya terlalu rumit: tidak ada dokumen kata 30 halaman. Turunkan ide-ide Anda, yang akan sangat memperjelas pemikiran Anda sendiri.

Itu tergantung pada jenis aplikasi. Jika ini aplikasi data-sentris, saya biasanya memulai dengan desain database. Jika memiliki UI, Anda dapat menjalankan (atau desain layar yang bagus) yang juga dapat memberi Anda ide bagus tentang apa yang dilakukan aplikasi dengan sangat cepat (saya hanya berbicara beberapa jam di sini paling banyak). Setelah itu saya mulai menggali ke dalam kode dan itu akan lebih masuk akal karena saya tahu apa yang sedang dilakukan aplikasi.

Saya mulai dengan dokumentasi desain. Secara khusus, spesifikasi - yang menceritakan maksud dari hal yang sedang dilihat.

Jika memungkinkan, saya kemudian melihat catatan desain dan dokumentasi untuk mendapatkan gambaran umum tentang bagaimana hal itu dilakukan, proses pemikiran, gaya dan sifat orang-orang yang bersangkutan.

Jika memungkinkan saya kemudian berbicara dengan orang-orang yang mengerjakannya - apa fungsinya? Bagaimana? Mengapa? Di mana mayat-mayat itu dikuburkan?

Ada kecenderungan di antara pengembang untuk beralih ke kode: "Biarkan saya menunjukkan kode ini kepada Anda". Ini bagus untuk mereka tetapi cenderung membajak kebutuhan saya - yaitu memahami level tinggi yang memberikan konteks pada hal-hal level rendah.

Ia menggunakan kekuatan otak dalam jumlah besar untuk melihat sedikit kode, di luar konteks lengkap, dan memahami apa pun yang bermakna. Jadi jika memungkinkan, minta pengembang untuk membicarakan PRINSIP, struktur, unit, modul, apa pun yang semuanya mengarah pada penghargaan terhadap tugas tersebut.

Hanya dengan demikian, ada baiknya mencoba masuk ke dalam kode.

Dalam skema besar, melihat kode seperti melihat halaman yang penuh dengan 0 dan 1. Ada artinya tetapi butuh waktu lama untuk mengetahuinya. Mendapatkan cita rasa ke mana harus mencari dan bagian mana yang bermakna membantu mempersempit ruang pencarian.

Semua yang dikatakan - ketika tidak ada dokumen, tidak ada orang, dan hanya kode - maka tidak ada apa-apa selain melihat kode.

Dalam hal ini, saya biasanya tidak mencoba dan memahaminya dengan membaca dalam-dalam yang lambat, saya melakukan quick pass, membaca sekilas semua hal. Terkadang ini hanya membuka file dan duduk dengan menekan tombol page-down. Anda bisa mendapatkan apresiasi yang luar biasa dari gambaran besar hanya dengan melakukan ini. (Dan dalam beberapa kasus saya bahkan string-dump file yang dapat dieksekusi dan menjaringnya, mencari tanda tangan dan pola. Ini telah sangat bermanfaat selama 20 tahun terakhir.)

Saya mulai dengan tes. Jika tes unit dan tes integrasi ditulis dengan baik, mereka menggambarkan kasus penggunaan. Jika mereka tidak ditulis dengan baik, atau tidak ditulis sama sekali (sayangnya, ini sebagian besar terjadi), saya mulai dengan titik masuk dalam kode dan mencocokkan orang-orang dengan desain.

Saya kemudian akan menulis tes untuk setiap kasus penggunaan, ditemukan oleh pohon Anda akan menemukan setelah menyelidiki titik masuk, untuk menyelidiki kode dan menggunakan utilitas cakupan kode untuk melihat apa yang saya hilang. Tes-tes ini memberi tahu saya persis bagaimana kodenya bekerja.

Saya selalu berusaha menambah nilai pada sesuatu yang saya lihat; penulisan tes, pembersihan kode, fungsi refactoring besar (20+ baris).

Saya menemukan bahwa membuat dokumentasi saja tidak menambah nilai nyata ke kode karena tidak pernah berinteraksi dengan kode.

baik, apa itu "desain"? README? diagram uml? Anda dapat melakukan dokumen desain setengah (dan sebagian besar), Anda tidak dapat membuat kode setengah

desain apa pun hanya akan menjadi pendapat , sedangkan kode adalah faktanya

saya hanya akan merujuk ke dokumen sekunder ketika saya tidak dapat memahami alasan kode

membaca kode adalah keterampilan penting bagi pengembang. Anda sebaiknya mempelajarinya sekarang, toh Anda tidak akan melihat banyak dokumentasi berguna selama karier Anda

Lalu saya melihat README pengembang, TODO, dan Changelog. Jika saya tidak mengerti mengapa perangkat lunak itu ditulis, bagaimana itu ditulis, dan kemana akan pergi ... Saya tidak menggunakannya.

Desain pertama, lalu kode, top-down jika Anda mau, jadi saya mengerti konteks di setiap level yang harus saya kerjakan.

Tetapi jika saya harus melakukan perubahan yang sangat spesifik, seperti memperbaiki laporan atau perhitungan, saya hanya pergi dan melihat kode.

Lebih khusus lagi, pendekatan "desain pertama" saya adalah yang ini:

Saya mulai dengan model de domain jika ada satu, jika tidak ada saya membangun setidaknya satu dasar (titik awal yang baik adalah model data). Ini mendefinisikan "glosari" dari aplikasi dan hubungan antara objek (kelas).

Ini menggambarkan "objek mana yang ditangani" oleh aplikasi.

Kemudian saya mencari model use case untuk mencari tahu "proses apa yang dilakukan" oleh aplikasi, meskipun saya lebih suka peta proses jika ada, yang menunjukkan urutan proses.

Setelah itu saya harus memiliki gambar aplikasi yang bagus dan kemudian saya bisa mendesain perubahan.

Omong-omong, jawaban di atas adalah dalam konteks aplikasi bisnis.

Kode tidak berbohong. Ide yang baik tentu saja untuk mendapatkan gambaran umum proyek terlebih dahulu untuk memahami apa yang dilakukannya. Namun, jika tugas Anda adalah untuk mendapatkan pemahaman terperinci tentang bagaimana proyek ini bekerja, melihat kode, setidaknya bagi saya, seperti melihat puzzle sepotong demi sepotong kecuali setiap kelas yang Anda lihat, Anda menambahkan yang lain potongan teka-teki gambar. Jika kode terstruktur dengan baik, Anda dapat melihat pola terbentuk dari nama-nama kelas tanpa menyelidiki apa yang dilakukan kelas. Dalam banyak kasus, Anda bisa mendapatkan petunjuk dan petunjuk dari kode yang akan membantu Anda lebih lanjut.

Akhirnya, Anda mendapatkan ide yang tidak dapat dibatalkan tentang apa yang dilakukan oleh program, teka-teki gambar yang lengkap. Dokumentasi mungkin tidak lengkap atau tidak akurat, tetapi kode tidak pernah bohong. Semua ini dapat Anda lakukan tanpa mencari tahu apa yang dilakukan masing-masing metode individu. Tidak semua orang bisa belajar tentang proyek dengan cara ini, tetapi jika Anda sering melakukannya, itu akan lebih mudah bagi Anda, belum lagi Anda bisa mendapatkan inti dari aplikasi berukuran sedang dalam beberapa jam belajar. Meskipun saya kira semuanya tergantung pada preferensi.

1. Tujuan fungsional aplikasi
2. Lingkup fungsional dan aliran aplikasi menghubungkannya dengan sistem pelanggan lainnya.

Setelah saya melihat kode dari modul / titik aplikasi paling kritis: melihat kode, saya bisa memverifikasi kebaikan desain.

Contoh:

Anda harus bekerja dalam manajemen aplikasi suatu aplikasi web tentang pelaporan keuangan.

1. Saya bertanya dan membaca dokumentasi tentang tujuan: data apa yang harus dilaporkan? Siapa yang menggunakan aplikasi ini?
2. Apa sajakah sistem yang tertaut? Ada tenggat waktu untuk menerima atau mengirim data ke siapa pun? Jika sistem ini tidak berfungsi, aplikasi apa yang rusak atau dihentikan, departemen apa yang rusak?

Setelah saya membaca kode tentang pesan, aplikasi awal dan akhir (untuk kemungkinan kunci dalam db), proses master pembuatan data apa yang harus dilaporkan dll dll (misalnya, dalam penyimpanan gas proses master adalah tentang perhitungan stok gas di area penyimpanan pelanggan dengan pasokan dan injeksi; proses sekunder adalah penagihan tentang data yang dihitung sebelumnya)

Baik kode atau desain. Saya suka berbicara dengan para pemangku kepentingan dan pengguna akhir dan mencari tahu cara kerjanya dari perspektif mereka. Setelah saya dapat membuat gambar dalam pikiran saya dari mereka, saya melihat desain teknis dan kemudian ke kode.

Saya akan pergi dengan desain terlebih dahulu kemudian kode bersamaan. Ini sangat penting karena setiap proyek berbeda. Anda harus keluar dengan rencana dan alur kerja proses tingkat tinggi dari A hingga Z sebelum Anda dapat mulai bekerja pada kode secara bersamaan. Setiap keputusan yang dibuat harus didokumentasikan sehingga tim lain (atau Anda sendiri) yang sedang / sedang mengembangkan kode akan mengetahui pembaruan terbaru dan apa yang telah dikonfirmasi.

Jika ada dokumen desain tingkat tinggi yang bagus, saya akan menggunakannya. Itu harus singkat dan terkini. Jika terlalu verbose atau ketinggalan zaman, saya akan menuju kode.

Tentu saja, itu tergantung pada proyeknya, bukan? Proyek yang sangat kompleks atau banyak sisi mungkin lebih baik didekati melalui dokumentasi (jika dokumentasinya cukup solid.)

Modul tunggal atau aplikasi sederhana, menurut pendapat saya, hampir selalu paling baik didekati pada tingkat kode.

Tidak ada jawaban yang tepat untuk setiap situasi!