Apakah ulasan kode diperlukan untuk pengembang junior?


39

Saya telah bekerja di dua perusahaan, yang masing-masing memiliki metodologi berbeda dalam hal tinjauan kode:

Di perusahaan pertama, tinjauan kode dilakukan oleh para pemimpin tim dan diminta setelah selesainya setiap modul.

Namun, di perusahaan kedua, pemimpin tim tidak diharuskan melakukan tinjauan kode apa pun, dan hanya memeriksa fungsionalitas dan masalah desain.

Jadi saya bingung. Apakah proses peninjauan kode sangat dibutuhkan? Jika ya, mengapa? Dan jika tidak, mengapa tidak?


28
Jika pengembang senior memberi tahu pengembang junior untuk melakukan sesuatu dengan cara tertentu, sering kali ada alasan yang sangat bagus ....

2
@Tilsan The Fighter: Ada baiknya Anda mengajukan pertanyaan - ingin tahu adalah, atau seharusnya, prestasi seorang programmer - tapi tolong buat itu dimengerti dan mudah dibaca.
gablin

9
@ Torbjorn - Itu hanya benar jika pengembang senior senior karena keterampilan dan bukan karena durasi. Saya telah melihat banyak kode dan desain yang buruk oleh insinyur senior
KallDrexx

8
Mungkin ada alasan bagus, dan itu bagus untuk mengetahui alasan itu, tetapi Anda tidak boleh mempercayai saran mereka secara membabi buta hanya karena gelar dan pengalaman X tahun mereka. Saya telah bertanya kepada insinyur senior di sini mengapa dia membuat banyak kode buruk dan yang saya dapatkan hanyalah mengangkat bahu dengan "Saya tidak tahu". Ada cukup banyak insinyur yang buruk di luar sana untuk membuat saya sadar untuk tidak menaruh kepercayaan hanya pada sebuah gelar.
KallDrexx

4
+1 KallDrexx - itulah yang saya temukan juga. Saya sering memiliki pengembang "senior" yang tidak tahu mengapa Anda tidak boleh hanya memasukkan semuanya ke kelas statis, atau tahu apa-apa tentang pengujian, atau tahu pola desain yang tepat .. "Senior" biasanya mengacu pada masa kerja dan bukan keterampilan dari apa yang bisa saya katakan.
Wayne Molina

Jawaban:


107

Saya pribadi berpikir bahwa setiap bagian dari kode harus melalui tinjauan kode, tidak masalah jika Anda adalah pengembang junior atau senior.

Mengapa? Sebagai permulaan, judul Anda tidak menyebutkan apa pun tentang bagaimana Anda berkembang, dan pengembang senior dapat belajar sesuatu dari junior. Di perusahaan kami, kami bergiliran sehingga salah satu anggota tim lainnya meninjau kode Anda ... sebagian besar kami bekerja sama sebagai "junior" dan senior bersama, sehingga semua hal yang tidak bisa diucapkan setiap hari dapat tertangkap dalam tindak lanjut. Jika senior tidak menyukai kode junior, dia harus mendengarkan mengapa junior melakukan seperti yang dia lakukan dan melihatnya dan melihat apakah itu solusi yang layak yang mungkin digunakan di masa depan ... itu masalah mendapatkan lebih bijaksana tidak peduli siapa kamu.

Satu hal penting tentang tinjauan kode tidak terlalu baik, jika Anda menjadi orang baik Anda hanya akan membiarkan kode berantakan semakin berkembang dalam sistem. Sama seperti kemarin saya mulai mengerjakan ulang aplikasi lengkap yang ditulis oleh seorang mantan juniordeveloper, dan tuhan saya kode itu mungkin perlu ditinjau sebelum dia pergi.

Saya tidak mengerti mengapa seharusnya pemimpin tim hanya melakukan tinjauan tetapi membutuhkan seseorang yang tidak takut memilih "bertengkar" atas sepotong kode yang kurang berkembang, dan haruslah orang yang peduli tentang bagaimana kode seharusnya menjadi. Tidak semua perusahaan mempekerjakan orang yang benar-benar peduli dengan apa yang mereka lakukan, dan telur-telur buruk itu seharusnya IMO tidak diizinkan melakukan review kode karena mereka cenderung hanya mengangkat bahu dan mengatakan "OK" untuk kode yang buruk.


8
Actaully, ada gunanya tidak hanya memiliki pemimpin tim melakukan tinjauan kode. Bahkan pengembang yang kurang berpengalaman harus dapat mengikuti kode. :)
Guffa

63
Pimpinan tim harus meninjau kode mereka juga, karena sering pengembang junior dapat mempelajari teknik yang berharga atau setidaknya melihat bagaimana kode "baik" seharusnya terlihat. Dan hanya karena Anda seorang pemimpin tim bukan berarti Anda tidak dapat membuat kesalahan.
TMN

4
@ TMN, saya sangat setuju. Pimpinan tim tidak selalu dipilih karena keahlian atau pengalaman mereka; kadang mereka semua yang tersisa setelah eksodus massal (yang telah terjadi beberapa kali di tempat saya bekerja), atau PHK besar. Kode setiap orang harus menjalani peninjauan, terlepas dari pengalaman, status, atau jabatan.
bedwyr

2
@ TMN Terlalu benar. Judul "pengembang senior" tidak berarti "tidak mampu membuat kesalahan" atau "tidak mampu meningkatkan". Jika ya, itu bukan jenis pengembang senior yang saya inginkan di tim saya.
Brandon DuRette

2
Saya sangat berpengalaman dan baik dalam apa yang saya lakukan. Saya membuat kesalahan, banyak di antaranya telah ditangkap oleh tinjauan kode.
David Thornley

37

Pada dasarnya review kode diperlukan untuk semua programmer terlepas dari pengalaman. Ini adalah Kontrol Kualitas pengembangan perangkat lunak, dan salah satu alasan Open Source bisa sangat berkualitas tinggi.

EDIT: Alasannya adalah bahwa peninjau kode hari ini persis sama perannya sebagai pengelola nanti. Jika kode itu tidak masuk akal baginya hari ini, nanti tidak masuk akal juga, membuat bug lebih mahal untuk diperbaiki. Oleh karena itu, MAKA dimengerti hari ini sementara pengembang masih mengingat kode. Juga pengulas mungkin melihat bug atau kelalaian yang tidak terjawab oleh pengembang.

Sayangnya sangat sedikit yang ingin melakukannya, tetapi dilihat dari sudut pandang bisnis, itu wajib.


@ Mr.Thorbjorn Ravn Andersen: Bisakah Anda jelaskan apa saja kelebihan dan kekurangan dari Proses Peninjauan Kode?
Sankar Ganesh

2
Anda mungkin tertarik dengan proposal tinjauan kode ini . Alangkah baiknya jika kita bisa mendapatkan bola pada ini.
greatwolf

@ Viktor, pendekatan yang menarik dan semoga sukses.

@Sankar Ganesh: ada buku gratis tentang ulasan kode yang membahas kelebihan dan kekurangan: smartbear.com/best-kept-secrets-of-peer-code-review
Joeri Sebrechts

17

Saya bekerja di tempat di mana tinjauan kode sekarang menjadi persyaratan tetapi tidak sesedikit 3 tahun yang lalu. Itu telah membuat peningkatan besar dalam kode kami dan kemampuan orang lain untuk mempertahankan kode nanti. Bahkan pengembang senior, yang sangat berpengalaman membuat kesalahan yang dapat dengan mudah dan diam-diam diperbaiki dalam tinjauan kode sebelum QA menemukannya atau lebih buruk sebelum pelanggan menemukannya. Lebih jauh, setidaknya satu orang selain pengembang asli familiar dengan kode.

Seringkali ketika suatu organisasi mencoba sesuatu yang baru untuk itu, seperti yang kami lakukan dengan tinjauan kode, ada banyak penolakan untuk berubah. Saya telah melihat hampir tidak ada (kami estatic untuk mendapatkan departemen QA formal juga.) Dengan ulasan kode. Cukup banyak hanya perlu satu atau dua ulasan untuk melihat nilainya.

Saya telah menemukan teknik baru yang tidak saya pertimbangkan baik dalam melakukan tinjauan kode terhadap pekerjaan orang lain atau dalam meminta kode saya ditinjau. Kami telah menemukan masalah kompetensi dengan karyawan baru yang relatif cepat dengan melakukan tinjauan kode dan yang lebih penting adalah bagaimana mereka merespons ulasan kode tersebut. Kami telah mempelajari hal-hal apa yang tampaknya sangat jelas sekarang di tengah pemrograman bagian yang tidak akan jelas dalam pemeliharaan. Ini sangat berharga. Mungkin satu-satunya yang dibutuhkan adalah komentar mengapa sesuatu dilakukan. Kami telah menemukan beberapa kesalahpahaman mendasar tentang desain database kami yang perlu diperbaiki agar laporan benar-benar memiliki informasi yang benar.

Seringkali yang saya lihat dalam tinjauan kode adalah, dengan menjelaskan sesuatu kepada orang lain, pengembang akan menyalakan bola lampu di kepalanya dan menyadari bahwa ada bug yang tidak dilihat oleh pengulas.

Dan anak laki-laki dapat meninjau kode mengidentifikasi pemrogram koboi yang tidak akan mengikuti standar atau menggunakan alat yang diamanatkan dan yang kodenya hampir tidak dapat dipelihara oleh siapa pun. Dan itu bisa memaksa mereka untuk keluar dengan program atau keluar juga.

Orang-orang yang paling resisten terhadap tinjauan kode sering kali adalah orang-orang yang paling perlu disingkirkan oleh organisasi karena mereka tahu di dalam hati bahwa kode mereka tidak dapat lulus tinjauan kode.


3
"Kami telah menemukan masalah kompetensi dengan karyawan baru yang relatif cepat dengan melakukan tinjauan kode dan yang lebih penting adalah bagaimana mereka menanggapi ulasan kode" - Ini adalah manfaat yang sangat penting (dan saya setuju, bagaimana mereka merespons memberi tahu lebih dari kesalahan yang mereka buat) .
Stephen C. Steel

1
+1 untuk menangkap alasannya

11

Cowok yang gesit akan berkata: "Anda tidak perlu review kode, cukup lakukan pemrograman berpasangan dan tulis tes yang bagus" :)


9
Dan sering-seringlah berganti pasangan dan mengenali bahwa tim, bukan individu mana pun, memiliki kode.
Don Roby

18
Pria lincah salah. Kode harus ditinjau oleh pikiran yang independen terhadap pikiran yang membuatnya. (Sangat mudah bagi sepasang programmer untuk berbicara satu sama lain di jalan buntu tanpa menyadarinya!)
Peter Boughton

6
Pemrograman pasangan adalah tinjauan kode kontinu.

3
@ Peter: Pria lincah juga memasangkan kembali secara acak, dan mempraktikkan kepemilikan kode bersama, jadi selama rentang waktu (hari ke minggu), sebagian besar anggota tim telah meninjau kode yang ditulis oleh pasangan asli. Cowok lincah punya jawaban untuk semuanya. Beberapa orang berpikir pria Agile benar- benar sok pintar.
Tom Anderson

2
Pemrograman pasangan memperbaiki masalah utama dengan ulasan kode - mereka terjadi sangat terlambat. Saya benci akan meninjau kode untuk melihat bahwa pengembang telah menghabiskan waktu seminggu untuk mengembangkan kembali algoritma perpustakaan atau struktur data.
kevin cline

8

Peninjauan kode adalah cara yang baik untuk menyebarkan pengetahuan dan praktik yang baik melalui tim. Dalam pengalaman saya itu adalah ide yang baik untuk memastikan semua kode ditinjau, dan mencoba memvariasikan siapa yang mengulas kode apa.

Dalam tim saya saat ini, kode setiap orang ditinjau secara setara, dan baik programmer maupun peninjau harus puas dengan kode sebelum dapat dirilis. Ini berlaku sama halnya dengan pengembang senior yang ditinjau oleh lebih banyak pengembang junior, pengembang junior yang meninjau yang lain, atau pengembang senior lainnya yang saling meninjau. Jika peninjau tidak berpengalaman atau merasa tidak nyaman meninjau setiap bagian kode tertentu maka mereka akan bekerja sama dengan pengembang lain (dan mungkin juga pengembang asli) untuk melakukan peninjauan sebagai grup.


2
Yap, review kode adalah kontrol kualitas sebanyak halnya berbagi pengetahuan. Semua orang dapat belajar dari tinjauan kode yang baik. Yang menghidupkan kembali dan yang ditinjau.
Guillaume

1
Perusahaan saya mirip dengan flamingpenguin. Setiap check-in ditinjau oleh pengembang lain. Peringkat tidak ada hubungannya dengan ulasan siapa. Ini adalah proses peer-to-peer. Syaratnya adalah semua kode ditinjau. Ulasan kode gaya orangtua-anak hanya berfungsi untuk mengusir pengembang 'A', meninggalkan pemimpin tim 'B' yang meninjau junior 'C'. Yang terbaik yang bisa diharapkan oleh tim gaya orangtua-anak adalah kode biasa-biasa saja. Jika mereka beruntung.
Jim In Texas

5

Saya sudah berkecimpung dalam bisnis ini selama lebih dari 20 tahun, bekerja untuk perusahaan perangkat lunak dan untuk bisnis yang berbeda dan tidak ada tempat ini yang memiliki proses peninjauan kode. Namun, saya dapat memahami dan menghargai manfaat memilikinya. Pada dasarnya, seperti yang saya pahami, mereka harus digunakan untuk memastikan kepatuhan terhadap standar, yang harus diikuti agar orang lain dapat lebih mudah menjaga kode di masa depan. Keterbacaan kode juga dapat diperiksa dalam proses peninjauan karena ini juga akan memastikan bahwa pemeliharaan dapat bekerja secara efektif dengan kode.

Saat ini, saya bekerja di sebuah toko kecil di mana saya adalah pengembang tunggal. Kadang-kadang kami telah membawa kontraktor untuk membantu dengan jaminan. Setidaknya satu atau dua kontraktor itu memiliki kode tertulis yang tidak serta-merta memenuhi standar saya atau perusahaan, tetapi itu bekerja dengan baik dan setidaknya agak dapat dimengerti. Ketika saya menunjukkan masalah ini kepada manajemen, mereka tidak peduli, mereka hanya ingin tahu apakah itu melakukan apa yang kami bayar untuk mereka lakukan. Jadi, saya kira itu hanya tergantung pada perusahaan, dan apakah bersih atau tidak, mudah mempertahankan kode adalah produk yang diinginkan, atau apakah mereka hanya menginginkan sesuatu yang berfungsi baik untuk uang.

Jelas sebagai pengembang, dan orang yang harus menjaga kode, saya ingin bekerja dengan kode bersih yang mengikuti standar semacam itu, tapi saya tidak selalu memiliki kemewahan itu, jadi saya membuat yang terbaik dan menangani apa yang saya miliki , walaupun itu berarti terkadang harus menulis ulang beberapa kode dengan standar saya sendiri.


4

Ulasan kode dapat mengidentifikasi cacat sebelumnya dalam siklus hidup perangkat lunak ketika masalah lebih mudah (dan lebih murah) untuk diperbaiki. Di SmartBear, kami telah mengembangkan alat peninjauan kode rekan dan juga telah melakukan banyak penelitian tentang cara membuat ulasan kode menjadi efektif. Berdasarkan data dari pelanggan kami, cacat yang ditemukan dalam tinjauan kode adalah 8-12X lebih murah untuk ditemukan dan diperbaiki daripada cacat yang ditemukan di QA. Penghematan biaya saja membuat tinjauan kode layak, tetapi ada nilai lebih dari itu. Tinjauan kode adalah cara terbaik bagi semua orang di tim untuk belajar dan meningkat sebagai pengembang perangkat lunak.

Ada beberapa jebakan yang dapat menyebabkan tinjauan kode menjadi kurang efektif, dan sepertinya organisasi Anda terperangkap di salah satunya. Buat ulasan kode tentang kode, bukan orang-orang. Judul tidak ada artinya dalam ulasan kode. Seruan kepada otoritas (Anda harus melakukannya dengan cara saya karena saya adalah pemimpin tim) melakukan lebih banyak kerusakan daripada kebaikan. Ajari saja. Insinyur senior harus menjelaskan mengapa itu harus dilakukan dengan cara mereka, bukan hanya menuntut itu. Jika Anda kesulitan menjelaskan konsep, itu juga pengalaman belajar bagi Anda. Anda berdua akan menjadi pengembang yang lebih baik untuk upaya yang Anda lakukan.


apakah Anda memiliki artikel resmi yang membahas 8-12 kali lebih murah? Kami sedang membahas ini secara internal.

@ Thorbjørn - Kami melakukannya: goo.gl/7dMf . Ini berasal dari buku kami tentang tinjauan kode, yang dapat Anda (dan orang lain) miliki gratis: codereviewbook.com
Brandon DuRette

2

Saya pikir kode meninjau SEMUA KODE terlalu banyak. Jumlah waktu yang dibutuhkan untuk meninjau semua kode bisa lebih baik dihabiskan di tempat lain. Alterntivley Saya pikir kode kritis dan atau bagian yang kompleks perlu ditinjau kode tapi tentu saja tidak setiap baris kode.


7
Saya tidak bisa tidak setuju lagi. Setiap baris kode harus melalui setidaknya 2x review ... pengembang asli harus meninjau sepenuhnya setiap perubahan baris sebelum melakukan mereka, dan setidaknya satu pengembang lain harus melakukan peer-review sebagai tindak lanjut. Sangat jarang kode berhasil melalui ulasan tanpa setidaknya 1 pertanyaan bagus diajukan; tinjauan sejawat juga meningkatkan kesadaran antara anggota tim tentang apa - dan bagaimana - orang lain menyelesaikan tugas mereka.
STW

3
@ Grzy - Saya benar-benar bersumpah; biasanya ia menambahkan ~% 10 ke siklus dev; investasi kecil untuk berapa banyak yang kita tangkap sejak dini.
STW

4
@ Grzy - hanya karena kita tidak sempurna. Tim kami telah tumbuh secara signifikan, dan kami memiliki beberapa omset (kebanyakan kontraktor). Di masa lalu ketika kita mundur pada ulasan kebijakan masalah merayap kembali segera. Proses peninjauan hanyalah langkah penting dalam mempertahankan tim yang efektif dan menghasilkan produk yang berkualitas. Meninjau semua kode tidak sulit; terutama jika Anda memiliki beberapa devs senior yang sangat pandai menemukan kode yang tidak dibutuhkan. Sebagian besar kode duplikat berasal dari pengembang yang melakukannya dengan baik, tetapi tidak menyadari adanya pendekatan yang ada.
STW

5
Saya menggunakan STW dalam hal ini - memperbaiki masalah yang tertangkap selama tinjauan jauh lebih murah daripada mencoba men-debug / memelihara kode nanti karena tidak dianggap kritis. Juga, ulasan kode hanya membutuhkan waktu jika kodenya buruk - kode yang baik cepat dan mudah dibaca!
Peter Boughton

7
Tentu saja tidak seharusnya, tetapi itu tidak berarti tidak! (Berapa banyak tim yang memiliki pengembang sempurna?) Baris kode apa yang tidak Anda tinjau? Bagaimana Anda membuat keputusan apakah perubahan tertentu dalam file tertentu harus ditinjau atau tidak?
Peter Boughton

2

Menurut pendapat saya, kode yang akan digunakan oleh perusahaan, apakah itu ditulis oleh pengembang Junior atau Senior, harus selalu ditinjau. Mengapa? Karena bagaimana jika kodenya memiliki beberapa bug? Dan bagaimana jika, selama kode ini digunakan, program macet? Untuk menghentikan hal-hal ini terjadi, semua kode harus ditinjau sebelum digunakan.

Tetapi bagaimana dengan perusahaan-perusahaan yang tidak meninjau kode? Mereka mungkin perusahaan yang memiliki banyak masalah teknologi dan banyak, seperti yang mereka katakan kepada konsumen, "crash" ;-).

Jadi izinkan saya menjawab semua pertanyaan Anda:

  • Ya, proses Review diperlukan.
  • Mengapa? Karena alasan yang saya nyatakan di atas.

2

Peninjauan Kode : Proses Peninjauan Kode harus menjadi hal yang vital untuk semua, saya akan menjelaskan siapa yang mendapatkan manfaat karena konduksi tinjauan kode serta manfaat apa yang mereka peroleh.

1. Manfaat yang Diperoleh Oleh Perusahaan Karena Konduksi Tinjauan Kode: Jika tinjauan kode sering dilakukan, maka perusahaan dapat memperoleh produk akhir dengan cara yang lebih optimal yang membantu mereka untuk mendapatkan nama merek di pasar mereka dan juga membantu perusahaan untuk dapatkan atau tingkatkan CMMI mereka saat ini .

2. Manfaat bagi Ketua Tim Karena Konduksi Tinjauan Kode: Seperti kita ketahui seorang guru dapat dengan mudah mengidentifikasi kesalahan, karena mereka lebih sering meninjau jawaban siswa mereka, sehingga mereka dapat memperoleh ide, di bidang mana mungkin ada mungkin untuk hal-hal yang salah. sama halnya dengan pemimpin tim juga tahu apa saja yang salah di bidang ini. Bagaimana kita dapat memperbaiki itu. Dan juga Membantu Ketua tim untuk mengambil ide berita dari pengembang junior juga.

3. Manfaat untuk Pengembang Junior Karena Konduksi Tinjauan Kode: Pengembang Junior dapat dengan mudah mengambil gagasan tentang Proses tinjauan Kode, juga mereka bisa mendapatkan apa standar pengkodean, Misalnya: untuk membuat API dengan cara yang tepat, mereka akan belajar standardisasi pengkodean yang dapat membantu mereka di masa depan khususnya ketika mereka berada di pos tingkat yang lebih tinggi.

Jadi Kesimpulan Saya adalah Ulasan kode adalah Proses yang Sangat Sangat Vital untuk semua [bahkan untuk Anggota tim juga], karena Pemeriksaan Kode membantu kita untuk memperbaiki kesalahan ceroboh kita dalam kode kita, karena kita semua adalah manusia, jadi kita tidak dapat memperkirakan bahwa kita tidak pernah melakukan kesalahan ceroboh dalam kode.


1

Apa bedanya dengan mengganggu ide-ide Anda sebelum memeriksa kode Anda (ulasan) atau setelahnya karena bug, menjadi terlalu pintar / sulit dipahami, atau tidak mengikuti praktik standar yang diterima? Apakah itu egomu?

Anda tidak dapat mengabaikan manfaat tinjauan kode atau apa pun hanya karena penerapannya buruk oleh anggota tim yang kurang berkualitas yang tidak Anda hormati. Peninjauan Kode bukanlah suatu proses yang sangat kompleks yang hanya dapat dilakukan oleh beberapa programmer super. Saya tidak yakin ada banyak programmer atau penulis profesional yang mampu atau punya waktu untuk mengedit sendiri.

Pernahkah Anda kembali ke barisan kode beberapa bulan kemudian dan bertanya-tanya apa yang saya pikirkan? Akan ada peluang yang lebih baik untuk menangkapnya dengan ulasan kode. Anda baru saja menangkapnya dan Anda hanya sedikit lebih baik daripada programmer yang Anda temui sebelumnya - saya harap.


1

IMO review kode harus penting untuk semua pengembang, tetapi hanya ketika orang-orang yang melakukan review kompeten sendiri. Di masa lalu saya telah menolak kode dalam ulasan karena, saya SOLIDkira Anda tidak, saya mengikuti , melakukan Injeksi Ketergantungan dan mengatur kode ke dalam ruang nama dan folder sesuai dengan desain logis, dan termasuk serangkaian kecil unit test untuk verifikasi kodenya. Kode ditolak sebagai "terlalu rumit" dan saya diberitahu untuk menggunakan satu kelas yang menghancurkan semuanya bersama-sama dan menghapus tes karena bukan bagaimana perusahaan menulis kode.

Peninjauan kode seperti itu tidak ada artinya, tetapi peninjauan kode dengan tim yang kompeten seringkali dapat menerangi sesuatu tentang desain (mis. Mengapa Anda harus melakukan X dan Y tetapi tidak Z) atau menunjukkan cacat yang sebenarnya (mis. Melakukan X akan menyebabkan Y gagal) untuk alasan yang salah).


1

Tentu saja Peninjauan Kode tidak diperlukan . Kemudian lagi, tidak ada tes, integrasi berkesinambungan, kontrol sumber, keterlibatan pelanggan, profiling, analisis statis, perangkat keras yang layak, build satu-klik, pelacakan bug, daftarnya terus berlanjut.

Bersama dengan Ulasan Kode, hal-hal yang saya sebutkan di atas adalah alat yang membantu memastikan kualitas perangkat lunak. Dengan kombinasi keterampilan, keberuntungan, waktu dan tekad; Anda dapat memberikan perangkat lunak berkualitas tanpa hal-hal ini, tetapi kemungkinan besar Anda tidak akan melakukannya .

Dalam skenario Anda, tidak ada yang perlu dikacaukan. Tidak semua organisasi menikmati praktik terbaik. Mereka mungkin tidak setuju dengan itu, mungkin bertentangan dengan praktik terbaik yang berbeda yang mereka laksanakan, atau mereka mungkin menganggap bahwa overhead penerapannya terlalu besar bagi mereka pada saat ini. Tergantung pada keadaan mereka, mereka mungkin benar dalam melakukannya, atau mereka mungkin membuat ekonomi palsu. Untuk beberapa alat, (misalnya kontrol sumber) rasio pengembalian / upaya sangat baik sehingga menggunakannya adalah no-brainer; untuk yang lain kurang jelas.

Tidak ada keraguan bahwa tinjauan kode adalah praktik yang memperkenalkan overhead yang signifikan. Karena itu, organisasi akan berusaha untuk meminimalkan overhead itu, baik dengan tidak melakukannya sama sekali, atau dengan hanya melakukannya dalam situasi tertentu (misalnya untuk anggota tim junior, atau perubahan yang sangat berbulu). Tidak selalu jelas bahwa ia membayar lebih banyak (dalam menangkap bug, mengurangi utang teknis atau berbagi pengetahuan) daripada biayanya. Sebagian besar pengembalian itu sulit untuk diukur, sedangkan sangat mudah untuk menghitung jumlah jam kerja yang dihabiskan organisasi Anda untuk melakukan tinjauan. Bit termudah untuk dikuantifikasi (pengurangan jumlah bug) mudah untuk dikaitkan dengan faktor-faktor lain (misalnya "tentu saja memiliki lebih sedikit bug, lebih matang").


-1

Kami membuat game sepakbola online di Turki. Banyak pengguna dan master game membantu kami dalam hal fungsionalitas. Mereka juga memberikan komentar tentang fitur yang dibutuhkan. Jadi saya pikir, jika Anda memiliki banyak pengguna, tes fungsionalitas dapat dilakukan untuk membantu atau mendapatkan lencana. Kolaborasi pengembang, master game, dan pengguna dengan forum, tim pendukung, dan lingkungan pengujian pribadi membuat proyek sosial.

Tentu ulasan kode dan berbagi pengalaman antara tim pengembangan diperlukan, tetapi jika tidak penting Anda tidak perlu memaksakan diri.


-1

Saya berpikir bahwa bagaimana inspeksi pihak ke-2 secara verbal tergantung pada siklus hidup Anda, apakah Anda lebih gesit, atau lebih banyak air terjun dalam proses Anda. Saya pikir masuk akal untuk melakukan desain / inspeksi tingkat tinggi, serta inspeksi desain tingkat lebih detail. Saya pikir sebaiknya melibatkan beberapa anggota tim untuk diperiksa.


-1

Mereka benar-benar diperlukan karena mereka memiliki sedikit pengalaman.


tanpa penjelasan, jawaban ini dapat menjadi sia-sia jika ada orang yang memposting pendapat yang berbeda. Misalnya, jika seseorang memposting klaim seperti "Mereka sama sekali tidak perlu karena mereka memiliki sedikit pengalaman", bagaimana jawaban ini membantu pembaca untuk memilih dua pendapat yang bertentangan? Pertimbangkan untuk mengeditnya menjadi bentuk yang lebih baik
agas
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.