Bagaimana menghindari penulisan ulang bagian aplikasi


13

Saya bekerja di sebuah perusahaan pada proyek untuk departemen Penjualan mereka. Ini adalah pekerjaan pemrograman profesional pertama saya, tetapi saya telah mengkode sendiri dan belajar selama bertahun-tahun. Bagian dari proyek ini melibatkan pengambilan beberapa data dan menggabungkannya dengan input untuk menghasilkan dan membuat grafik. Lalu simpan datanya ... seterusnya dan sebagainya. Jadi saya menulis kode untuk ini dalam waktu kurang dari sehari. Hari berikutnya saya menunjukkan kepada supervisor proyek saya, dan dia menyukainya, tetapi "bagaimana jika kita memiliki ini", dan ingin saya menambahkan sesuatu ke grafik. Ini bukan perubahan besar pada tampilan atau fungsi program, tetapi secara drastis mengubah cara saya perlu menyimpan data, memprosesnya, dll.

Sekali lagi, butuh sekitar satu hari untuk menyusun kembali tabel database, dan menulis ulang kode pada dasarnya dari awal untuk mendukung permintaan baru ini. Saya membawanya kembali kepadanya, dan hal yang persis sama terjadi. Dia meminta hal lain yang secara drastis mengubah cara saya perlu memproses data. Jadi, saya harus menulis ulang lagi. Akhirnya dia menandatanganinya, dan mudah-mudahan, saya tidak perlu menulis ulang lagi.

Jelas saja, saya tidak akan memukul manajer saya atau semacamnya. Dia pria yang hebat dan hal-hal yang dia minta tidak keluar dari dunia ini, mereka hanya tidak sesuai dengan apa yang telah saya lakukan sebelumnya.

Saya hanya ingin tahu apakah ada yang bisa saya lakukan di masa depan untuk menghindari penulisan ulang yang lengkap. Saya mengerti membuat kode yang fleksibel dan berusaha melakukannya, tetapi saya hanya ingin mengetahui praktik atau hal-hal yang dapat saya lakukan secara berbeda untuk membuatnya lebih mudah, jadi, di masa depan, saya tidak menghabiskan 3 hari untuk sesuatu yang seharusnya diambil 1.


2
Paradigma pemrograman apa yang Anda gunakan? Prosedural, berorientasi objek, fungsional, lainnya?
Tulains Córdova

2
Untuk menghindari penulisan ulang - pisahkan basis data dan lapisan aplikasi Anda. Ini bukan konsep sederhana untuk diterapkan pada cara Anda menulis kode. Ini adalah konsep kompleks yang membuat kode Anda sederhana dan mudah beradaptasi.
StackOverFowl

6
Sepertinya persyaratannya tidak jelas atau Anda salah paham. Tidak ada prinsip atau praktik terbaik yang dapat menyelamatkan Anda dari melakukan kembali seluruh aplikasi jika penerapannya dibuat berdasarkan asumsi yang salah. Sebelum mengetik bawah LOC tunggal baik itu untuk meminta persyaratan " apa Jika ... " ... Jangan menunggu manajer mengejutkan Anda dengan yang baru apa Jika ... . Menghabiskan waktu mencari celah fungsional akan mengurangi faktor surpise juga.
Laiv

3
Injeksi Ketergantungan adalah teman Anda. Google itu, dan lihat bagaimana menerapkannya ke bahasa / kerangka kerja Anda. Ini akan memungkinkan Anda untuk menulis kode yang jauh lebih modular, yang akan mengurangi jumlah kode yang perlu ditulis ulang ketika persyaratan berubah.
Eternal21

2
Walaupun mungkin tampak seperti banyak menulis ulang adalah hal yang buruk, hal yang sangat penting adalah seberapa cepat Anda dapat menanggapi permintaan dari pengguna akhir Anda. Sementara itu tergantung pada kompleksitas proyek, saya akan mengatakan bahwa 1 hari adalah waktu yang cukup baik - Anda harus melakukan sesuatu dengan benar! Sebenarnya perangkat lunak yang melihat perubahan signifikan adalah pertanda baik - artinya bermanfaat dan membaik. Perangkat lunak yang tidak mengalami perubahan signifikan selama bertahun-tahun jauh lebih sulit untuk dipelihara.
Justin

Jawaban:


22

Ketika saya berkomentar, saya memiliki perasaan yang kuat bahwa persyaratan tidak jelas pertama kali atau mungkin Anda melewatkan beberapa detail penting.

Tidak semuanya dapat diatasi dengan kode yang lebih baik, praktik terbaik, pola desain, atau prinsip OOP. Tidak satu pun dari mereka akan mencegah Anda mengulangi seluruh aplikasi jika implementasinya didasarkan pada asumsi yang salah atau premis yang salah.

Jangan terburu-buru dalam mengkode solusi. Sebelum mengetik satu LOC, luangkan waktu untuk mengklarifikasi persyaratan. Semakin dalam Anda mempelajari persyaratan, semakin banyak bagaimana jika pertanyaan muncul. Jangan menunggu sampai Manajer mengejutkan Anda dengan bagaimana-jika selanjutnya . Mengantisipasi hal-hal sendiri. Latihan kecil ini dapat mengurangi faktor kejutan secara signifikan .

Jangan takut untuk bertanya sebanyak yang Anda butuhkan. Kadang-kadang pohon (detail) tidak membiarkan kita melihat hutan (gambaran keseluruhan). Dan hutanlah yang perlu kita lihat terlebih dahulu.

Ketika persyaratannya jelas, akan lebih mudah untuk membuat keputusan yang lebih baik selama fase desain.

Akhirnya, ingatlah bahwa gambaran keseluruhan adalah tujuan. Rute ke tujuan ini tidak sederhana atau langsung. Perubahan akan terus terjadi, jadi gesitlah.


3
Ini. Jawaban ini adalah cara terbaik yang bisa diajukan. Dapatkan persyaratan itu sebelum Anda melakukan apa pun.
Rhys Johns

1
Ini adalah jawaban yang bagus, tapi saya punya perasaan mengganggu bahwa ada cara yang lebih baik untuk menyusun aplikasi agar lebih mudah mengakomodasi permintaan ini. Saya tidak percaya apa yang disebut "prinsip" mengambang tentang akan membantu; solusinya harus spesifik untuk masalah tersebut. Tanpa informasi lebih lanjut, jawaban Anda adalah satu-satunya yang masuk akal.
Frank Hileman

Yah, saya punya perasaan kuat bahwa masalahnya adalah yang saya komentari karena itu persis apa yang terjadi pada saya di masa awal saya sebagai pengembang. Saya secara instan menerjemahkan frasa ke dalam LOC atau modul, dan ketika saya harus mengubah sesuatu sangat dramatis bagi saya. Refactor over refactor setiap hari atau minggu. Bahkan tidak melakukan yang terbaik dengan SoC, SPR, polymorphism, ... Banyak konflik yang saya alami dengan perubahan disebabkan oleh bocoran visi keseluruhan saya.
Laiv

2
Untuk membangun di atas jawaban ini: Penting juga gesit tentang pengumpulan persyaratan. Terkadang orang mendapatkan ide baru atau mengingat sesuatu yang mereka lupa ketika mereka melihat produk. Mereka mungkin berkata: "Aku tahu aku memintamu untuk membangun ini tetapi bukan itu yang kumaksudkan" atau "Aku tahu aku meminta ini, tetapi sekarang setelah aku melihatnya, aku menginginkan sesuatu yang lain." Anda dapat mencegah hal ini menyebabkan frustrasi dan pengerjaan ulang dengan membuat "Bukti Konsep" yang cepat dan kotor. Ini bahkan bisa menjadi maket seperti grafik palsu. Ini membantu pelanggan Anda berpikir.
Akhil

1
Beberapa orang mungkin berpendapat bahwa mengabstraksikan db dari kode bukanlah suatu keharusan karena "vendor db jarang berubah". Saya setuju dengan Anda, tetapi inti dari jawaban saya adalah: sambil mengumpulkan persyaratan, lupakan Anda adalah pengembang, Fokuslah pada pengumpulan persyaratan. Berpikirlah seperti manajer, jangan tanya seperti manajer. Jangan terburu-buru berpikir seperti pengembang.
Laiv

4

Tidak ada cara untuk mengetahui itu berdasarkan apa yang telah Anda berikan. Ini lebih cepat dan kotor yang Anda butuhkan saat itu. Tapi, kemudian seseorang menyukainya dan itu semakin rumit, jadi sekarang Anda mulai melihat bahwa banyak masalah tidak muncul sampai kompleksitas muncul. Ada begitu banyak hal yang dapat dilakukan yang hanya luar biasa.

Ada yang lama, "No Silver Bullet," dan itu benar. Sekali lagi, tidak ada cara untuk mengetahui apa yang harus dilakukan dengan spesifikasi lengkap (atau spesifikasi Agile yang lebih baik), dan kemampuan untuk menggunakan prinsip-prinsip pemrograman yang baik dan desain yang baik. Programmer suka menulis ulang, berulang-ulang . Saya tidak mengatakan Anda jatuh ke dalam ini karena itu, pada saat ini, kecil.

Gunakan kesempatan ini untuk menerapkan beberapa prinsip dasar. Anda akan menemukan bahwa mereka bekerja tetapi kemudian seseorang akan berkata, "Oh tidak, itu buruk" atau Anda akan sesuatu yang Anda sukai. Anda tidak dapat melakukan semuanya dengan uang perusahaan, tetapi jika mereka memberi Anda waktu untuk mengeksplorasi, gunakan itu sebagai peluang. Ada selalu seseorang, beberapa yayasan, beberapa orang, yang memiliki "terbaik" cara atau cara "baru" dalam melakukan sesuatu.


Artikel bagus yang Anda tautkan.
SH7890

1
Artikel yang bagus! Saya pikir ini bukan kasus OP tetapi saya tidak bisa lebih setuju dengan penulis.
Laiv

1
Saya tidak mengira itu satu untuk satu, tetapi bunyinya seperti satu hari. Semoga ini akan membantu OP.
johnny

2

Manajer Anda kemungkinan besar benar dalam setiap langkah yang Anda lalui. Ini bukan karena dia adalah manajer, tetapi karena dia mempertimbangkan hasil dan kegunaan dan mungkin sejumlah transaksi sebelumnya dengan pelanggan atau permintaan pelanggan.

UI adalah hal yang sulit, biasanya, 5 orang memiliki 15 pandangan berbeda. Dan penataan data dan data dan analisis data cenderung untuk mengubah itu lipat dengan faktor 10 :). UI seperti fashion, beberapa kombinasi keren, ada juga yang masuk akal atau hilang akal sehat.

Belum lagi, bahwa misalnya selama proses LEAN tidak ada yang ditetapkan. Anda mengalami sesuatu seperti evaluasi berulang dan selama setiap langkah, sedikit jalan yang lebih baik atau salah dihindari.

Jadi jawaban yang sederhana adalah, bahwa tidak ada yang namanya menulis ulang sama sekali.


2

Pengembangan berulang (yang adalah apa yang Anda lakukan pada dasarnya, meskipun iterasi satu hari) sering seperti ini. Upaya awal untuk solusi sering melenceng, dan dengan mengumpulkan umpan balik, sistem bertemu menjadi solusi. Saya akan meminjam Gambar 2.2 dari bahan instruktur Craig Larman untuk buku Aplikasi UML dan Pola Desainnya .

masukkan deskripsi gambar di sini

Pada awal proyek, Anda belajar hidup dengan versi yang tampaknya tidak stabil. Saya akan tidak setuju dengan jawaban yang mengatakan "Anda harus mendapatkan lebih banyak persyaratan sejak awal," karena itu adalah pemikiran Waterfall. Memang benar Anda harus berusaha untuk mendapatkan sebanyak mungkin dari segi persyaratan, tetapi karena berbagai alasan tidak mungkin untuk memiliki persyaratan yang lengkap dan akurat.

Ini bukan untuk mengatakan Anda tidak dapat mengurangi berapa banyak yang harus Anda tulis ulang setelah mendapat umpan balik. Satu hal yang sering benar adalah bahwa interaksi manusia-komputer dari perangkat lunak sangat mungkin berubah, karena itu adalah bagian yang sulit untuk diperbaiki saat pertama kali.

Pikirkan tentang Microsoft Word dan bagaimana format datanya (.doc) tidak terlalu berkembang selama ini. Itu karena dokumen teks sebagai domain masalah tidak benar-benar berkembang banyak (halaman masih halaman, paragraf masih paragraf, dll). Namun, antarmuka pengguna Word banyak berkembang (dan terus berlanjut). Kode untuk presentasi atau input cenderung tidak stabil di antara versi, jadi sebaiknya tidak ada bagian lain dari sistem yang digabungkan secara langsung (untuk melindungi mereka dari penulisan ulang).

Arsitektur perangkat lunak yang dapat memisahkan presentasi dari logika dan data yang mendasarinya tentang masalah memungkinkan penulisan ulang yang lebih sedikit. Banyak pola perangkat lunak seperti pemisahan Model-View muncul karena orang-orang seperti Anda menderita karena banyak menulis ulang, dan mencari cara yang lebih baik.

Ini mungkin terdengar sangat Buddhis, tetapi Anda beruntung telah menderita penulisan ulang ini! Begitu banyak orang belajar tentang pola MVC atau pola desain lain tanpa harus "menderita" menulis ulang mimpi buruk pola yang seharusnya dihindari.


Saya lebih suka jawaban ini diterima. Iterasi menuju solusi lebih baik daripada mencoba mengatur semua persyaratan di muka. Terutama jika seluruh aplikasi dapat ditulis ulang dalam sehari.
Euforia

Saya yakin bos tidak tahu apa yang mereka inginkan dalam iterasi kedua sampai yang pertama selesai. “Mengumpulkan lebih banyak persyaratan sebelumnya tidak mungkin.
gnasher729

1

Saya tidak punya jawaban, sebanyak latihan - yang mungkin harus Anda lakukan di waktu Anda sendiri, meskipun tergantung pada organisasi Anda, Anda mungkin bisa mendapatkan izin untuk melakukannya selama jam kerja.

Desain ulang solusi pertama Anda untuk melakukan apa yang dilakukan, tetapi membuatnya lebih mudah untuk menambahkan langkah ke-2 atau ke-2 dan ke-3. Jangan menambahkan langkah-langkah itu, jangan mematikannya. Cukup buat solusi yang memenuhi semua persyaratan asli tetapi dapat dengan mudah ditingkatkan untuk menyertakan fitur baru. Lakukan hal yang sama untuk solusi kedua Anda.


1

Persyaratan berubah, itu fakta kehidupan. Di belakang: Mungkinkah solusi pertama berbeda sehingga total waktu pemrograman akan lebih sedikit? Itulah yang Anda pelajari bagaimana melakukannya dengan pengalaman.

Itu kurva pembelajaran curam pertama. Ketika Anda mengelola ini, akan ada tantangan kedua: Bagaimana Anda menangani persyaratan yang berubah ketika pengguna telah menyimpan data satu tahun yang tidak ingin mereka buang?


-1

Dari kisah Anda, jelas bahwa persyaratan dan keputusan arsitektur yang disukai belum dikomunikasikan dengan cukup baik. Karenanya salah satu dari Anda, atau mungkin keduanya, adalah komunikator yang buruk.

Mungkin juga arsitek, karena beberapa arsitek mendapatkan status tinggi untuk pencapaian yang baik ketika pemrograman sendiri, atau pendidikan yang hebat (yang juga paling sering tentang belajar sendiri), atau menjadi pengembang pertama di perusahaan (jelas saja) dan tidak perlu baik dalam berkomunikasi dengan tim. Tidak jarang bagi mereka untuk terus fokus pada pemrograman daripada mendokumentasikan desain dan mendukung tim.

Namun juga dalam hal ini Anda dapat mencoba kompensasi dengan berbicara lebih lama, mengajukan pertanyaan dan membuat catatan. Anda bahkan dapat menulis spesifikasi kecil sendiri dan meminta arsitek untuk menyetujuinya.

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.