Tetap sederhana sekarang, atau program dengan masa depan dalam pikiran?


21

Saat ini saya sedang mengkode aplikasi baru untuk perusahaan saya yang agak terlibat. Untuk memenuhi tenggat waktu, fungsionalitas telah diturunkan sedikit sehingga kita dapat memiliki sesuatu yang siap untuk diluncurkan.

Saya telah diberi tugas untuk meningkatkan versi 1 dan berjalan pada akhir bulan. Saya hampir setengah jalan dalam pengembangan dan saya sampai pada titik sekarang bahwa ada akhir yang terlihat.

Kemarin, saya menghabiskan beberapa waktu untuk menghasilkan solusi mudah yang sangat bagus untuk salah satu persyaratan dan cukup bangga dengan hasilnya. Pagi ini dokumen versi 2 dikirimkan, dan ada persyaratan di sana yang akan meminta kode yang saya tulis kemarin untuk dimusnahkan, atau sangat diubah. Itu akan membutuhkan banyak pekerjaan di masa depan jika saya membiarkannya apa adanya. Saya dapat mengambil satu hari ekstra sekarang untuk membuat solusi saya saat ini lebih kuat sehingga fitur v2 akan dapat ditambahkan dengan usaha yang jauh lebih sedikit, tetapi itu akan membuat saya sedikit ketinggalan untuk pengkodean tambahan yang diperlukan.

Saya tidak tahu apakah saya akan melakukan v2. Mungkin saya atau rekan kerja, atau bahkan magang.

Jika Anda berada di posisi saya, apakah Anda akan menghabiskan waktu sekarang untuk membuatnya lebih mudah di masa depan, atau apakah Anda akan meninggalkan solusi Anda dan menghadapinya ketika saatnya tiba?



Tautan berikut bermanfaat bagi saya: elegantcode.com/2012/01/16/marines-vs-boy-scouts
QuanhD

Jawaban:


18

Jika tenggat waktu Diukir Di Batu, selesaikan saja apa yang harus Anda penuhi. Pastikan Anda mengembang perkiraan untuk v2 untuk mengakomodasi perubahan kode untuk persyaratan baru. Pastikan juga untuk mendokumentasikan secara singkat apa yang menurut Anda perlu diubah untuk fitur v2 baru sehingga rekan kerja dapat mengambilnya jika Anda dipindahkan ke sesuatu yang lain.

Jika ada fleksibilitas yang cukup dalam tenggat waktu (1 hari, dengan suara itu, jadi bertujuan untuk perpanjangan 2,5 hari) maka pasti, silakan dan kode untuk masa depan yang diketahui!


1
+1 untuk saran untuk mendokumentasikan solusi yang lebih kuat. Fitur ini mungkin atau mungkin tidak diterapkan persis seperti yang Anda rencanakan, tetapi jelas merupakan ide bagus untuk memberi tahu pelaksana masa depan tentang pemikiran Anda tentang perubahan tersebut.
Mike Partridge

2
Saya benar-benar mulai menulis metode bertopik untuk antisipasi v2 pagi ini setelah membaca dokumen. Saya pikir saya akan berhenti di situ dan beberapa komentar mengatakan bagaimana ini akan bermain di masa depan. Terima kasih :)
Tyanna

1
Mengawasi bola .... pengalaman saya adalah hal yang buruk untuk mengkhawatirkan diri sendiri dengan apa pun yang berkaitan dengan V2 ketika Anda memiliki tenggat waktu V1 yang akan mengenai mata Anda. Jika fleksibel, itu bukan Tenggat. Jika suatu pengembangan melewatkan Batas Waktu, itu adalah kesalahan pengembang.
mattnz

13

Hindari jatuh mangsa (awal) ke Efek Sistem Kedua . Berikut adalah beberapa teknik yang baik untuk diterapkan:

  1. Jelas menghindari menghapus versi 1 hanya karena apa yang Anda lihat muncul di versi 2. Perencanaan ke depan baik-baik saja, tetapi pencipta spesifikasi v2 harus bertanggung jawab atas kegagalan v2, bukan v1.
  2. (Jika mungkin) lihat apakah Anda dapat membuat pembuatnya mengerjakan kembali persyaratan untuk versi 2 yang tidak memerlukan perubahan yang lebih besar sekarang - dan kemudian rencanakan untuk mereka nanti, mungkin untuk v3.
  3. Ingat -ingatlah YAGNI , tetapi cobalah kode untuk kelaikan dalam pikiran - hindari angka-angka ajaib, nilai-nilai hard-code, tulis unit test yang baik atau kontrak kode, dll. Menerapkan teknik yang baik sejak dini akan membuat refactoring dan perubahan kode tidak begitu menyakitkan di sepanjang jalan.

Sebagian besar proyek perangkat lunak yang tumbuh seperti kota berhasil dalam jangka panjang. Perencanaan evolusi hanya ke masa depan yang terbatas memungkinkan perangkat lunak Anda dirilis tepat waktu dan dengan fungsionalitas yang diperlukan pada rilis - dan tidak lebih. Lihat kutipan ini dari Carl Sagan:

Pengaturan [sebuah kota] mungkin lebih efisien jika semua sistem kewarganegaraan dibangun secara paralel dan diganti secara berkala (itulah sebabnya kebakaran yang menghancurkan — kebakaran besar London dan Chicago, misalnya — kadang-kadang merupakan bantuan dalam perencanaan kota). Tetapi pertambahan fungsi baru yang lambat memungkinkan kota untuk bekerja lebih atau kurang terus menerus selama berabad-abad.


Saya suka ide untuk berbicara dengan desainer dan manajemen untuk melihat apakah mereka menikah dengan fitur itu. Saya melihatnya lebih sebagai bel yang tidak berguna yang akan menyebabkan lebih banyak pekerjaan daripada nilainya ... tapi kemudian saya adalah atm yang stres. :)
Tyanna

2
+1: Hindari mencoba memprediksi masa depan. Ketika tiba, itu akan mengejutkan.
S.Lott

7

Jangan menambahkan kode hari ini untuk kebutuhan bulan depan. Hari ini Anda harus menulis kode terbersih yang Anda bisa untuk persyaratan yang Anda miliki. Saya ragu bahwa pekerjaan sehari sekarang akan menghemat beberapa hari kemudian. Saya pernah mendengar klaim seperti itu, dan tidak dapat mengingat satu kasus pun di mana itu benar. Anda mungkin dapat meyakinkan saya dengan menunjukkan beberapa kode, tetapi pengalaman saya mengatakan itu tidak mungkin.


Memang benar, tetapi itu hanya benar jika Anda punya waktu di depan untuk merencanakannya di depan dengan sangat teliti dan Anda memiliki pengetahuan bisnis yang diperlukan untuk mengantisipasi sifat berbagai perubahan. Mengingat sebagian besar situasi bisnis (sekarang, lebih murah, lebih kecil) saya setuju sepenuhnya dengan pernyataan Anda. Saya punya beberapa contoh, jika Anda adalah orang yang tidak percaya :)
Joel Etherton

@ JoelEtherton: Bahkan jika Anda memiliki pengetahuan bisnis, mengantisipasi perubahan sangat sulit, sampai-sampai sering tidak layak untuk dicoba ... hanya pengalaman saya.
sleske

@sleske: Terkadang mungkin, tapi pengalaman saya ada di dua arah. Dalam pekerjaan saya saat ini, perencanaan dan tinjauan ke depan yang baik telah menyelamatkan saya banyak sakit kepala.
Joel Etherton

6

Biarkan apa adanya.

Pengembang sebenarnya MENGHARGAI proyek warisan yang melakukan apa yang seharusnya dilakukan dan tidak lebih.

Apa, hari ini, mungkin tampak seperti ide yang bagus untuk "menentukan" basis kode untuk memenuhi persyaratan "masa depan", dalam semua kemungkinan akan bertindak sebagai penghambat untuk memahami kode di masa depan. Tidak ada yang suka berurusan dengan fungsionalitas yang diimplementasikan sebagian dan sisa-sisa persyaratan hantu yang terlupakan. Saya tidak mengatakan itu akan menjadi masalah, tetapi banyak hal menjadi seperti itu meskipun ada niat baik.


+1 untuk "fungsionalitas yang tidak diterapkan setengah". Seandainya aku bisa lebih banyak memilih.
sleske

1

Jawaban yang bagus Saya hanya akan menambahkan - apa yang saya lakukan dalam kasus seperti ini adalah mengambil perbedaan yang baik sehingga saya dapat menangkap apa yang telah saya lakukan dan membuangnya di tempat yang aman. Maka jika ada kesempatan untuk melakukannya lagi di versi berikutnya, itu akan mudah.

Secara umum, pengembang yang baik mengantisipasi persyaratan di masa depan, tetapi ketika tenggat waktu menjulang, inilah saatnya untuk merespons bug pada apa yang sudah Anda dapatkan dan bukan "mengacau".


Ide bagus tentang menjaga perubahan terpisah. Alih-alih beda, cabang mungkin merupakan ide yang lebih baik (terlihat, lebih mudah untuk digabung, dll.). Anda selalu dapat menghapusnya nanti.
sleske

1

Tergantung. Ada aturan kuno yang baik: perlakukan orang lain seperti Anda ingin diperlakukan sendiri. Apa yang akan Anda lakukan jika itu adalah proyek Anda sendiri dan Anda tahu semua prioritas?

Jika v2 benar-benar diperlukan dan tenggat waktu hanya harapan daripada kebutuhan yang sulit maka jangan membuat utang teknis dan memperbaiki layar Anda saat cuaca baik-baik saja. Bahkan jika orang lain akan melakukan v2 mereka akan menghargai pandangan jauh ke depan.

Jika ada keraguan tentang perlunya v2 maka tetap dengan YAGNI. Juga jika Anda berada di sisi lain spektrum dan memiliki salah satu klien yang terus-menerus mengirim spam kepada Anda dengan ide-ide mereka sebelum mereka terbentuk kemudian periksa email Anda hanya 2 atau 3 kali sehari dan jangan terburu-buru dengan tindakan, Anda akan terkejut berapa banyak "masalah" dan permintaan menjadi tidak relevan bahkan sebelum Anda membacanya.

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.