Bagaimana Anda memberi tahu seseorang bahwa mereka menulis kode yang buruk? [Tutup]

Saya telah bekerja dengan sekelompok kecil orang pada proyek pengkodean untuk bersenang-senang. Ini adalah kelompok yang terorganisir dan cukup kohesif. Orang-orang yang bekerja dengan saya semua memiliki berbagai perangkat keterampilan yang terkait dengan pemrograman, tetapi beberapa dari mereka menggunakan metode yang lebih tua atau salah, seperti variabel global yang berlebihan, konvensi penamaan yang buruk, dan hal-hal lainnya. Sementara semuanya berjalan, implementasinya buruk. Apa cara yang baik untuk dengan sopan bertanya atau memperkenalkan mereka untuk menggunakan metodologi yang lebih baik, tanpa itu muncul sebagai mempertanyakan (atau menghina) pengalaman dan / atau pendidikan mereka?

Perkenalkan pertanyaan untuk membuat mereka sadar bahwa apa yang mereka lakukan salah. Misalnya, ajukan pertanyaan semacam ini:

Mengapa Anda memutuskan untuk menjadikannya variabel global?

Mengapa Anda memberi nama itu?

Itu menarik. Saya biasanya melakukan ini dengan cara saya karena [Masukkan alasan mengapa Anda lebih baik]

Apakah cara itu berhasil? Saya biasanya [Sisipkan bagaimana Anda akan membuatnya tampak konyol]

Saya pikir cara ideal untuk melakukan ini adalah secara halus bertanya kepada mereka mengapa mereka mengkode dengan cara tertentu. Anda mungkin menemukan bahwa mereka percaya bahwa ada manfaat untuk metode lain. Kecuali saya tahu alasan gaya pengkodean mereka adalah karena informasi yang salah saya tidak akan pernah menilai cara saya lebih baik tanpa alasan yang baik. Cara terbaik untuk melakukannya adalah dengan bertanya kepada mereka mengapa mereka memilih itu; pastikan untuk terdengar tertarik dengan alasan mereka, karena itulah yang Anda butuhkan untuk menyerang, bukan kemampuan mereka.

Standar pengkodean pasti akan membantu, tetapi jika itu adalah jawaban untuk setiap proyek perangkat lunak maka kita semua akan minum koktail di pulau pribadi kita di surga. Pada kenyataannya, kita semua rentan terhadap masalah dan proyek perangkat lunak masih memiliki tingkat keberhasilan yang rendah. Saya pikir masalah sebagian besar akan berasal dari kemampuan individu daripada masalah dengan konvensi, itulah sebabnya saya sarankan bekerja melalui masalah sebagai sebuah kelompok ketika sebuah masalah muncul dengan kepalanya yang jelek.

Yang terpenting, jangan langsung berasumsi bahwa jalan Anda lebih baik . Pada kenyataannya, mungkin memang demikian, tetapi kita berhadapan dengan pendapat orang lain dan bagi mereka hanya ada satu solusi. Jangan pernah mengatakan bahwa cara Anda adalah cara yang lebih baik untuk melakukannya kecuali Anda ingin mereka melihat Anda sebagai pecundang.

Mulai lakukan tinjauan kode atau pasangkan pemrograman.

Jika tim tidak mau melakukannya, coba ulasan desain mingguan. Setiap minggu, bertemu selama satu jam dan berbicara tentang suatu bagian kode. Jika orang-orang tampak defensif, pilih kode lama yang tidak ada lagi yang terlampir secara emosional, setidaknya di awal.

Seperti @JesperE: berkata, fokus pada kode, bukan koder.

Ketika Anda melihat sesuatu yang Anda pikir harus berbeda, tetapi orang lain tidak melihatnya dengan cara yang sama, maka mulailah dengan mengajukan pertanyaan yang mengarah pada kekurangan, alih-alih menunjukkannya. Sebagai contoh:

Global : Apakah Anda pikir kami ingin memiliki lebih dari satu ini? Apakah Anda pikir kami ingin mengontrol akses ke ini?

Status yang dapat berubah : Apakah Anda pikir kami ingin memanipulasi ini dari utas lainnya?

Saya juga merasa terbantu untuk fokus pada keterbatasan saya , yang dapat membantu orang-orang rileks. Sebagai contoh:

fungsi panjang : Otak saya tidak cukup besar untuk menampung semua ini sekaligus. Bagaimana kita bisa membuat potongan-potongan kecil yang bisa saya tangani?

nama buruk : Saya mudah bingung ketika membaca kode yang jelas; ketika nama-nama menyesatkan, tidak ada harapan bagi saya.

Pada akhirnya, tujuannya bukan untuk Anda mengajarkan tim Anda cara membuat kode yang lebih baik. Ini untuk membangun budaya belajar di tim Anda. Di mana setiap orang mencari bantuan orang lain untuk menjadi programmer yang lebih baik.

Perkenalkan ide standar kode. Yang paling penting tentang standar kode adalah bahwa ia mengusulkan gagasan konsistensi dalam basis kode ( idealnya , semua kode harus terlihat seperti itu ditulis oleh satu orang dalam satu duduk) yang akan mengarah pada kode yang lebih mudah dipahami dan dipelihara.

Anda harus menjelaskan mengapa cara Anda lebih baik .

Jelaskan mengapa suatu fungsi lebih baik daripada memotong & menempel.

Jelaskan mengapa sebuah array lebih baik dari $ foo1, $ foo2, $ foo3.

Jelaskan mengapa variabel global berbahaya, dan bahwa variabel lokal akan membuat hidup lebih mudah.

Cukup mengeluarkan standar pengkodean dan mengatakan "lakukan ini" tidak ada gunanya karena tidak menjelaskan kepada programmer mengapa itu hal yang baik.

Pertama, saya akan berhati-hati untuk tidak menilai terlalu cepat. Sangat mudah untuk mengabaikan beberapa kode sebagai buruk, ketika mungkin ada alasan bagus mengapa demikian (misalnya: bekerja dengan kode lama dengan konvensi aneh). Tapi mari kita asumsikan sejenak bahwa mereka benar-benar buruk.

Anda dapat menyarankan untuk menetapkan standar pengkodean, berdasarkan masukan tim. Tetapi Anda benar-benar perlu mempertimbangkan pendapat mereka, bukan hanya memaksakan visi Anda tentang kode yang baik.

Pilihan lain adalah membawa buku-buku teknis ke kantor (Kode Lengkap, Efektif C ++, Programmer Pragmatis ...) dan menawarkan untuk meminjamkannya kepada orang lain ("Hei, saya sudah selesai dengan ini, ada yang mau meminjamnya?" )

Jika memungkinkan, pastikan mereka mengerti bahwa Anda mengkritik kode mereka , bukan mereka secara pribadi.

Sarankan alternatif yang lebih baik dengan cara yang tidak konfrontatif.

"Hei, aku pikir cara ini juga akan berhasil. Apa yang kalian pikirkan?" [Gesture untuk kode yang jelas lebih baik di layar Anda]

Buat ulasan kode, dan mulai dengan meninjau kode ANDA .

Ini akan membuat orang merasa nyaman dengan seluruh proses peninjauan kode karena Anda memulai proses dengan meninjau kode Anda sendiri, bukan kode mereka. Memulai dengan kode Anda juga akan memberi mereka contoh yang baik tentang bagaimana melakukan sesuatu.

Mereka mungkin berpikir gayamu juga bau. Dapatkan tim bersama untuk membahas seperangkat pedoman gaya pengkodean yang konsisten. Setuju dengan sesuatu. Apakah itu cocok dengan gaya Anda, bukan masalah, tetap pada gaya apa pun selama itu konsisten adalah yang penting.

Contohnya. Tunjukkan pada mereka dengan cara yang benar.

Santai saja. Jangan membasmi mereka untuk setiap kesalahan kecil, mulai dengan hal-hal yang benar-benar penting.

Gagasan standar kode adalah ide yang bagus.

Tetapi pertimbangkan untuk tidak mengatakan apa-apa, terutama karena itu untuk bersenang-senang, dengan, mungkin, orang-orang yang berteman dengan Anda. Itu hanya kode ...

Ada beberapa saran yang sangat bagus dalam buku Gerry Weinberg "The Psychology of Computer Programming" - seluruh gagasannya tentang "pemrograman tanpa ego" adalah tentang bagaimana membantu orang menerima kritik terhadap kode mereka sebagai berbeda dari kritik terhadap diri mereka sendiri.

Praktik penamaan yang buruk: Selalu tidak bisa dimaafkan.

Dan ya, jangan selalu menganggap bahwa jalan Anda lebih baik ... Ini bisa sulit, tetapi objektivitas harus dipertahankan.

Saya sudah memiliki pengalaman dengan seorang pembuat kode yang memiliki penamaan fungsi yang mengerikan, kodenya lebih buruk daripada tidak dapat dibaca. Fungsi berbohong tentang apa yang mereka lakukan, kode itu tidak masuk akal. Dan mereka protektif / tahan untuk meminta orang lain mengubah kode mereka. ketika dihadapkan dengan sangat sopan, mereka mengakui bahwa nama itu buruk, tetapi ingin mempertahankan kepemilikan mereka atas kode tersebut dan akan kembali dan memperbaikinya "di kemudian hari." Ini di masa lalu sekarang, tetapi bagaimana Anda menghadapi situasi di mana kesalahan mereka DIAKUI, tetapi kemudian dilindungi? Ini berlangsung untuk waktu yang lama dan saya tidak tahu bagaimana menembus penghalang itu.

Variabel global: Saya sendiri bukan ITU yang menyukai variabel global, tetapi saya tahu beberapa programmer yang sangat baik yang menyukainya BANYAK. Sedemikian rupa sehingga saya menjadi percaya bahwa mereka sebenarnya tidak terlalu buruk dalam banyak situasi, karena mereka memungkinkan untuk kejelasan, kemudahan debugging. (tolong jangan nyalakan / downvote saya :)) Maka, saya telah melihat banyak kode bebas bug yang sangat bagus, efektif, yang menggunakan variabel global (tidak dimasukkan oleh saya!) dan banyak buggy, tidak mungkin membaca / memelihara / memperbaiki kode yang dengan cermat menggunakan pola yang tepat. Mungkin ada IS tempat (meskipun menyusut mungkin) untuk variabel global? Saya sedang mempertimbangkan memikirkan kembali posisi saya berdasarkan bukti.

Mulai wiki di jaringan Anda menggunakan beberapa perangkat lunak wiki.

Mulai kategori di situs Anda yang disebut "praktik terbaik" atau "standar pengkodean" atau sesuatu.

Arahkan semua orang untuk itu. Berikan umpan balik.

Ketika Anda melakukan rilis perangkat lunak, minta orang yang tugasnya adalah memasukkan kode ke dalam push build pada pengembang, mengarahkan mereka ke halaman Wiki di atasnya.

Saya telah melakukan ini di organisasi saya dan butuh beberapa bulan bagi orang untuk benar-benar memahami penggunaan Wiki, tetapi sekarang ini adalah sumber yang sangat diperlukan.

Jika Anda bahkan memiliki standar pengkodean yang longgar, dapat menunjukkan hal itu, atau menunjukkan bahwa Anda tidak dapat mengikuti kode karena itu bukan format yang benar, mungkin bermanfaat.

Jika Anda tidak memiliki format pengkodean, sekarang saat yang tepat untuk mendapatkannya. Sesuatu seperti jawaban untuk pertanyaan ini mungkin bermanfaat: /programming/4121/team-coding-styles

Saya selalu mengikuti garis 'Ini yang akan saya lakukan'. Saya tidak mencoba dan memberi ceramah kepada mereka dan memberi tahu mereka bahwa kode mereka adalah sampah tetapi hanya memberikan sudut pandang alternatif yang semoga dapat menunjukkan kepada mereka sesuatu yang jelas sedikit lebih rapi.

Mintalah orang yang bersangkutan menyiapkan presentasi kepada seluruh kelompok mengenai kode untuk modul perwakilan yang telah mereka tulis, dan biarkan Tanya Jawab mengurusnya (percayalah, itu akan, dan jika itu adalah kelompok yang baik, itu seharusnya tidak jelek).

Saya suka kode, dan tidak pernah memiliki kursus dalam hidup saya tentang apa pun yang berkaitan dengan informatika saya mulai sangat buruk dan mulai belajar dari contoh, tetapi apa yang saya selalu ingat dan ingat dalam pikiran saya sejak saya membaca buku "Gang Of Four" adalah :

"Semua orang bisa menulis kode yang dimengerti oleh mesin, tapi tidak semua bisa menulis kode yang dipahami manusia"

dengan mengingat hal ini, ada banyak yang harus dilakukan dalam kode;)

Saya tidak bisa cukup menekankan kesabaran. Saya telah melihat hal yang persis seperti ini menjadi bumerang sebagian besar karena seseorang ingin perubahan terjadi SEKARANG. Beberapa lingkungan membutuhkan manfaat evolusi, bukan revolusi. Dan dengan memaksa perubahan hari ini, itu bisa membuat lingkungan yang sangat tidak bahagia untuk semua.

Kuncinya adalah kunci. Dan pendekatan Anda perlu memperhitungkan lingkungan tempat Anda berada.

Sepertinya Anda berada di lingkungan yang memiliki banyak "individualitas". Jadi ... Saya tidak akan menyarankan satu set standar pengkodean. Ini akan menemukan bahwa Anda ingin mengambil proyek "menyenangkan" ini dan mengubahnya menjadi proyek kerja yang sangat terstruktur (oh bagus, apa selanjutnya ... dokumen fungsional?). Sebaliknya, seperti kata orang lain, Anda harus menghadapinya sampai batas tertentu.

Tetap sabar dan bekerja untuk mendidik orang lain ke arah Anda. Mulailah dengan tepi (titik-titik di mana kode Anda berinteraksi dengan orang lain) dan ketika berinteraksi dengan kode mereka cobalah untuk menjadikannya sebagai kesempatan untuk membahas antarmuka yang telah mereka buat dan tanyakan kepada mereka apakah akan baik-baik saja dengan mereka jika diubah (oleh Anda atau mereka). Dan jelaskan mengapa Anda menginginkan perubahan ("itu akan membantu menangani perubahan atribut subsistem yang lebih baik" atau apa pun). Jangan memilih dan mencoba mengubah semua yang Anda anggap salah. Setelah Anda berinteraksi dengan orang lain di ujung tanduk, mereka harus mulai melihat bagaimana itu akan menguntungkan mereka pada inti kode mereka (dan jika Anda mendapatkan momentum yang cukup, masuk lebih dalam dan benar-benar mulai membahas teknik modern dan manfaat dari standar pengkodean). Jika mereka masih tidak melihatnya ... mungkin Anda

Kesabaran. Evolusi, bukan revolusi.

Semoga berhasil.

Saya tidak mengenakan toga dan membuka sekaleng metode sosial.

The Metode Socrates dinamai Klasik Yunani filsuf Socrates, adalah bentuk penyelidikan filosofis di mana penanya mengeksplorasi implikasi dari posisi orang lain, untuk merangsang pemikiran rasional dan ide-ide menerangi. Metode dialektik ini sering melibatkan diskusi oposisi di mana pembelaan dari satu sudut pandang diadu terhadap yang lain; salah satu peserta dapat memimpin yang lain untuk bertentangan dengan dirinya sendiri dalam beberapa cara, memperkuat poin penanya sendiri.

Banyak jawaban di sini berkaitan dengan pemformatan kode yang saat ini tidak terlalu relevan, karena sebagian besar IDE akan memformat ulang kode Anda dengan gaya yang Anda pilih. Yang benar-benar penting adalah bagaimana kodenya bekerja, dan posternya tepat untuk melihat variabel global, menyalin & menempelkan kode, dan konvensi penamaan hewan peliharaan saya yang kesal. Ada yang namanya kode buruk dan tidak ada hubungannya dengan format.

Bagian yang baik adalah bahwa sebagian besar buruk karena alasan yang sangat baik, dan alasan-alasan ini umumnya dapat diukur dan dijelaskan. Jadi, dengan cara yang tidak konfrontatif, jelaskan alasannya. Dalam banyak kasus, Anda bahkan dapat memberikan skenario penulis di mana masalah menjadi jelas.

Saya bukan pengembang utama pada proyek saya dan karena itu tidak dapat memaksakan standar pengkodean tetapi saya telah menemukan bahwa kode buruk biasanya menyebabkan masalah lebih cepat daripada kemudian, dan ketika itu terjadi saya di sana dengan ide atau solusi yang lebih bersih.

Dengan tidak menyela pada saat itu dan mengambil pendekatan yang lebih alami, saya mendapatkan kepercayaan lebih banyak dengan pimpinan dan dia sering meminta saya untuk ide dan memasukkan saya pada desain arsitektur dan strategi penyebaran yang digunakan untuk proyek tersebut.

Orang yang menulis kode buruk hanyalah gejala ketidaktahuan (yang berbeda dengan menjadi bodoh). Inilah beberapa tips untuk berurusan dengan orang-orang itu.

• Pengalaman masyarakat sendiri meninggalkan kesan yang lebih kuat daripada apa yang akan Anda katakan.
• Beberapa orang tidak bersemangat dengan kode yang mereka hasilkan dan tidak akan mendengarkan apa pun yang Anda katakan
• Pemrograman Berpasangan dapat membantu berbagi ide tetapi beralih siapa yang mengemudi atau mereka hanya akan memeriksa email di ponsel mereka
• Jangan menenggelamkan mereka dengan terlalu banyak, saya bahkan menemukan Integrasi Berkelanjutan perlu dijelaskan beberapa kali kepada beberapa devs yang lebih tua
• Buat mereka bersemangat lagi dan mereka ingin belajar. Bisa jadi sesuatu yang sederhana seperti pemrograman robot selama sehari
• PERCAYA TIM ANDA, standar pengkodean dan alat yang memeriksa mereka pada waktu membangun sering tidak pernah membaca atau mengganggu.
• Hapus Kepemilikan Kode, pada beberapa proyek Anda akan melihat silo kode atau bukit semut di mana orang mengatakan itu kode saya dan Anda tidak dapat mengubahnya, ini sangat buruk dan Anda dapat menggunakan pemrograman berpasangan untuk menghapus ini.

Alih-alih meminta mereka menulis kode, minta mereka mempertahankan kode mereka.

Sampai mereka harus menjaga tumpukan spaghetti mereka yang mengepul, mereka tidak akan pernah mengerti betapa buruknya mereka dalam pengkodean.

Tidak ada yang suka mendengarkan seseorang mengatakan pekerjaan mereka menyebalkan, tetapi siapa pun yang waras akan menerima bimbingan dan cara menghindari pekerjaan yang tidak perlu.

Satu sekolah pengajaran bahkan mengatakan bahwa Anda tidak harus menunjukkan kesalahan, tetapi fokuskan apa yang dilakukan dengan benar. Misalnya, alih-alih menunjukkan kode yang tidak dapat dipahami sebagai buruk, Anda harus menunjukkan di mana kode mereka sangat mudah dibaca. Dalam kasus pertama Anda membuat orang lain berpikir dan bertindak seperti programmer yang jelek. Dalam kasus selanjutnya Anda priming untuk berpikir seperti seorang profesional yang terampil.

Saya memiliki senario yang sama dengan orang-orang yang bekerja dengan saya .. Mereka tidak memiliki eksposur untuk pengkodean seperti yang saya lakukan tetapi mereka masih berguna dalam pengkodean.

Daripada saya membiarkan melakukan apa yang mereka inginkan dan kembali dan mengedit semuanya. Saya biasanya hanya duduk dan menunjukkan kepada mereka dua cara melakukan sesuatu. Cara saya dan Cara saya, Dari sini kita membahas pro dan kontra dari masing-masing metode dan karena itu mencapai pemahaman yang lebih baik dan kesimpulan yang lebih baik tentang bagaimana seharusnya kita melanjutkan pemrograman.

Inilah bagian yang benar-benar luar biasa. Kadang-kadang mereka akan datang dengan pertanyaan yang bahkan saya tidak punya jawaban, dan setelah penelitian kita semua mendapatkan konsep metodologi dan struktur yang lebih baik.

1. Bahas.
2. Tunjukkan pada mereka Mengapa
3. Bahkan jangan berpikir Anda selalu benar .. Kadang-kadang bahkan mereka akan mengajari Anda sesuatu yang baru.

Itulah yang akan saya lakukan jika saya adalah Anda: D

Mungkin agak terlambat setelah efek, tetapi di situlah standar pengkodean yang disepakati adalah hal yang baik.

Jujur saya percaya bahwa kode seseorang lebih baik ketika lebih mudah untuk mengubah, men-debug, menavigasi, memahami, mengkonfigurasi, menguji dan menerbitkan (wah).

Yang mengatakan saya pikir itu tidak mungkin untuk memberitahu seseorang / nya kodenya buruk tanpa terlebih dahulu memiliki dia menjelaskan apa yang dilakukannya atau bagaimana orang seharusnya memperbaikinya setelah itu (seperti, menciptakan fungsi baru atau men-debug itu).

Hanya kemudian pikiran mereka tersentak dan siapa pun dapat melihat itu:

• Perubahan nilai variabel global hampir selalu tidak bisa dilacak
• Fungsi besar sulit dibaca dan dipahami
• Pola membuat kode Anda lebih mudah ditingkatkan (selama Anda mematuhi aturan mereka)
• (dll ...)

Mungkin sesi pemrograman pasangan harus melakukan trik. Adapun menegakkan standar pengkodean - itu membantu tetapi mereka terlalu jauh dari benar-benar mendefinisikan apa kode yang baik.

Anda mungkin ingin fokus pada dampak kode buruk, daripada apa yang mungkin dianggap hanya sebagai pendapat subjektif Anda apakah itu gaya yang baik atau buruk.

Secara pribadi, tanyakan tentang beberapa segmen kode "buruk" dengan pandangan terhadap kemungkinan bahwa itu sebenarnya adalah kode yang masuk akal , (tidak peduli seberapa besar kecenderungan Anda), atau bahwa mungkin ada keadaan yang semakin melemahkan. Jika Anda masih yakin bahwa kode itu benar-benar buruk - dan bahwa sumber sebenarnya adalah orang ini - pergilah. Salah satu dari beberapa hal dapat terjadi: 1) orang tersebut memperhatikan dan mengambil tindakan korektif, 2) orang itu tidak melakukan apa-apa (tidak menyadari, atau tidak peduli seperti Anda).

Jika # 2 terjadi, atau # 1 tidak menghasilkan peningkatan yang cukup dari sudut pandang Anda, DAN itu merugikan proyek, dan / atau berdampak cukup pada Anda, maka mungkin sudah waktunya untuk memulai kampanye untuk membangun / menegakkan standar dalam tim. Hal itu membutuhkan persetujuan manajemen, tetapi paling efektif ketika dihasut dari akar rumput.

Semoga beruntung dengan itu. Saya merasakan sakit saudara Anda.