Apakah kode yang baik tidak mungkin dalam pengembangan perangkat lunak modern? [Tutup]


19

Tampaknya bahkan alat pengembang menjadi lebih solid dan kuat, menulis kode yang baik telah menjadi tantangan. Meskipun alat-alat itu lebih kuat, kualitas kode tidak menjadi lebih baik. Saya datang dengan dua faktor penting, ada sedikit waktu dan proyek lebih kompleks. Karena alat yang kita gunakan saat ini lebih kuat, lebih mudah untuk menulis kode yang lebih kompleks, tetapi tidak punya waktu untuk merencanakan dan tanpa melihat ke belakang menurunkan kualitas kode dan meningkatkan bug dan pemeliharaan. Bukannya kami tidak menulis kode kompleks sebelumnya. Kita menulis kode yang lebih rumit.

Pertanyaan saya adalah sebagai berikut: Mengingat kita memiliki bahasa dan alat yang lebih kuat.

  • Mengapa menulis kode yang baik lebih sulit?
  • Apakah faktor, waktu, dan kerumitan berkontribusi terhadap hal ini?
  • Apakah metodologi tidak dipraktikkan dengan benar?

Jenis proyek yang saya pertimbangkan adalah aplikasi perusahaan dengan kompleksitas besar dan logika bisnis. Definisi "kode yang baik" adalah perorangan, jangan terjebak dalam interpretasi "kode yang baik".

Jawaban:


34

Seperti yang dinyatakan oleh DeMarco dan Lister di Peopleware sekitar 20 tahun yang lalu, sebagian besar proyek perangkat lunak yang gagal gagal bukan karena tantangan teknis, tetapi masalah sosiologis . Ini tidak berubah dalam dekade terakhir, tidak peduli seberapa banyak alat kami telah membaik.

Manajemen yang salah, harapan yang tidak realistis, gagal mendapatkan orang yang tepat untuk pekerjaan itu, dan / atau tidak membiarkan mereka melakukan pekerjaan mereka, akibatnya gagal mempertahankannya; tempat kerja dan alat yang tidak cocok untuk pekerjaan pengembangan SW; konflik pribadi yang tidak tertangani; politik ; ini hanya beberapa dari masalah-masalah khas yang mungkin membuat proyek hancur sejak awal.

Mengapa menulis kode yang baik lebih sulit?

Saya tidak begitu yakin benar-benar sulit untuk menulis kode yang baik sekarang daripada beberapa dekade yang lalu. Bahkan, dibandingkan dengan kode mesin atau perakitan, semua yang kita miliki sekarang di arus utama lebih mudah untuk ditangani. Hanya kita mungkin perlu menghasilkan lebih banyak.

Apakah hanya karena faktor-faktor yang disebutkan, waktu dan kompleksitas?

Ya, kompleksitas yang dapat dicapai tentu saja meningkat (dan terus meningkat) karena kekuatan alat kami meningkat. Dengan kata lain, kami terus mendorong batas. Yang saya terjemahkan sehingga sama sulitnya untuk memecahkan tantangan terbesar hari ini seperti 30 tahun yang lalu untuk menyelesaikan tantangan terbesar hari itu.

OTOH karena bidang ini telah berkembang sangat pesat, sekarang ada lebih banyak masalah "kecil" atau "diketahui" daripada 30 tahun yang lalu. Masalah-masalah ini secara teknis (seharusnya) tidak menjadi tantangan lagi, tapi ... di sini memasuki pepatah di atas :-(

Juga jumlah programmer sejak itu tumbuh sangat pesat. Dan setidaknya persepsi pribadi saya adalah bahwa tingkat rata-rata pengalaman dan pengetahuan telah menurun, hanya karena ada jauh lebih banyak yunior tiba terus ke lapangan daripada ada senior yang bisa mendidik mereka.

Apakah metodologi tidak dipraktikkan dengan benar?

IMHO tentu tidak. DeMarco dan Lister memiliki kata-kata kasar tentang Metodologi M besar. Mereka mengatakan bahwa tidak ada metodologi yang bisa membuat proyek berhasil - hanya orang-orang dalam tim yang bisa. OTOH metodologi kecil-m yang mereka puji cukup dekat dengan apa yang sekarang kita kenal sebagai "gesit", yang menyebar luas (IMHO karena alasan yang baik). Belum lagi praktik yang baik seperti pengujian dan refactoring unit, yang hanya 10 tahun yang lalu tidak dikenal secara luas, dan saat ini bahkan banyak lulusan tahu ini.


2
Bukan untuk menjadi tata bahasa Nazi atau apa pun selain 'tidak realistis' (Dalam paragraf kedua) bukanlah sebuah kata. Saya pikir maksud Anda 'tidak realistis'.

Saya hanya dapat mendukung masalah "Junior". Saya adalah salah satu dari mereka dan saya tentu berharap memiliki mentor untuk membantu saya. Syukurlah bahwa Internet ada di sana hari ini, dan Amazon dan SO membantu, tetapi masih ...
Matthieu M.

1
+1: Juga patut dicatat, karena perubahan yang cepat dan pertumbuhan alat / teknologi / metodologi, sampai batas tertentu kita semua junior setidaknya dua kali setahun. Pengalaman hanya memungkinkan beberapa dokter hewan untuk meningkatkan kecepatan lebih cepat daripada beberapa jam.
Steven Evers

Saya menolak untuk menanggapi pertanyaan ini dengan serius kecuali kami tidak memiliki aturan formal untuk memisahkan kode yang indah dari kode yang jelek.
shabunc

17

Masalah yang terkait dengan pengkodean di bawah tenggat waktu yang tidak realistis dan berurusan dengan utang teknis telah diketahui sejak Weinberg '71 dan juga Brooks '72. Literatur menjadi sulit untuk digali secara online sebelum itu, tetapi saya cukup yakin ada laporan CDC, IBM, dan NASA yang mengatakan hal yang sama.


1
+ Untuk "hutang teknis" dan referensi.
Amir Rezaei

10

Saya pikir kita semua memiliki ide dan ambang batas sendiri untuk "Kode yang Baik". Namun, ada sejumlah masalah yang semuanya berkontribusi:

  • Aplikasi yang salah dari "get it berfungsi kemudian memperbaikinya" berarti kita meninggalkan kode mati dan 10 varian berbeda dari metode yang sama di mana masing-masing digunakan hanya sekali dalam basis kode. Barang-barang ini sepertinya tidak pernah dibersihkan.
  • Kurang waktu dan anggaran. Klien menginginkan 100 fitur baru dalam 3 bulan, beberapa di antaranya non-sepele, dan mereka tidak ingin menghabiskan uang untuk hal-hal yang tidak dapat mereka lihat secara langsung.
  • Kurang peduli. Mari kita hadapi itu, beberapa pengembang peduli tentang cara kode terlihat dan berperilaku lebih dari yang lain. Lihat poin-poin pertama sebagai contoh.
  • Kami benar-benar tidak tahu cara membuat "kode yang baik". Konsep kode saya yang baik terus berkembang. Apa yang saya pikir baik satu dekade lalu tidak lagi baik.
  • "Kode yang baik" adalah penilaian nilai. Selain "berfungsi", dan tidak ada bug yang dikenal, kriteria lain untuk kode yang baik pada dasarnya adalah masalah pendapat.

Pada akhirnya, saya pikir yang terbaik adalah mengejar lebih baik daripada mengejar "baik" atau "terbaik". Jika kita melihat kode terbaik di luar sana, akankah kita mengenalinya?


1
+1 Poin bagus. Dengan "kode yang baik", saya tidak merujuk ke kode yang sempurna. Kode sempurna tidak ada. "Kode yang baik" adalah kode yang tidak membuat Anda sakit kepala, itu misalnya dipikirkan dengan baik.
Amir Rezaei

1
Poin bagus tentang "kode yang baik" menjadi target yang bergerak. Namun, saya tidak setuju dengan itu hanya penilaian nilai. Saya percaya bahwa kode bersih lebih mudah untuk unit test, memperpanjang dan memelihara daripada kode berantakan, sehingga lebih murah dalam jangka panjang. Tentu saja, karena kita biasanya tidak menjalankan tes buta ganda dengan kelompok kontrol dalam proyek SW nyata ;-), hanya ada bukti anekdotal untuk ini, tidak ada bukti ilmiah yang keras.
Péter Török

Sepertinya kedua definisi kami saat ini tentang "kode yang baik" kebetulan setuju. Namun, saya telah melihat beberapa contoh desain API yang bagus yang membuat hidup saya jauh lebih mudah - tetapi perpustakaan tidak memiliki unit test. Itu tidak berarti itu tidak diuji, hanya saja tidak ada yang mengotomatisasi pengujian. Saya meninggalkan ruang untuk itu.
Berin Loritsch

8

Mengapa menulis kode yang baik lebih sulit?

Karena perangkat lunak semakin dibangun di atas lapisan abstraksi. Setiap teknologi baru yang mengklaim membuat pengembangan lebih mudah dan lebih cepat hanya menambah satu tingkat kompleksitas yang perlu dipahami pengembang. Sekarang, abstraksi ini dapat memiliki manfaat besar bagi produktivitas, tetapi jika Anda tidak memahami apa yang mereka coba sembunyikan maka itu membuat perangkat lunak lebih rentan terhadap bug dan kualitas buruk.


+1 Poin yang sangat bagus, alat baru meningkatkan produktivitas yang dapat menyebabkan lebih banyak kompleksitas.
Amir Rezaei

1
+1. Juga dikenal sebagai "Hukum Abstraksi Kebocoran". :)
Bobby Tables

6

Apakah kode yang baik tidak mungkin dalam pengembangan perangkat lunak modern?

Memang itu tidak mungkin. Tetapi tidak untuk alasan apa pun yang sudah Anda dengar.

Ruang lingkup sebagian besar proyek jauh melampaui kapasitas otak manusia. Itulah sebabnya orang datang dengan ide abstraksi , yaitu menyembunyikan detail dan memanjat pohon abstraksi lebih tinggi sampai kepadatan cabang (jumlah informasi yang harus ditangani) berkurang hingga tingkat yang dapat diterima.

Kami telah melakukan itu, kami memecahkan masalah kompleksitas, tetapi itu belum menghilangkan masalah yang lebih besar yang kami miliki sebelumnya.

Masih terlalu rumit untuk kita tangani.

Untuk menciptakan solusi berkualitas tinggi kita harus dapat melihat dan memahami semuanya secara bersamaan pada saat yang bersamaan, yaitu semua modul pada detail implementasi yang besar dan kecil. Sekaligus untuk melihat perbedaan, lihat setiap bagian kode dalam konteks semua skenario yang mungkin dan optimalkan seluruh basis kode pada saat yang sama.

Kami tidak akan pernah bisa melakukan itu.

Dan jika kita tidak bisa, kita tidak akan pernah menghasilkan kode kualitas.

Manajer akan melihat segelintir modul tetapi tidak akan tahu masalah internal dan batasan per modul.

Pemrogram modul akan mengetahui keterbatasan lokal tetapi tidak akan dapat mengoptimalkannya dalam konteks gambar yang lebih besar.

Tidak ada cara untuk mengkomunikasikan pemahaman antara manajer dan programmer (dan bahkan antara programmer). Dan kalaupun ada, kapasitas otak manusia tidak bisa mengatasinya.

Ada sedikit yang bisa kita lakukan kecuali terus berusaha (latihan yang sia-sia). Mari kita terus kode operasional kurang lebih dan menikmati hidup.


Saya suka jawaban ini, kalau saja itu tidak ditulis dengan nada pesimistis, fatalis ...
Timwi

1
@Timwi: Tidak terlalu pesimis. Seharusnya memberimu bantuan beban. :)

4

Saya menyangkal premis dari pertanyaan Anda. Lebih mudah dari sebelumnya untuk menulis kode yang baik, dan karena itu kami menangani masalah jauh lebih sulit yang telah kami tangani sebelumnya.

Saya tidak ingin memilih vendor tertentu, tetapi membandingkan Windows 1.0 dengan Windows 7. Yang terakhir berisi ribuan kali lebih banyak kode, tetapi waktu rata-rata antara crash telah meningkat seratus kali lipat. Kami seharusnya dapat menanamkan lembar bentang Excel dalam dokumen Word sejak Windows 3.1, tetapi hari ini sebenarnya lebih atau kurang berfungsi.

Tanpa ingin jatuh ke sentimentalitas "Anda anak-anak sekarang ini dengan mengetik bebek dan VM", saya sarankan Anda tidak tahu betapa sulitnya untuk menulis kode yang baik di tahun 80-an: model memori TINY, SMALL, dan HUGE, overlay , panggilan OS yang tidak disewakan (ngeri). Bagus untuk semua itu.


Benci untuk keluar dari topik, tetapi secara pribadi saya berpendapat bahwa Windows 1.0 hingga 3.11 sebenarnya sangat stabil, mungkin karena kurangnya kompleksitas mereka. Versi Windows yang paling sulit adalah 95, 98 dan ME. Tentu saja, versi mana yang "baik" dengan cara lain adalah masalah yang berbeda.
Timwi

Bagaimana dengan pengkodean pada minicomputer atau mainframe alih-alih sistem berdaya rendah? Masalah yang Anda rujuk terkait dengan model Intel 8086 ...
Paul Nathan

@ Paul, masalah 8086 adalah masalah yang paling banyak saya tangani, jadi mereka terbayang besar di pikiran saya. Namun alat untuk menulis perangkat lunak bahkan pada mainframe luar biasa kasar oleh standar modern. Para editor umumnya lebih dekat ke edlin daripada mereka ke emacs. Sampai 1982 saya menggunakan NUROS (Nebraska University Remote Operating System) pada perangkat keras IBM. Pekerjaan diprogram dan dijalankan menggunakan kartu punch 'virtual'. Dan janganlah kita melupakan bug Y2K, sebagian besar disebabkan oleh besi besar oleh kendala yang dirasakan pada penyimpanan.
Charles E. Grant

2

Aplikasi modern yang lebih kompleks daripada mereka 20-30 tahun yang lalu, karena lingkungan mereka lebih kaya dan lebih fleksibel.

Itu adalah khas untuk program-DOS untuk duduk dalam lingkaran ketat menunggu penekanan tombol berikutnya dari pengguna, dan kemudian memanggil kode yang sesuai, dan kembali untuk menunggu penekanan tombol berikutnya.

Aplikasi modern mana pun di mana Anda tidak dapat menggunakan mouse di ALL untuk apa pun, memiliki masalah penjelasan yang serius. Dan hal-hal dapat terjadi dalam urutan apa pun, karena sangat mungkin bagi pengguna untuk mengetik, klik dengan mouse dan terus mengetik sementara RSS-feed sedang diperbarui dalam aplikasi yang menampilkan entri terbaru kepada pengguna saat ia mengetik.

Semua hal yang multi-tugas ini pada hakekatnya jauh lebih kompleks daripada ketika semua yang harus Anda pikirkan adalah kunci dari pengguna. Itu membuatnya lebih sulit untuk menulis kode yang benar-benar bagus.

Mudah-mudahan ketika para peneliti telah menemukan bagaimana kita dapat membuat program multi-tasking lebih bermanfaat dilihat dari sudut pandang pengembang, ini mungkin mudah tetapi untuk sekarang kita terjebak dengan semua orang yang mencoba untuk melakukannya dengan baik, tetapi tidak cukup tahu bagaimana melakukannya. Itu.


+1 "Aplikasi modern lebih kompleks daripada 20-30 tahun yang lalu"
Amir Rezaei

2

Sepertinya saya bahwa perangkat lunak telah berkembang untuk mengisi kecepatan prosesor, memori, disk, dan waktu programmer yang tersedia. Orang bisa menyatakan bahwa itu karena perangkat lunak mencapai lebih banyak. Yah, saya yakin itu menghasilkan lebih banyak, tetapi tidak cukup untuk membenarkan mengasapi.

Saya pikir ada hukum kuno sains yang perlu diingat:

Alam membenci kekosongan.

Francois Rabelas (Biksu dan satiris Prancis 1494-1553)


1

Bahkan, saya pikir sudah menjadi lebih mudah untuk menulis kode yang baik, yaitu program yang berfungsi seperti yang diharapkan dan dipelihara, selama dekade terakhir. Alat yang tersedia sekarang lebih baik, libs lebih matang dan komprehensif, perangkat keras menjadi lebih cepat sehingga kita tidak harus menggunakan trik pengoptimalan.

Jadi mengapa kita tidak melakukannya?

IMO alasan utamanya adalah kita terus mencari cara dan alasan untuk melakukan penyalahgunaan. Alih-alih menggunakan cara lama, mudah, mungkin membosankan, seperti membuat Windows yang dapat dieksekusi, kami mendorong batas-batas yang mungkin dan mencari cara untuk misalnya menciptakan kembali sesuatu seperti PhotoShop sebagai aplikasi web. Mengapa? Karena kita bisa. Atau setidaknya kami pikir begitu.


1
Saya tidak setuju dengan implikasi bahwa inovasi harus dihindari dan teknologi atau metode kuno tidak boleh ditinggalkan. Mungkin juga berhenti menulis program apa pun dan gunakan saja apa yang kita punya ...
Timwi

Timwi: Saya tidak menentang inovasi. Itu hanya alasan mengapa sangat sulit untuk menulis kode yang bagus.
user281377

1

Kapan terakhir kali SIAPA SAJA tidak menulis eksploit atau belajar untuk melakukan hal tersebut di sekitar dengan perakitan (tidak termasuk peretas kernel dan orang-orang ASIC)? Berapa banyak bug yang telah ditemukan di perpustakaan inti C? Hampir tidak ada dan sedikit. Yang saya katakan adalah bahwa orang mampu kode yang sangat baik. Alat dan bahasa yang lebih baik membuatnya kurang 'wajib' dan lebih 'opsional'. Bukannya saya pikir kita semua harus menulis kode yang benar-benar mengerikan, tetapi ketika saya memikirkan konstruksi logis yang rumit ... tidak ada yang akan bermimpi menulis sesuatu dengan array hash dalam perakitan. Harus ada cara yang 'lebih baik' untuk menangani logika daripada menggunakan konstruk yang rumit. Sekalipun kodenya indah, terkadang pendekatannya tidak elegan. Saya pikir itu semacam mengatasi masalah yang Anda sebutkan. Kode yang baik tidak selalu hanya terorganisir,


Teman-teman sistem tertanam menulis jumlah perakitan yang layak.
Paul Nathan

@ Paul Nathan True
RobotHumans

0

Saya pikir itu karena alat yang lebih baik, dan komputer yang lebih cepat lebih responsif berarti kita berharap untuk mendapatkan lebih banyak kompleksitas produk akhir perunit waktu daripada yang kita lakukan beberapa tahun (atau beberapa dekade) kembali. Jadi kompleksitas aplikasi terus meningkat, dan asumsi kami tentang tingkat produktivitas yang wajar terus bertambah.

Di tempat saya bekerja, pengembang selalu terburu-buru (karena selalu ada lebih banyak hal yang pelanggan inginkan maka mereka punya waktu untuk). Jadi banyak blok kode disalin dengan pengeditan minimal, dan tanpa upaya dibuat untuk benar-benar memahaminya. Dan tentu saja kesalahan bisa terjadi. Saya baru saja melihat bug diperbaiki, di mana pengembang telah menyalin beberapa kode yang telah saya optimalkan, tanpa menyadari bahwa asumsi yang membuat optimasi itu valid tidak benar di mana ia meletakkannya.

Ini semua bermuara pada harapan, baik internal (harapan kita sendiri), dan dari organisasi kita. Kami berusaha melakukan sebanyak mungkin dalam waktu sesingkat mungkin. Dan kesalahan pasti terjadi.

Juga respon komputer mendorong pengeditan cepat cepat, kemudian kompilasi dan uji coba. Di masa lalu (seperti 35 tahun yang lalu), perputaran sangat lambat, sehingga saya akan mencetak kode (sumber adalah kartu punch kemudian), dan melakukan langkah-langkah manual kode sebelum mengirimkan dek saya. Sekarang, kita cukup mengedit kompilasi dan menjalankan. Jadi banyak bug yang akan kita temui, melalui penelusuran kode metodis, sekarang kita mengandalkan kompiler dan / atau suite unit test untuk ditangkap.


Kedengarannya seperti perusahaan muda yang belum mengetahui bahwa yang termurah melakukannya dengan benar pertama kali ...

Thorbjorn: Hebatnya sudah ada selama hampir tiga dekade. Dan itu sebenarnya cukup baik. Tentu saja ada model bisnis yang sangat responsif terhadap permintaan pelanggan (kami), dan beberapa yang sangat berorientasi pada kualitas. Sangat sulit untuk menjadi keduanya.
Omega Centauri

0

Bagaimana orang menjadi lebih buruk dalam menghasilkan kode yang baik?

Jika Anda menggunakan .NET dan bahasa seperti C #, misalnya (dan saya sadar itu bukan satu-satunya platform / bahasa), saya berpendapat bahwa pengkodean dengan baik telah menjadi jauh, jauh lebih mudah karena otomatisasi banyak hal dalam Visual Studio lingkungan Hidup.

Jika ada, fakta sederhana bahwa kita sekarang memiliki IDE yang sangat canggih yang mampu membimbing kita melalui proses pengkodean dan pengembangan membuat "kode yang baik" lebih mudah untuk dicapai.

Programmer sekarang dapat fokus pada benar-benar menghasilkan struktur yang baik daripada menghabiskan begitu banyak waktu hanya mengetik kurung dan kurung dan baris baru dan mengingat panggilan metode dan nama kelas.

Dua sen saya.



-2

kualitas kode belum membaik

tolong jangan terjebak dalam interpretasi "kode yang baik"

Tautologi logis yang bagus.

Kode tidak menjadi lebih baik karena orang terus memindahkan definisi "baik".

Jika Anda dapat 'membahas "kode yang baik", maka Anda tidak dapat membandingkan dan Anda benar-benar tidak dapat memutuskan apakah itu "tantangan" atau tidak.


Bagi saya "kode yang baik" adalah sedemikian sehingga mengurangi jumlah bug. Sekarang hal itu dapat dicapai dengan banyak cara.
Amir Rezaei

@Amir Rezaei: "Definisi" kode yang baik "adalah individu". "'kode yang baik' sedemikian rupa sehingga mengurangi jumlah bug" Silakan pilih hanya satu definisi dan perbarui pertanyaan Anda untuk memasukkan hanya satu definisi.
S.Lott

Nah "'kode yang baik' adalah sedemikian rupa sehingga mengurangi jumlah bug" adalah ide pribadi saya tentang "kode yang baik". Saya pikir semua orang tahu kapan proyek perlu dibersihkan atau tidak .
Amir Rezaei

@Amir Rezaei: Ini poin saya. Jika Anda tidak dapat (atau tidak akan) mendefinisikan "baik" dalam pertanyaan, maka kami tidak dapat membandingkan. Anda dapat mengklaim jumlah bug yang sama. Beberapa yang lain dapat mengklaim bahwa biaya bug turun. Yang lain dapat mengklaim bahwa risiko bisnis akibat perencanaan bug naik. Tanpa definisi tunggal "baik" kita semua dapat berbicara tentang hal-hal yang berbeda. Harap perbarui pertanyaan.
S.Lott

Kode Baik: itu dikompilasi, lulus tes, menerima persetujuan pengguna dan dimasukkan ke dalam produksi. Semoga saja tidak ada yang mau mengubahnya.
JeffO
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.