Apakah mungkin untuk menulis perangkat lunak yang tidak perlu terus dimodifikasi?

Saya telah menulis banyak perangkat lunak dalam berbagai bahasa, dan saya juga telah "menulis" perangkat keras untuk digunakan dengan FPGA menggunakan Verilog dan VHDL.

Saya cenderung menikmati menulis perangkat keras lebih dari perangkat lunak, dan saya pikir salah satu alasan utama adalah bahwa adalah mungkin untuk menulis perangkat keras yang "selesai" dan tidak pernah perlu dimodifikasi: Anda mendefinisikan antarmuka dan fungsionalitas, menulis bangku tes , laksanakan modul perangkat keras, lalu uji coba menggunakan simulator. Kemudian Anda dapat mengandalkan modul perangkat keras itu sebagai blok penyusun untuk membuat sesuatu yang lebih besar dan lebih baik: jika Anda perlu menambahkan fitur ke modul itu, Anda membuat modul kedua dan menambahkan fungsionalitas di sana. Anda tidak pernah membuang modul asli karena berfungsi dengan baik dan masih bisa bermanfaat.

Salah satu frustrasi utama saya dengan perangkat lunak adalah bahwa hal itu tidak pernah "dilakukan". Selalu ada fitur lain untuk ditambahkan. Seringkali ketika menambahkan fitur itu memperkenalkan bug di tempat lain yang berfungsi dengan baik sebelumnya. Ini tidak terjadi pada perangkat keras selama antarmuka tidak dilanggar.

Untuk lebih jelasnya, saya tidak menganjurkan membangun satu versi dari sesuatu dengan daftar fitur dan hanya untuk selamanya: Saya mendukung iterasi dan beberapa rilis dari waktu ke waktu untuk menambahkan fitur baru. Saya hanya tidak ingin menyodok kode di sebelah kiri dan menemukan bug di sebelah kanan, dan ini tampaknya terjadi setelah menambahkan fitur baru.

Apakah mungkin untuk menulis perangkat lunak dengan cara yang sama di mana perangkat keras "ditulis"? Apakah ada metodologi pengembangan perangkat lunak yang baik yang memungkinkan kemajuan ke depan selalu dibuat dan memungkinkan fungsionalitas baru ditambahkan tanpa perlu menulis ulang kode yang ada dan memperkenalkan bug baru?

Mungkin ada hubungannya dengan antarmuka dan pengujian yang terdefinisi dengan baik, seperti perangkat keras?

Pikiranku persis!

Modul yang dirancang dengan baik dengan antarmuka yang jelas cenderung pada dasarnya sempurna. Pikirkan sesuatu seperti Stringkelas Jawa. Ini adalah program komputer, tetapi memiliki antarmuka yang sangat jelas. Tidak ada bug yang dikenal di dalamnya. Itu melakukan apa yang seharusnya dilakukan, dengan sempurna. Tentu, itu telah diuji secara luas selama 15 tahun terakhir, dan karena hampir semua program menggunakan Strings sebagai blok bangunan dasar, bug apa pun di dalamnya akan cepat diketahui. "Keunikan" apa pun - tidak sepenuhnya bug, tetapi detail desain perlu diperhatikan - seperti yang dijelaskan di sini http://www.jwz.org/doc/java.html sudah dikenal saat ini, dan dengan demikian dapat dimasukkan ke dalam rekening.

Perangkat lunak Buggy sebagian merupakan masalah budaya: orang-orang terbiasa dengan perangkat lunak kereta, dan tidak seperti perangkat keras, perangkat lunak biasanya dapat dengan mudah diperbaiki setelahnya, sehingga tidak harus sempurna pada awalnya (atau sebelumnya, karena hei, kita harus mengirim sekarang, mari perbaiki di versi berikutnya). Tetapi sebagian besar, ini adalah masalah kompleksitas nyata: kompleksitas perangkat lunak telah meningkat dengan stabil selama sekitar 50 tahun terakhir, tetapi otak manusia tetap sama. Ketika semakin sulitnya mencapai kesempurnaan dan semakin mudahnya memperbaiki hal-hal di kemudian hari (cepat, otomatis, distribusi internet) bergabung dengan tekanan jadwal dan kurangnya disiplin, hasilnya adalah apa adanya.

Apakah ada metodologi pengembangan perangkat lunak yang baik yang memungkinkan kemajuan ke depan selalu dibuat dan memungkinkan fungsionalitas baru ditambahkan tanpa perlu menulis ulang kode yang ada dan memperkenalkan bug baru?

Mungkin tidak ada peluru perak, tetapi kombinasi yang baik dari praktik terbaik, termasuk tetapi tidak terbatas pada:

• Modul sederhana dan otonom. Dengan kata lain, kopling rendah dan kohesi tinggi.
• Kekekalan. Terutama penting dengan pertumbuhan konkurensi.

Perlu dicatat bahwa kedua poin tersebut bertujuan mengurangi kompleksitas. Itulah poin kuncinya. Entropi selalu cenderung meningkat, dan kecuali kita melawannya, kita akan segera tenggelam dalam kompleksitas. Sangat menarik untuk melihat bahwa selama beberapa tahun terakhir, bahasa pemrograman telah berkembang ke arah mendorong atau bahkan menegakkan praktik yang disebutkan di atas. Khususnya, munculnya bahasa fungsional hanya itu: fungsi murni selalu mengembalikan nilai yang sama untuk input yang sama, tidak ada keadaan di dalamnya. Kemudian Anda hanya membuat fungsi-fungsi murni yang mengambil dan mengembalikan nilai-nilai yang tidak dapat diubah , dan membatasi mutabilitas yang tak terhindarkan ke tempat-tempat kecil yang terdefinisi dengan baik alih-alih menyebarkannya ke mana-mana. Lihat ini: http://clojure.org/state

Perbedaannya adalah seberapa jauh lebih mudah dan lebih murah untuk memodifikasi perangkat lunak dibandingkan dengan perangkat keras. Jika perangkat keras semudah dan murah untuk dimodifikasi dan dikirim ke pelanggan, mereka akan melakukannya.

Saya pikir jika saya dapat meringkas pertanyaan saya yang kurang terekspresikan, itu akan seperti, "bagaimana saya bisa memiliki lebih banyak perangkat lunak penulisan yang menyenangkan dengan tidak memasukkan bug ke dalam kode kerja dan selalu membuat kemajuan di masa depan?" Mungkin ada hubungannya dengan antarmuka dan pengujian yang terdefinisi dengan baik, seperti perangkat keras?

Anda pasti harus memeriksa pengembangan yang digerakkan oleh tes .

Saya akan mengomentari beberapa komentar Anda, berharap Anda mendapatkan jawaban dari komentar ini.

Salah satu frustrasi utama saya dengan perangkat lunak adalah bahwa hal itu tidak pernah "dilakukan".

Ini karena spesifikasi solusi tidak lengkap atau karena rencana untuk memberikan peningkatan tidak akurat. Ini dapat terjadi pada perangkat lunak proyek apa pun, perangkat keras, atau lainnya.

Apakah ada metodologi pengembangan perangkat lunak yang baik yang memungkinkan kemajuan ke depan selalu dibuat dan memungkinkan fungsionalitas baru ditambahkan tanpa perlu menulis ulang kode yang ada dan memperkenalkan bug baru?

Tentu saja, membuat modul independen harus sangat mengurangi ketergantungan. Ini harus dipertimbangkan ketika Anda merancang perangkat lunak. Anda perlu mempertimbangkan, memisahkan masalah, lapisan, tingkatan, objek pengontrol, antarmuka, dll.

"Bagaimana saya bisa memiliki lebih banyak perangkat lunak penulisan yang menyenangkan dengan tidak memasukkan bug ke dalam kode kerja dan selalu membuat kemajuan?"

1-Memahami persyaratan dengan cermat. Mungkin Anda perlu mempertimbangkan untuk menutup persyaratan sebelum desain. Jika Anda melakukan pengembangan berulang, tidak ada kesempatan untuk melakukan ini. Beberapa metodologi mendorong ini, tetapi secara pribadi, saya pikir ini tidak baik untuk semua jenis proyek. Membangun perangkat lunak dengan persyaratan yang solid memungkinkan desain yang lebih baik.

2-Buat pengguna Anda memahami filosofi jangka panjang ini.

Implementasi 3-Plan dengan hati-hati

4-Desain sebelum kode.

5-Gunakan desain generik bila perlu.

6-Gunakan prototipe sebagai alat konfirmasi desain.

Karena orang biasanya sangat cepat untuk menunjukkan, salah satu manfaat dari perangkat lunak adalah bahwa itu seharusnya mudah dan relatif murah untuk diubah dibandingkan dengan perangkat keras. Ini sangat penting ketika Anda terlambat menyadari bahwa Anda mendapatkan sesuatu yang secara fundamental salah. Lakukan hal yang sama dengan perangkat keras, dan Anda kehilangan satu juta dolar, jadi seperti yang Anda katakan, Anda menggunakan simulator Anda dll, dan Anda menguji bazinga itu. Saya pikir ini adalah paradigma yang gagal ketika Anda beralih ke perangkat lunak.

Masuki kepala pengembang perangkat lunak biasa, dan yang Anda miliki adalah orang yang sangat sibuk dengan tenggat waktu yang sangat ketat. Manajernya mengatakan tidak masalah untuk meninggalkan beberapa bug karena Anda selalu dapat memperbaikinya nanti. Tes seringkali merupakan renungan, tetapi bahkan dalam skenario yang didorong oleh tes, tes tetap minimal dan kode ditulis seminimal mungkin, dan sering kali pintasan diambil sehingga banyak kasus batas mungkin terlewatkan. Sistem ini mungkin diuji secara menyeluruh namun jarang diuji secara ketat, dan jarang juga diuji stres pada tingkat yang besar. Tambahkan ke ini bahwa Anda menulis perangkat lunak dari awal, dan ada sedikit kesempatan untuk mensimulasikan perangkat lunak sebelum Anda berkomitmen untuk menulisnya, terutama karena kami jarang menulis perangkat lunak dari jenis yang sama dari blok bangunan berbutir halus yang akan Anda temukan di perangkat keras.

Kembali ke pertanyaan OP. Bisakah Anda mendefinisikan suatu sistem blok bangunan dari mana untuk memperoleh semua perangkat lunak Anda? Mungkin. Apakah ini sangat hemat biaya? Mungkin tidak, karena saat Anda mulai mengembangkan sistem komponen, pengujian, dan peralatan lain yang cukup kuat untuk mendukung cita-cita ini.sistem pemrograman, Anda akan menemukan bahwa pesaing Anda akan mengalahkan Anda ke pasar, dan lebih buruk lagi, dari perspektif programmer rata-rata Anda mungkin akan menemukan gaya "cookie-cutter" sistem pemrograman menjadi sangat membatasi dan lebih mungkin sangat membosankan. Saya pribadi bekerja pada API, di mana sebagian besar kode modul telah disempurnakan dan distandardisasi sepenuhnya, sehingga yang saya lakukan sekarang hanyalah membuat templat kode dan mengisi bagian yang kosong. Sebagian besar waktu saya dapat dihabiskan untuk menulis kode konektor sederhana, dan mengeluarkan modul secepat mungkin. Ini sangat mematikan pikiran. Ada sangat sedikit kesempatan untuk melakukan lebih dari sekedar kode hal-hal yang sama berulang-ulang, jadi ketika kesempatan proyek lain datang, saya melompat pada kesempatan untuk dapat melakukan APA SAJA yang lain.

Jadi bagaimana Anda bisa memberikan perangkat lunak yang berkualitas tinggi dan berfaktor dengan baik, namun tetap menikmati diri Anda melakukannya? Saya percaya ini tergantung pada pilihan alat dan metodologi Anda. Bagi saya jawabannya adalah menggunakan penggunaan API BDD yang baik, karena memungkinkan saya membuat kode yang mudah dibaca, namun sangat granular. Saya dapat membuat serangkaian tes dari sejumlah kecil metode yang dapat digunakan kembali, dan menjelaskan tes saya dalam bahasa spesifikasi. Dengan cara ini, saya mendekati pendekatan pengembangan yang lebih berbasis komponen, kecuali kenyataan bahwa saya bertanggung jawab untuk merancang dan memeriksa blok bangunan. Selain itu, hasil tes menunjukkan dengan tepat bagian dari tes di mana kegagalan terjadi, sehingga saya tidak perlu menebak apakah kegagalan ada di pengaturan atau pernyataan.

Menyetel metodologi Anda juga membantu. Saya seorang advokat besar untuk menerapkan prinsip-prinsip pembangunan lean, dan menggabungkannya dengan banyak teknik dan kepala sekolah lain yang telah digerakkan oleh gerakan Agile selama bertahun-tahun sekarang. Setelah menghilangkan sebagian besar praktik boros yang biasa saya temukan sehingga membuat frustrasi telah membantu banyak untuk membuat pengembangan menjadi kegiatan yang lebih menyenangkan. Saya masih menyisakan masalah yang kadang-kadang - tetapi mudah-mudahan tidak terlalu sering - bug akan muncul dalam kode saya, namun sekarang saya menemukan diri saya dengan lebih banyak waktu, dan bahkan lebih banyak insentif untuk menghabiskan lebih banyak waktu menulis tes yang lebih kuat, dan bertujuan untuk 100 % cakupan tes. Lebih baik lagi, rasanya sangat menyenangkan melihat semua lampu hijau itu muncul di penghujung hari saya,

Salah satu frustrasi utama saya dengan perangkat lunak adalah bahwa hal itu tidak pernah "dilakukan". Selalu ada fitur lain untuk ditambahkan.

Jika itu membuat Anda frustrasi, pertimbangkan karier yang berbeda. Serius.

The titik dari perangkat lunak untuk dapat menambahkan fitur. Seluruh alasan untuk menciptakan "perangkat lunak" di tempat pertama adalah agar kami dapat menambahkan fitur.

Seringkali ketika menambahkan fitur itu memperkenalkan bug di tempat lain yang berfungsi dengan baik sebelumnya.

Itu masalah QA.

Ini tidak terjadi pada perangkat keras selama antarmuka tidak dilanggar.

Itu juga benar dalam perangkat lunak.

Apakah ada metodologi pengembangan perangkat lunak yang baik yang memungkinkan kemajuan ke depan selalu dibuat dan memungkinkan fungsionalitas baru ditambahkan tanpa perlu menulis ulang kode yang ada dan memperkenalkan bug baru?

Iya nih. Anda harus benar-benar mempraktikkan Jaminan Kualitas.

Apakah mungkin untuk menulis perangkat lunak dengan cara yang sama di mana perangkat keras "ditulis"? Apakah ada metodologi pengembangan perangkat lunak yang baik yang memungkinkan kemajuan ke depan selalu dibuat dan memungkinkan fungsionalitas baru ditambahkan tanpa perlu menulis ulang kode yang ada dan memperkenalkan bug baru?

Saya sarankan Anda melihat ke " metode formal " untuk memverifikasi kebenaran desain dan perangkat lunak. Alat simulator yang Anda gunakan untuk desain perangkat keras berusaha melakukan sesuatu yang dekat. Saya tidak percaya bahwa alat untuk metode formal mendekati berguna dalam industri saat ini, dan satu-satunya industri yang memiliki insentif kuat untuk bebas cacat adalah avionik dan obat - obatan (cukup menarik, FDA dengan jelas mengatakan "perangkat lunak berbeda dari perangkat keras "pada tautan itu). Selanjutnya, jika Anda mengembangkan dengan Verilog / VHDL, maka Anda tetap menggunakan logika biner. Ini secara drastis mengurangi kompleksitas. Tidak akan ada hardware yang setara dengan masalah Y2K.

Masalah besar adalah bahwa semuanya rumit. Dan Anda tidak dapat menghilangkan kompleksitas, Anda hanya dapat memindahkannya.

adalah mungkin untuk menulis perangkat keras yang "selesai" dan tidak perlu dimodifikasi: Anda mendefinisikan antarmuka dan fungsionalitas, menulis bangku tes, menerapkan modul perangkat keras, kemudian menguji hal itu menggunakan simulator. Kemudian Anda dapat mengandalkan modul perangkat keras itu sebagai blok penyusun untuk membuat sesuatu yang lebih besar dan lebih baik: jika Anda perlu menambahkan fitur ke modul itu, Anda membuat modul kedua dan menambahkan fungsionalitas di sana. Anda tidak pernah membuang modul asli karena berfungsi dengan baik dan masih bisa bermanfaat.

Di dunia peranti lunak, kami menyebutnya "modul" perpustakaan, dan kami menggunakannya dengan cara yang sama. Banyak perpustakaan dibangun ke titik yang berfungsi dengan baik, dan kemudian duduk dengan puas melakukan pekerjaan mereka tanpa perubahan sampai Sesuatu Penting mengarah ke revisi berikutnya. Anggap mereka sebagai perangkat lunak yang telah pot dengan epoksi :-)

Salah satu frustrasi utama saya dengan perangkat lunak adalah bahwa hal itu tidak pernah "dilakukan". Selalu ada fitur lain untuk ditambahkan. Seringkali ketika menambahkan fitur itu memperkenalkan bug di tempat lain yang berfungsi dengan baik sebelumnya. Ini tidak terjadi pada perangkat keras selama antarmuka tidak dilanggar.

Omong kosong. Mungkin Anda secara pribadi lebih baik daripada banyak orang "perangkat keras" non-solder-besi, tetapi saya telah melihat sejumlah desain sirkuit yang buruk, kegagalan chip ( misalnya , masalah Intel "f00f" yang terkenal), tetapi itu tidak berbicara ke lapangan secara keseluruhan. Dan ketika perangkat palsu menjadi "lebih lunak", masalahnya menjadi lebih sulit untuk dicegah.

Apakah mungkin untuk menulis perangkat lunak dengan cara yang sama di mana perangkat keras "ditulis"? Apakah ada metodologi pengembangan perangkat lunak yang baik yang memungkinkan kemajuan ke depan selalu dibuat dan memungkinkan fungsionalitas baru ditambahkan tanpa perlu menulis ulang kode yang ada dan memperkenalkan bug baru?

Iya nih. Kami hanya tidak menggunakan metodologi itu banyak. Mereka cenderung sangat mahal untuk beroperasi, dan sebagian besar programmer tidak suka bekerja dalam batasan mereka. Tetapi ketika kehidupan manusia terlibat, misalnya, yah, kami berusaha untuk tidak membunuh pengguna.

Satu poin terakhir: Perangkat lunak memiliki model keuangan yang berbeda dari perangkat keras, bahkan perangkat keras yang diprogram. Sebagian besar perangkat lunak non-konsumen, dan beberapa perangkat lunak konsumen juga, dijual dengan cara yang mendorong perubahan. Ketika Anda dapat memberi tahu bisnis "Bayar kami $ 10.000 sekarang ditambah 18% setahun", Anda pada dasarnya dapat menjual kembali produk tersebut setiap beberapa tahun. Tetapi untuk membenarkan biaya itu, Anda perlu memberi pelanggan perubahan yang mereka inginkan. Hmm ... memikirkan kurva usang perangkat keras Apple, mungkin ini bukan perbedaan - perangkat keras hanya membuat Anda benar - benar membelinya kembali!

bagaimana saya bisa lebih menyenangkan menulis perangkat lunak dengan tidak memasukkan bug ke dalam kode kerja dan selalu membuat kemajuan?

Saya akan senang menemukan jawaban akhir untuk pertanyaan Anda. Tetapi kenyataannya adalah bahwa tidak ada cara mudah untuk melakukannya, itu sebabnya pemrograman ekstrem dan teknik TDD menjadi sangat populer. Anda perlu merangkul perubahan, karena itu akan terjadi. Saya tidak tahu apakah ini lebih lucu dari ini, tapi pasti jauh lebih sedikit stres ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

Ketika Anda berinteraksi dengan perangkat keras, perangkat keras membutuhkan nilai x dan itu semua (dalam teori), tetapi ketika Anda berinteraksi dengan orang-orang hari ini mereka membutuhkan x, dan besok mereka dapat membutuhkan y, dll. Begitulah adanya, bisnis dan kebutuhan orang berubah . Karena Orang! = Mesin, maka kode yang TIDAK PERNAH berubah sebagian besar kali tidak mungkin.

Juga seperti yang saya katakan pada jawaban saya sebelumnya / dihapus, cobalah untuk menghindari perubahan yang tidak penting dengan membuat orang berpikir sebelum memulai pengkodean. Libatkan pengguna lebih banyak dalam pengambilan keputusan, dll. Perjelas biaya perubahan, rencanakan lebih banyak, dll. Itu bukan "cara pengkodean", adalah cara "tidak pengkodean" karena dengan lebih banyak tentang persyaratan, akan ada lebih sedikit perubahan dan lebih menyenangkan.

Apakah mungkin untuk menulis perangkat lunak dengan cara yang sama?

Ya itu. Berhati-hatilah seolah-olah Anda sedang mengembangkan perangkat keras, uji semua yang Anda bisa, dan perangkat lunak Anda akan memiliki kualitas yang sama.

Ngomong-ngomong, apakah Anda belum pernah mendengar tentang bug HW? Jauh lebih jahat daripada bug SW dan lebih sulit untuk diperbaiki (tidak hanya memutakhirkan perangkat lunak)

Saya juga akan menunjukkan bahwa bug perangkat lunak dalam perangkat keras sering kali dapat membunuh orang. Jadi ada lebih banyak perhatian yang diambil untuk menentukan persyaratan secara menyeluruh dan mengujinya secara ekstensif di muka. Dan persyaratan itu tidak perlu diubah sampai perangkat kerasnya berubah. Dan karena perangkat keras baru mungkin memerlukan penulisan ulang, saya menduga cruft juga tidak terlalu banyak menumpuk.

Di sisi lain, kebutuhan bisnis berubah secara konstan, kadang-kadang Anda hampir tidak dapat memasukkan satu persyaratan ke dalam produksi sebelum perubahan diminta. Kadang-kadang, saya mengalami perubahan persyaratan beberapa kali sebelum mulai berproduksi. Ini adalah hasil dari beberapa hal. Pertama para pemangku kepentingan proyek di sisi bisnis sering kurang tertarik menghabiskan waktu untuk secara menyeluruh mendefinisikan apa yang dia inginkan karena dia "sibuk" dan "penting" dan orang tidak akan mati dan keluarga menuntutnya atau membuatnya dijebloskan ke penjara jika dia menghancurkan bagian dari proses itu. Kedua, para pemangku kepentingan proyek cenderung memiliki ide yang lebih baik tentang apa yang mereka inginkan dari perangkat keras karena kurang abstrak bagi mereka. Mereka benar-benar tidak tahu apa yang mereka inginkan sampai mereka melihatnya. Yang kurang dari masalah dengan Hardware.

Ada alat tingkat tinggi dengan banyak 'batu bata' selesai, seperti yang Anda sebut, yang dapat Anda gabungkan ke dalam aplikasi. Batu bata adalah potongan jadi untuk Anda gunakan, Anda hanya perlu menggabungkannya. Mungkin Anda pikir itu lebih mudah ... sampai pelanggan Anda meminta Anda untuk beberapa perubahan aneh dan tak terduga.