Saya telah diberi peran untuk meningkatkan pengembangan di perusahaan kami. Hal pertama yang saya ingin mulai adalah ulasan kode karena itu belum pernah dilakukan di sini sebelumnya.

Ada 3 programmer di perusahaan kami. Saya seorang programmer web, bahasa saya yang dikenal terutama PHP, ActionScript dan JavaScript. 2 pengembang lainnya menulis aplikasi internal di VB.net

Kami telah melakukan tinjauan kode selama beberapa minggu sekarang. Saya merasa sulit untuk memahami kode VB. Jadi ketika mereka mengatakan apa yang dilakukannya, sebagian besar saya hanya harus mengambil kata mereka untuk itu.

Jika saya melihat sesuatu yang keliru, saya menjelaskan pendapat saya dan saya menjelaskan bagaimana saya akan mengatasinya dalam salah satu bahasa yang saya tahu.

Terkadang saran saya disambut tetapi sering kali saya diberitahu hal-hal seperti "ini adalah cara terbaik untuk melakukannya dalam bahasa ini " atau "yang tidak berlaku untuk bahasa ini " atau hal serupa dari sifat itu.

Ini mungkin benar, tetapi tanpa mengetahui bahasa saya tidak yakin bagaimana cara mengkonfirmasi atau membantah klaim ini.

Saya tahu salah satu solusi yang mungkin adalah belajar vb sehingga saya bisa melakukan tinjauan kode yang lebih baik. Saya benar-benar tidak tertarik untuk belajar vb (terutama karena saya memiliki daftar teknologi lain yang saya coba pelajari untuk proyek-proyek saya sendiri) dan ingin menjadikan ini sebagai pilihan terakhir tetapi itu adalah pilihan.

Gagasan lain yang datang kepada saya adalah, mereka berdua memiliki minat pada C # dan begitu juga saya. Ini relatif terhadap mereka karena .net dan relatif terhadap saya karena lebih mirip dengan bahasa yang saya tahu. Namun itu baru bagi kita semua. Saya berpikir tentang manfaat dari kita semua berkolaborasi pada proyek hewan peliharaan C # .net dan meninjau masing-masing kode dari itu.

Saya kira ada juga kemungkinan mempekerjakan konsultan untuk datang dan memberi kami beberapa tinjauan kode.

Apa yang akan Anda rekomendasikan saya lakukan dalam situasi ini.

Keinginan pribadi Anda untuk mempelajari hal-hal lain harus duduk di belakang untuk mempelajari apa yang sebenarnya Anda butuhkan saat ini untuk pekerjaan Anda. Pelajari VB.net. Anda dapat secara efektif mengkode kode ulasan yang tidak Anda mengerti ketika Anda tahu bahasa yang digunakan dengan mengajukan banyak pertanyaan (biasanya itu pertanda bahwa kode tersebut tidak ditulis dengan baik jika Anda tahu bahasa tersebut dan tidak dapat mengetahui apa yang dilakukannya dan Mengapa). Tetapi tidak memahami kode, yang terbaik yang dapat Anda lakukan adalah membuat mereka menjelaskannya kepada Anda dan berharap mereka akan melihat bug melalui proses menjelaskannya. Bukannya saya belum menemukan bug dalam kode saya sendiri dalam ulasan dengan melakukan hal itu, tetapi itu bukan cara paling efektif untuk meninjau kode. Peninjauan kode sekarang menjadi bagian dari pekerjaan Anda, atasi dan pelajari apa yang perlu Anda pelajari untuk melakukannya secara efektif.

Saat Anda belajar, ketika mereka mengatakan dengan baik bahwa bukan cara kami melakukannya dalam bahasa ini, buatlah mereka menunjukkan kepada Anda sebuah sumber yang mengatakan itu adalah teknik yang baik untuk digunakan. Terserah mereka untuk membenarkan kepada Anda dalam review kode bukan sebaliknya. Anda juga akan menjadi lebih baik di bahasa setelah Anda mulai melihat tautan itu.

Sebenarnya, saya tidak setuju dengan semua hal di atas. Dengan JS / PHP / ActiopnScript, Anda memiliki pemahaman mendasar tentang apa yang dimiliki bahasa pemrograman dan cara kerjanya. Bahkan, saya berpendapat bahwa ada banyak kesamaan antara VB dan JS. Namun, itu bukan poin saya. Bahkan jika Anda sangat kompeten dengan bahasa tersebut, mudah untuk mengabaikan sesuatu ketika mencoba mengikuti proses berpikir orang lain, jadi apa yang harus dilakukan tinjauan adalah memberikan kesempatan bagi programmer untuk menjelaskan apa yang telah ia lakukan dan mengapa.

Seorang teman pernah menggambarkan ini sebagai "The Janitor Theory": dengan menjelaskan detailnya kepada seseorang, siapa pun, bahkan petugas kebersihan, programmer memaparkan setiap kelemahan dalam kode tersebut kepada dirinya sendiri, yang tentu saja merupakan tujuan akhir dari ulasan tersebut. proses. Meskipun demikian, kode ini harus dijelaskan secara menyeluruh dan terbuka (ulasan tidak berfungsi ketika pengembang bersikap defensif).

Versi singkat

1. Ingatlah bahwa ulasan kode adalah kesempatan untuk dipelajari dan dikaji oleh pengulas.
2. Umpan balik frasa sebagai pertanyaan.
3. Jangan biarkan kurangnya pengetahuan menghentikan Anda dari memberikan umpan balik (selama Anda melakukan # 2).
4. Hindari "ulasan preferensi" atau setidaknya cobalah membuatnya menjadi jelas bahwa itu adalah preferensi pribadi Anda dan mereka tidak perlu setuju.
5. Cobalah untuk mengirimkan tambalan alih-alih menjadi "peninjau kode kursi".

Versi yang lebih panjang

Pertama-tama, ingatlah bahwa tinjauan kode bukan hanya kesempatan bagi orang yang ditinjau untuk belajar. Ini juga merupakan kesempatan bagi pengkaji untuk belajar juga. Bahkan, saya pernah mendengar beberapa organisasi yang membuat pemrogram baru mulai melakukan tinjauan kode sehingga mereka bisa merasakan kode tersebut.

Dengan mengingat hal ini, ada satu saran saran ulasan kode yang saya anggap berguna secara umum, tetapi khususnya berkaitan dengan posisi Anda. Frase tanggapan Anda dalam bentuk pertanyaan dan bukan sebagai pernyataan. Dengan kata lain, alih-alih mengatakan "Kode ini payah!", Anda bisa mengatakan "Mengapa Anda menulis kode dengan cara ini daripada melakukan ..." Ini membuat proses peninjauan kode lebih menyenangkan dan memungkinkan Anda untuk belajar juga.

Saran lain yang saya miliki untuk Anda adalah jangan biarkan kurangnya pengetahuan membuat Anda mundur. Jika Anda melihat sesuatu yang Anda anggap salah, dan Anda mendapatkan jawaban yang bergelombang dari orang yang ditinjau, jangan mundur (setidaknya bukan karena kurangnya pengetahuan). Ingat, apa yang membuat kode yang baik dalam satu bahasa jarang berbeda dari apa yang membuat kode yang baik dalam bahasa lain. Ya, bahasa tertentu memiliki idiom berbeda untuk membantu Anda menulis kode yang baik. Tetapi penting untuk menyadari bahwa idiom-idiom itu adalah alat dan bukan tujuan.

Selanjutnya, cobalah untuk tidak melakukan "ulasan preferensi". Ini adalah sesuatu yang saya (dan banyak orang lain) harus lakukan dengan sangat sadar. Dengan kata lain, cobalah untuk menghindari melakukan ulasan yang ada di sepanjang baris "Anda melakukan x , tapi saya lebih suka y ". Sekarang, tidak ada yang salah dengan menyatakan preferensi, tetapi Anda harus memberi label dengan jelas seperti itu dan membuat catatan bahwa pihak lain bebas untuk tidak setuju. Ini penting, karena sebagian besar hal yang berbeda dari bahasa ke bahasa termasuk dalam kategori ini.

Terakhir, apakah kalian menggunakan sistem kontrol versi terdistribusi? Satu hal yang mungkin membantu adalah jika daripada hanya mencatat apa yang salah dengan kode tersebut, Anda dapat menulis ulang kode tersebut bagaimana Anda akan menulisnya, mengujinya, dan kemudian mengirimkan tambalan untuk itu. Ini membantu menunjukkan bahwa Anda benar-benar tertarik untuk meningkatkan kode mereka dan tidak hanya menjadi "peninjau kode kursi" dan memberi Anda kesempatan untuk mempelajari bahasa lebih baik. Plus, biasanya lebih mudah untuk tidak setuju dengan "Saya pikir Anda harus melakukan ini" daripada "Ini adalah bagaimana saya akan melakukannya, dan inilah tambalan jika Anda setuju". Saya kira Anda tidak perlu DVCS untuk ini, tetapi tentu saja membantu.

Anda kehilangan fokus pada masalah dan menghasilkan solusi yang buruk. Anda telah diberi tugas untuk meningkatkan pengembangan dan solusi Anda adalah membuat seseorang bertanggung jawab atas peninjauan kode (diri Anda) yang tidak mengerti bahasa. Siapa yang meninjau kode Anda? Mengapa mereka tidak dapat saling meninjau sampai Anda mempelajari bahasa?

Harus ada beberapa bidang masalah lain yang bisa dipilih untuk memiliki peningkatan yang lebih cepat. Dengan cara ini mereka hanya meniupkan asap pada Anda dan tidak ada yang membaik.

Mengarahkan pengembangan baru ke bahasa yang tidak ada di antara Anda yang mengerti (C #) akan membutuhkan waktu lama untuk membayar terutama jika Anda semua membawa kebiasaan buruk mereka bersama mereka.

Fokus pada desain (Itu sudah disebutkan.). Jika mereka mengalami kesulitan mempertahankan kode saat ini, lihatlah beberapa alat refactoring untuk VB. Banyak praktik dasar yang sama.

Anda dapat 'membuktikan bacaan' hal-hal yang tidak benar-benar Anda ketahui, tetapi Anda tidak dapat memeriksanya secara memadai . Saya sangat kompeten dalam C, tahu C ++ dengan cukup baik, tapi saya tidak akan bermimpi meninjau sesuatu dalam C #.

Saya tidak berpikir Anda perlu bertindak sejauh membawa seorang konsultan, karena beberapa perusahaan mengkhususkan diri dalam menjalankan kode Anda melalui banyak tes dan memberi tahu Anda apa yang mungkin salah dengan kode itu.

Namun, tergantung pada pengembang individu yang tahu bahasa untuk menginterpretasikan hasilnya. Sebagai contoh, jika seorang pengkaji kode mengecam saya karena tidak menggunakan nilai pengembalian printf(), saya akan melihat mereka dengan aneh dan mempertanyakan ketenangan hati mereka, lalu bertanya "Oke, bagus, apa yang bisa saya lakukan ketika tidak ada yang dapat dicetak ke konsol yang akan berguna?"

Yang mungkin ingin Anda pertimbangkan adalah berbicara dengan bos Anda tentang pengaturan departemen dan pimpinan tim, sehingga Anda bisa efektif dalam domain Anda, sementara orang lain efektif dalam domain mereka.

Namun, saya pikir Anda mungkin dapat menggunakan pihak ketiga untuk mengaudit. Kebanyakan programmer menghargai garam mereka akan memperhatikan keprihatinan yang sah , bahkan jika mereka menganggap setengah sebagai palsu (seperti saya akan dalam printf()contoh saya ).

Memberikan panduan tentang sesuatu yang tidak Anda mengerti sama dengan orang buta yang menuntun orang buta seperti yang Anda sadari.

Salah satu pendekatan adalah dengan menggunakan alat serat seperti FxCop dan StyleCop yang akan membahas bagian depan analisis statis dari basis kode. Ini akan memberi Anda titik awal untuk memperdebatkan laporan yang dihasilkan dari alat.

Pendekatan lain adalah mengubah ulasan kode menjadi ulasan desain. Review desain lebih sering daripada tidak mengungkap masalah jauh sebelum kode bahkan ditulis. Jika seorang programmer memiliki desain mereka dapat bekerja dari mereka secara umum jauh lebih efisien dalam pendekatan mereka dan bug berkurang karena ini. Ketika sebuah desain tidak ada, itu menjadi adhoc dalam pendekatan dan kode menderita dengan meningkatnya jumlah bug. Tangkap masalah dalam ulasan desain sebelum muncul di ulasan kode dengan memastikan Anda masing-masing memiliki desain konkret untuk diimplementasikan; UML adalah teman Anda di sini dan alat-alat seperti umlet cepat dan cepat digunakan.

Berita buruknya adalah agar dapat berpartisipasi secara efektif dalam ulasan kode, Anda harus belajar VB. Ini juga akan membantu untuk menggunakan VB dalam semacam proyek (tidak harus untuk produksi).

Kabar baiknya adalah bahwa setelah Anda melakukan ini, sebagian dari apa yang telah Anda pelajari masih akan berguna ketika Anda beralih ke C #.

Pikiran yang harus Anda pertahankan setiap saat ketika melakukan peer review adalah:

"AKU ADALAH SATU YANG BERIKUTNYA UNTUK MENJAGA KODE INI!"

Anda harus memahaminya dengan cukup baik untuk dapat melakukannya sebagai bagian dari persiapan Anda untuk meninjau, dan tugas Anda adalah membuat programmer asli mengetahui adanya kekurangan yang membuatnya lebih rumit daripada yang diperlukan untuk memahami kode dengan cukup baik untuk mempertahankannya. .

Jika Anda tidak dapat memprogram dalam VB, Anda tidak dapat mempertahankan kode, dan Anda tidak memenuhi syarat untuk menjadi peer reviewer.

Anda seharusnya tidak meninjau kode yang tidak Anda mengerti, yang hanya akan mengganggu pengembang yang harus menjelaskan setiap hal aneh yang telah mereka lakukan.

Apa yang dapat Anda lakukan, pilih / tentukan pedoman pengkodean dan periksa kode terhadap pedoman ini. Ketika ada sesuatu yang tidak sesuai dengan pedoman Anda dapat meminta penjelasan pengembang.

Saya akan mulai dengan memilih pedoman yang ada (saya tidak tahu standar pengkodean VB.net tetapi google memberi saya:

• VB .Net pedoman pengkodean
• Tunduk
• Semua dalam satu kerangka kerja kode

Gunakan alat seperti stylecop untuk VB .net

Menganalisis sumber dengan NDepend (memiliki aturan tentang kompleksitas siklomatik, panjang, kedalaman dll)

Ketika Anda telah melakukannya Anda dapat mengatakan bahwa kode tersebut sesuai dengan standar yang dipilih, itu tidak mengatakan apa-apa tentang fungsi yang benar atau kode menggunakan prinsip-prinsip OOP yang tepat. Tapi setidaknya itu adalah sesuatu.

Tinjauan kode yang baik adalah tentang hal-hal yang mengharuskan Anda untuk memahami bahasa - penggunaan bahasa yang tepat, API dan perpustakaan, gaya, nama variabel dll. - dan tentang seberapa baik kode memecahkan masalah - komentar yang baik, arsitektur yang tepat, desain yang relevan pola, pertimbangkan semua kasus kesalahan, dll. Ketika Anda pertama kali mulai melakukan tinjauan kode, Anda cenderung berkonsentrasi pada yang pertama. Mereka lebih mudah dilihat dan lebih mudah dipilih. (mis. Saya tidak suka nama variabel Anda. Anda harus menggunakan nama gaya XXXX.)

Tinjauan kode menjadi lebih bernilai ketika ada lebih banyak fokus pada seberapa baik kode memecahkan masalah. Karena Anda tidak dapat memberikan nilai sebanyak di bidang pertama sekarang, berkonsentrasilah pada mengajukan pertanyaan dan menawarkan saran tentang solusi untuk masalah tersebut, bukan pada bagaimana hal itu dibuat.

Tentu saja ada tumpang tindih antara keduanya. Mengetahui VB.NET akan memungkinkan Anda memberikan saran mengapa pola desain tertentu bukan pilihan yang baik dalam situasi tertentu misalnya.

Yang terpenting, rendah hati pada tahap ini. Mengubah proses itu sulit. Bahkan jika Anda seorang guru VB.NET perubahan kemungkinan tidak akan mudah. Orang-orang yang belum pernah menggunakan tinjauan kode tidak suka pada awalnya. Membuat orang lain melihat kode Anda adalah pengalaman yang sulit. Butuh waktu untuk melihat nilainya, dan kesabaran di sekitar. Ini adalah proses yang hebat ketika Anda menerima, tetapi itu akan memakan waktu.

Bisakah Anda mengalihkan fokus lebih pada tes daripada melihat kode secara langsung? Saya tidak mengatakan meninggalkan ulasan kode, tetapi pada awalnya mungkin lebih masuk akal untuk mendapatkan aplikasi internal untuk memiliki tes yang cukup yang dapat membantu memecahkan kode beberapa dari apa yang terjadi. Gagasan di sini adalah bahwa tes juga dapat membantu Anda sedikit lebih terbiasa dengan beberapa fungsi. Saya hanya melihat ini sebagai rute yang berbeda untuk ditempuh. Gagasannya di sini adalah bahwa ulasan akan kembali lagi nanti dan dapat dilakukan dalam beberapa bagian karena mungkin ada gunanya memiliki tinjauan umum / sesi di muka dan kemudian sedikit istirahat. Waktu istirahat itu sampai satu atau dua hari ke depan sehingga ada cukup waktu bagi siapa pun yang mungkin ingin tidur malam memikirkan kode atau sesuatu yang serupa sebelum kembali dengan pertanyaan dan berdiskusi.

Tentu saja jika Anda sudah memiliki tes ini sayangnya tidak berarti. Pemikiran lain adalah untuk memberikan contoh di mana mereka mengklaim bahwa dalam VB.Net ini dilakukan dengan cara tertentu, karena itu dapat membantu membuat pertanyaan ini lebih jelas dengan cara yang saya bisa bayangkan ini bervariasi dari sedikit standar kode ke bagian dari jantung bagaimana VB.Net dibangun dalam arti tertentu.

Bahkan jika Anda mempelajari dasar-dasar VB, melakukan tinjauan kode sambil tidak mengetahui semua fitur bahasa tidak akan memungkinkan Anda mendeteksi penggunaan fitur tidak aman dalam bahasa.

Misalkan Anda tidak menyadari bahwa fungsi input () dalam Python 2 sebenarnya mengevaluasi input sebelum mengembalikannya, untuk membuatnya lebih mudah untuk mem-parsing tipe input non-string. Kemudian kode akan rentan terhadap Eksekusi Kode Sewenang-wenang, yang memungkinkan pengguna untuk memasukkan sesuatu seperti __import__('os').execl('/bin/sh', '/bin/sh')pada sistem Linux untuk mengubah proses Python menjadi shell. Sebagai gantinya, raw_input () harus digunakan untuk mendapatkan data input yang tidak diproses.

Mencoba melakukan tinjauan kode sementara tidak mengetahui semua fitur bahasa tidak hanya dapat mencegah Anda dari menyadari cara yang lebih baik untuk melakukan prosedur tertentu dalam bahasa; itu juga dapat menyebabkan kelemahan keamanan yang merugikan.