Apa hambatan untuk mengadopsi praktik terbaik? Bagaimana mereka dapat diatasi? [Tutup]

Kita semua telah melihat (dan kebanyakan dari kita telah menulis) banyak kode yang ditulis dengan buruk. Mengapa? Apa yang membuat kita mengadopsi praktik buruk dan bukan praktik yang baik?

Jawaban yang paling jelas (bagi saya) adalah "ketidaktahuan", tapi saya yakin itu bukan satu-satunya alasan. Apa yang ada di sana? Apa yang dapat kita lakukan untuk mengatasi godaan untuk menulis kode yang buruk?

Bertahan untuk tidak berubah.

Itu adalah pendorong utama di balik ketidaktahuan, manajemen buruk dll

Bab 30 Peopleware Edisi 2 dikhususkan untuk topik ini. Dan itu mengutip dari sebuah buku oleh konsultan lain yang cukup terkenal, yang ditulis sedikit lebih awal:

Dan harus dipertimbangkan bahwa tidak ada yang lebih sulit untuk ditangani, lebih diragukan keberhasilannya, atau lebih berbahaya untuk dikelola, kemudian menempatkan diri sendiri sebagai pemimpin dalam memperkenalkan pesanan baru. Karena pengantar memiliki semua orang yang mendapat manfaat dari perintah lama sebagai musuh, dan ia memiliki pembela yang suam-suam kuku di semua orang yang mungkin mendapat manfaat dari perintah baru.

Niccolo Machiavelli: The Prince (1513)

DeMarco dan Lister terus menyatakan mantra untuk diingat sebelum meminta orang untuk berubah:

Respons mendasar terhadap perubahan tidak logis, tetapi emosional.

Proses perubahan jarang merupakan penggerak lurus dan halus dari kondisi suboptimal saat ini ke dunia baru yang lebih baik. Untuk setiap perubahan nontrivial, selalu ada periode kebingungan dan kekacauan sebelum tiba ke status quo baru . Mempelajari alat, proses, dan cara berpikir baru itu sulit , dan butuh waktu. Selama masa transisi ini, produktivitas menurun, moral menderita, orang mungkin mengeluh dan berharap jika hanya mungkin untuk kembali ke cara lama yang baik dalam melakukan sesuatu. Sangat sering mereka melakukannya, bahkan dengan semua masalah, karena mereka merasa bahwa masalah yang diketahui baik lebih baik daripada masalah yang baru, tidak diketahui, membuat frustrasi dan memalukan. Ini adalah perlawanan yang harus dengan bijaksana dan lembut, tetapi jelas diatasi untuk berhasil.

Dengan kesabaran dan ketekunan, akhirnya tim tiba dari Chaos ke tahap berikutnya, Latihan dan Integrasi. Orang-orang, meskipun tidak sepenuhnya nyaman dengan alat / proses baru, mulai memahami ini. Mungkin ada pengalaman positif "Aha". Dan lambat laun, tim mencapai status quo baru.

Sangat penting untuk menyadari bahwa kekacauan adalah bagian integral dari proses perubahan . Tanpa pengetahuan ini - dan persiapan untuk itu -, seseorang mungkin panik setelah mencapai fase Kekacauan, dan salah mengartikannya dengan status quo baru. Selanjutnya proses perubahan ditinggalkan dan tim kembali ke keadaan semula yang menyedihkan, tetapi dengan harapan yang lebih kecil untuk memperbaiki apa pun ...

Untuk referensi, fase yang dijelaskan di atas pada awalnya didefinisikan dalam Satir Change Model (dinamai setelah Virginia Satir ).

Péter Török benar, tetapi mengabaikan satu poin penting dan optimis:

• orang mungkin menyukai perubahan yang mereka lakukan, tetapi mereka hampir tidak pernah menyukai perubahan yang "terjadi" pada mereka

jadi libatkan mereka, biarkan mereka menyumbangkan ide, biarkan mereka membuat pasak di dalamnya, dan itu tidak akan begitu menyakitkan

Catatan: ini relevan dengan pemrograman karena banyak proyek perangkat lunak yang berhasil secara teknis gagal karena pengguna menolaknya .

Waktu sepertinya menjadi hal yang besar di mana saya bekerja.

mis. Mengapa mengadopsi pengujian unit ketika Anda harus menulis lebih banyak kode, dan karenanya membutuhkan waktu lebih lama untuk mendapatkan produk yang dapat dirilis? Klien x menginginkannya sekarang! Kode lebih cepat!

(Ini jelas tidak berakhir dengan baik)

Ini juga merupakan hasil dari manajemen dan ekonomi yang buruk, tidak membebani pelanggan dengan cukup untuk menghabiskan waktu untuk Melakukannya dengan Benar.

Terlepas dari bukti besar yang bertentangan, manusia biasanya makhluk yang sangat rasional. Alasan mengapa orang tidak mengadopsi praktik terbaik, seperti TDD misalnya, adalah bahwa mereka tidak berpikir itu akan sia-sia. Entah mereka berpikir bahwa praktiknya sebenarnya bukan yang terbaik; dan bahwa itu benar-benar akan membuat mereka lebih mahal daripada menyelamatkan mereka. Atau mereka berpikir bahwa manfaatnya sangat kecil sehingga biaya perubahan akan lebih besar daripada manfaat kecilnya. Intinya adalah bahwa masalah praktik terbaik adalah masalah garis bawah.

Jika Anda ingin menjadi agen perubahan, tugas Anda adalah menunjukkan bahwa persepsi mereka tentang intinya cacat. Anda perlu menunjukkan bahwa praktik terbaik adalah yang terbaik. Bahwa manfaatnya langsung dan signifikan . Anda perlu menunjukkan bahwa kurva belajar cukup kecil untuk bertahan, dan setidaknya beberapa manfaat segera dimulai.

Bagaimana Anda menunjukkan ini? Dengan mengadopsi praktik terbaik sendiri! Tidak ada yang bisa meyakinkan orang lain lebih baik daripada perilaku Anda sendiri. Jika Anda mengikuti praktik terbaik, dan vokal tentang hal itu, orang lain akan melihat bahwa Anda melakukan analisis ekonomi dan membuat keputusan sebaliknya. Itu akan membuat mereka mempertimbangkan kembali keputusan mereka. Mereka akan melakukan ini secara pribadi, dan tidak pernah mengakuinya pada awalnya. Tetapi setiap orang yang melihat Anda menggunakan praktik terbaik itu, akan memeriksa kembali posisi mereka.

Itu yang terbaik yang bisa Anda harapkan. Jika praktik terbaik adalah praktik terbaik, maka sisanya akan mengikuti secara otomatis. Oh itu tidak akan cepat, dan akan ada banyak pertikaian. Transisi akan lambat dan jerawatan; dan Anda akan mengalami banyak kekecewaan. Tetapi transisi juga tidak terhindarkan dan tak terhindarkan. Mungkin butuh satu generasi, tetapi praktik terbaik akan menang.

Sebagai buktinya, tanyakan pada diri Anda kapan terakhir kali Anda melihat seseorang menggunakan goto.

Ini adalah hasil dari tidak mengetahui, atau berpikir bahwa seseorang tahu metode yang ideal. Orang tidak memilih untuk menulis kode dengan buruk; ini lebih merupakan kasus ketidaktahuan. " Naif ", sebagai kebalikan dari " ketidaktahuan " akan menjadi kata yang lebih baik.

Cara paling sederhana untuk menyesuaikan diri dengan praktik yang baik adalah mengakui ada (kemungkinan besar) cara yang lebih baik untuk menulis kode yang baru saja Anda tulis, dan kemudian bercita-cita untuk belajar apa 'cara yang lebih baik' itu.

Dua penyebab

• Ketidakpedulian.

• Arogansi.

Bagaimana mereka dapat diatasi?

• Insentif.

Sampai manajer (yaitu, orang-orang yang membeli keterampilan pengembang) memerlukan praktik terbaik sebagai bagian dari pengiriman perangkat lunak, tidak ada yang bisa berubah. Banyak organisasi jelas menderita skizofrenia: mereka mendidik pengembang dalam berbagai teknologi dan kemudian menuntut perangkat lunak yang tidak diuji atau desain yang tidak dapat diuji coba. Atau lebih buruk.

Praktik terbaik bagi saya adalah perangkat lunak yang ditulis oleh tim yang terdiri dari 8 orang. Kami tidak memiliki persyaratan tertulis, ulasan kode, Tes unit, format dokumen rilis. Tidak ada pengujian pengguna akhir, tidak satu pun dari semua buku mengatakan bahwa kita harus melakukan. Kode itu tergesa-gesa, tidak stabil dan sulit dipelihara. Itu dibuang 3 tahun setelah rilis itu sangat buruk. Jadi apa yang hebat dari itu. Dua tahun setelah rilis pertama pemilik perusahaan (yang telah mendanai pembangunan dengan hipotek di rumahnya sendiri) berjalan pergi dengan $ 30- $ 40 juta di saku belakangnya.

Kita sering melupakan fakta bahwa kita (lebih sering daripada tidak) ada di sini untuk membuat perangkat lunak yang menghasilkan uang untuk bisnis. Bisnis tidak ada untuk memberi kita kesempatan untuk mengembangkan perangkat lunak menggunakan "Praktik Terbaik", mereka ada untuk menghasilkan uang.

Kebanyakan praktik "praktik terbaik" tidak meningkatkan laba. Mereka yang melakukan, harus dan sedang, diadopsi secara luas. Itu sebabnya "praktik terbaik" tidak dilakukan.

Risiko yang Dapat Diterima

Pernahkah Anda mengambil risiko dan mempertaruhkan sesuatu? Ada krisis waktu, jadi Anda membuatnya berfungsi dengan maksud untuk refactoring nanti (sebagai lawan refactoring lebih awal). Itu sebenarnya dianggap praktik yang baik bagi sebagian orang.

Akhirnya, Anda terbakar cukup waktu dan Anda mengubah cara Anda. Pikirkan semua 'praktik terbaik' yang ada di luar sana. Bisakah Anda mengikuti mereka semua sepanjang waktu? Apakah ada yang saling bertentangan? Anda tidak ingin membuang waktu menangani setiap outlier.

Jika saya menulis kode buruk yang berfungsi dan tidak ada yang melihatnya lagi, apakah masih dianggap buruk? (Tolong, jangan merusak debat filosofis dengan berdebat tentang apa 'kode buruk' itu.)

IME itu kombinasi dari apa yang dikatakan orang lain. Ketidaktahuan ("Saya hanya pernah menggunakan DataSet, mengapa repot-repot dengan hal-hal LINQ ini?", Kurangnya waktu ("Bos ingin itu dilakukan sesegera mungkin, kita tidak bisa menghabiskan banyak waktu untuk itu"), kurang pemahaman ("Apa yang salah dengan menulis semua kode saya di belakang kode?") semua berkontribusi.

Ironi yang saya lihat adalah begitu Anda memulai jalan itu, Anda hanya membuat diri Anda semakin dalam. Jika Anda mengambil jalan pintas sekarang dan melemparkan semua kode untuk aplikasi dalam file ASPX, Anda tidak akan pernah bisa memperbaikinya nanti; hal-hal baru akan terus dilemparkan kepada Anda yang berarti Anda harus melakukannya dengan cepat, yang berarti Anda harus membuang semua kode dalam file ASPX (bersumpah Anda akan memperbaikinya suatu hari), dll. itu tidak pernah -meng spiral karena Anda tidak bisa lagi menghentikan perkembangan dan mengatakan hal-hal yang perlu diperbaiki terlebih dahulu.

Seringkali pengembang tidak menunjukkan praktik yang lebih baik atau yang lebih penting manfaat menggunakan praktik yang lebih baik (Saya mulai berhenti menggunakan istilah 'Praktik terbaik' karena berbagai alasan).

Ada teori bahwa pengembang 'sengaja malas'. Dengan kata lain, mereka akan cenderung memilih jalur yang paling tidak resistan.

Begitu Anda dengan cepat menunjukkan kepada mereka manfaat dari praktik yang lebih baik (seperti TDD, atau katakanlah, mengikuti prinsip-prinsip SOLID) dan bahwa itu benar-benar memungkinkan mereka untuk menjadi pengembang yang lebih baik (tapi masih 'malas') maka Anda cenderung menemukan bahwa resistensi meleleh. jauh.

Ini masalah pendidikan :)

(Kurangnya) Pengetahuan dan Keterampilan + Waktu Untuk Berinvestasi

Saya terkejut tidak ada orang lain yang mengeluarkan ini, tapi mungkin itu jelas bagi saya karena begitu banyak pekerjaan saya sebagai programmer singleton, tanpa seorangpun (selain tumpukan) untuk pergi ketika saya berjuang pada sesuatu. Saya tahu 'teknik' yang lebih baik - seperti TDD - tetapi seringkali saya tidak memahaminya dengan cukup baik untuk menggunakannya dan kesulitan menemukan informasi yang baik untuk membantu saya mulai menggunakannya. Sekali lagi, menggunakan TDD sebagai contoh, saya mengerti arti dasarnya - membangun tes yang menyatakan kode Anda mengeluarkan hasil tertentu - tetapi sebenarnya menerapkannya?

Selain fakta bahwa XCode telah memiliki unit-testing di dalamnya, saya tidak tahu harus mulai dari mana. Apakah saya menegaskan bahwa tampilan memiliki tombol X di atasnya setelah saya menjalankan rutin untuk membuatnya? Bagaimana kalau menyatakan bahwa UIViews saya telah diatur ulang dengan tepat setelah saya memanggil tag putar?

Heck, bagaimana saya bahkan menulis unit test di XCode? Itu hal lain yang perlu saya habiskan waktu untuk belajar.

@Zues dan @Joshua Smith

Ya saya kadang-kadang setuju waktu dan anggaran adalah beberapa kendala yang tidak membiarkan Anda memasukkan setiap prinsip "pemrograman yang lebih baik" yang Anda ketahui ke dalam suatu program.

Anda tahu bahwa tugas saat ini dapat dilakukan dengan cara yang jauh lebih kuat jika Anda punya waktu lebih banyak. Tetapi sangat sedikit klien (terutama jika mereka menyelesaikan Aplikasi iPhone pertama mereka atau perangkat lunak intelijen bisnis kustom pertama mereka) mengerti ketika Anda mengatakan bahwa Anda menerapkan kembali sesuatu yang sudah dilakukan karena Anda telah menemukan cara yang lebih baik untuk melakukannya.

Sama untuk Tes Unit. Sayangnya saya belum bertemu dengan klien yang siap mengalokasikan anggaran untuk itu. Jawaban khasnya seperti “Pengujian regresi otomatis OK, saya mengerti tetapi tes unit? Kami tidak punya waktu untuk itu! Kita harus membuatnya cepat ke pasar! "

Dua bagian dalam sebagian besar pengalaman saya:

• waktu
• mendapatkan cukup banyak orang untuk menyetujui praktik apa yang terbaik untuk situasi saat ini

"Praktik Terbaik" SANGAT subyektif dalam banyak situasi dunia nyata. Jika satu setengah dari tim sedang mencoba melakukan banyak SOLID & TDD sementara setengah lainnya bekerja 60 jam minggu untuk mencukur detik dari durasi lari di sana-sini melalui segala cara yang diperlukan karena Anda sudah melewati titik di mana sudah terlambat untuk mendesain ulang sesuatu yang tidak berkinerja tepat waktu untuk rilis berikutnya, Anda tidak akan melangkah terlalu jauh.

Bahkan jika Anda tidak mengalami terlalu banyak perselisihan di seluruh tim, banyak upaya untuk mendapatkan persetujuan resmi, dokumentasi, dan pelatihan tentang kebijakan apa pun yang Anda putuskan akan Anda ikuti. Itu adalah blok besar waktu non-produktif dari sudut pandang bisnis yang harus Anda benarkan dengan hati-hati.

Terkadang, Anda akan menemukan bahwa kebiasaan juga merupakan kontributor utama untuk menulis kode yang buruk.

Anda mungkin seorang programmer yang sangat berpengalaman dan Anda mungkin tahu semua tentang praktik terbaik industri saat ini. Neraka, Anda bahkan bisa menjadi yang ahli tentang hal-hal seperti itu. Pengalaman memberi tahu saya bahwa orang-orang semacam itu tidak sering menulis kode yang buruk, namun mudah untuk kembali pada kebiasaan lama dan melakukan sesuatu yang Anda tahu akan melanggar aturan, hanya karena terasa aman dan nyaman. Dalam kasus seperti itu, ketidaktahuan dan kesombongan dan semua kata sifat lainnya yang Anda pikirkan mungkin tidak terlalu penting. Belum tentu bahwa programmer seperti itu secara khusus buruk pada apa yang mereka lakukan (walaupun ini lebih sering terjadi), atau bahkan mereka ingin membuat kekacauan yang mengerikan.

Sangat disayangkan bahwa saya secara pribadi telah menyaksikan ini terjadi lebih dari yang saya ingin hitung, di mana beberapa orang yang benar-benar berbakat mengeluarkan sampah semata-mata karena jari dan otak mereka beroperasi secara otomatis selama beberapa bulan. Paling sering ini adalah di mana Anda melihat bukti kelelahan, kesedihan dan stres menumpuk. Kadang-kadang itu hanya kebiasaan buta yang membawa mereka melalui gerakan sehari-hari. Ini adalah sesuatu yang telah saya pelajari untuk mengawasi dengan hati-hati untuk menghindari risiko melabeli orang-orang yang rentan secara tidak perlu.

Hanya beberapa makanan untuk dipikirkan bagi kita yang merasa lebih mudah untuk melompat ke kesimpulan negatif ... meskipun sayangnya Anda akan benar lebih sering daripada tidak.

Tidak ada yang menunjukkan minat untuk membayar proyek berjudul sesuatu di sepanjang refactoring. Itu harus memiliki beberapa kata yang menarik minat 'bisnis'. Kata-kata seperti pembenahan, penyegaran, remake total, peningkatan siklus hidup, dll bekerja di tempat kerja saya. Hampir semuanya memiliki refactoring sebagai bagian utama dari proyek.

Sayangnya, terima kasih kepada pelaku ekonomi, pekerjaan terjadi hanya ketika ada bayaran. Sekalipun pekerjaan itu hanya untuk menyelamatkan kekayaan bisnis dalam jangka panjang.