Apa hambatan untuk mengadopsi praktik terbaik? Bagaimana mereka dapat diatasi? [Tutup]
22
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?
Apa alasan Anda dapat mengatakan hari ini bahwa kode ditulis dengan buruk sebagai kebalikan dari mengapa itu ditulis?
@ Thorbjørn: Maaf, saya tidak mengerti pertanyaannya?
Kramii Reinstate Monica
@ Kramil, apakah Anda mengenali ketika Anda menulis kode yang ditulis dengan buruk bahwa itu ditulis dengan buruk, dan jika demikian mengapa Anda menulis seperti itu? Jika tidak, maka apa yang telah terjadi sejak Anda dapat mengenalinya sekarang, berbeda dengan sebelumnya.
4
@ Kramii, tidak ada "praktik terbaik" yang bisa menjadi pengganti pemikiran rasional dan kritis. Semua "praktik terbaik" hanyalah alat, dan menggunakannya secara membabi buta hanya akan berbahaya. Bodoh mengikuti sesuatu hanya karena dianggap sebagai "praktik terbaik", tanpa memahami alasan di baliknya. Tetapi dengan pemahaman seperti itu Anda tidak perlu mengikuti "praktik terbaik" Anda. Oleh karena itu, gagasan "praktik terbaik" sangat cacat dan secara inheren berbahaya.
SK-logic
Jawaban:
29
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 ).
Saya pikir ini benar untuk programmer yang lebih mapan, tapi saya pikir mereka hanya membuat sebagian kecil dari mereka yang tidak membuat kode dengan praktik terbaik. Semua kode yang saya lihat yang tidak mengikuti praktik terbaik berasal dari dua jawaban lain di sini - kurangnya waktu dan kenaifan.
AndrewKS
1
@AndrewKS, ini tidak hanya menyangkut pengembang tetapi juga manajer dan klien. Dalam tim dan proses pengembangan yang baik, tenggat waktu realistis dan pengembang tidak diberi tugas di atas kemampuan mereka saat ini - atau setidaknya tidak tanpa bimbingan dan verifikasi yang tepat. Kegagalan dalam hal ini hampir selalu merupakan tanda bahwa manajemen menolak untuk mengadopsi praktik terbaik.
Péter Török
Poin yang sangat bagus - saya tidak memikirkan non-programmer dalam situasi ini sampai sekarang.
AndrewKS
Keengganan seringkali menghasilkan kemalasan tertentu, yang pada akhirnya melahirkan kebodohan.
Anda harus berhati-hati terhadap bikeshedding ! Jangan biarkan mereka terlibat terlalu lama!
shapr
18
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.
Waktu juga sangat besar di sini. Bos saya benar-benar memberi tahu kami dalam rapat staf, "Bisnis tidak membayar untuk pekerjaan yang hebat".
Joshua Smith
@ Joshua Smith: wtf !? Serius? Saya tidak akan terkejut jika mereka mendapatkan apa yang mereka lakukan membayar.
Steven Evers
2
Saya sering melihat pendekatan yang kita tidak mampu melakukannya dengan benar. Tapi, kita bisa menghabiskan waktu tanpa henti untuk memperbaiki kekacauan ini. Untuk perusahaan konsultan yang menagih per jam, pendekatan mana yang terbaik?
BillThor
1
@jwenting: Untuk meletakkan komentar saya sebelumnya dalam konteks, saya menganjurkan tes unit dalam rapat staf. Saat ini, hanya kami berdua yang menulis tes unit (dan kami harus melakukannya diam-diam). Secara pribadi saya tidak menganggap unit test sebagai hiasan emas dan berlian.
Joshua Smith
1
@shapr: Itu adalah hal yang menakutkan untuk didengar dari perusahaan yang membuat ROCKET DAN LEWATKAN. >: P
Mr. JavaScript
11
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.
+1 dan tidak semua pengembang diberikan atau luangkan cukup waktu untuk mempelajari atau menjelajahi cara yang lebih baik. bagi banyak orang (manajemen dan pengembang), itu ditangguhkan sampai menjadi hambatan yang tidak dapat diabaikan. sementara itu, resolusi tidak dibuat secara heuristik cukup sering - itu biasa bagi banyak orang untuk menerima solusi atau rekomendasi yang ada sebagai gantinya. praktik ini melibatkan kesempatan, perkiraan, dan memotong banyak proses pembelajaran, yang sangat penting untuk dipahami. pada gilirannya, tidak memahami (merugikan) memengaruhi kemampuan seseorang untuk membuat pilihan yang lebih baik.
justin
6
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.
Benar bahwa: terutama kombo + bodoh arogan mematikan.
Sklivvz
6
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.
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.)
+1 untuk gagasan bahwa kita dibayar untuk menghasilkan kode terlebih dahulu. Kami memiliki tanggung jawab tambahan untuk (secara subyektif) membuatnya dapat dipertahankan, kedua. Lagi pula - saya tidak membayar tukang kebun ekstra untuk merawat mesin pemotong rumputnya - itu terserah dia untuk mengelola. Jika dia melakukan pekerjaan dengan baik dan perlengkapannya terangkat, saya akan mengundangnya kembali dan memberikan bisnis saya lagi.
Tn. JavaScript
4
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.
Saya belajar pemrograman dalam sesi singkat (2 hingga 3 jam). (Sebenarnya beberapa sesi dengan bahasa yang berbeda.) Selama sesi, kode yang sangat bagus ditunjukkan, dan alasan untuk menulis kode seperti yang dijelaskan. Tidak ada, dari kursus bahasa "resmi" saya yang nyaris memperkenalkan kode yang baik.
BillThor
"perlawanan paling" cukup deskriptif. Pemrogram berpengalaman hanya memiliki ide yang lebih baik tentang apa yang "resistensi paling" selama seluruh masa aplikasi.
4
(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.
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! "
Saya tidak pernah meminta klien untuk mengalokasikan waktu untuk pengujian unit tetapi menganggapnya sebagai bagian dari pekerjaan. Membuat Klien berkomitmen pada pengujian unit hanya mendorong klien Anda untuk mengelola pekerjaan Anda secara mikro. Ketika mobil Anda diperbaiki, mekanik tidak menanyakan alat apa yang harus ia gunakan untuk menyelesaikan pekerjaan !! Hal yang sama berlaku untuk unit test, ANDA harus menilai keseimbangan tes yang tepat yang menurut Anda perlu untuk menyelesaikan pekerjaan dengan benar.
Newtopian
Sayangnya, teknik pemrograman yang lebih baik mungkin lebih cepat daripada teknik yang tidak mampu Anda tingkatkan.
BillThor
2
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.
Jawaban:
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:
DeMarco dan Lister terus menyatakan mantra untuk diingat sebelum meminta orang untuk berubah:
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 ).
sumber
Péter Török benar, tetapi mengabaikan satu poin penting dan optimis:
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 .
sumber
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.
sumber
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.
sumber
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.
sumber
Dua penyebab
Ketidakpedulian.
Arogansi.
Bagaimana mereka dapat diatasi?
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.
sumber
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.
sumber
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.)
sumber
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.
sumber
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 :)
sumber
(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.
sumber
@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! "
sumber
Dua bagian dalam sebagian besar pengalaman saya:
"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.
sumber
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.
sumber
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.
sumber