Bagaimana saya meninjau kode saya sendiri? [Tutup]


177

Saya sedang mengerjakan proyek solo dan harus menjaga kode saya sendiri. Biasanya review kode dilakukan bukan oleh pembuat kode, sehingga reviewer dapat melihat kode dengan mata segar - namun, saya tidak memiliki kemewahan seperti itu. Praktik apa yang dapat saya terapkan untuk meninjau kode saya sendiri secara lebih efektif?


34
Saya tidak yakin Anda bisa, setidaknya tidak secara efektif - Anda dapat mengumpulkan sumber tim peninjau di codereview.stackexchange.com jika kode Anda tidak berpemilik
jk.

8
Anda tidak dapat meninjau kode Anda sendiri. Jika Anda tidak bisa mendapatkan manusia lain, saya akan mempertimbangkan yang terbaik yang dapat Anda lakukan untuk menggunakan sebanyak mungkin analisis statis yang bisa Anda dapatkan, dan mengaktifkan SEMUA peringatan.

136
Meninjau kode Anda sendiri mudah. Tulis kode bagian. Melangkahlah selama 2 minggu / bulan / tahun saat Anda terus belajar dan mengembangkan perangkat lunak lain. Kembalilah ke bagian itu dan cobalah untuk memahami apa yang dilakukan kode. Anda tahu Anda belajar sesuatu ketika Anda berpikir: "Orang bodoh macam apa yang menulis ini ?!"
Yuriy Zubarev

6
@YuriyZubarev Tetapi bagaimana jika Anda tidak ingin menunggu selama berminggu-minggu / bulan / tahun?
anatoliG

12
Anda dapat meninjau kode Anda dalam kondisi pikiran yang berubah. Atau Anda dapat kode dalam kondisi pikiran yang berubah dan mendelegasikan peninjauan kode ke diri membosankan Anda yang normal.
SK-logic

Jawaban:


92

Pertama-tama, gunakan alat untuk memeriksa sebanyak mungkin. Pengujian (didukung dengan cakupan kode yang masuk akal) akan memberi Anda kepercayaan diri tentang kebenaran kode. Alat analisis statis dapat menangkap banyak hal praktik terbaik. Akan selalu ada masalah yang Anda perlu mata manusia untuk menentukan dan Anda tidak akan pernah melakukan pekerjaan sebaik meninjau barang-barang Anda sendiri seperti orang lain, ada beberapa hal yang dapat Anda lakukan untuk membantu.

  • periksa tes yang ada dan lulus (mungkin memiliki cakupan tes target, meskipun Anda mungkin perlu memecahkan ini dalam kasus-kasus tertentu, tetapi Anda harus dapat membenarkan alasannya)
  • centang lolos analisis Statis (juga akan ada negatif palsu di sini, tetapi itu sah-sah saja asalkan Anda dapat membenarkan mengapa hal itu baik-baik saja untuk menekannya)
  • memelihara daftar periksa hal-hal lebih lanjut untuk memeriksa dalam tinjauan (idealnya tambahkan ini sebagai aturan analisis statis baru jika mungkin) pastikan Anda memeriksa apa pun yang tidak dapat diperiksa oleh SA, misalnya, apakah komentar masih valid, adalah hal-hal yang dinamai dengan benar (penamaan hal-hal adalah tentu saja, salah satu dari 2 masalah sulit yang dikenal dalam ilmu komputer)
  • jika kesalahan teridentifikasi, periksa apakah penyebabnya sistemik dan lihat mengapa tidak ditemukan dalam tes atau ulasan sebelumnya

Ini tentu saja berguna ketika Anda meninjau kode orang lain juga


3
Mengenai daftar periksa, memiliki spesifikasi sangat berguna.
Wayne Werner

Saya tidak suka daftar periksa. Mereka membuat pengulas berkonsentrasi pada daftar periksa alih-alih memikirkan masalah, solusi, dan banyak hal lainnya. Jadi saya sarankan membuatnya minimal.
Balog Pal

57

Lihatlah situs Penukaran Kode Review Tumpuk. Ini untuk berbagi kode dari proyek yang sedang Anda kerjakan untuk peer review :

Code Review Stack Exchange adalah situs tanya jawab untuk mencari peer review dari kode Anda. Kami bekerja bersama untuk meningkatkan keterampilan programmer di seluruh dunia dengan mengambil kode kerja dan membuatnya lebih baik.

Jika Anda mencari umpan balik tentang bagian kerja kode tertentu dari proyek Anda di bidang berikut ...

  • Praktik terbaik dan penggunaan pola desain
  • Masalah keamanan
  • Performa
  • Ketepatan dalam kasus yang tidak terduga

Anda juga dapat menggunakan alat bantu analisis statis kode untuk mendeteksi jenis masalah tertentu, tetapi mereka akan menghasilkan alarm palsu dalam beberapa kasus, dan tidak dapat menyarankan cara meningkatkan desain.


2
Itu jawaban yang sangat baik untuk pertanyaan "Cara mendapatkan kode saya ditinjau", dan saran yang baik secara umum (saya pasti akan melakukan itu) - tetapi masih sedikit offtopic.
Max Yankov

5
Saya biasanya tidak suka jawaban 5 kata, tetapi yang ini benar .
maple_shaft

20
Paling-paling ini hanya solusi terbatas. Terus menempatkan seluruh output harian Anda pada CR.SE tidak layak karena celah besar itu akan menjadi kode boilerplate yang cukup biasa. CR.SE juga tidak akan banyak membantu dalam menemukan masalah yang membutuhkan pemahaman non-sepele tentang seluruh arsitektur aplikasi atau domain yang menjadi tujuan aplikasi ini. Dari informal, lihat kode rekan kerja ketika diperiksa dalam gaya, ulasan di mana saya bekerja kesalahan semacam ini mungkin lebih umum daripada yang akan cocok untuk ditangkap melalui CR.SE.
Dan Neely

3
Nilai sebenarnya dalam peninjauan adalah mendapatkan potongan kode yang Anda tidak pernah sekalipun akan menampilkan masalah yang terlihat dan disorot sebagai tidak jelas atau menjelaskan sendiri atau bahkan secara logis tidak benar . Anda tidak dapat memposting snipet ke code reviewjika Anda belum mengetahui bahwa itu bermasalah.
ZJR

3
@ ZJR Baiklah, apakah kode di proyek Anda 100% diulas? Jika ya, teknisi Anda memiliki terlalu banyak waktu luang. Adapun komentar 2 Anda, saya tidak melihat masalah dalam meminta review kode dalam kode yang menurut Anda sempurna.
BЈовић

29

Saya telah mengembangkan beberapa orang yang benar-benar berbeda di kepala saya. Salah satunya bahkan bukan programmer! Kami mengobrol, membahas berita terbaru dan meninjau kode masing-masing.

Saya sangat merekomendasikan pendekatan saya.

PS Dia tidak bercanda.


27
Nama saya Bill, Jeff, Bob, dan Alice, dan kami menyetujui pesan ini.
Michael K

22

Saya setuju dengan pendapat jk-s bahwa review satu orang tidak seefisien 2 orang. namun Anda dapat mencoba melakukan yang terbaik:

ulasan jangka pendek (tak lama setelah kode diproduksi)

Saya menggunakan git sebagai repositori lokal. Setiap kali saya menyelesaikan fitur atau memperbaiki bug, saya mentransfer perubahan ke repositori.

Sebelum saya check-in saya membandingkan apa yang telah saya ubah dalam kode saya dan memikirkan kembali:

  • apakah variabel / metode / nama kelas masih mencerminkan untuk apa mereka digunakan?

tinjauan jangka panjang (6 bulan setelah kode diproduksi)

Saya bertanya pada diri sendiri:

  • dapatkah saya menjelaskan dalam satu sentense apa yang dilakukan oleh kelas / metode / variabel?
  • betapa mudahnya menggunakan kelas secara terpisah (memutihkan kelas lain) atau menulis unittest untuk?

4
+1 untuk saran ulasan jangka pendek. Menggunakan git untuk melihat semua perubahan di antara berbagai titik waktu dapat benar-benar membantu membersihkan kode.
Leo

Saya diam seperti ide ulasan jangka panjang, saya pikir saya mungkin akan menggabungkannya menjadi proyek umum review cuci-up dan mungkin tidak meninjau semua kode (sekali lagi saya tidak cenderung melakukan pengembangan solo banyak)
jk.

Saya mencoba melakukan sesuatu di antaranya: tinjau kode saya sekitar sebulan. Saya juga suka review 6 bulan.
David G

18

Pertama, sisihkan kode Anda selama mungkin. Kerjakan sesuatu yang lain, potongan kode lainnya. Bahkan setelah sehari, Anda akan kagum dengan apa yang akan Anda temukan.

Kedua, dokumentasikan kode Anda. Banyak programmer tidak suka mendokumentasikan kode mereka, tetapi buatlah diri Anda duduk dan menulis dokumentasi, cara menggunakan kode dan cara kerjanya. Dengan melihat kode Anda dengan cara yang berbeda, Anda akan menemukan kesalahan.

Dikatakan bahwa penguasaan sejati suatu subjek adalah kemampuan untuk mengajarkannya kepada orang lain. Dengan dokumentasi, Anda mencoba mengajarkan kode lain kepada orang lain.


15

Ubah teknik debugging ini menjadi teknik tinjauan kode: http://en.wikipedia.org/wiki/Rubber_duck_debugging

Konsep ini berhasil karena menempatkan Anda dalam pola pikir yang tepat untuk mengerjakan kode seolah-olah itu baru.


3
Saya percaya teknik bebek telah ditemukan secara independen di beberapa lokasi; inilah kisah yang hebat tentang hal itu: hwrnmnbsol.livejournal.com/148664.html
Russell Borogove

10
Saat ini, bebek karet saya adalah formulir tanya-jawab Pertukaran Stack. Keinginan untuk menulis pertanyaan yang bagus bisa membantu.
Kevin Reid

Saran yang sangat baik. Ini bahkan lebih baik karena saya sudah memiliki bebek karet di meja saya (ini sudah ada di sini sebagai model untuk salah satu karakter permainan saya, tapi saya kira itu tidak akan keberatan dengan pekerjaan tambahan seorang konsultan TI).
Max Yankov

5
@KevinReid, saya akan senang melihat beberapa statistik pada posting SE yang ditinggalkan - terutama yang orang telah mengetik lebih dari 60-an. Saya tahu saya telah melakukan hal yang sama sendiri setidaknya 5 kali.
Wayne Werner

Wah! Saya tidak tahu ini "sesuatu". Saya baru saja berkomentar di atas bahwa profesor sci saya merekomendasikan ini selama kuliah pertama kami, beberapa dekade yang lalu. Dia merekomendasikan kucing, tapi kurasa bebek karet bisa melakukannya. Satu hal yang pasti, itu tidak akan berhasil tanpa sidekick antropomorfik :-)
Mawg

13

Selain alat yang berguna yang disebutkan dalam jawaban lain, saya pikir memodifikasi pola pikir Anda berguna ketika melakukan tinjauan kode. Ini konyol, tapi saya berkata pada diri sendiri: "Saya memakai topi ulasan kode saya". Saya melakukan hal yang sama dengan QA.

Maka penting untuk membatasi diri Anda pada pola pikir itu. Anda adalah peninjau atau penerima ulasan, Anda tidak bisa sekaligus. Jadi sebagai peninjau, saya membuat catatan obyektif untuk dibagikan dengan orang yang ditinjau. Saya tidak mengubah kode saat saya meninjaunya, itu bukan sesuatu yang harus dilakukan oleh pengulas.

Formalitas terasa agak aneh di kali, tetapi saya menemukan ketika bekerja solo bahwa saya sering menarik banyak arah. Jadi saya mungkin belum tentu menutup loop ulasan sebelum sesuatu yang lain muncul - formalitas itu (dan sungguh, saya berbicara catatan kasar dalam alat wiki), berguna untuk memastikan review selesai. Begitu juga dengan topi QA saya aktif, saya menambahkan tiket untuk bug sebelum saya memperbaikinya.


Saya rasa tidak mungkin untuk meninjau kode Anda sendiri
BЈовић

4
@ VJovic - Saya rasa saya tidak melakukan tinjauan kode terbaik pada kode saya, tetapi saya biasanya menemukan hal-hal yang dapat ditingkatkan. Saya membaca banyak kode orang lain juga. Pandangan saya tentang seperti apa kode "baik" itu terus berkembang. Saya malu dengan kode yang saya tulis bertahun-tahun yang lalu. Tidak ada bedanya dengan memeriksa artikel Anda sendiri - itu membutuhkan latihan dan lebih banyak usaha, tetapi bisa dilakukan. Hal utama yang tidak bisa saya ulas sendiri adalah jika abstraksi masuk akal bagi orang lain. Tapi saya bisa bertanya pada diri sendiri bagaimana membuat sesuatu yang lebih sederhana, apakah ini perlu, dll.
Steve Jackson

@VJovic - Seperti ThomasOwens sebutkan, Anda juga dapat membuat daftar periksa dari kesalahan masa lalu dan menjalankannya dengan cukup objektif. Itu hal baik lainnya tentang menjadi semacam formal tentang hal itu, Anda dapat melihat apa yang Anda lewatkan selama ulasan dan menyesuaikan proses Anda sesuai. Saya mendapati saya belajar banyak pelajaran dengan melacak diri saya dan berusaha mengubah pendekatan saya ketika ditunjukkan.
Steve Jackson

3
Masuk ke pola pikir yang benar sangat penting. Saya menemukan bahwa itu membantu jika saya benar-benar mencetak kode dan membacanya di atas kertas dengan spidol. Maka saya tidak dapat mengubah apa pun ketika meninjau (yang mencegah saya masuk ke mode pengkodean) dan dapat dengan mudah menuliskan komentar dan panah gerakan di atas kertas.
Leo

Itu berarti meninjau kode lama, dan bukan kode baru. Untuk itu Anda perlu mendapatkan pengalaman, yang bisa makan waktu lama.
BЈовић

9

Nampaknya sentimen yang umum adalah bahwa self-review tidak efektif. Saya tidak setuju, dan saya pikir peninjauan kembali dapat menangkap banyak masalah jika dilakukan secara menyeluruh.

Berikut tips dari pengalaman saya selama beberapa tahun:

  • Siapkan daftar periksa kasar. Ini adalah hal-hal yang ingin Anda panji saat membaca kode Anda.
  • Bawa ulasan kode Anda offline. Mungkin terdengar boros, tetapi ambil cetakan yang bisa Anda anotasi dan balik-balik, atau setara digital pdf yang disorot dengan baik disinkronkan ke iPad yang kemudian diambil offline. Pergi dari meja Anda, sehingga yang Anda lakukan hanyalah meninjau kode Anda tanpa gangguan.
  • Lakukan lebih awal di pagi hari, bukan di akhir hari kerja. Sepasang mata lebih baik. Bahkan, mungkin membantu untuk menjauh dari kode sehari sebelum meninjaunya kembali.

Hanya FYI - pedoman ini adalah bagian dari rekomendasi di Oracle beberapa tahun yang lalu ketika saya bekerja di sana, di mana tujuannya adalah untuk menangkap bug "hulu" sebelum kode masuk ke pengujian. Itu banyak membantu, meskipun itu dianggap pekerjaan yang membosankan oleh banyak pengembang.


3
Saya juga menambahkan "tunggu 24 jam" sehingga Anda tidak melihat kode yang baru saja Anda tulis. Pastikan umurnya setidaknya 1 hari sehingga Anda melihatnya setelah tidur semalaman dan tidak menyentuhnya selama 24 jam penuh.
Jeff Atwood

Saya sering menggunakan cetakan ketika saya perlu meninjau atau terutama refactor beberapa kode. Ini bekerja keajaiban bagi saya.
yitznewton

Seperti dalam beberapa film yang kami pelajari dari GB bahwa orgasme palsu lebih baik daripada tanpa orgasme - ulasan sendiri lebih baik daripada tidak sama sekali. Ya, Anda bisa berlatih untuk melakukan rubberducking banyak. Tapi itu masih sangat tidak efektif dibandingkan dengan peer review yang sebenarnya. terutama tanpa terkena pengulas sebenarnya baik untuk beberapa waktu untuk mengambil metode.
Balog Pal

8

Teknik Proses Perangkat Lunak Pribadi untuk ulasan mungkin berguna, meskipun mengandalkan memiliki data historis tentang pekerjaan Anda dan kualitas produk.

Anda mulai dengan data historis tentang produk pekerjaan Anda, khususnya jumlah dan jenis cacat. Ada berbagai metode mengklasifikasikan cacat, seperti ini dari kursus PSP . Anda bisa mengembangkan sendiri, tetapi idenya adalah Anda harus bisa mengatakan kesalahan apa yang Anda lakukan di sepanjang jalan.

Setelah Anda tahu kesalahan apa yang Anda buat, Anda dapat mengembangkan daftar periksa yang dapat Anda gunakan selama ulasan. Daftar periksa ini akan mencakup kesalahan teratas yang Anda buat yang menurut Anda paling baik ditangkap dalam ulasan (sebagai lawan menggunakan beberapa alat lain). Setiap kali Anda meninjau produk kerja, gunakan daftar periksa dan cari kesalahan atau kesalahan tersebut, dokumentasikan, dan perbaiki. Perbaiki daftar periksa ini secara berkala dari waktu ke waktu untuk memastikan Anda berfokus pada masalah nyata dan relevan dalam kode Anda.

Saya juga akan merekomendasikan menggunakan dukungan alat ketika masuk akal. Alat analisis statis dapat membantu menemukan beberapa cacat, dan beberapa bahkan mendukung pemeriksaan gaya untuk menegakkan konsistensi dan gaya kode yang baik. Menggunakan IDE dengan penyelesaian kode dan penyorotan sintaksis juga dapat membantu Anda mencegah atau mendeteksi beberapa masalah sebelum mengklik "build". Tes unit dapat mencakup masalah logika. Dan jika proyek Anda cukup besar atau kompleks, integrasi berkesinambungan dapat menggabungkan semua ini ke dalam proses yang dijalankan secara teratur dan menghasilkan laporan yang bagus untuk Anda.


7

Bekerja solo berarti bahwa kecuali Anda memercayai orang asing untuk meninjau kode atas nama Anda, Anda harus melihat cara Anda menulis perangkat lunak untuk menjaga kualitas kode.

Pertama dan terpenting, Anda harus memiliki sarana untuk memastikan bahwa kode Anda sesuai dengan persyaratan, dan kedua bahwa kode Anda akan relatif mudah diubah jika Anda kemudian memutuskan bahwa Anda mendapatkan sesuatu yang salah. Saran saya adalah untuk menerapkan pendekatan Pembangunan Berbasis Perilaku karena alasan berikut:

  1. BDD berarti menulis tes kode terlebih dahulu. Ini memastikan semua kode Anda dicakup oleh tes.
  2. BDD pada dasarnya adalah TDD, tetapi dengan fokus dan "bahasa" yang sedikit berbeda. Apa artinya ini adalah bahwa Anda terus-menerus memperbaiki kode Anda saat Anda mengerjakannya, dan menggunakan tes Anda untuk memastikan upaya refactoring Anda terus memastikan bahwa kode Anda memenuhi spesifikasi produk Anda.
  3. Bahasa BDD mendorong tes ditulis dalam bentuk pernyataan yang pada dasarnya menyandikan persyaratan sebagai tes unit.

Jadi idenya di sini, adalah bahwa refactoring kode Anda yang berkesinambungan bahkan setelah Anda mendapatkan tes Anda untuk lulus, berarti bahwa Anda secara efektif meninjau kode Anda sendiri dan menggunakan tes unit Anda sebagai "sepasang mata tambahan" yang memastikan kode Anda tidak t menyimpang dari persyaratan yang dikodekan dalam tes. Selain itu, cakupan tes tinggi berdasarkan persyaratan memastikan Anda akan dapat mengubah kode Anda di masa depan tanpa gagal persyaratan.

Masalah sebenarnya bagi Anda adalah apakah Anda dapat menemukan potensi masalah dalam kode Anda yang akan menunjukkan perlunya refactor. Ada beberapa alat profil di pasar yang dapat membantu Anda dengan ini, serta beberapa alat lain yang berkaitan dengan metrik kualitas kode. Ini sering dapat memberi tahu Anda banyak hal yang dapat dilewatkan oleh tinjauan kode, dan merupakan keharusan ketika mengembangkan proyek sendiri. Namun dalam kenyataannya, pengalaman adalah kuncinya, dan begitu Anda terbiasa tanpa ampun dalam refactoring Anda, kemungkinan Anda akan menjadi jauh lebih kritis terhadap kode Anda sendiri. Jika Anda belum melakukannya, saya sarankan membaca buku Refactoring Martin Fowler sebagai titik awal, dan mencari API BDD yang bagus yang menurut Anda akan cocok untuk Anda dalam bahasa apa pun yang Anda pilih untuk digunakan.


5

Setiap kali saya berada dalam situasi yang sama dengan diri Anda sendiri, saya telah mencoba untuk memecahkan masalah "terlalu dekat dengan kode untuk secara objektif memeriksanya" dengan menggunakan peninjauan kode / alat metrik. Tak perlu dikatakan bahwa alat tidak dapat memberikan nilai yang sama dengan resensi yang berpengalaman, tetapi Anda masih bisa menggunakannya untuk menunjukkan area dengan desain yang buruk.

Salah satu alat yang saya temukan cukup berguna dalam hal ini adalah SourceMonitor . Ini agak sederhana, tetapi memberikan pendapat tingkat menengah yang baik dari kode Anda, seperti jumlah metode dalam kelas, dan kompleksitas setiap metode. Saya selalu merasa bahwa jenis informasi ini sama pentingnya (jika tidak lebih penting dari) penegakan gaya pengkodean melalui alat-alat seperti StyleCop, dll (yang penting, tetapi seringkali bukan sumber masalah terbesar). Gunakan alat ini dengan penafian biasa: tahu kapan harus melanggar aturan praktis, dan sesuatu yang semuanya hijau dalam alat metrik kode tidak secara otomatis berkualitas baik.


5

Saya tidak bisa memberi tahu Anda berapa kali saya telah menjelaskan sesuatu kepada pengkaji kode dan bola lampu di kepalaku menyala dan berkata, "Hei, tunggu dulu." Jadi saya sering menemukan kesalahan saya sendiri dalam ulasan kode yang tidak dilihat orang lain. Jadi Anda bisa mencobanya, mulailah menjelaskan kodenya seolah-olah ada orang yang duduk di sebelah Anda yang berusaha memahami apa yang Anda lakukan dan mengapa.

Hal lain yang sering saya temukan dalam ulasan kode adalah bahwa pengembang tidak benar-benar mengikuti persyaratan. Jadi membandingkan kode Anda dan apa yang dilakukannya dengan persyaratan yang sebenarnya adalah pemeriksaan yang baik.

Kami sering melakukan hal-hal seperti paket SSIS yang memiliki kebutuhan struktural yang serupa - untuk ulasan kode, saya mengembangkan daftar hal yang harus diperiksa (apakah konfigurasi sudah benar, apakah logging sudah diatur, apakah menggunakan basis data metadata, apakah file di lokasi standar, dll.) Anda mungkin memiliki beberapa hal yang berguna untuk diperiksa setiap kali dalam tinjauan kode juga. Duduk dan pikirkan apa yang akan Anda masukkan pada daftar hal-hal yang Anda ingin pastikan untuk memeriksa dalam tinjauan kode Anda (item pertama, pastikan persyaratannya dipenuhi, item berikutnya mungkin ada hubungannya dengan kesalahan trapping dan logging). Saat Anda membuat kesalahan dan memperbaikinya, Anda dapat menambahkan item lain ke daftar (katakan sesuatu seperti, apakah saya pindah ke catatan berikutnya dalam satu lingkaran atau apakah saya akan terus-menerus mengulang item pertama yang sama - hanya perlu satu putaran tanpa akhir untuk mengajari Anda untuk mencari itu!).


1
Seperti yang disarankan Patrick Hughes dalam jawabannya, menggunakan proxy seperti bebek karet untuk menggantikan resensi membantu pola pikir.
Russell Borogove

5

Berikan 3 bulan, lalu kembali dan lihat kode Anda. Saya berjanji kepada Anda, jika Anda tidak dapat menemukan sesuatu yang salah dengan itu (atau pertanyaan siapa yang menulis sampah ini!) Anda adalah orang yang lebih baik daripada saya!


Itu teknik saya juga. 3 bulan cukup lama sehingga segala sesuatu yang tidak dapat saya langsung mengerti perlu disederhanakan atau didokumentasikan dengan lebih baik, tetapi cukup singkat sehingga saya masih ingat apa yang terjadi cukup mudah untuk memperbaikinya.
Eric Pohl

5

Saya biasanya mencetak semua kode saya dan duduk di lingkungan yang tenang dan membacanya, saya menemukan banyak kesalahan ketik, masalah, hal-hal untuk diperbaiki, pembersihan dengan melakukan itu. Ini adalah pemeriksaan diri yang baik yang menurut saya semua harus dilakukan.


Tambahan yang bagus untuk saran di atas, terima kasih - walaupun saya berpikir bahwa tablet atau sesuatu seperti itu (dengan editor, tetapi tanpa lingkungan pengembangan) akan bekerja juga. Saya ingin tahu siapa yang menurunkan itu dan mengapa.
Max Yankov

4

Kembali di perguruan tinggi saya adalah seorang guru menulis. Ini tentu saja memberi saya beberapa perspektif tentang pengkodean yang saya pikir banyak pengembang tidak akan pernah pikirkan. Salah satu yang paling penting adalah membaca kode Anda dengan keras. Kedengarannya tidak banyak, tapi saya akan memberikan contoh yang sempurna yang saya pikir semua orang bisa berhubungan.

Pernahkah Anda menulis email atau kertas, membaca ulang beberapa kali untuk memastikan itu benar, lalu mengirimkannya, hanya untuk mengetahui bahwa Anda memiliki kesalahan pengejaan, kesalahan ketik, atau tata bahasa yang mencolok? Saya baru saja melakukan ini kemarin ketika saya meminta klien untuk menekan tombol shit daripada tombol shift. Ketika Anda membaca di kepala Anda - Anda melihat apa yang ingin Anda lihat.

Ini adalah jalan pintas untuk saran 'tunggu saja sehari atau seminggu atau sebulan' yang dibuat orang lain. Jika Anda membacanya dengan keras, Anda menangkap hal yang sama. Saya tidak tahu mengapa ini sangat efektif, tetapi setelah duduk bersama ratusan siswa dan membacanya dengan keras, saya hanya dapat mengatakan bahwa itu berhasil.


+1 Ini akan sejalan dengan pendekatan "jelaskan ke kucing Anda". Menggunakan berbagai bagian otak Anda dapat membantu ketika Anda tidak dapat menggunakan rekan kerja.
BMitch

ditambah satu untuk kunci kotoran
Mawg

3

Sebagian besar orang cenderung menganggap kode mereka sebagai bayi mereka sendiri dan memberi mereka makan dengan ego daripada kenyataan. Sama seperti ulasan kode lainnya, tinjau ketika Anda melihat kode orang lain. Benar-benar lupa bahwa Anda telah menulis sesuatu. Tinjau setiap baris kode. Daftar periksa akan membantu untuk menjadi estetika tentang peninjauan kode sendiri. Alat otomatis untuk tinjauan kode dapat membantu memperluas. Saya telah menggunakan beberapa alat seperti klocwork (perangkat lunak komersial), ini cukup berguna saat Anda bekerja di proyek besar dan beberapa pengembang bekerja untuk itu. Selalu fokus pada deteksi cacat daripada koreksi.

Tetapi praktik terbaik adalah, meninjau diri sendiri dan kemudian melibatkan setidaknya dua orang lain untuk diperiksa dengan peran yang berbeda.


3

Pertimbangkan melakukan inspeksi Fagan sendiri - Anda harus menyesuaikan proses karena Anda sendiri, tetapi Anda harus bisa mendapatkan sedikit nilai dari itu. Kuncinya adalah menemukan "aturan" yang tepat untuk mengevaluasi kode Anda sebagai pengembang solo, dan kemudian memiliki disiplin untuk mengajukan pertanyaan-pertanyaan itu dalam kerangka berpikir kritis, analitis, tanpa ampun setiap kali. Saya menduga Anda mungkin ingin melakukan brainstorming 4-5 pertanyaan penting Anda sendiri untuk memulai, dan kemudian mengembangkannya dari waktu ke waktu. Beberapa orang menentang inspeksi formal karena mereka tampaknya sangat intensif waktu ... sebelum Anda memutuskan bahwa mereka terlalu mahal, ingatlah semua bukti statistik bahwa melakukan inspeksi dengan benar sebenarnya mengurangi waktu proyek. Berikut ini tautan Wikipedia yang dapat Anda mulai penelitian lebih lanjut:

http://en.wikipedia.org/wiki/Software_inspection

Ada beberapa buku juga, misalnya Google untuk "Proses Inspeksi Perangkat Lunak" oleh Strauss dan Ebenau.

Pilihan lain adalah membayar seseorang untuk memeriksa proyek penting - atau mungkin membayar mereka sesekali untuk melakukan inspeksi semua kode Anda. Orang ini cukup baik, kami telah menerbangkannya beberapa kali untuk melatih pengembang baru kami:

http://www.javaspecialists.eu/


0

Terlepas dari semua rekomendasi untuk tinjauan kode, Anda dapat menggunakan alat-alat seperti PMD dan findBug untuk melakukan kewarasan tingkat pertama untuk kode Anda.


0

Ini sebenarnya belum ditempatkan di jawaban (tetapi telah ditambahkan sebagai komentar untuk jawaban yang ada)

Tinjau kode Anda setelah tidur malam yang nyenyak, misalnya mulai hari dengan meninjau kode yang Anda tulis hari sebelumnya.

Ini tentu saja tidak akan memberi Anda pengalaman kolektif dari suatu tim, tetapi itu akan memberi Anda kesempatan meninjau kode dari perspektif baru.

Misalnya, jika Anda meninggalkan sepotong kode dengan hack jahat, Anda mungkin tidak terlalu cenderung untuk memperbaikinya, jika Anda meninjau kode Anda segera setelah itu. Lagi pula, ketika Anda mulai meninjau kode Anda, Anda sudah tahu, dan telah menerima, keberadaan peretasan ini. Tetapi jika Anda telah tidur nyenyak, Anda mungkin lebih termotivasi untuk menemukan solusi yang lebih baik.

Ketika kita tidur, otak tidak benar-benar berhenti bekerja pada masalah yang kita miliki, jadi Anda mungkin benar-benar menemukan solusi di sana, meskipun solusi itu kadang-kadang muncul dengan cara yang aneh .

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.