Pemrograman paradigma dan pengembang pemeliharaan [ditutup]

9

Saya sedang membaca, Fakta dan Kekeliruan Rekayasa Perangkat Lunak, yang memiliki bagian pemeliharaan. Karena, saya telah menjadi pengembang pemeliharaan selama bertahun-tahun sekarang, saya menyajikan fakta yang sangat menarik. Ini tiga.

Fakta 41: Pemeliharaan biasanya menghabiskan 40 hingga 80 persen (rata-rata, 60 persen) dari biaya perangkat lunak. Oleh karena itu, ini mungkin merupakan fase siklus hidup terpenting dari perangkat lunak.
Fakta 42: Peningkatan bertanggung jawab atas sekitar 60 persen dari biaya pemeliharaan perangkat lunak. Koreksi kesalahan sekitar 17 persen. Oleh karena itu, pemeliharaan perangkat lunak sebagian besar tentang menambahkan kemampuan baru ke perangkat lunak lama, bukan memperbaikinya.
Fakta 45: Pengembangan rekayasa perangkat lunak yang lebih baik mengarah pada lebih banyak pemeliharaan, bukan lebih sedikit.

Yang ini kontra-intuitif, ternyata perangkat lunak yang baik memiliki lebih banyak perawatan, karena mudah diubah. Oleh karena itu, ia tetap digunakan lebih lama, mengarah ke, ya, lebih banyak perubahan.

Paradigma mana (seperti fungsional, berorientasi objek, prosedural) yang memiliki kemampuan pemeliharaan terbaik, dan adakah penelitian untuk mendukung hal ini?

maintenance maintainability

— KaizenSoze
sumber

Saya memiliki salinan Fakta dan Kekeliruan, dan untuk setiap fakta (dan kekeliruan), ada kutipan untuk berbagai publikasi yang mendukungnya. Saya tidak punya salinannya, tetapi apakah ada di antara kutipan itu yang membahas efek paradigma pada pemeliharaan?

— Thomas Owens

Buku ini ditulis pada tahun 2003, banyak kesimpulan masih relevan sampai sekarang. Saya ingin tahu apakah orang memiliki studi baru tentang paradigma tertentu. Pemeliharaan tampak seperti bagian yang diabaikan dari diskusi.

— KaizenSoze

Jika ada studi atau publikasi yang dikutip dalam Fakta dan Kekeliruan adalah tentang pemeliharaan paradigma tertentu, salah satu pilihan adalah mencari database IEEE atau ACM untuk artikel dan makalah lain yang mengutip makalah itu. Jika Anda tidak memiliki akses ke database IEEE atau ACM, saya dapat melihat salinan buku saya ketika saya pulang dan melihat apakah saya dapat melakukan pencarian seperti itu. Sayangnya, saya hanya bisa memberi Anda nama surat kabar lain dan bukan surat kabar itu sendiri.

— Thomas Owens

12

Saya pikir Anda akan menemukan bahwa paradigma seperti fungsional, OO, dan prosedural mungkin tidak berhubungan dengan pemeliharaan perangkat lunak dengan cara yang bermakna.

Apa yang mungkin Anda temukan berkorelasi lebih jelas dengan pemeliharaan perangkat lunak:

Tingkat pengumpulan persyaratan dan persyaratan rekayasa
Praktik pengembangan yang baik: (Kopling longgar, Kohesi Tinggi, Pengujian unit, YAGNI ...)
Insinyur perangkat lunak yang terampil dan berkualitas (Mereka bernilai 10 kali lebih banyak daripada orang bodoh)
Tim QA teknis yang berkualitas dan terorganisir
Manajemen proyek yang baik dipimpin oleh manajer proyek yang kompeten (Bahkan lebih sulit ditemukan daripada pengembang perangkat lunak terampil IMHO)
Pemilik Produk atau manajer aplikasi yang baik, kepemimpinan yang kuat, arahan jangka panjang yang baik, umpan balik yang baik untuk tim proyek, visi keseluruhan.

— maple_shaft
sumber

+1 Saya ingin menambahkan dokumentasi yang bagus ke daftar

— treecoder

+1 Tambahkan Proses "Nilai Fokus" ke daftar. Proses mendefinisikan dan mendorong apa yang dilakukan dan tidak dilakukan. Apa yang diukur oleh proses itu penting, dan apa yang tidak diukur oleh proses itu tidak penting. Terutama benar ketika HR guys mulai mengisi kursi dengan "orang bodoh".

— mattnz

2

Yang ini kontra-intuitif, ternyata perangkat lunak yang baik memiliki lebih banyak perawatan, karena mudah diubah. Oleh karena itu, ia tetap digunakan lebih lama, mengarah ke, ya, lebih banyak perubahan.

Anda tampaknya melihat ini dari jumlah pemeliharaan dan bukan persentase biaya. Perangkat lunak bagus yang memiliki lebih banyak fitur yang ditambahkan hanyalah jumlah perangkat lunak yang lebih besar. Jika persentase pemeliharaan diperbaiki (karena itu perangkat lunak yang baik dan kami menganggap fitur tambahan ditambahkan sebagai perangkat lunak yang baik), jumlahnya akan meningkat. Ini hanya sepotong pai yang lebih besar dengan jumlah irisan yang sama.

Berdasarkan apa yang Anda tanyakan, penting apakah perangkat lunak "baik" ditulis dalam: kode fungsional, OOP, atau prosedural. Akankah memberi seseorang kekuatan yang dipandu laser menghemat kayu jika orang itu tidak tahu bagaimana mengukurnya?

— JeffO
sumber