Bagi banyak orang IT, termasuk saya beberapa tahun yang lalu, proses pengembangan perangkat lunak yang ideal akan melibatkan pembuatan dokumen desain terperinci dengan banyak diagram UML sebelum satu baris kode ditulis. (Ini terlihat seperti deskripsi model air terjun tapi sama dengan lincah, kecuali bahwa iterasi lebih kecil.)
Selama dua atau tiga tahun terakhir, saya benar-benar berubah pikiran. Saya masih berpikir bahwa spesifikasi persyaratan terperinci dengan kasus uji terkait sangat penting. Untuk proyek besar, saya juga membutuhkan garis besar arsitektur keseluruhan sebelum mulai kode. Tetapi semua yang lain harus dilakukan dalam kode sebanyak mungkin. Dalam kasus yang ideal seharusnya tidak ada deskripsi desain perangkat lunak kecuali kode itu sendiri.
Bagaimana saya sampai pada kesimpulan ini? Berikut beberapa argumen:
Umpan balik
Alat untuk menulis dokumen atau membuat diagram memberikan sedikit umpan balik. Ya, ada alat pemodelan yang melakukan beberapa pemeriksaan konsistensi pada diagram UML tetapi mereka terbatas dan memiliki banyak overhead.
Tanpa umpan balik, sulit untuk mengenali dan memperbaiki kesalahan.
Segera setelah Anda menulis kode, Anda mendapat banyak umpan balik, misalnya:
- Kesalahan dan peringatan dari kompiler
- Hasil analisis kode statis
- Tes unit
Kesalahan dapat dengan cepat dikenali dan diperbaiki.
Konsistensi
Untuk memastikan bahwa kode tersebut konsisten dengan dokumen Anda, Anda harus memeriksa lagi dan lagi. Jika sering ada perubahan, sulit untuk menjaga kode dan dokumen tetap sinkron.
Refactoring
Ada alat dan teknik yang kuat untuk kode refactoring sementara refactoring deskripsi atau diagram biasanya sulit dan rentan kesalahan.
Ada satu prasyarat untuk membuat ini berfungsi: Kode harus cukup mudah dibaca dan dipahami. Ini mungkin tidak dapat dicapai dengan Assembler, Basic atau Fortran tetapi bahasa modern (dan perpustakaan) jauh lebih ekspresif.
Jadi, jika argumen saya valid, harus ada kecenderungan ke arah spesifikasi dan dokumentasi desain perangkat lunak yang kurang atau lebih ringan. Apakah ada bukti empiris untuk tren ini?
sumber
Jawaban:
Saya mempertanyakan premis bahwa bahasa lebih dan lebih ekspresif. Dengan kode ASP.NET hari ini di c #, saya menulis pada tingkat yang sama seperti yang saya lakukan ketika saya menulis kode ASP dalam Visual Basic. Kami masih menggunakan c ++. Javascript telah menambahkan fitur tetapi secara keseluruhan bahasa tidak berubah. Sama dengan SQL.
Saya pikir perubahan lain ini lebih penting:
Adopsi tes unit otomatis. Beberapa akan mengatakan bahwa tes adalah spesifikasinya. Jadi kami belum menghilangkan kebutuhan untuk menulis spesifikasi; alih-alih, kami menulisnya dalam kode daripada di dokumen Word.
Perubahan dalam metodologi penyebaran. Di masa lalu itu sangat mahal untuk membuat kesalahan karena Anda perlu mengirimkan salinan pembaruan perangkat lunak Anda. Jadi kamu harus hati-hati. Dengan aplikasi berbasis web, Anda dapat menggunakan perbaikan untuk segera digunakan, dan Anda dapat bereaksi terhadap masalah alih-alih mengantisipasi mereka, merestrukturisasi kode saat berjalan.
Adopsi pola desain. Ketika semua orang tahu polanya, Anda tidak perlu merancang apa pun; Anda bisa mengatakan "tambah pabrik repositori" dan tim Anda harus melakukannya tanpa perlu melihat UML.
Kontrak data SOA. Hampir semuanya adalah SOA hari ini. Yang Anda butuhkan hanyalah WSDL. Hari-hari mendefinisikan dan mendokumentasikan format transfer data hilang. Pergerakan saat ini ke arah yang lebih tenang dan layanan mikro melanjutkan tren ini.
Perangkat lunak lebih kecil. Sebagian sebagai hasil dari arsitektur SOA, tim menulis program yang lebih kecil yang diikat bersama. Setiap komponen individu kurang kompleks dan membutuhkan desain muka yang lebih sedikit; juga, lebih mudah untuk mengubah bagian arsitektur tanpa memecahkan solusi keseluruhan karena pemadaman api yang dipaksakan oleh definisi antarmuka antar komponen.
Jauh lebih banyak menggunakan perpustakaan yang sudah ada. .NET CLR menawarkan banyak fungsionalitas dari rak, jadi tidak perlu merancang, katakanlah, skema untuk caching data sesi. Perpustakaan pihak ketiga seperti jQuery UI atau Bootstrap menetapkan standar untuk menulis kode agar bekerja dengan cara tertentu. Anda tidak perlu mendokumentasikan ini; tim harus bisa menggunakannya.
Kematangan industri. SWE telah belajar bahwa tidak ada yang namanya proyek "Battlestar Galactica" di mana Anda menghabiskan waktu bertahun-tahun untuk mencapai tujuan tertentu; pada saat tahun-tahun itu berlalu, tujuannya akan berubah. Hari ini kita tahu bahwa waktu memasarkan jauh lebih penting daripada mendapatkan semuanya persis seperti yang kita inginkan dalam desain.
Insinyur yang berpendidikan lebih baik dan lebih konsisten. Saat ini Anda dapat merekrut insinyur yang memahami praktik terbaik (mudah-mudahan) dan hanya akan mengimplementasikannya tanpa dokumen desain yang memberi tahu mereka apa yang harus dilakukan.
Alat produktivitas seperti TFS memungkinkan Anda untuk menulis tugas sederhana yang merujuk pada use case dan memberikan beberapa poin untuk setiap keputusan teknis yang ambigu. Anda tidak perlu lebih dari itu. Pengembang dapat meninjau, memperkirakan, mendapatkan ulasan kode, memeriksa, dll semuanya melalui alat. Ini jauh lebih efisien daripada bekerja dengan dokumen eksternal karena ini mengikat semuanya.
Anda masih memerlukan dokumen desain untuk beberapa hal ... misalnya, jika aplikasi Anda dipecah menjadi beberapa komponen yang dikembangkan oleh tim yang berbeda, Anda setidaknya perlu memberi tahu mereka komponen mana yang bertanggung jawab untuk persyaratan mana. Tetapi sebagian besar, metodologi pengembangan saat ini memungkinkan lebih banyak kebebasan sambil memberi Anda alat untuk mengelola dan mengandung risiko yang mungkin timbul dari pengembang yang membuat keputusan yang buruk.
sumber
Saya berpendapat untuk No .
Untuk alasan sederhana itu
Tidak pernah dianggap "ideal", karena Extreme Programming sudah ada sejak 1990-an . Dan seperti yang Anda katakan:
Telah diperdebatkan sejak lama. Misalnya artikel legendaris ini dari tahun 1992: Apa itu Desain Perangkat Lunak .
Di atas menunjukkan bahwa Anda dapat memiliki proses "ekstrem" dengan arsitektur yang sangat evolusioner dan pendekatan berulang tanpa perlu bahasa atau IDE yang kompleks.
Alih-alih, saya akan mengatakan perubahan "yang kelihatannya" ini dari desain di muka dengan banyak diagram dan menggunakan dokumen kasus ke pendekatan yang lebih evolusioner dan berulang hanyalah manajer "sekolah lama" diganti dengan yang baru, yang tumbuh lebih banyak lingkungan yang dinamis dan untuk siapa lebih mudah untuk menerima dan bekerja di lingkungan yang lebih "gesit".
sumber
Saya cukup setuju dengan ini tetapi saya pikir ini dimulai jauh lebih awal daripada yang Anda maksudkan. Saya juga berpikir bahwa ada faktor besar lain selain dari ekspresif. Ketika ayah saya pertama kali memulai pemrograman, dia harus membuat kartu berlubang, dan menjadwalkan waktu di komputer. Anda mungkin mendapat satu kesempatan sehari untuk menjalankan program Anda. Tidak ada banyak waktu untuk membuang kode bangunan, membiarkannya gagal, dan kemudian memperbaikinya. Anda mungkin mendapat 2 atau 3 tembakan dan jika tidak berhasil, Anda dalam masalah.
Risiko ini berarti sangat penting untuk menghabiskan banyak waktu ekstra untuk merencanakan program Anda. Orang-orang akan menulis kode mereka dengan pensil, dan kemudian mentransfernya ke kartu yang dilubangi. Seiring kemajuan teknologi, Anda dapat membuat kode langsung ke terminal tetapi Anda masih menggunakan sumber daya bersama dan CPU mahal. Metodologi uji-pertama akan sepenuhnya tidak bisa dipertahankan di dunia itu. Jika Anda tidak berencana, rekan-rekan Anda akan berada di meja Anda dengan garpu rumput.
Sumber daya komputasi telah menjadi lebih murah dan lebih baik dengan kecepatan yang luar biasa. Banyak kendala di mana semua praktik ini dikembangkan sepenuhnya dilenyapkan. Seperti yang Euforia tunjukkan, perpindahan dari ini benar-benar dimulai pada tahun 90-an. Kelanjutan dari sebagian besar desain muka besar adalah inersia murni.
Jadi, ya, peningkatan ekspresifitas bahasa pemrograman telah berdampak pada hal ini dari fakta sederhana bahwa lebih mudah untuk menggunakan kode ekspresif karena dokumentasi itu sendiri. Biaya pembuatan dokumen yang memberi tahu Anda apa yang dikatakan kode sangat tinggi dan nilainya (pasti salah di beberapa tingkat.) Pada saat yang sama biaya membuang kotoran di dinding dan melihat tongkat apa yang pada dasarnya dapat diabaikan.
sumber
Saya pikir Anda lupa tujuan memiliki dokumen desain di tempat pertama!
Dokumen desain (persyaratan, kasus penggunaan, mock-up dll) memungkinkan kita untuk menggambarkan, memahami dan mendiskusikan sistem pada tingkat tinggi. Jumlah detail yang ditinggalkan dari dokumen-dokumen tersebut adalah yang membuatnya berguna.
Tidak perlu memiliki dokumen yang menggambarkan perilaku yang tepat dari sistem sistem dalam semua detail, karena memang kode sumber itu sendiri melayani tujuan ini.
Pengembangan perangkat lunak dapat dianggap sebagai proses mengubah spesifikasi yang dapat dibaca manusia tingkat tinggi menjadi spesifikasi ambigu tingkat rendah yang dapat dieksekusi oleh mesin. Tetapi Anda memerlukan beberapa masukan untuk proses ini.
sumber
Ini lebih jauh dari yang Anda maksudkan. Bahkan hal-hal seperti tipe dependen (yang, seperti yang saya pahami, cukup menjanjikan secara teoritis) sudah beberapa tahun berlalu.
Verifikasi formal cukup sulit, dan untuk alasan itu satu-satunya tempat di mana verifikasi formal umum digunakan adalah perpustakaan kriptografi.
Jika pengujian properti belum mencapai arus utama, saya pikir ini tidak praktis untuk waktu yang lama.
Selain itu, menulis tes yang baik (yang tidak perlu diedit dengan setiap refactor tetapi masih akan menangkap cukup banyak kesalahan) cukup sulit.
Mungkin lebih mudah menggunakan alat pengujian dokumentasi saat ini.
Sayangnya, merancang bahasa yang tidak hanya sangat ekspresif tetapi juga sangat mudah dibaca adalah sulit. Bahasa-bahasa seperti Go memprioritaskan keterbacaan, dan itu mengganggu pikiran tingkat tinggi.
Akhirnya, dalam pengalaman saya, bahasa dan alat yang lebih baik tidak mengarah ke perangkat lunak dengan bug lebih sedikit, tetapi proyek yang lebih besar. Sebenarnya tidak ada cara yang masuk akal
pandocakan ditulis pada tahun 1970.sumber