Bagaimana saya meninjau kode saya sendiri? [Tutup]

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?

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

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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!).

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!

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.

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.

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.

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/

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

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 .