Apakah kebutuhan akan spesifikasi desain perangkat lunak berkurang secara signifikan dengan evolusi bahasa pemrograman yang lebih ekspresif?

16

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?

— Frank Puffer
sumber

2

Desain dimuka tidak disukai karena pengembangan lincah mendapatkan popularitas sebagai industri dewasa. Bahasa menjadi lebih ekspresif dan alat-alat menjadi lebih ringan membuatnya lebih mudah untuk membuat prototipe dengan cepat, memungkinkan pengembangan yang lebih gesit. Saya pikir ada beberapa penyebab di antara keduanya.

— Pasang kembali Monica

14

Menurut pengalaman saya, "pembuatan dokumen desain terperinci dengan banyak diagram UML sebelum satu baris kode ditulis" tidak pernah merupakan ide yang bagus - setidaknya tidak pada saat saya bekerja sebagai programmer profesional, yang lebih dari satu dekade lebih lama dari UML ada. Namun, membuat sketsa desain tingkat tinggi sebelum pengkodean adalah dan merupakan ide bagus ketika sistem diharapkan memiliki ukuran tertentu. Tapi UML adalah IMHO bukan alat yang tepat untuk ini.

— Doc Brown

2

Terlalu malas untuk jawaban yang tepat: bahasa pemrograman yang lebih ekspresif dan komputer yang lebih kuat mengarah pada kebutuhan untuk program yang semakin mampu dan kompleks, yang mengarah kembali ke spesifikasi persyaratan yang lebih rumit.

— whatsisname

2

Bacaan yang disarankan: Mengalahkan Rata-rata .

— Robert Harvey

1

Saya telah mengerjakan proyek dengan desain UML lengkap. Dari mana kita membuat kode. Saya sampai pada kesimpulan bahwa saya tidak pernah ingin melakukannya lagi. Itu adalah banyak lebih sulit untuk mengubah UML bahwa itu adalah untuk mengubah kode; dan model UML besar setidaknya sama sulitnya dengan banyak kode sumber. Kode "yang dihasilkan" sulit dibaca dan generator meninggalkan "penanda" dalam kode.

— Nick Keighley

9

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.

— John Wu
sumber

3

Industri kami telah matang ... sedikit. Item 5 sejauh ini merupakan perubahan yang paling penting; itu berdampak positif bagi semua yang lain. Tetapi fakta bahwa kami mengubah semua teknologi kami setiap 5 tahun menunjukkan bahwa kami masih memiliki jalan panjang, dan ekspresi bahasa (satu-satunya hal yang relatif stabil dari waktu ke waktu karena peningkatan yang berarti di bidang itu sangat susah payah) menghasilkan lebih banyak keuntungan daripada yang Anda berikan.

— Robert Harvey

1

Ini tidak semua kemajuan: maju utama adalah, anggun, dengan penemuan kompiler. Tetapi kami masih mengajarkan diagram alir, abstraksi pada kode assembler (dan banyak praktik usang lainnya). Mungkin karena kita sudah lupa kenapa?

— ctrl-alt-delor

6

Saya berpendapat untuk No .

Untuk alasan sederhana itu

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.

Tidak pernah dianggap "ideal", karena Extreme Programming sudah ada sejak 1990-an . Dan seperti yang Anda katakan:

Dalam kasus yang ideal seharusnya tidak ada deskripsi desain perangkat lunak kecuali kode itu sendiri.

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".

— Euforia
sumber

6

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.

— JimmyJames
sumber

3

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.

— JacquesB
sumber

Tentu, dokumentasi tingkat tinggi yang tidak berhubungan dengan detail mutlak diperlukan. Tapi itulah yang saya harapkan dari bahasa pemrograman yang bagus. Seharusnya memungkinkan untuk menulis kode pada berbagai tingkat detail. Kode tidak harus berupa kekacauan instruksi tingkat rendah yang tidak terstruktur.

— Frank Puffer

@FrankPuffer diagram bernilai 100.000 LoC.

— RubberDuck

1

@RubberDuck Terjadi pada saya bahwa kemampuan (atau ketiadaan) untuk menghasilkan berbagai diagram yang berguna dari kode bisa menjadi ukuran dari ekspresi bahasa. Tidak ada diagram yang dapat Anda gambar yang tidak dapat diekspresikan dalam beberapa jenis bahasa. Pertanyaannya adalah apakah bahasa itu dapat menyampaikan informasi yang sama dengan cara yang dapat dengan mudah ditulis atau dibaca.

— JimmyJames

1

@RubberDuck: Diagram memang masuk akal dalam beberapa kasus, misalnya untuk menjelaskan keseluruhan arsitektur. Tapi saya tidak berpikir bahwa mereka harus menjadi default. Jelas ada diagram yang baik dan berguna tetapi sayangnya sebagian besar UML yang saya lihat lebih membingungkan daripada membantu. Dan yang lebih buruk, seringkali berbeda dari implementasi yang sebenarnya.

— Frank Puffer

Saya suka bahwa Anda menyebutkan membuat diagram @ JimmyJames. Saya lebih suka generasi daripada pembuatan manual. Anda memiliki poin yang sangat valid, tetapi saya ingin tahu apakah ini merupakan fungsi ekspresif atau perkakas.

— RubberDuck

1

Dalam kasus yang ideal seharusnya tidak ada deskripsi desain perangkat lunak kecuali kode itu sendiri.

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.

Tes unit

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.

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.

Mungkin lebih mudah menggunakan alat pengujian dokumentasi saat ini.

Ada satu prasyarat untuk membuat ini berfungsi: Kode harus cukup mudah dibaca dan dipahami.

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.