it-swarm-id.com

Terus terang, apakah Anda lebih suka pengkodean Koboi?

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 Pengodean koboi di Wikipedia

68
Maniero

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

  1. Cowboy coders atau nugget tidak tahu banyak 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, membuat bos terkesan, membuat programmer merasa senang dengan dirinya sendiri dan menegaskan gagasan bahwa dia tahu apa yang dia lakukan (walaupun dia tidak).

  2. Astronot Arsitektur telah menyaksikan kegagalan proyek ball-of-yarn pertama mereka untuk beradaptasi dengan keadaan yang berubah. Semuanya harus ditulis ulang dan untuk mencegah perlunya penulisan ulang lain di kemudian hari, mereka membuat platform dalam, dan akhirnya menghabiskan 4 jam sehari untuk dukungan karena tidak ada orang lain yang mengerti cara menggunakannya dengan benar.

  3. Kuasi-insinyur sering salah mengira untuk aktual , insinyur 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 kontinum dan biasanya dapat menyesuaikan tingkat arsitektur/desain dengan persyaratan proyek.

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

  4. programmer tape duct AKA guru atau konsultan dengan bayaran 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 berada pada level intuitif dan terjadi begitu cepat sehingga pengamat yang tidak terlatih akan salah mengartikannya sebagai pengkodean koboi - dan banyak yang melakukannya .

    Umumnya orang-orang ini semua tentang menciptakan produk yang "cukup baik" dan karya-karya mereka mungkin sedikit kurang direkayasa tetapi mereka mil jauh dari kode spaghetti yang diproduksi oleh koboi koboi . Nugget bahkan tidak dapat mengidentifikasi orang-orang ini ketika mereka diberitahu tentang mereka , karena bagi mereka, segala sesuatu 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 adalah tingkat keterampilan , dan Anda tidak dapat memilih untuk menjadi pembuat kode koboi lagi daripada Anda dapat memilih untuk menjadi buta huruf.

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

Jika Anda telah menjadi astronot arsitektur, Anda tidak mampu secara fisik dan psikologis memproduksi 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 kualitas sama cepatnya.

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 video game. Tidak apa-apa untuk level pemula tetapi siapa saja yang pindah melewati tahap itu tidak akan melakukannya. Mereka mungkin melakukan sesuatu yang terlihat mirip tetapi tidak akan menjadi hal yang sama.

204
Aaronaught

Ya.

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 adalah liburan yang layak, makanan yang dimakan dengan pikiran menuju nutrisi makanan yang tepat, atau tinggal di jalur yang dikenal dengan 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 itu adalah persis apa yang diperlukan 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.

46
Shog9

Anda benar sekali. Pendekatan "pemrograman koboi" ini mungkin mendapatkan revisi pertama dari 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 di 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.

31
Warren Pena

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 membuang sesuatu di sini 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 suatu proyek dan mendapatkan berbagai tingkat pengembang pada 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 dan pengecualian Edge

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

29
Brandon

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


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

Maksud saya, bukan karena dia menggunakan metodologi yang tidak konvensional atau mungkin sudah ketinggalan zaman. Dia hanya secara sadar menggunakan tidak ada. 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 meninggalkan (demi kewarasan Anda).
Tapi kegagalannya sejak awal jauh lebih mungkin dan harus membuktikan pendapat Anda. Dan kemudian dia akan mulai mengikuti praktik terbaik seperti yang dilakukan banyak orang dengan banyak pengalaman.

13
back2dos

Ini sepenuhnya tergantung pada apakah saya bekerja solo, atau dalam tim.

Jika saya bekerja dalam tim, beberapa konvensi dan perjanjian diperlukan - semua orang di tim harus mengikuti beberapa standar yang disepakati bersama untuk bekerja menuju tujuan bersama sehingga upaya mereka kompatibel.

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. Hanya untuk beberapa nama:

  • 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 melakukan 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.

11
Joonas Pulakka

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.

7
Coder

Itu tergantung keadaan. Sebagai contoh, 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.

6
Neil Butterworth

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

5
jojo

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

Seperti yang Anda perhatikan, waktu yang dihemat dalam desain, organisasi, dan kontrol hilang dalam proses debug. Dan seringkali dalam menemukan rilis kode mana yang benar-benar dikirimkan. 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 yang 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 yang buruk dalam diri mereka sendiri, sehingga mereka menciptakan metodologi baru untuk mengatur pengkodean sambil tetap membuatnya lebih berorientasi pada kerajinan, dan kemudian memberi tahu orang lain tentang hal itu - dengan menerbitkan buku (bagaimana lagi yang Anda lakukan saat itu 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!) Lalu 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 seorang penulis yang benar-benar berwawasan. Itu tidak memperbaiki masalah Anda, tetapi itu memberi Anda beberapa wawasan mengapa itu seperti itu dan mungkin beberapa tips untuk mengatasinya secara profesional.

4
gbjbaanb

Saya pikir salah satu komentator melakukannya dengan benar - semua tentang hasilnya.

Jika orang tersebut dapat menghasilkan produk yang baik - sesuatu yang melakukan apa yang seharusnya dilakukan, dan dapat dipertahankan 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, yang bertentangan dengan menghasilkan produk yang baik.

4
GrandmasterB

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

Ketika seseorang dapat melihat masalah dan segera mulai mengeluarkan kode, dengan cepat dan akurat, itu boleh menjadi pertanda seorang insinyur ahli yang telah melihat semuanya ribuan kali sebelumnya dan sudah mengetahui yang terbaik cara untuk memecahkan 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" pasti bukan "profesional" atau bahkan pendekatan 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 sepenuhnya salah, dan harus mengembalikannya? Ini terjadi bahkan pada pengembang yang paling berpengalaman dan berbakat karena persyaratan salah. Jika Anda tidak menjalankan kontrol versi apa pun, Anda hanya akan memutar roda di lumpur. Saya pernah ke sana, sekali, dan akan tidak 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 (note the capital A) tetapi kadang-kadang Anda benar-benar perlu hanya menyingsingkan lengan baju Anda dan mulai menulis kode sialan itu. Saya telah melihat orang dan tim dengan "kelumpuhan analisis" dan produktivitas benar-benar terpukul. Tapi pemberhentian alat dasar perdagangan kami seperti kontrol revisi dan tes benar-benar menentukan bagi saya; orang ini tidak termasuk dalam posisi senior.

3
Aaronaught

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 tertentu), 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 mana, dan optimalkan daftar tim.

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

3
hotpaw2

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 Metodologi Agile , 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.

2
MIA

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.

2
Bill

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 sedang berlangsung. 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 hanya 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 merancang untuk skenario masa depan yang mungkin tidak pernah terjadi. Dengan pengalaman Anda akan merasakan dengan baik bagaimana melakukannya dengan sangat cepat.

1
Eran Galperin

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, lebih menyelesaikan pekerjaan, adalah bahwa saya membantu siapa pun yang menggunakan kode saya untuk menyelesaikan pekerjaan MEREKA. Saya tidak bisa mengatakan bahwa saya selalu mencapai itu - 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.

1
sunwukung

Hanya ketika prototyping fitur yang sangat sederhana.

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

1
Klaim

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, itu 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-pinggul.

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, mis., Ada jauh lebih sedikit kerugian dari kegagalan, sehingga biaya dan beban praktik pengembangan yang ketat dan metodis tidak benar-benar dibenarkan.

1
Randall Schulz

Itu (sangat) tergantung pada ukuran proyek. Di satu sisi, untuk mendapatkan hasil yang layak Anda perlu 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 kaya 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 gagasan 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 hal 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, yang sering bernilai bermanfaat adalah membuat pustaka untuk membuat 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 50+ flagnya yang berbeda, banyak di antaranya berinteraksi dalam 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 diberikannya kepada Anda alih-alih mencoba mendapatkan apa yang Anda inginkan semula.

1
Jerry Coffin

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 disebutkan Neil Butterworth. Dan dalam situasi ini, saya lebih suka memiliki pengembang senior yang berpengalaman menjadi orang yang harus melakukan pengkodean koboi.

0
Bernard Dy

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 sepotong kode yang berbelit-belit 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 menghabiskan banyak uang untuk mencari tahu bahwa satu-satunya pilihan adalah menulis ulang (saya dulu berpikir bahwa 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 sudah menemukannya ketika datang untuk membangun perangkat lunak. Itu salah satu hal yang membuatnya menjadi bidang yang menarik ...

0
Aaron Anodide

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

0

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 untuk "menyelesaikan sesuatu" karena tekanan dari bos, dll Saya tahu saya telah melewati jalan ini beberapa kali karena saya kurang memiliki 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 keterampilan mereka sebagai pengembang perangkat lunak, sepertinya bukan seseorang yang ingin saya ajak bekerja sama.

0
programmx10

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.

0
CesarGon