Terus terang, apakah Anda lebih suka pengkodean Koboi? [Tutup]

Kebanyakan programmer membela metodologi yang secara politis benar seperti Agile, Waterfall, RUP, dll. Beberapa dari mereka mengikuti metodologi tetapi tidak semuanya. Terus terang, jika Anda dapat memilih metodologi, Anda tentu akan pergi ke arus utama metodologi "benar" atau Anda lebih suka metodologi "lebih mudah" seperti pemrograman koboi? Mengapa?

Saya tahu itu tergantung. Tolong, jelaskan kapan Anda akan menggunakan satu atau yang lain. Tolong, katakan apa keuntungan yang Anda lihat pada pengkodean Koboi.

Lihat tentang pengkodean Koboi di Wikipedia

Saya pikir hampir setiap programmer berpengalaman telah melalui tiga tahap dan beberapa melewati empat:

1. Coder atau nugget koboi tidak tahu apa-apa tentang desain dan melihatnya sebagai formalitas yang tidak perlu. Jika bekerja pada proyek-proyek kecil untuk pemangku kepentingan non-teknis, sikap ini mungkin bermanfaat bagi mereka untuk sementara waktu; Gets Things Done, itu mengesankan bos, membuat programmer merasa baik tentang dirinya sendiri dan menegaskan gagasan bahwa dia tahu apa yang dia lakukan (walaupun dia tidak).

2. Arsitektur Astronot telah menyaksikan kegagalan proyek ball-of-yarn pertama mereka untuk beradaptasi dengan keadaan yang berubah. Semuanya harus ditulis ulang dan untuk mencegah kebutuhan untuk lain menulis ulang di masa depan, mereka menciptakan platform batin , dan akhirnya menghabiskan 4 jam sehari pada dukungan karena tidak ada orang lain mengerti bagaimana menggunakannya dengan benar.

3. Kuasi-insinyur sering mengira diri mereka sebagai insinyur yang sebenarnya dan terlatih karena mereka benar-benar kompeten dan memahami beberapa prinsip rekayasa. Mereka sadar akan konsep rekayasa dan bisnis yang mendasar: Risiko, ROI, UX, kinerja, rawatan, dan sebagainya. Orang-orang ini melihat desain dan dokumentasi sebagai sebuah kontinum dan biasanya dapat menyesuaikan tingkat arsitektur / desain dengan persyaratan proyek.

   Pada titik ini, banyak yang jatuh cinta pada metodologi, apakah itu Agile, Waterfall, RUP, dll. Mereka mulai percaya pada infalibilitas absolut dan bahkan kebutuhan metodologi ini tanpa menyadari bahwa dalam bidang rekayasa perangkat lunak yang sebenarnya , mereka hanyalah alat , bukan agama. Dan sayangnya, itu mencegah mereka untuk tidak pernah sampai ke tahap akhir, yaitu:

4. Pemrogram lakban, guru AKAatau konsultan bergaji tinggi tahu arsitektur dan desain apa yang akan mereka gunakan dalam lima menit setelah mendengar persyaratan proyek. Semua pekerjaan arsitektur dan desain masih terjadi, tetapi pada tingkat intuitif dan terjadi begitu cepat sehingga pengamat yang tidak terlatih akan salah mengartikannya sebagai pengkodean koboi - dan banyak yang melakukannya .

   Umumnya orang-orang ini adalah semua tentang menciptakan sebuah produk yang "cukup baik" dan karya-karya mereka mungkin sedikit di bawah-direkayasa tetapi mereka mil jauhnya dari kode spaghetti diproduksi oleh coders koboi. Nugget bahkan tidak dapat mengidentifikasi orang-orang ini ketika mereka diberitahu tentang mereka , karena bagi mereka, semua yang terjadi di latar belakang tidak ada.

Beberapa dari Anda mungkin akan berpikir sendiri pada saat ini bahwa saya belum menjawab pertanyaan itu. Itu karena pertanyaannya sendiri cacat. Pengodean koboi bukanlah pilihan , ini tingkat keahlian , dan Anda tidak dapat memilih untuk menjadi koboi koboi lebih dari yang bisa Anda pilih untuk menjadi buta huruf.

Jika Anda seorang pembuat kode koboi, maka Anda tidak tahu cara lain.

Jika Anda telah menjadi astronot arsitektur, Anda secara fisik dan psikologis tidak mampu menghasilkan perangkat lunak tanpa desain.

Jika Anda adalah seorang insinyur semu (atau insinyur profesional), maka menyelesaikan proyek dengan sedikit atau tanpa upaya desain di muka adalah pilihan sadar (biasanya karena tenggat waktu yang absurd) yang harus ditimbang dengan risiko yang jelas, dan dilakukan hanya setelah para pemangku kepentingan menyetujui mereka (biasanya secara tertulis).

Dan jika Anda adalah programmer lakban, maka tidak pernah ada alasan untuk "kode koboi" karena Anda dapat membangun produk yang berkualitas dengan cepat.

Tidak ada yang "lebih suka" pengkodean koboi daripada metodologi lain karena itu bukan metodologi. Ini adalah pengembangan perangkat lunak yang setara dengan tombol tumbuk dalam gim video. Tidak apa-apa untuk level pemula tetapi siapa pun yang pindah melewati tahap itu tidak akan melakukannya. Mereka mungkin melakukan sesuatu yang terlihat mirip tetapi itu tidak akan menjadi hal yang sama.

Iya.

Saya juga lebih suka meninggalkan kaus kaki saya di lantai di mana saya melepasnya, meja saya penuh dengan cetakan dan bungkus makanan ringan, wastafel saya penuh dengan piring kotor, dan tempat tidur saya belum dirapikan.

Saya tidak menganggap liburan yang direncanakan sebelumnya sebagai liburan yang layak, makanan yang dimakan dengan pikiran menuju nutrisi makanan yang tepat, atau tinggal di jalur yang dikenal sebagai hiking yang tepat.

Saya suka bersenang-senang, terkejut, belajar hal-hal baru, membuat kesalahan, dan tidak pernah yakin apakah saya akan berhasil kembali. Dan kadang-kadang, sikap itulah yang dibutuhkan untuk mendapatkan proyek dari awal ...

... tetapi sebagian besar waktu, itu hanya tidak bertanggung jawab. Ketika tarian berakhir, piper akan dibayar ... Lupakan ini dengan risiko Anda.

Anda benar sekali. Pendekatan "pemrograman koboi" ini dapat membuat revisi pertama kode lebih cepat, tetapi penghematan waktu akan lebih dari hilang berkat:

• Bug tambahan
• Lagi pula, diperlukan waktu tambahan untuk menemukan bug yang Anda miliki
• Harus merekayasa ulang kode Anda untuk mengingat apa yang Anda lakukan ketika Anda perlu melakukan perubahan dalam enam bulan
• Waktu ekstra dihabiskan untuk melatih pengembang tambahan yang perlu mengerjakan kode Anda
• Tidak memiliki log revisi untuk melihat kembali ketika Anda membuat perubahan yang merusak sesuatu
• Tidak memiliki modul Anda dapat dengan mudah digunakan kembali dalam proyek-proyek selanjutnya
• Dan terus dan terus dan terus

Seperti Neil Butterworth yang disebutkan dalam jawabannya, terkadang Anda harus melakukan apa yang harus Anda lakukan. Sebagai praktik umum, tidak, membanting kode secepat mungkin tanpa menghabiskan waktu untuk kontrol kode sumber, pola, dokumentasi, dll. Adalah kebiasaan yang sangat buruk untuk diterima.

Baik bagi Anda untuk menganalisis rekan kerja Anda dan mempertimbangkan apakah kebiasaan mereka bermanfaat atau berbahaya daripada melakukan secara membabi buta seperti yang mereka lakukan.

Ini benar-benar bermuara pada pertanyaan apakah Anda dapat menerapkan hal-hal dengan benar tanpa struktur yang ketat di tempat dan banyak waktu yang dihabiskan dalam perencanaan.

Saya akan melemparkan sesuatu di sini pada yang ini mungkin benar-benar tidak populer: pelanggan umumnya ingin hal-hal ditangani dengan cara koboi .

Yaitu, mereka ingin meminta sesuatu diselesaikan, dan meminta seseorang melompatinya, melaksanakannya, dan menyelesaikannya di sana. Tidak ada manajemen proyek, rapat, panggilan konferensi, atau formulir. Lakukan saja. Saya tidak pernah memiliki pelanggan yang mengatakan "hei, ini dilakukan agak terlalu cepat untuk selera kita, kami akan sangat menghargai jika Anda akan menaruh sedikit air terjun atau sesuatu di sana nanti".

Metodologi dan struktur tim dirancang untuk meratakan lapangan permainan proyek dan mendapatkan berbagai tingkat pengembang di halaman yang sama, bekerja untuk tujuan yang sama, dengan cara yang sama.

"Koboi" yang berhasil yang telah bekerja sama dengan saya dapat:

• Identifikasi cara paling sederhana untuk mengimplementasikan sesuatu dengan cepat
• Ketahuilah pada titik mana itu akan pecah
• Tulis kode yang bersih, mudah dibaca, dan langsung
• Prediksi bagaimana pengguna akan menggunakannya, menyalahgunakannya, dan menghancurkannya
• Skala itu / abstraksi di tempat yang tepat, dan tidak pergi arsitektur astronot di atasnya
• Ketahui di mana dan bagaimana menangani kasus tepi dan pengecualian

Orang-orang seperti ini menghasilkan hasil yang sangat bagus dengan manajemen dan struktur overhead yang sangat sedikit, tetapi mereka jarang.

EDIT: Untuk referensi di masa mendatang, jawaban saya adalah untuk pertanyaan lain , yang telah digabung menjadi pertanyaan ini. Cukup tidak pada tempatnya di sini, tapi itu bukan panggilan saya.

Dia hanya malas, sombong, bodoh dan sangat egois. Perilaku ini sembrono.

Maksudku, bukan karena dia menggunakan metodologi yang tidak konvensional atau mungkin sudah ketinggalan zaman. Dia secara sadar tidak menggunakan satu pun . Tidak ada standar. Tidak ada jaminan kualitas. Tidak apa pun. Dari mana dia mengharapkan kualitas perangkat lunak akan datang? Pohon?
Lucu dia benar-benar menyangkal pengalaman orang-orang yang Anda kutip, padahal dia jelas tidak memiliki pengalaman itu. Memberikan argumen yang dapat diverifikasi dan relevan untuk mempertanyakan klaim mereka valid. Tetapi hanya mencoba untuk mendiskreditkan mereka dengan menyangkal pengalaman mereka tidak.

Tapi, intinya adalah: Berapa lama waktu yang dibutuhkan kontrol versi?
Jika dia tidak dapat diyakinkan untuk menginvestasikan 5 detik setiap sekarang dan kemudian, Anda harus membawanya ke bosnya. Kontrol versi bukan opsional. Titik.

Dan begitu Anda memilikinya menggunakan kontrol versi, Anda dapat dengan mudah melacak bug yang dia perkenalkan. Dan biarkan dia memperbaikinya. Ini kekacauannya, mengapa Anda harus membersihkannya? Jika dia berpikir pendekatannya lebih baik, maka biarkan dia melakukannya - sepanjang jalan .
Dengan asumsi dia benar-benar dapat melakukannya (dalam waktu yang wajar), Anda masih memiliki masalah: kerja tim dengannya hampir mustahil. Dan ini adalah sesuatu yang harus Anda pecahkan dengan meyakinkannya (yang kedengarannya tidak mungkin), membuatnya pergi (demi perusahaan Anda) atau pergi (demi kewarasan Anda).
Tetapi kegagalannya sejak awal jauh lebih mungkin dan harus membuktikan maksud Anda. Dan kemudian dia akan mulai mengikuti praktik terbaik seperti yang dilakukan banyak orang dengan banyak pengalaman.

Itu sepenuhnya tergantung pada apakah saya bekerja sendiri, atau dalam sebuah tim.

Jika saya bekerja dalam sebuah tim, beberapa konvensi dan perjanjian diperlukan - setiap orang dalam tim harus mengikuti beberapa standar yang disepakati bersama untuk mencapai tujuan bersama sehingga upaya mereka sesuai.

Tetapi jika saya bekerja sendirian, maka tentu saja saya ingin menjadi seorang koboi. Semua kreasi besar di dunia telah diciptakan oleh satu pikiran, atau paling banyak dua, bekerja dengan gaya koboi. Untuk beberapa nama saja:

• Mekanika klasik? Koboi Isaac Newton, tambahan selanjutnya dari Leibniz, Lagrange, Hamilton.
• Pesawat terbang? Koboi Wright.
• Teori relativitas? Koboi Albert Einstein.
• Ilmu komputer yang mendasar? Koboi Alan Turing.
• Transistor? Koboi Walter Brattain dan John Bardeen.

Tim pandai membuat peningkatan bertahap dan menyusun sistem baru berdasarkan resep yang terbukti cukup cepat (asalkan mereka dipimpin dengan baik), tetapi jarang mendengar tentang penemuan aktual yang dibuat oleh tim. Kerja tim dan metode yang dibutuhkan memiliki sifat mereka, tetapi begitu juga pengkodean koboi.

Tergantung pada masalahnya. Pengembang senior yang baik akan menulis kode yang sangat ringkas, sederhana, dan kuat yang sangat stabil dan menggunakan semua praktik terbaik tanpa harus menelusuri halaman dokumentasi dan banyak pola serta paradigma yang berbeda. Tetapi dia juga akan tahu kapan dia mampu melakukan hal-hal seperti itu.

Saya akan terkejut jika dia akan mengambil masalah baru dan mulai merancang aplikasi yang membutuhkan beberapa bulan dari awal. Tetapi jika itu sebuah plugin, alat sederhana yang dapat Anda tulis dalam 2 jam, sebuah fungsi yang melakukan konversi dan tidak dimaksudkan untuk digunakan kembali, desain dan pola sebenarnya hanya baik untuk membuang-buang waktu.

Juga, saya kira sebagian besar desain sudah diproses di latar belakang di suatu tempat di dalam kepala pengembang senior.

Anda harus mulai khawatir ketika pengembang senior mulai mengaduk kelas sistem yang kompleks, atau aplikasi baru dari awal, dan tanpa langkah perencanaan.

Itu tergantung keadaan. Misalnya, setelah beberapa skandal perdagangan yang merusak, beberapa bursa saham elektronik bersikeras bahwa bendera perdagangan otomatis ditambahkan ke semua perdagangan. Dan ini harus untuk semua perangkat lunak perdagangan dalam seminggu. Maksud saya itu harus dilakukan - jika bendera tidak ada di sana Anda tidak bisa berdagang. Dalam keadaan seperti itu, semua praktik baik dilakukan oleh dewan - Anda hanya perlu (seperti yang biasa kita katakan) "hacky, hacky, hacky". Dan dalam keadaan itu, menulis kode dengan cepat dan akurat adalah kuncinya. Terutama karena tidak ada sistem uji yang tersedia.

Dari pengalaman saya, cow boy coding DENGAN kontrol sumber adalah cara terbaik dan paling bebas bug untuk mengembangkan sistem perangkat lunak besar.

Saya pikir salah satu komentator sudah benar - semua tentang hasilnya.

Jika orang tersebut dapat menghasilkan produk yang baik - sesuatu yang melakukan apa yang seharusnya dilakukan, dan dapat dipelihara dan dapat diandalkan - lalu apa bedanya jika metodologi atau proses formal diikuti? Proses sangat bagus untuk memastikan lantai dalam kualitas, tetapi jika seseorang sudah bekerja di atas lantai itu, maka proses tidak menambahkan apa pun ke dalam persamaan. Terlalu banyak pengembang hari ini, imo, tampaknya berpikir titik pemrograman adalah untuk mematuhi proses, sebagai lawan menghasilkan produk yang baik.

Orang seperti ini disebut peretas, dan biasanya bukan istilah gratis dari yang lebih profesional di antara kita.

Seperti yang Anda perhatikan, waktu yang disimpan dalam desain, organisasi, dan kontrol hilang dalam proses debug. Dan seringkali dalam menemukan rilis kode mana yang sebenarnya dikirim. Jika Anda dapat menemukannya sama sekali!

Saya menemukan orang semacam ini terlalu sibuk dengan diri mereka sendiri, berpikir mereka terlalu baik untuk bekerja dengan 'keterbatasan' yang harus diderita orang lain, jadi jangan repot-repot dengan mereka, dan itu bahkan kehilangan lebih banyak waktu dibandingkan yang lain. Tim harus membersihkan setelah mereka. Mereka juga tidak terlalu terlibat dalam proses perbaikan bug (itu adalah tugas pengembang pemeliharaan, jauh di bawah keterampilan dan bakat pembuat kode 'l33t).

Jadi, itu mungkin pendekatan umum di tempat lain, tetapi di tempat saya (dan saya seorang pembuat kode senior yang memiliki kecenderungan untuk pendekatan ini, ahem) kita tidak menderita itu. Bukannya kami menuntut banyak proses dan prosedur, tetapi kami bersikeras pada jumlah minimal organisasi, kontrol kode sumber (yang sejujurnya berdarah timur dan sangat berguna!)

Kent Beck et al, adalah semua profesional yang melihat cara lama yang sarat dengan proses itu buruk dalam diri mereka sendiri, sehingga mereka menciptakan metodologi baru untuk mengatur pengkodean sambil tetap menjaganya agar lebih berorientasi pada kerajinan, dan kemudian memberi tahu orang lain tentang hal itu - dengan menerbitkan buku ( bagaimana lagi yang Anda lakukan sebelum Internet?)

Anda kedengarannya benar - jangan menerima latihan yang buruk hanya karena orang lain tidak dapat meretasnya. Pimpinan atau manajer tim Anda harus bersikap keras pada 'rockstar' ini, tetapi jika mereka tidak .. yah, itu masih tidak menghalangi Anda untuk melakukan hal yang benar. Hanya saja, jangan menerima latihan buruk darinya, jika dia mengacaukan (dan dia akan!) Kemudian biarkan dia membersihkannya. Anda berpegang teguh pada praktik yang baik (dan Anda tahu apa itu) tanpa membiarkannya mengambil alih sehingga merusak produktivitas pengkodean Anda, dan Anda akan baik untuk masa depan.

Inilah esai dari penulis yang benar-benar berwawasan luas. Itu tidak memperbaiki masalah Anda, tetapi itu memberi Anda beberapa wawasan tentang mengapa itu seperti itu dan mungkin beberapa tips untuk menghadapinya secara profesional.

Satu-satunya fakta penting adalah hasil produk jangka panjang tim.

Ada klaim bahwa sebuah tim termasuk satu programmer hebat (atau lebih) akan menghasilkan hasil yang lebih baik daripada tim dengan jumlah programmer rata-rata yang lebih besar pada tingkat rata-rata.

Jika koboi menghasilkan barang-barang yang tidak diprogram oleh programmer biasa (untuk tenggat waktu atau spesifikasi yang diberikan), dan tim dengan koboi bahkan harus menghabiskan beberapa minggu pria / bulan membersihkan kekacauan koboi, mereka mungkin masih berakhir dengan hasil yang lebih baik lebih cepat.

Jika tim dengan koboi tidak dapat membersihkan (mendokumentasikan, men-debug, mengintegrasikan, memelihara) kekacauan bahkan setelah beberapa bulan manusia / tahun, maka kemajuan apa pun yang diciptakan koboi tidak memberi tim keuntungan jangka panjang.

Putuskan yang mana, dan optimalkan daftar tim.

Tidak setiap programmer bekerja (atau seharusnya bekerja) dengan cara yang sama, selama hasil akhirnya baik.

Anda mungkin menemukan beberapa wawasan dalam jawaban saya untuk Frankly, apakah Anda lebih suka pengkodean koboi? Masalahnya adalah, "pengkodean koboi" memiliki arti yang berbeda bagi orang yang berbeda, dan tidak segera jelas, bagi mata yang tidak terlatih, versi mana yang Anda lihat.

Ketika seseorang dapat melihat suatu masalah dan segera mulai mengeluarkan kode, dengan cepat dan akurat, itu mungkin merupakan pertanda dari seorang insinyur ahli yang telah melihatnya ribuan kali sebelumnya dan sudah tahu cara terbaik untuk menyelesaikan masalah.

Atau, itu mungkin merupakan tanda peringkat amatir.

Saya akan memberi tahu Anda satu hal: Menolak untuk menggunakan kontrol versi atau menulis tes karena terlalu "akademis" jelas bukan pendekatan "senior" atau bahkan profesional jarak jauh. Anda tidak akan pernah melihat hal seperti ini dilakukan di toko perangkat lunak besar seperti Microsoft atau Google, dan mungkin tidak akan melihatnya di sebagian besar startup atau tim perusahaan yang cukup matang juga.

Risikonya terlalu besar. Bagaimana jika PC Anda mati dalam semalam? Sampai jumpa 3 tahun produktivitas. Oke, jadi Anda membuat backup; lalu apa yang terjadi ketika Anda membuat perubahan besar, menyadari bahwa itu benar-benar salah, dan harus mengembalikannya? Ini terjadi bahkan untuk pengembang yang paling berpengalaman dan berbakat karena persyaratannya salah. Jika Anda tidak menjalankan kontrol versi apa pun, Anda hanya akan memutar roda di lumpur. Saya pernah ke sana, sekali, dan tidak akan pernah kembali.

Tidak ada alasan - dibutuhkan 10 menit untuk menyiapkan repositori dan 10 detik untuk melakukan komit. Itu mungkin membuat 1% dari total waktu pengembangan Anda. Tes, jika Anda sedang terburu-buru, dapat dengan mudah dipangkas menjadi 20-30 menit sehari dan masih cukup berguna.

Saya bukan penggemar metodologi Agile (perhatikan ibukota A), tetapi kadang-kadang Anda benar-benar perlu hanya menyingsingkan lengan baju Anda dan mulai menulis kode sial. Saya telah melihat orang dan tim dengan "kelumpuhan analisis" dan produktivitas benar-benar terpukul. Tetapi pemberhentian alat dasar perdagangan kami seperti kontrol revisi dan tes benar-benar menentukan bagi saya; orang ini tidak termasuk dalam posisi senior.

Ya, tetapi Anda harus mengenali kapan TIDAK melakukannya.

Pada hal-hal kecil Anda mungkin baik-baik saja, tetapi jika Anda memiliki sesuatu yang kompleks, berbahaya, terbatas, dll, Anda harus dapat mengenali kapan desain yang tepat sepadan dengan waktu tambahan.

Saya juga berpikir Anda harus memikirkan jawaban Aaronaught. Koboi memiliki arti yang berbeda bagi orang yang berbeda.

Ketika saya memikirkan metodologi "tradisional", saya pikir "manajemen tidak tahu bagaimana memahami pengembang, jadi alih-alih datang ke dunia pengembang dan cukup memahami untuk mengetahui apa yang terjadi, mereka membuat pengembang datang ke dunia mereka".

Pada dasarnya, ketika saya memikirkan "Agile", saya pikir "Anda melakukan apa yang perlu Anda lakukan untuk meminimalkan inefisiensi yang diperkenalkan oleh banyak orang yang bekerja bersama." Jadi saya tegas di kamp bahwa "tidak ada yang namanya THE Agile Methodology , hanya seperangkat nilai dan prinsip".

Dengan kata lain, ada hal-hal yang perlu Anda lakukan pada proyek yang sangat besar, dan ada hal-hal yang perlu Anda lakukan pada proyek kecil, dan ada hal-hal yang Anda lakukan pada keduanya.

Sebagai contoh, saya tidak akan memiliki lebih dari simpanan paling sederhana untuk proyek yang sedang saya kerjakan sendiri ... Itu hanya akan menjadi daftar tugas. Jika ada dua dari kita, saya mungkin memiliki daftar itu dibagikan, tetapi dalam format yang sangat sederhana (mungkin hanya catatan yang disimpan dalam repositori kode kita). Setelah saya memiliki 3 atau 4, saya mencari semacam sistem item kerja.

Hanya ketika prototyping fitur yang sangat sederhana.

Kemudian setelah selesai dan mempertimbangkan cara yang benar, saya membuang kode dan menjadi serius.

Saya pernah melakukannya pada sebuah proyek nyata (pada saat itu kami menyebutnya Pemrograman Samurai, setelah serangkaian sketsa Samurai pada Saturday Night Live), dan banyak yang membuat saya takjub, ternyata berhasil dengan baik. Tentu saja, yang saya mulai adalah sampah, jadi ada sedikit risiko memperburuknya.

Namun, saya seorang "rapi" di hati dan tidak suka gaya pengembangan dari awal.

Di sisi lain, modus operandi yang sarat dengan proses juga tidak sesuai dengan selera saya. Saya hanya ingin merencanakan sebelum bertindak.

Secara keseluruhan, saya merasa bahwa jumlah proses formal yang sesuai sangat tergantung pada besarnya (ukuran kode, durasi proyek, jumlah pengembang, jenis persyaratan, dll.) Proyek. Saya ingin kriteria yang ketat dan ketat diterapkan pada orang yang mengembangkan perangkat lunak untuk avionik atau peralatan biomedis, mis. Untuk game, misalnya, ada jauh lebih sedikit kerugian dari kegagalan, sehingga biaya dan beban praktik pengembangan yang ketat dan metodis tidak benar-benar dibenarkan.

Itu (sangat) tergantung pada ukuran proyek. Di satu sisi, untuk mendapatkan hasil yang layak Anda harus memiliki desain. Di sisi lain, jika proyek tersebut cukup kecil sehingga Anda dapat membuat konsep seluruh desain (sebagian besar memang demikian) tanpa menuliskannya, menggambar diagram, dll., Maka Anda mungkin cukup beruntung tanpa kerja ekstra dari mendokumentasikan semua yang Anda lakukan.

Hampir setiap orang telah mendengar cukup banyak cerita horor untuk menyadari bahwa mencoba untuk melompat tanpa ide yang jelas tentang apa yang Anda lakukan dan ke mana hal-hal terjadi adalah resep untuk bencana. Apa yang jauh lebih jarang ditunjukkan adalah bahwa yang sebaliknya bisa menjadi bencana. Sebagai contoh, kebanyakan dari kita secara rutin menulis alat kecil dalam proses pemrograman. Menulis spesifikasi lengkap, tes, dokumentasi seringkali tidak bermanfaat. Ada ambang di bawah di mana produksi tidak bernilai - orang sering tidak suka menciptakan kembali roda, tetapi dalam beberapa kasus lebih mudah untuk diciptakan kembali daripada menghindarinya.

Dalam kasus seperti ini, apa yang sering adalah berharga adalah productizing perpustakaan untuk membuat tugas-tugas seperti ini mudah. Dengan itu, kode front-end sering menjadi sangat sepele sehingga menulis (atau memodifikasi) kode untuk melakukan apa yang Anda inginkan menjadi lebih mudah daripada memilah-milah cara mendapatkan program lengkap untuk melakukan apa yang Anda inginkan. Pertimbangkan, misalnya, gnu indent dengan lebih dari 50 flag yang berbeda, banyak yang berinteraksi dengan berbagai cara yang halus, jadi tentang satu-satunya pilihan yang masuk akal adalah 1) tidak menggunakannya sama sekali, atau 2) memutuskan untuk menyukai apa yang memberi Anda alih-alih mencoba mendapatkan apa yang Anda inginkan semula.

Tampaknya ada dua kubu - mereka yang mendukung hasil, dan mereka yang mendukung prinsip. Saya jatuh ke yang terakhir.

Saya seorang programmer yang biasa-biasa saja tetapi bisa dibilang teliti - perhatian utama saya ketika coding, di luar menyelesaikan pekerjaan, adalah bahwa saya membantu siapa pun yang menggunakan kode saya untuk menyelesaikan pekerjaan MEREKA. Saya tidak bisa mengatakan bahwa saya selalu mencapainya - tetapi itulah yang ingin saya lakukan.

Tentu, Anda mungkin memiliki hotrod di tim Anda - tetapi apa yang terjadi ketika mereka mengambil cuti beberapa minggu dan Anda diminta untuk men-debug pekerjaan mereka, atau menambahkan barang ke sana? Pada akhirnya, pemrogram koboi bukanlah pemain tim. Mereka mungkin membuat kode yang bagus, tetapi jika tim bergantung pada mereka - maka itu berbahaya.

Saya merasa bahwa ketidaksukaan Anda terhadap gayanya menyebabkan Anda sedikit salah mengartikannya. Anda mengatakan pendekatan koboi dibayar dalam debugging - apakah ini yang sudah terjadi, atau apakah asumsi Anda tentang bagaimana hal itu akan terjadi?

Pengungkapan yang adil - saya sendiri adalah pengembang senior, dan saya sering melupakan proses formal untuk desain dan pengalaman yang berkelanjutan. Tidak memiliki proses formal untuk seseorang yang sangat berpengalaman dalam domain masalah cukup umum. Jika Anda telah menyelesaikan banyak masalah, Anda tidak perlu proses formal untuk merumuskan solusi serupa lagi.

Proses formal berkaitan dengan desain kode - Saya tidak melihat mengapa lebih banyak bug harus diperkenalkan karena proses formal tidak ada. Satu-satunya masalah besar yang saya baca di akun Anda adalah bahwa kontrol revisi tidak sedang digunakan - yang tidak hanya egois, tetapi benar-benar sembrono atas nama pengembang. Apakah dia sebenarnya tidak melakukan sama sekali, atau tidak melakukan dalam pola yang sesuai dengan keinginan Anda?

Tidak memiliki pendekatan formal untuk mendesain bukanlah 'pengkodean koboi' dalam buku saya (meskipun tidak menggunakan kontrol revisi). Pengalaman harus digunakan untuk hal itu - untuk mengurangi waktu yang dibutuhkan untuk menghasilkan solusi 'cukup baik'. Ingat, Anda harus menyelesaikan masalah yang Anda miliki saat ini dan membuat kode mudah diubah, bukan desain untuk skenario masa depan yang mungkin tidak pernah terjadi. Dengan pengalaman Anda akan merasakan dengan baik bagaimana melakukannya dengan sangat cepat.

Tidak, tidak pernah.

Saya selalu melakukan analisis persyaratan, berpikir tentang arsitektur, mendesain detail, dan kemudian kode. Bahkan jika saya bekerja sendirian di rumah untuk proyek pribadi.

Dan saya akan langsung memecat pengembang di tim saya jika dia bekerja dengan gaya koboi. Kami adalah insinyur dan memiliki tanggung jawab dengan pelanggan dan pengguna.

Saya tidak berpikir pengkodean koboi adalah pendekatan senior.

Seperti yang orang lain katakan, ada bahaya nyata dalam membuang kontrol versi. Melewatkan dokumentasi dan analisis juga bisa berarti mempertaruhkan pengiriman sesuatu yang tidak diinginkan pengguna. Hanya pendapat saya, tapi saya tidak berpikir Anda beralih dari "coder ke pengembang" jika semua yang Anda lakukan adalah kode koboi.

Namun, ya, ada pengecualian seperti yang Neil Butterworth sebutkan. Dan dalam situasi ini, saya lebih suka memiliki pengembang senior yang berpengalaman yang harus melakukan pengkodean koboi.

Pemrograman koboi adalah cara yang agak pasti untuk menciptakan bola lumpur yang besar . Yang, tidak menyenangkan seperti kedengarannya, cenderung memberikan ...

Saya pikir programmer yang lebih baru cenderung melakukan beberapa hal pengkodean koboi ketika mengambil aspek proyek / lingkup yang mereka mungkin tidak memiliki banyak pengalaman dengan atau ketika mereka mencoba "menyelesaikan sesuatu" karena tekanan dari bos, dll Saya tahu saya sudah melewati jalan ini beberapa kali karena saya kurang pengetahuan tentang pola yang tepat untuk digunakan dan hanya "meretas jalan saya untuk melewatinya".

Perbedaan antara saya dan orang yang Anda keluhkan adalah bahwa saya biasanya segera setelah menyadari bahwa saya bisa melakukannya dengan lebih baik dan membuatnya lebih dapat dipertahankan dan biasanya memacu saya untuk belajar lebih banyak dan meningkatkan keterampilan saya (dengan membaca buku / artikel tentang subyek). Ketika saya kembali untuk men-debug beberapa solusi yang diretas ini, saya biasanya merasa sakit dan memberikan kontribusi lebih pada keinginan saya untuk belajar bagaimana melakukannya dengan "cara yang benar". Saya pikir orang yang Anda gambarkan ini pada dasarnya terjebak pada tingkat refleksi diri yang kekanak-kanakan dan membiarkan ego mereka sendiri menghalangi peningkatan kemampuan mereka sebagai pengembang perangkat lunak, sepertinya bukan seseorang yang ingin saya ajak bekerja sama.

Saya menemukan posting Anda menarik. Saya sering berbagi pandangan dengan subjek Anda, dan perasaannya adalah bahwa metode yang terlalu formal itu menyesakkan. Seperti yang dicatat orang lain, jika dia jenius dan dapat melacak banyak catatan mental pada saat yang sama tanpa lupa atau bingung, maka sangat mungkin untuk mempertahankan potongan kode berbelit-belit monolitik dan membuatnya melakukan hal-hal menakjubkan dengan perubahan yang benar-benar tidak jelas. . Ada kebahagiaan mental tertentu yang datang ke otak orang-orang yang bisa melakukan itu - itu seperti menjadi dewa alam semesta kecil dalam pikiran Anda.

Namun, pengusaha yang cerdas telah belajar dengan cara yang sulit bahwa tidak seorang pun selain penulis asli yang dapat melakukan apa pun yang bermanfaat untuk kode itu. Jika programmer melanjutkan, mereka akhirnya membuang banyak uang dengan mencari tahu bahwa satu-satunya pilihan adalah menulis ulang (saya dulu berpikir itu berarti kerugian total, tetapi saya menyadari hari ini bahwa Anda tidak menghancurkan hasil intrinsik dari pengembangan berulang pada tingkat fungsionalitas eksternal).

Secara pribadi, saya tidak akan keberatan memiliki seseorang seperti itu di tim, karena dalam krisis, mereka mungkin melakukan sesuatu yang tidak dipikirkan orang lain.

Di sisi lain, jadilah orang Anda sendiri dan tentukan sendiri apa jawaban untuk pertanyaan Anda, karena satu-satunya hal yang pasti adalah tidak ada yang tahu kapan harus membangun perangkat lunak. Itu salah satu hal yang membuatnya menjadi bidang yang menarik ...