Berurusan dengan pengembang terus-menerus mengabaikan kasus tepi dalam karyanya

25

Saya memiliki masalah yang menarik, cukup umum, dengan salah satu pengembang di tim saya. Lelaki itu adalah pengembang hebat, bekerja cepat dan produktif, menghasilkan kode kualitas yang cukup bagus dan semuanya. Insinyur yang bagus. Tetapi ada masalah dengan dia - sangat sering dia gagal untuk menangani kasus tepi dalam kodenya.

Kami berbicara dengannya tentang itu berkali-kali dan dia berusaha tetapi saya kira dia tidak berpikir seperti itu. Jadi apa yang akhirnya terjadi adalah bahwa QA akan menemukan banyak masalah dengan kodenya dan mengembalikannya untuk pengembangan lagi dan lagi, akhirnya menghasilkan tenggat waktu yang terlewat dan semua orang di tim tidak senang.

Saya tidak tahu apa yang harus saya lakukan dengannya dan bagaimana membantunya mengatasi masalah ini. Mungkin seseorang dengan pengalaman lebih bisa memberi saran?

code-quality

— Alex N.
sumber

11

Minta seseorang untuk menutupi kodenya dengan unit test.

— Pekerjaan

8

Orang yang memenuhi syarat terbaik untuk menguji-menutupi kode adalah penulisnya.

16

@Developer Art: Sepenuhnya tidak setuju. Orang terburuk yang melakukan pengujian kode adalah orang yang mengembangkan kode itu. Setiap orang memiliki blind spot tetapi orang yang melakukan penciptaan memiliki blind spot terbesar sehubungan dengan kode-nya.

— James P. Wright

2

@Developer Art: Saya percaya menulis tes otomatis sebenarnya adalah peran yang cukup umum. Biasanya itu adalah sesuatu yang Anda lakukan selama satu atau dua tahun jika Anda tidak cukup siap untuk prime time di perusahaan tempat Anda berada. Ini semacam periode penyucian.

— Morgan Herlocker

19

Anda menggambarkannya sebagai "pengembang hebat", "produktif", "insinyur yang baik", dan menghasilkan 'kode berkualitas baik ". Tetapi QA terus menemukan masalah dengan pekerjaannya. Apakah Anda benar-benar menggunakan istilah-istilah itu untuk menggambarkan seseorang yang secara teratur dan konsisten menyuntikkan cacat ke dalam kode mereka? Saya ingin tahu apakah ada lebih banyak cerita ini, karena deskripsi individu sebagai profesional dan pekerjaan yang mereka lakukan tidak cocok sama sekali

— Thomas Owens

29

Mewajibkannya untuk menulis tes unit otomatis untuk kode-kodenya. Tes unit menulis memaksa seseorang untuk memikirkan kasus-kasus tepi.

Beberapa keterangan khusus:

Untuk memastikan dia tidak merasa dipilih, ini harus dilakukan untuk seluruh tim Anda. Mewajibkan semua orang untuk menulis tes unit otomatis untuk kode baru atau kode yang mereka modifikasi.
Mengharuskan nama uji unit untuk deskriptif tentang kasus yang mereka uji.
Tutup pengujian unit otomatis dalam tinjauan kode di tingkat tinggi. Mintalah pengulas mencari kasus uji yang tidak terjawab (yaitu kasus tepi yang selalu dia lewatkan). Setelah sejumlah umpan balik dari timnya tentang kasus tepi terjawab, ia mungkin akan belajar untuk mempertimbangkannya sebelum ditinjau.
Menegakkan aturan ini untuk seluruh tim: Jika QA menemukan bug, pengembang yang bertanggung jawab berhutang tes otomatis yang mengkonfirmasi kegagalan dan kemudian membuktikan bahwa mereka telah memperbaikinya. (sebelum mereka melakukan pekerjaan lain)

— Matthew Rodatus
sumber

Amin, bahkan lebih baik lagi, mengharuskan semua orang untuk menulis kode mereka terlebih dahulu. Menggunakan kerangka BDD biasanya mengurangi rasa sakit ini

— George Mauer

@ George Ide bagus. TDD akan membantu lebih banyak lagi di sini.

— Matius Rodatus

3

Unit testing bukan tentang menemukan bug - blog.stevensanderson.com/2009/08/24/…

— Dainius

1

@ Dainius saya setuju. Pengujian unit memfasilitasi pengembang untuk memikirkan kasus-kasus tepi, yang dapat mencegah (tetapi tidak mengidentifikasi) bug.

— Matthew Rodatus

After some amount of feedback from his team about missed edge cases, he will probably learn to consider thosePengembang yang memiliki praktik buruk sering berargumen tentang tidak relevannya upaya tambahan yang diperlukan untuk praktik yang baik (karena mereka tidak melihat manfaat dari melakukannya). Meskipun pengembang dapat menyetujui ketika Anda menambahkan kasus tepi tambahan, itu tidak berarti dia menganggap itu relevan atau apakah dia akan menambahkannya sendiri.

— Flater

23

Beri dia daftar periksa, mis

input nol
input pada ujung rentang sangat besar
input pada ujung kecil ekstrim jangkauan
kombinasi
input yang melanggar asumsi invarian (mis. jika x = y)

Orang-orang QA dapat membantu menyusun daftar periksa

Berikan daftar periksa kepada semua pengembang, bukan hanya yang ini.

— Steven A. Lowe
sumber

1

Poin bagus bahwa semua pengembang harus menggunakan daftar periksa, memilih satu pengembang dapat menyebabkan perasaan buruk. Dan itu dapat membantu meningkatkan kualitas kode setiap orang.

— FrustratedWithFormsDesigner

Gagasan bagus, walaupun saya penasaran bagaimana hal itu bisa dilihat dari sudut pandang para devs. Saya tidak pernah benar-benar menemukan praktik ini dalam karier saya sebagai pengembang, jadi agak sulit untuk mengukur reaksinya. Adakah wawasan di sana?

— Alex N.

@Alex: daftar periksa adalah praktik rutin untuk beberapa devs, dan penghinaan mengerikan bagi yang lain. Cobalah dan lihat apa yang terjadi. Jika dia berhenti, maka kualitas kode Anda akan meningkat ;-)

— Steven A. Lowe

4

Pengembang Anda tidak akan menggunakan daftar periksa? Jika daftar periksa dapat menyelamatkan nyawa, apakah mereka akan menggunakannya? Banyak dokter tidak, dan pasien menderita. Baca ini: newyorker.com/reporting/2007/12/10/071210fa_fact_gawande

— Barry Brown

1

@ Barry, saya tidak mengatakan mereka tidak akan melakukannya. Daftar periksa dalam hal ini terdengar, IMHO, seperti obat untuk gejala masalah, bukan untuk masalah itu sendiri. Masalahnya adalah disiplin dan ketekunan dalam hal ini. Ketika masalahnya adalah kompleksitas sistem yang membutuhkan perawatan darurat dengan tingkat tanggung jawab dan stres yang tinggi, yang mengakibatkan tingkat perhatian terhadap detail yang menurun, maka ya, daftar periksa ftw (pilot, dokter, dll.) Tapi itu lebih dari perdebatan filosofis saya kira, di luar ruang lingkup pertanyaan ini.

— Alex N.

17

Insinyur yang bagus.

Baik.

Tetapi ada masalah dengan dia - sangat sering dia gagal untuk menangani kasus tepi dalam kodenya.

Ini adalah kualitas yang tidak dibagikan oleh para insinyur baik.

Mengawasi kasus tepi adalah karakteristik yang hadir atau tidak pada orang. Itu tidak ada hubungannya dengan menjadi insinyur atau programmer. Perkembangan karakteristik ini dipengaruhi oleh latar belakang budaya, lingkungan hidup, peristiwa masa kecil dan pengalaman hidup. Maka sikap itu hanya diterapkan pada pekerjaan apa pun yang dilakukan individu.

Yang Anda butuhkan adalah mencari tahu apakah lelaki Anda berjenis sama yang belum mengembangkan indra tertentu ini (mungkin). Kemungkinan besar dia tidak peduli dengan alasan apa pun. Anda perlu menganalisis seluruh situasi, apakah dia bahagia dalam pekerjaannya. Jika tidak maka mungkin Anda harus melakukan sesuatu untuk membantunya terlebih dahulu.

Jika dia baik-baik saja dengan pekerjaan tetapi belum mengalami bahaya kasus tepi maka Anda dapat mulai mendidiknya. Jika dia menganggapnya serius, dia mungkin akan mengubah cara hidupnya. Meskipun saya skeptis dengan yang satu ini Anda masih bisa mencobanya.

Namun jika ia akan menjadi tipe orang yang tidak pandai dalam kasus tepi maka Anda mungkin tidak memiliki hal lain selain menghapusnya dari tim. Karakteristik ini sangat penting untuk pemrograman praktis. Sedihnya, tanpa itu bahkan orang yang hebat tidak akan menghasilkan pekerjaan yang baik.

6

1 ini adalah keterampilan bahwa beberapa orang memiliki beberapa orang harus belajar untuk menjadi seorang programmer yang baik. Namun, saya perhatikan bahwa ada dua jenis kasus tepi: kasus tepi persyaratan bisnis ("Jika kami memesan 27 pelatih kiri dan 28 pelatih kanan pesanan itu mungkin salah") yang harus ditangani dalam persyaratan proyek, dan aktual mengkodekan kasus tepi (berurusan dengan input yang tidak valid, terus-menerus mengulangi daftar ketika hashset akan lebih masuk akal jika dibandingkan dengan set yang lebih besar dari x dll.) yang lebih merupakan sesuatu yang harus Anda pelajari.

— Ed James

Terima kasih atas wawasan Anda. Sangat menghargai itu. Anda benar di semua bidang di sini, meskipun saya ingin tahu, jika dia adalah orang yang hebat tetapi tidak memiliki sesuatu yang membuat insinyur hebat, bagaimana saya masih bisa menempatkan dia untuk melakukan pekerjaan lain dan membuatnya tetap dalam organisasi, mungkin pindah ke tim lain atau sesuatu ... Meskipun saya kira hanya saya yang bisa menjawab pertanyaan itu :)

— Alex N.

Saya sudah memikirkannya tapi saya tidak yakin. Peran lain agar dapat diterima oleh orang semacam itu seharusnya tidak memerlukan perhatian terhadap detail dan tidak banyak dari mereka dalam perusahaan perangkat lunak.

Dunia tidak begitu hitam dan putih seperti yang disiratkan oleh kalimat pertama Anda. Saya rasa ada pengembang yang dapat mengidentifikasi beberapa kasus tepi tetapi tidak semua.

— Mike Partridge

5

Bisakah Anda melakukan tinjauan kode atau ulasan desain sebelumnya dalam proses?

— PSU_Kardi
sumber

4

Ajari dia untuk memprogram tes pertama. Padukan dengan dia. Anda akan menulis test case dan dia akan menulis kode untuk lulus tes.

— kevin cline
sumber

3

Bisakah melibatkan QA cukup awal dalam pengembangan fitur membantu menyediakannya dengan daftar kasus tepi dekat awal untuk menutupi? Sementara beberapa orang mungkin melihat ini sebagai tidak mengharapkan pengembang untuk mencakup semuanya, ini mungkin cara untuk mengatasi hal ini jika ia cenderung melewatkan kasus-kasus batas yang mungkin dapat ditangkap oleh penguji pada awalnya.

Gagasan lain yang saya miliki di sini adalah bagaimana dia melihat masalah ini. Apakah dia benar-benar kesal dan berdetak pada dirinya sendiri untuk pola ini atau apakah dia hanya melihat ini sebagai hal yang normal dan bukan sesuatu yang dia khawatirkan untuk diselesaikan? Memang ini memang membutuhkan banyak kepercayaan dan membuatnya terbuka pada sudut pandangnya, tetapi saya pikir ada tingkat empati di sini yang dapat membantu jika Anda dapat melihat sesuatu dari sudut pandangnya.

— JB King
sumber

3

Ada jumlah kasus tepi yang tak terbatas, yang mencakup semuanya tidak layak. Bagaimana jika seseorang melakukannya #define TRUE FALSE? Ini menambahkan kasus tepi, apakah Anda akan memeriksanya juga?

Juga, saya tidak akan mempertimbangkan untuk membuktikan setiap fungsi dari kelas privat atau fungsi internal.

Pendekatan yang saya pilih untuk kode yang harus sangat solid dan stabil adalah:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

Dengan cara ini Anda mendapatkan kesedihan aplikasi yang solid di QA, dan pada saat Anda mendapatkan rilis, aplikasi tersebut solid dan aman.

Mengatasi kesalahan itu buruk. Ok, Anda mungkin menyimpan fungsi jika file menangani nol dan mengembalikan nol, tetapi dalam kebanyakan kasus, ada kesalahan desain di suatu tempat, dan aplikasi crash adalah cara yang lebih baik untuk memaksa Anda menemukan penyebabnya. Kebanyakan kasus tepi hanya menutupi kesalahan dengan menyembunyikan masalah, misalnya - tombol berhenti berfungsi. Crash memberi tahu Anda bahwa beberapa asumsi tentang produk salah, dan Anda harus merevisi logika yang menyebabkan kerusakan.

— Coder
sumber

#define TRUE FALSE bukan merupakan kasus tepi, ini adalah pelanggaran pemecatan.

— gnasher729

1

Jika ini kasus tepi, apakah perlu dipertimbangkan? Jika kasus tepi penting maka kasus tepi perlu dimasukkan ke dalam persyaratan / fitur / cerita pengguna.

Jika kasus tepi telah dianggap sebagai bagian dari suatu pekerjaan dan perangkat diharuskan untuk ditempatkan maka mereka harus menjadi bagian dari item pekerjaan dan menurut definisi item pekerjaan tidak lengkap sampai mekanisme untuk menangani kasus tepi adalah di tempat.

Ini memberi Anda sebagai Tim Pimpin sesuatu untuk diperiksa setelah pekerjaan selesai selama diskusi pasca kerja dan memberi pengembang sesuatu untuk diperiksa saat ia menyelesaikan pekerjaan.

— Bronumski
sumber

Selalu ada kasus tepi. Jika seseorang mengklaim kasus tepi tidak akan pernah ditemukan, itu bukan kasus tepi kanan.

— Barry Brown

1

@Barry Brown Saya setuju bahwa selalu ada kasus tepi tetapi ada perbedaan antara kasus tepi penting yang dianggap penting oleh Stakeholder yang dapat kita sebut Skenario dan kasus tepi yang dianggap penting oleh pengembang. Jika Stakeholder menganggap sesuatu itu penting, maka itu harus dibahas pada sesi perencanaan dan dimasukkan sebagai Skenario pada Kisah Pengguna dan tidak diserahkan kepada pengembang untuk dipikirkan, itu harus menjadi persyaratan yang tepat terhadap tugas tersebut. Hal ini sangat memakan waktu dan tidak perlu tetapi pemeriksaan nol terhadap parameter pada setiap metode non publik.

— Bronumski

1

Kasus-kasus menarik adalah mengapa QA ada. Programmer memiliki tanggung jawab untuk mendorong pekerjaan tepat waktu. Menghabiskan seluruh waktu mereka untuk mencari kasus tepi sangat tidak efisien. Jika Anda memiliki siklus berulang yang cukup cepat, maka ini seharusnya tidak menjadi masalah sama sekali. Kasing tepi hampir tak terhingga jumlahnya. Jika itu adalah masalah dengan kasus "Core" maka saya akan sedikit khawatir. Sama seperti pengembang yang ahli dalam pengembangan, penguji juga harus ahli dalam pengujian. Ketika seorang tester menemukan masalah, mereka mengirimkannya kembali ke pengembangan. Pengembang memperbaiki masalah tersebut. Masalah terpecahkan. Waktu bagi pengembang untuk melacak setiap kasus tepi jauh lebih lama daripada waktu yang dibutuhkan siklus pengujian berulang. Perhatikan juga, ketika saya berbicara tentang pengujian, saya tidak bermaksud tes unit kotak putih, tetapi tes kotak hitam.

— Morgan Herlocker
sumber

1

Ini benar-benar bukan jawaban yang tepat. Diberi imbalan karena menghasilkan pekerjaan setengah kualitas adalah praktik yang buruk. Tim pengembang harus secara keseluruhan bertanggung jawab atas pekerjaan berkualitas tinggi.

— David

Pengembang yang layak tidak harus mencari kasus tepi. Beberapa kode ditulis sehingga tidak memiliki kasus tepi, dalam kasus lain kasus tepi jelas. Kode tidak menangani kasus tepi adalah kode tidak lengkap.

— gnasher729

0

Itu adalah salah satu kasus di mana saya percaya pengembangan didorong oleh tes datang untuk menyelamatkan karena membantu untuk berpikir dalam hal kasus tepi dan apa pun yang dapat memecahkan kode.

— Billal Begueradj
sumber