Bagaimana Anda mentransisikan suatu program dari pengembangan ke rilis?


67

Pada titik tertentu program sedang dalam pengembangan. Fitur sedang ditambahkan atau dihapus atau diubah sepanjang waktu. Setiap versi hanyalah prototipe. Jadi saya tidak membuang banyak waktu untuk menulis kode super bersih pada saat itu karena saya tidak pernah tahu berapa lama sesuatu berlangsung. Tentu saja saya mencoba untuk menjaga kualitas kode ke standar tertentu, tetapi waktu selalu menjadi masalah.

Kemudian tibalah titik di mana program selesai dan pembuat keputusan mengatakan "itu saja". Saya memang memiliki prototipe yang berfungsi pada saat ini, tetapi kode di dalamnya agak berantakan dari semua bolak-balik selama fase pengembangan. Saya diharapkan untuk memulai pengujian / debugging akhir tetapi nyali saya mengatakan bahwa saya sekarang harus entah bagaimana membersihkan dan atau menulis ulang hal-hal untuk memberikan arsitektur yang tepat yang membuat pemeliharaan dll lebih mudah.

Setelah barang diuji dan disetujui, tidak masuk akal untuk menulis ulang. Secara teratur saya berdiri di sana dengan prototipe 'selesai' yang berfungsi dan saya mendapatkan bug selama pengujian dan saya melihat bahwa itu adalah hasil dari pengkodean yang tidak cerdas yang merupakan hasil dari seluruh proses pengembangan. Saya di tengah pengujian dan perbaikan bug akan menjadi penulisan ulang ... itu berantakan!

Ada cara yang lebih baik / buku teks, saya yakin. Tetapi saya harus bekerja di lingkungan kerja nyata di mana tidak semua buku teks.

Jadi bagaimana cara mentransisikan prototipe kerja saya ke versi rilis dengan basis kode yang stabil? Mungkin saya seharusnya tidak menganggap pengembangan selesai begitu saya lakukan dan benar-benar melihatnya sebagai fase pembersihan ... Saya tidak tahu, saya butuh bantuan di sini.

SUNTING

Saya ingin mengklarifikasi beberapa hal.

  • Saya 100% di sisi melakukannya tepat sebelum dan tidak setelah, kode bersih dan mudah dibaca. Tetapi saya juga harus menyelesaikan sesuatu dan tidak bisa bermimpi tentang keindahan kode semua bersih dan mengkilap. Saya harus mencari kompromi.

  • Seringkali fitur baru benar-benar hanya sesuatu yang ingin kita coba dan lihat apakah masuk akal untuk mengimplementasikan sesuatu seperti ini. (khususnya dalam aplikasi seluler, untuk mendapatkan tampilan dan rasa yang nyata pada perangkat yang sebenarnya) Jadi itu adalah sesuatu yang kecil yang (imho) tidak membenarkan terlalu banyak pekerjaan dalam iterasi "mari kita lihat" pertama. Namun terkadang muncul pertanyaan KAPAN saya membayar tech.debt ini? Itulah pertanyaan tentang ini.

Jika saya tahu bahwa setengah dari fitur-fiturnya akan hilang satu hari kemudian (cukup pengalaman di perusahaan kami sekarang), saya benar-benar merasa sulit untuk percaya bahwa cara terbaik untuk mendekati masalah saya adalah dengan menginvestasikan waktu ekstra untuk menulis semuanya dengan bersih bahkan jika sebagian besar akan jatuh segera setelahnya. Rasanya bagi saya bahwa saya akan menghemat waktu jika saya melakukan satu pembersihan besar setelah semuanya padat, maka pertanyaan saya.


68
Pertanyaan Anda adalah "Saya menggali lubang; bagaimana saya bisa keluar?" Jawaban standar tentu saja adalah langkah pertama, STOP DIGGING DEEPER. Proses pengembangan Anda dapat disimpulkan sebagai "menghasilkan utang teknis dalam jumlah besar dan kemudian mengabaikannya ketika jatuh tempo". Jika ini masalah, ubah proses pengembangan Anda. Hanya memeriksa kode yang bersih, berfungsi, ber-debug, dan ditinjau dengan cermat yang memenuhi spesifikasi tertulisnya. Jangan berhutang dan Anda tidak perlu keluar dari utang.
Eric Lippert

11
@NikkyD Jika Anda tidak diberi waktu untuk implementasi yang tepat, Anda perlu berbicara dengan manajer Anda tentang dampaknya pada kualitas perangkat lunak. Pahami apa yang dikatakan semua orang di sini: tidak menginvestasikan waktu di muka merusak kemampuan Anda untuk bekerja secara efisien nanti. Masalah lain yang ingin Anda sampaikan kepada mereka: jika Anda meninggalkan perusahaan (atau "ditabrak bus"), akan sangat mahal bagi pengembang baru untuk membiasakan diri dengan kode tersebut. Uang yang mereka pikir akan mereka hemat sekarang akan dikenakan biaya nanti.
jpmc26

32
Jika Anda membuat sedikit cabang fitur untuk mengejek antarmuka pengguna yang diusulkan untuk fitur, itu hebat. Jadikan itu secepat dan kotor yang Anda inginkan, perlihatkan ke klien, lalu hapus cabang itu . Ketika para pembuat mobil membuat mobil dari tanah liat dan kertas untuk membuat desain baru, mereka kemudian tidak mencoba memasukkan mesin ke dalam model tanah liat. Proses untuk menentukan apakah fitur tersebut layak dilakukan harus murah. Setelah Anda memutuskan untuk melakukan fitur, pastikan Anda mulai dari kode bersih dan selalu menghasilkan kode bersih, karena kode itu sekarang adalah kode produksi .
Eric Lippert

10
"tidak bisa bermimpi tentang keindahan kode yang semuanya bersih dan berkilau" Ini adalah kesalahpahaman mendasar tentang apa arti "kode bersih". Kode bersih tidak berarti Anda menghabiskan sore hari membuat tab berbaris sehingga Anda dapat mencetak kode dan membingkainya. Kode bersih adalah kode yang baik dan kode yang baik adalah kode yang bersih. Kode bersih adalah kode yang berfungsi dengan baik, dapat didebug, dan dapat dipahami. Jika Anda tidak punya waktu untuk menulis kode bersih dari awal, maka Anda pasti tidak punya waktu untuk menulis kode yang berantakan dan kemudian memperbaikinya nanti. Itu hanya berapa lama tugasnya.
GrandOpener

8
"Aku juga harus menyelesaikan sesuatu dan tidak bisa memimpikan keindahan kode semuanya bersih dan bersinar. Aku harus menemukan kompromi." Kompromi berarti jalan tengah yang "cukup baik" untuk kedua belah pihak. Jika kode Anda berantakan - terutama jika cukup berantakan sehingga Anda merasa akan kesulitan mempertahankannya - maka itu tidak "cukup baik", dan Anda perlu mencari kompromi yang lebih baik.
anaximander

Jawaban:


98

Jadi saya tidak membuang banyak waktu untuk menulis kode super bersih pada saat itu karena saya tidak pernah tahu berapa lama sesuatu berlangsung.

Tidak tahu berapa lama sesuatu berlangsung seharusnya tidak menjadi alasan untuk kecerobohan - justru sebaliknya. Kode terbersih adalah IMHO yang tidak menghalangi Anda ketika Anda harus mengubah sesuatu. Jadi rekomendasi saya adalah: selalu mencoba untuk menulis kode terbersih yang Anda bisa - terutama ketika pengkodean prototipe. Karena akan jauh lebih mudah untuk mengadaptasinya ketika sesuatu harus diubah (yang pasti akan terjadi).

Jangan salah paham - pemahaman saya tentang "kode terbersih" tidak ada hubungannya dengan menjadikan kode cantik demi kecantikan. Itu memang sesuatu yang bisa memperlambat Anda. Dalam pandangan saya, kode bersih adalah kode yang sebagian besar menjelaskan sendiri (tidak perlu menulis begitu banyak dokumen - menyebabkan percepatan), mudah dimengerti (lebih sedikit kesalahan, sehingga lebih sedikit diperlukan debugging - percepatan, lebih sedikit waktu yang diperlukan untuk menemukan yang benar tempat untuk mengubah - speedup), memecahkan masalah yang diberikan dengan jumlah paling sedikit kode yang diperlukan (kode kurang untuk debug - speedup jelas), adalah KERING (hanya satu tempat untuk mengubah ketika sesuatu harus diubah - speedup - dan lebih sedikit risiko untuk memperkenalkan bug baru dengan lupa mengubah tempat kedua), mengikuti standar pengkodean (hal-hal yang kurang rumit untuk dipikirkan - speedup), menggunakan yang kecil,

Saya diharapkan untuk memulai pengujian / debugging akhir tetapi nyali saya mengatakan bahwa saya sekarang harus entah bagaimana membersihkan dan atau menulis ulang hal-hal untuk memberikan arsitektur yang tepat yang membuat pemeliharaan dll lebih mudah

Melakukan "pembersihan" sesudahnya tidak pernah berhasil. Pertimbangkan Anda membersihkan sebelum menerapkan fitur baru, atau ketika mulai mengimplementasikannya, tetapi tidak setelahnya. Misalnya, setiap kali Anda mulai menyentuh metode untuk suatu fitur, dan Anda melihatnya lebih lama dari 10 baris, pertimbangkan untuk mengubahnya menjadi metode yang lebih kecil - segera , sebelum mendapatkan fitur lengkap. Setiap kali Anda mendeteksi variabel atau nama fungsi yang ada, Anda tidak tahu persis apa artinya, cari tahu apa yang baik untuk dan ganti nama benda itu sebelum melakukan hal lain. Jika Anda melakukan ini secara teratur, Anda menyimpan kode Anda setidaknya dalam keadaan "cukup bersih". Dan Anda mulai menghemat waktu - karena Anda membutuhkan lebih sedikit waktu untuk debugging.

Saya di tengah pengujian dan perbaikan bug akan menjadi penulisan ulang

... yang merupakan bukti aktual untuk apa yang saya tulis di atas: menjadi "kotor" menghantui Anda segera ketika Anda mulai men-debug kode Anda dan akan membuat Anda lebih lambat.

Anda dapat menghindari ini hampir sepenuhnya jika Anda segera melakukan pembersihan. Maka perbaikan bug sebagian besar akan berarti perubahan kecil pada kode, tetapi tidak pernah merupakan perubahan arsitektur utama. Jika Anda benar-benar mendeteksi bukti untuk perbaikan arsitektur selama pengujian, tunda, masukkan ke dalam sistem pelacakan masalah Anda, dan terapkan saat Anda harus mengimplementasikan fitur yang mendapat manfaat dari perubahan itu ( sebelum Anda mulai dengan fitur itu).

Ini membutuhkan beberapa disiplin, dan beberapa pengalaman pengkodean, tentu saja. Ini adalah ide yang mirip seperti ide di balik "pengembangan yang didorong oleh pengujian", melakukan hal-hal ini sebelumnya alih-alih melakukannya setelah itu (TDD dapat membantu juga, tetapi apa yang saya tulis bekerja bahkan ketika Anda tidak menggunakan TDD). Ketika Anda melakukan ini secara konsekuen, Anda tidak akan memerlukan "fase pembersihan" khusus sebelum melepaskan.


40
@NikkyD Saran yang dibuat oleh Doc Brown adalah kebiasaan yang sebenarnya mengurangi waktu yang dibutuhkan dan sangat realistis dalam jangka panjang. Pikirkan berapa banyak waktu yang Anda hemat jika Anda tidak perlu memeriksa kode Anda untuk mencari cara untuk tidak merusaknya setiap kali Anda perlu mengubahnya . Keuntungannya mirip dengan mengubah dari mengetik "berburu dan mematuk" menjadi belajar untuk menyentuh. Pada awalnya mungkin butuh waktu lebih lama, karena Anda sedang belajar, tetapi begitu kebiasaan itu ada, itu tidak dapat disangkal lebih baik dan akan bermanfaat bagi Anda selama sisa karier Anda. Jika Anda memilih untuk tidak mencoba, Anda tidak akan pernah sampai di sana.
Daniel

44
@ NikkyD: Itu tidak mengasapi kerangka waktu. Kerangka waktu sudah membengkak; Anda hanya tidak memperhitungkan mengasapi ketika Anda menulis perangkat lunak dan masuk ke hutang teknis yang belum Anda anggarkan.
Eric Lippert

7
@ NikkyD: Saya persembahkan kepada Anda Idol dengan Feet of Clay dan konsep Hutang Teknis . Yang pertama berarti bahwa Anda dapat membangun perangkat lunak suara di atas fondasi yang goyah, yang terakhir adalah tentang "tertarik" (biaya tambahan) yang dialami oleh fitur yang Anda coba tempel ketika struktur tidak sehat.
Matthieu M.

10
@ NikkyD: tidak, saya sarankan untuk menulis kode Anda mirip dengan bagaimana seorang ahli biliar memainkan bola: setiap tembakan terlihat sederhana untuk orang luar, karena setelah tembakan bola berhenti di posisi untuk "tembakan sederhana" baru. Dan dalam biliar atau pengkodean, ini membutuhkan waktu bertahun-tahun untuk berlatih ;-)
Doc Brown

16
@ NikkyD: menurut pengalaman saya, ketika "menambahkan sedikit fitur memerlukan banyak refactoring" kode sudah berantakan, dan kebutuhan untuk "banyak refactoring" berasal dari kenyataan Anda perlu mengubah fungsi atau kelas yang Anda lakukan tidak cukup bersih di masa lalu. Jangan biarkan segalanya sampai sejauh ini. Tetapi jika Anda berada dalam situasi itu, cari kompromi. Setidaknya ikuti "aturan boyscout" dan tinggalkan kode dalam keadaan yang lebih baik daripada sebelum Anda menambahkan fitur. Jadi, bahkan jika fitur dihapus minggu depan, kode harus dalam kondisi yang lebih baik daripada sebelumnya.
Doc Brown

22

Anda memiliki dua masalah terpisah, keduanya dengan gejala yang sama (kode ceroboh):

Masalah # 1: Kontrol persyaratan yang tidak mencukupi Saya tidak bermaksud bahwa pemangku kepentingan Anda terlalu sering mengubah persyaratan Anda, maksud saya bahwa Anda mengizinkan perubahan persyaratan selama siklus perbaikan / pengujian bug. Bahkan metodologi gesit tidak mendukung itu; Anda membangun, Anda menguji, Anda memberikan, Anda menyuntikkan persyaratan baru.

Masalah # 2: Anda yakin bahwa hal-hal yang Anda tulis adalah "hanya untuk saat ini" Dalam pengembangan perangkat lunak "hanya untuk saat ini" kode sangat jarang. Anda telah memperhatikan diri sendiri bahwa sekali Anda telah memenuhi persyaratan pengguna, kerasnya penawaran dan permintaan membuatnya sangat sulit untuk dibenarkan untuk kembali dan menerapkan kembali fitur "selesai". Jadi, apa yang harus dilakukan? Selalu tulis kode produksi. Secara fungsional untuk Anda, itu berarti estimasi Anda untuk pemangku kepentingan Anda harus jauh lebih besar sehingga Anda punya waktu untuk melakukannya dengan benar.

Selain itu, harap dipahami bahwa Anda bekerja di posisi yang paling sulit sebagai pengembang: Baca pendapat Joel Spolsky tentang kehidupan pengembang in-house . Jadi, Anda harus ekstra waspada jika ingin menjalin kewarasan.


21

Ini adalah masalah umum - terutama ketika membuat apa yang pada dasarnya adalah balon percobaan perangkat lunak .

Ada sejumlah pendekatan yang dapat membantu. Pertama TDD pendekatan dapat membantu mengurangi basis kode dengan yang benar-benar diperlukan. Jika tes Anda berjalan seiring dengan kode Anda, maka Anda setidaknya dapat memiliki keyakinan bahwa kode Anda berperilaku sebagaimana mestinya.

Luangkan waktu untuk refactor saat Anda pergi. Setelah Anda memiliki prototipe dan pelanggan sangat bersemangat untuk mendapatkannya, sulit untuk mengatakan bahwa Anda perlu waktu untuk memoles apa (kepada mereka) yang lengkap. Saya suka check-in setiap hari diikuti dengan check-in refactor tapi YMMV.

Pengembang yang menulis kode dengan cepat sering diminta - kami memiliki pengembang seperti itu di departemen terakhir saya. Setiap tim menginginkannya karena dia bekerja sangat cepat. Namun, begitu tiba saatnya untuk menguji dan melepaskan kodenya, roda dengan cepat terlepas. Kode, retasan, dan pintasan berkode keras di mana-mana. Stoknya segera jatuh - secara besar-besaran.

Memotong kode produksi sejak awal bisa terlihat seperti hambatan tetapi tergantung pada lingkungan Anda, ada banyak alat yang dapat menghilangkan perkembangan seperti Ghostdoc dan Stylecop .

Perlu mendapatkan pola pikir pengembangan yang benar sejak awal. Anda akan terkejut betapa banyak sistem back-of-a-fag-paket yang seharusnya hanya solusi stop-gap menjadi aplikasi landasan.


Maksud Anda setiap solusi celah berhenti yang pernah ditulis, kan?
RubberDuck

4
Poin bagus tentang justifikasi kepada pelanggan. Saya memiliki banyak pengalaman dengan pelanggan yang berpikir bahwa ketika GUI terlihat selesai, aplikasi dilakukan juga. Saya belajar untuk membuat GUI terlihat tidak lengkap sementara kode di latar belakang belum siap, dan akibatnya, hanya membuat apa yang dilihat pelanggan terlihat dipoles ketika kode (dan logika bisnis). Sangat sulit untuk menjelaskan bahwa apa yang tampak selesai untuk pelanggan masih akan memakan waktu satu atau dua bulan untuk benar-benar dikirimkan.
Luaan

11

Terus menerus

Kecepatan pengembangan adalah alasan utama untuk menulis kode yang bersih, mudah dibaca, dan dapat diuji; itu tidak dilakukan untuk kecantikan, atau nilai-nilai abstrak lainnya. Mengapa saya menolak itu untuk diri saya sendiri dan hanya melakukannya setelah itu untuk beberapa programmer di masa depan?

Tentu mungkin ada perubahan yang sebagian besar kosmetik dan karena itu tidak penting; Saya berpendapat bahwa jauh lebih bermanfaat untuk memiliki kode yang cukup bagus saat ini, selama pengembangan, daripada memiliki kekacauan sekarang dan berharap untuk membuatnya sempurna nanti (yang, mari kita hadapi itu, itu tidak akan pernah terjadi, bahkan jika Anda memiliki waktu).


6
+1 dan dari sudut pandang pribadi, saya merasa terlalu sulit untuk mengubah persneling dari meretas proyek pribadi di rumah dan menulis kode produksi dalam pekerjaan saya. Menulis kode profesional dalam proyek hobi saya membayar dividen langsung - kode lebih mudah dibaca dan ada bug lebih sedikit.
Robbie Dee

Salah satu alasan itu tidak akan pernah terjadi adalah bahwa Anda (lebih baik) menjadi lebih baik dari apa yang Anda lakukan seiring waktu. Jadi jika Anda menunggu setengah tahun untuk "membersihkan" sesuatu, Anda tidak hanya akan melupakan semua minutae yang diperlukan untuk melakukan pembersihan dengan aman, Anda juga akan menjadi programmer yang lebih baik daripada sebelumnya, dan Anda mungkin akan tergoda untuk membuang semuanya dan memulai kembali. Dan karena begitu banyak pekerjaan (dan seringkali ide yang buruk), Anda mungkin hanya akan melewatkan pembersihan lagi.
Luaan

"Mengapa saya menolak itu untuk diri saya sendiri dan hanya melakukannya setelah itu untuk beberapa programmer masa depan?" Wahyu! Dan coba tebak? Anda kadang-kadang (dan kadang-kadang, sering) adalah programmer masa depan itu.
radarbob

@RobbieDee, Pengamatan Superlatif! Dalam sebuah wawancara Malcom Gladwell - pria yang membawa "aturan 10.000 jam" ke kesadaran populer (dalam buku Outliers ) - mengatakan bahwa itu harus "latihan yang disengaja" atau itu hanya membuang-buang waktu. Berarti fokus pada peningkatan, berlatih spesifik dengan maksud untuk meningkatkan aspek tertentu dari keterampilan, dll.
radarbob

@ThanosTintinidis, maka ada masalah "tidak ada perbuatan baik yang tidak dihukum". Setelah menulis kode bersih seperti itu, seseorang pasti akan mengacaukannya. Pastikan Anda peninjau kode ketika orang lain menyentuh kode bersih Anda. Satu metode tambahan yang sederhana menghancurkan enkapsulasi dan koherensi yang bahkan didokumentasikan secara online . Saya sangat marah selama seminggu; dan setahun kemudian, setiap kali saya melihat kode itu.
radarbob

4

Anda melakukan ini dengan membedakan antara "Saya hanya mencoba ini untuk melihat cara kerjanya" kode dan "ini menuju ke dalam produk" kode. Ada sejumlah cara untuk melakukannya.

Satu bercabang atau apa pun kata itu dalam sistem kontrol sumber Anda. Anda membuat cabang untuk laporan baru atau tata letak impor baru atau apa pun. Jika orang menyukainya, pekerjaan untuk mengembalikannya ke cabang utama adalah pekerjaan yang terpisah dan dapat dilacak. Itu dapat ditugaskan kepada seseorang dan dilaporkan dan tidak diharapkan terjadi secara ajaib manajemen hari (atau penjualan) setuju bahwa fitur tersebut termasuk dalam produk.

Lainnya adalah paku. Anda tidak melakukan perubahan pada produk. Anda pergi ke beberapa aplikasi terpisah, super sederhana, yang hanya ada bagi Anda untuk memiliki tempat untuk meletakkan kode. Anda bisa berantakan seperti yang Anda inginkan karena Anda hanya menjelajahi API baru atau apa pun. Dan lagi, jika Anda kembali dan melaporkan "ya, kami bisa melakukan itu, saya telah menemukan caranya" ada tugas yang dapat dilacak, dapat dilaporkan, tugas yang dapat ditugasi untuk menulis kode siap-produk dalam produk untuk melakukan apa yang Anda inginkan.

Dalam kedua kasus tersebut, produk-siap berarti dapat dibaca, rapi, mengikuti standar penamaan, dengan tes, dan mengikuti gaya kode dan target kinerja Anda. Dalam kedua kasus, Anda membuat pekerjaan itu terlihat. Saya setuju bahwa Anda tidak ingin melakukan semua itu bekerja setiap kali ketika seseorang sangat mungkin untuk menarik kembali fitur dari produk. Tetapi Anda juga tidak ingin pekerjaan itu tidak terlihat. Bekerja dalam salinan terpisah dari produk atau dalam produk yang tidak terkait yang tidak lebih dari test harness memungkinkan Anda memunculkan pekerjaan untuk membuat kode siap-produk begitu seseorang memutuskan mereka menginginkan sesuatu.

Kelemahannya adalah mereka tidak dapat memutuskan mereka menginginkan sesuatu dan mengirimkannya (artinya setengah-setengah, berantakan, tidak teruji, tidak berdokumen, mungkin setengah versi yang telah Anda laksanakan sebagai bukti konsep) besok. Mereka pertama kali Anda mendapatkan pushback di bagian depan itu, cukup tanyakan apakah Anda harus melakukannya dengan cara panjang (lebih mahal) setiap kali untuk berjaga-jaga, memperlambat jalan menuju fitur yang ditolak. Jika Anda bertanya dengan benar, Anda akan mendapat "tidak".


1

Sungguh saya pikir Anda sudah memahami masalahnya. Masalahnya adalah bahwa gaya pengkodean Anda mengharuskan Anda melakukan terlalu banyak pengerjaan ulang. Alasan mengapa diperlukan terlalu banyak pengerjaan ulang adalah karena (a) itu disatukan dengan pandangan ke depan dan perencanaan yang tidak memadai dan (b) tambalan jangka pendek tambahan yang secara teratur dimasukkan selama pengembangan secara bersama-sama meningkatkan kompleksitas setiap pengerjaan ulang yang diperlukan.

Karena itu, jawabannya adalah

(a) ubah gaya pengembangan Anda sedikit lebih ke arah air terjun dan sedikit kurang gesit. Namun jangan pergi jauh-jauh, karena air terjun klasik memiliki jebakannya sendiri. Ada keseimbangan sehat yang bisa didapat. Saya tahu itu bisa mengenai memikirkan hal-hal selama beberapa hari kadang-kadang, seperti tidak ada pengembangan yang dilakukan, tetapi Anda harus memercayai prosesnya. Dalam rekayasa, Anda tidak bisa hanya memakukan hal-hal bersama dan kemudian memaku hal-hal di atas dan berharap untuk keluar dengan solusi yang elegan. Jika tidak ada orang yang melakukan arsitektur dan desain teknis tingkat tinggi, itu adalah pekerjaan Anda. Anda telah membayar harga mengabaikan pekerjaan itu.

(B) mencoba untuk menghindari menambal sesuatu. Jangan berpikir jangka panjang hanya ketika tiba saatnya untuk melakukan QA. Sungguh, Anda harus menguji setiap bagian kecil yang Anda buat, sepanjang waktu, dan mencakup semua kasus masukan, yang tidak berada di jalur bahagia juga. Sebuah tambalan / retasan hampir secara definisi merupakan perbaikan jangka pendek, yang mungkin memiliki biaya jangka panjang, mengenai total Biaya Kepemilikan klien dalam sistem. Sekali lagi, tekanan menyala untuk mengeluarkan kode, jadi harus ada keseimbangan. Tetapi cobalah untuk tidak menempatkan perbaikan jangka pendek di tempat, esp. komponen-komponen yang terikat erat yang harus benar-benar longgar digabungkan Akan ada pekerjaan ulang, jadi lakukan AWAL untuk membuatnya lebih mudah, untuk menghindari peretasan dan tambalan yang akan meningkat dari waktu ke waktu dan menjadi tidak terkelola.


2
Sekadar catatan - gesit bukan berarti "sering berubah tanpa pikir" atau "kurang desain". Bahkan, saya menemukan bahwa lincah membutuhkan desain yang jauh lebih dari apa yang orang sebut air terjun. Kurangnya desain yang baik adalah salah satu alasan mengapa air terjun tidak bekerja dengan baik dalam praktik - jika Anda benar-benar berinvestasi dalam desain dengan benar, itu berfungsi dengan baik; itu juga menjadi jauh lebih mahal daripada gesit. Jika Anda melewatkan bagian desain dengan gesit, Anda hanya membenturkan kode bersama-sama, dan itu tidak akan bekerja lebih baik daripada praktik lain yang menghindari desain.
Luaan

Fokus lincah pada iterasi pendek, sprint dll, membuat prototipe keluar dengan cepat, tentu saja memberi tekanan lebih besar pada pengabaian desain yang memadai di depan
Brad Thomas

Tidak, itu berfokus pada mendesain bagian yang lebih kecil. Tetapi secara keseluruhan, Anda harus mendesain banyak, jika tidak, Anda hanya akan menghasilkan produk yang mengerikan. Kuncinya adalah membuat hal-hal kecil dan dirancang dengan baik, serta dipertukarkan. Jika desain Anda kurang gesit, Anda merugikan diri sendiri (dan pelanggan Anda). Iterasi pendek adalah manfaat menggunakan gesit, bukan prasyarat atau hanya bagian dari proses - setelah Anda mendapatkan semuanya dengan cukup baik, Anda tiba-tiba dapat membeli iterasi pendek, bukan sebaliknya.
Luaan

Menempatkan lebih banyak penekanan pada mendesain bagian-bagian yang lebih kecil adalah masalah besar, ketika benar-benar gambaran yang lebih besar biasanya merupakan penyebab paling signifikan dari pengerjaan ulang. Saya telah melihat lebih banyak uang yang terbuang untuk bisnis yang secara tiba-tiba mengatakan "tetapi kita membutuhkannya untuk melakukan ini", yang membutuhkan perbaikan besar-besaran daripada yang pernah saya lihat dalam perubahan desain sebuah komponen kecil yang longgar ditambah
Brad Thomas

Ya, tetapi pada titik itu Anda sudah kehilangan (dan terlepas dari apakah Anda mencoba untuk lincah atau air terjun). Ketika "gambaran besar" Anda terdiri dari banyak bagian kecil yang relatif terisolasi, satu-satunya perombakan luas yang Anda dapatkan adalah ketika Anda perlu mengganti hampir semuanya. Pendekatan apa yang tidak membuat Anda kehilangan segalanya ketika Anda harus mulai dari awal? Bahkan tingkat desain NASA mengarah pada sesekali "kita perlu mengubah segalanya". Dengan menjaga diri Anda fleksibel dan mudah beradaptasi, Anda mendapatkan lebih banyak ruang bermanuver untuk mengakomodasi perubahan, kecil atau besar.
Luaan

0

Anda menulis:

Setiap versi hanyalah prototipe. Jadi saya tidak membuang banyak waktu untuk menulis kode super bersih pada saat itu karena saya tidak pernah tahu berapa lama sesuatu berlangsung. ...

Kemudian tibalah titik di mana program selesai dan pembuat keputusan mengatakan "itu saja". Saya memang memiliki prototipe yang berfungsi pada saat ini, tetapi kode di dalamnya agak berantakan dari semua bolak-balik selama fase pengembangan.

Versi check-in dapat menjadi "prototipe" karena melewatkan fitur atau beberapa fitur tidak disempurnakan, tetapi semua kode yang diperiksa harus berupa kode kualitas produksi yang tidak perlu perlu dibersihkan.

Saya pikir Anda banyak menunda "pembersihan".

Aturan praktis saya adalah:

  • Mulai dengan fitur (sub-)
  • merasa bebas untuk menulis hal-hal yang tidak lengkap dan tidak lengkap, mungkin beberapa hal untuk merasakan apa yang saya laksanakan atau jika saya harus menggaruk jam terakhir pengkodean (perhatikan bahwa ini dapat berjalan seiring dengan TDD / tes, hanya saja semuanya sedikit melunak untuk mendapatkan umpan balik cepat dari ruang implementasi yang saya jelajahi)
  • Sub-fitur "berfungsi" cukup bagus untuk saat ini
  • Sekarang lakukan pembersihan: sebelum komit SCC .
    • Lihat kode untuk melihat apa yang jelas
    • Lakukan komitmen diff vs last untuk meninjau perubahan dan mungkin mengalami beberapa masalah
    • Memperbaiki hal-hal yang saya catat pada scratchpad saya
  • Sekarang saya melakukan commit - kualitas kode ini siap dikirim

Pada titik ini, kode yang dikomit mungkin masih mengandung beberapa solusi atau "hutang teknis" yang akan baik untuk dibersihkan, dan mungkin saya akan membersihkannya ketika itu adalah hal yang wajar dilakukan untuk sub-fitur berikut, tetapi akan baik-baik saja jika kode itu dirilis apa adanya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.