Apakah Programmer kadang-kadang sengaja atas kode rumit? [Tutup]


26

Tampaknya banyak kali pada stackoverflow, bahwa orang-orang (terutama programmer) cenderung terlalu menyulitkan solusi untuk masalah di mana solusinya jauh lebih rumit daripada masalah aslinya? Saya bukan ahli dengan cara apa pun, tetapi banyak kali saya mencoba untuk pergi dengan solusi paling sederhana yang bekerja (dan jelas ini tidak berhasil di MANA SAJA) tetapi saya sudah cukup sukses dengan menyarankan solusi sederhana pada pekerjaan yang orang tampaknya mengabaikan solusi JAUH lebih rumit?

Apakah ini seperti hal yang normal bagi programmer ..... atau saya hanya tidak berpikir dalam perspektif yang benar.


5
1. Ya, saya kadang berpikir. 2. Ya, setidaknya beberapa programmer setidaknya beberapa waktu terlalu memperumit kode mereka, setidaknya beberapa kali dengan sengaja. 3. Kasing ditutup.
Ayub

3
Pernahkah Anda memiliki seseorang yang meneriaki Anda, "Seharusnya Anda memikirkan itu!" ketika Anda melewatkan beberapa persyaratan yang tidak disebutkan dalam pengumpulan persyaratan awal? Itulah yang dapat menyebabkan beberapa hal menjadi lebih kompleks daripada yang diperlukan.
JB King

Jawaban:


18

Jelas, beberapa programmer sangat ingin menunjukkan seberapa pintar mereka dengan membuat beberapa kode rumit yang tidak dapat dimengerti oleh siapa pun. Pemrogram lain menembaki tingkat tinggi, sehingga komplikasi dalam solusi adalah evolusi alami.

Beberapa kode terburuk yang pernah saya lihat adalah metode yang memiliki lebih dari 2000 baris kode di dalamnya. Tidak diragukan lagi kode ini kompleks, tetapi juga sangat buruk.

Saya pikir seorang programmer yang baik menghindari kode yang terlalu rumit. Ini termasuk menghindari godaan untuk memaksakan pola desain agar sesuai dengan solusi yang tidak benar-benar membutuhkannya. Ini juga termasuk menghindari objek Tuhan, tombol ajaib, optimisasi prematur, generalisasi prematur, dan anti-pola lainnya.

Saya terus-menerus memperbaiki dan mencari peluang untuk menyederhanakan solusi saya karena pertumbuhan kompleksitas adalah hal yang organik. Seperti banyak hal organik lainnya, harus dipangkas dan dipangkas jika kita ingin terus digunakan. Saya benci harus berinteraksi dengan solusi yang terlalu rumit karena dengan meningkatnya kerumitan, semakin besar kemungkinan melanggar kode.

Saya pikir keterbacaan adalah elemen paling penting dari pemeliharaan kode, dan solusi yang terlalu rumit hampir selalu mengurangi keterbacaan, dan meningkatkan biaya pemeliharaan.


32

Saya telah melihat banyak kode yang lebih kompleks dari yang seharusnya dan hampir selalu karena tiga alasan berikut:

1) Over-engineered karena generalisasi prematur atau mencoba mengantisipasi kebutuhan masa depan yang tidak pernah muncul

2) Pengembang ingin belajar / bereksperimen dengan pola desain baru atau teknologi yang belum pernah mereka gunakan sebelumnya dan memilihnya bahkan ketika itu berlebihan. Mereka melakukannya karena itu membuat pekerjaan mereka lebih menarik dan mereka dapat belajar sesuatu yang baru.

3) Fitur dan perbaikan bug telah ditambahkan, tetapi kode yang ada saat itu tidak di-refactored dengan benar saat itu. Itu mungkin hanya sepotong kecil duplikasi atau menempel argumen bendera lain ke suatu metode tetapi semuanya bertambah. Secara efektif, peretasan ditambahkan dan tidak butuh waktu lama untuk semuanya menjadi terlalu rumit karena semua bau kode. Ini adalah yang paling umum dan biasanya hanya karena tidak mengetahui tekanan waktu atau lebih baik.


Saya bersalah karena # 2, saya khawatir. Dengan pengalaman (dan kedewasaan?) Sekarang saya cenderung menahan diri ... dan malah bereksperimen di rumah :)
Matthieu M.

Saya melihat orang melakukan 1 sepanjang waktu, mereka akhirnya menciptakan 5 kali lebih banyak pekerjaan untuk diri mereka sendiri
Ally

11

Ini benar-benar hal yang umum. Seperti yang dikatakan sebagian besar buku, pengembang yang baik tahu bagaimana membuatnya sederhana. Terlalu mudah untuk menyulitkan sesuatu dengan teknologi baru atau kerangka kerja "keren" yang baru saja Anda temukan, jadi Anda mulai mencari cara untuk menggunakannya, alih-alih berpikir dari perspektif masalah.

Seperti yang dikatakan Martin Fowler, mereka yang mempelajari teknologi baru memiliki masalah jangka pendek di mana "teknologinya" mendorong solusi.


4
-1: Seperti yang dikatakan kebanyakan buku, pengembang yang baik tahu bagaimana membuatnya sederhana. - Anda benar tentang ini. Tapi kemudian Anda menyiratkan bahwa penyalahgunaan teknologi baru adalah penyebab terbesar dari kode yang terlalu rumit. Anda salah tentang itu. Percayalah, ada banyak kode yang terlalu rumit di luar sana yang tidak ada hubungannya dengan penyalahgunaan teknologi baru.
Jim G.

Di mana tepatnya saya menyiratkan bahwa itu "penyebab terbesar dari kode yang terlalu rumit"? Ini tentu masalah, "Hei, saya baru belajar pola X, di mana saya bisa menerapkannya" - Patternitus. Anda benar-benar memasukkan kata-kata ke mulut saya di sana Jim.
Martin Blore

4
"Aku sudah membuat surat ini lebih lama dari biasanya, hanya karena aku belum punya waktu untuk membuatnya lebih pendek." - Blaise Pascal Sangat berlaku di sini juga. "Complicated" seringkali merupakan tanda kode yang terburu-buru, malas, atau tidak kompeten.
Bill

@Bill Hal yang menarik tentang itu adalah argumen yang bagus untuk kode yang lebih kompleks dari sudut pandang bisnis - jika Anda dibayar jumlah tetap untuk mengimplementasikan sesuatu dan butuh waktu ekstra untuk refactor atau membuatnya lebih pendek, kecuali Anda bisa melakukannya benar saat pertama kali (siapa yang bisa?) pada dasarnya ada penalti untuk membuat kode Anda yang sudah ada menjadi lebih kompleks.
Michael

10

Saya tidak berpikir itu normal untuk semua programmer, tapi saya pasti melihat banyak programmer melakukan ini.

Saya pikir beberapa orang percaya bahwa beberapa orang melihat membuat sesuatu yang sangat sederhana 'terlalu mudah', dan itu bukan karya yang baik dari keterampilan mereka. Oleh karena itu, mereka harus membuat solusi besar dan kompleks yang ada cara mengatakan 'lihat apa yang bisa saya lakukan!', Meskipun itu mungkin bukan solusi terbaik untuk masalah yang dihadapi.


1
Begitulah cara saya melihatnya. Apakah itu terlalu mudah atau tidak layak digunakan?

@Mercfh saya tidak mengerti tampilan. Apa hubungan kemudahan solusi dengan keefektifannya?
GSto

Saya mengomentari komentarnya yang mengatakan "Ya saya setuju" bahwa programmer terkadang berpikir "Oh jika terlalu sederhana, itu tidak terlalu baik".

7

Saya telah melihat programmer sering menulis beberapa baris kode untuk menyelesaikan tugas yang mereka tidak tahu sudah dibangun ke dalam bahasa. Ini tidak disengaja tetapi pasti bisa dicegah.


Saya telah melihat programmer yang menulis loop untuk setiap salinan string. Tidak pernah menggunakan panggilan ke fungsi perpustakaan standar. (Apa yang lebih buruk adalah salinan platform dioptimalkan untuk membaca sebuah kata pada suatu waktu.)
BillThor

7

Itu tergantung pada apa yang Anda sebut "sederhana". Beberapa orang melihat kode yang sangat refactored sebagai lebih "kompleks" karena ada lebih banyak kode, dan beberapa grafik panggilan. Namun, kode ini lebih "sederhana" karena lebih mudah untuk melakukan perubahan.

Saya sering menemukan bahwa fungsi besar terlihat "sederhana" sampai Anda perlu melakukan perubahan, kemudian menjadi kompleks dengan cepat.

Dengan kata lain, sederhana ada di mata yang melihatnya dalam banyak kasus.


2
+1: terlalu banyak programmer yang tidak memikirkannya
Luca

5

Masalahnya adalah jika Anda tidak dapat melihat solusi sederhana dengan jelas (di sinilah diskusi dengan rekan-rekan bermain) atau jika Anda terlalu menyamaratakan terlalu dini.

Dengan kata lain, Anda membuat loop sederhana ke fungsi pustaka lanjut karena Anda pikir Anda akan memerlukannya untuk proyek berikutnya (kecuali bahwa Anda tidak akan dalam bentuk yang tepat ini). Lakukan ini terlalu lama dan Anda memiliki aplikasi yang sangat kompleks dengan inti yang sangat sederhana.

Anda mungkin juga menemukan bahwa Anda harus memiliki kode yang sangat kuat, dan semua ketahanan membuatnya rumit secara default. Namun saya tidak berpikir bahwa ini adalah masalah Anda.


4

Dalam beberapa kasus mungkin hanya kompleksitas dengan solusi bersih / sederhana.

Ada kutipan yang tidak dapat saya ingat atau temukan sesuatu yang berjalan sendiri, baris "Kode tidak lengkap begitu Anda telah menulis semua yang Anda butuhkan untuk menulis tetapi hanya menyelesaikan begitu Anda tidak memiliki sesuatu yang tersisa untuk dihapus"

Kurangnya kejelasan akan menghalangi kemampuan orang untuk menghapus semua kelebihan.


4
Kutipan lain yang relevan adalah, "Saya akan menulis surat yang lebih pendek tetapi tidak punya waktu."
user16764

3
“Bagaimana dengan kesempurnaan, jadi lakukan ini tanpa pertanyaan dan rien à ajouter, mais tanya rien à plus rien à retrancher.” (“Sepertinya, kesempurnaan dicapai bukan ketika tidak ada lagi yang ditambahkan tetapi ketika tidak ada lagi yang bisa dihapus. ") - Pilot, penyair dan insinyur Prancis Antoine Marie Roger Vicomte de Saint-Exupéry, 1939 (dari buku Terre des Hommes ( Wind, Sand and Stars )).
Jörg W Mittag

Terima kasih, sepertinya saya tidak pernah tahu asal yang sebenarnya :-) Bagus.
Stephen Bailey

3

Insinyur terbaik adalah yang dapat mengambil masalah yang sangat rumit dan mengubahnya menjadi solusi yang mudah diimplementasikan dan mudah dipahami. Kedengarannya sederhana, tetapi tidak ada banyak insinyur / pengembang seperti itu yang ada. Sebenarnya tidak banyak orang seperti itu yang ada. Pada kenyataannya mayoritas orang di luar sana melakukan hal yang sebaliknya. Mereka mengambil masalah sederhana dan mempersulit mereka tanpa bisa dikenali. Lihat saja politisi kita untuk contoh orang-orang yang berhasil mengambil masalah sederhana dan mengubahnya menjadi kekacauan total. Programmer tidak berbeda dalam hal ini.


3
Aduh! Saya baru saja akan memberi Anda +1, tetapi kemudian saya melihat analogi Anda dengan politik, dan itu paling lemah. // Itu benar - Ada banyak kebingungan, gerakan sia-sia, lambaian tangan, dan minat khusus yang melekat dalam politik, dan sebagai hasilnya, tagihan mungkin menjadi terlalu rumit. Tetapi komplikasi yang berlebihan adalah produk sampingan dari kebingungan, gerakan yang sia-sia, lambaian tangan, dan minat khusus. Bukan penyebab root.
Jim G.

Apa pun alasannya, ada solusi yang sangat sederhana untuk banyak masalah negara tetapi politisi memilih untuk membuat mereka lebih sulit daripada yang mereka butuhkan. Kami menganggap ini karena uang, kekuatan atau suara, tetapi saya juga percaya ini sebagian besar tentang kemampuan. Dalam hal ini analogi saya adalah pijakan yang kokoh.
Dunk

1
@ Jim. Ya saya setuju dengan Anda ... bagi saya banyak masalah dengan solusi politik adalah politisi yang mengklaim ada solusi mudah (untuk mereka!) Untuk masalah yang sangat rumit yang benar-benar tidak memiliki solusi yang mudah.
Michael

2

Secara pribadi, saya tidak pernah dengan sengaja mencoba membuat perangkat lunak lebih rumit. Namun, saya telah menyelesaikan sesuatu dan berpikir "wow, itu terlalu rumit" dan kembali ke sana dan refactored. Beberapa orang mungkin melihat ini dan hanya berpikir itu berfungsi dan itu cukup baik dan bukan refactor.


1

Orang bijak dituduh mengatakan Anda harus menjaga sesederhana mungkin, tetapi tidak sederhana. Hal yang sama berlaku untuk kode. Kadang-kadang Anda harus menggunakan teknik yang beberapa anggap kompleks (rekursi mungkin menjadi contoh yang baik, sering membuat takut programmer junior).

Namun, secara umum saya pikir kode kompleks sering muncul secara organik. Masalah sederhana diselesaikan dengan kode yang sederhana, kemudian ruang lingkup meluas dan kode dimodifikasi tanpa terlalu banyak berpikir, dan seiring waktu Anda mendapatkan kode yang mencoba untuk menutupi masalah baru tetapi benar-benar dirancang untuk menyelesaikan masalah yang berbeda. Ini menjadi selimut tambal sulam berbagai potongan logika. Kode seperti itu kemudian sering kali tampak jauh lebih kompleks daripada yang dibutuhkan oleh masalah, tetapi kode itu menjadi seperti itu karena setiap perubahan kecil tampaknya, pada saat itu, menjadi cara termudah untuk membuat kode berfungsi.

Saya tidak berpikir sebagian besar pengembang sengaja membuat kode kompleks (meskipun Anda mendapatkan pamer aneh yang akan menggunakan beberapa teknik untuk membuktikan keterampilan mereka sendiri), saya pikir kode hanya akan seperti itu jika tidak dipelihara secara agresif dan refactored .


Sungguh menakjubkan betapa banyak sistem dimulai dengan inti yang sangat sederhana yang hampir sesuai dengan kebutuhan tetapi gagal dalam banyak cara yang berbeda, dan akhirnya menambahkan banyak komplikasi untuk menangani banyak celah yang bisa dihindari dengan desain yang sedikit lebih rumit. Pertimbangkan desain sederhana tipe integer C dan beberapa aturan rumit-rumit yang menyertainya. Jika untuk setiap jenis ada opsi "seandainya ini bisa dipromosikan", yang secara nominal akan menggandakan jumlah jenis (walaupun tidak benar-benar berbeda dari kualifikasi seperti volatile, dll.) Tetapi ...
supercat

... itu akan sangat memudahkan aturan promosi / penyeimbangan. Short unsigned non-promotable yang ditambahkan ke int promotable akan menghasilkan short unsigned non-promotable, baik shortsebesar atau tidak int. Suatu promotable yang unsigned shortditambahkan ke promotable intakan menghasilkan a int. Menambahkan hal-hal yang ditandatangani dan tidak ditandatangani dengan ukuran yang sama, atau menambahkan hal-hal yang tidak dapat dipromosikan dengan ukuran yang berbeda, akan menjadi kesalahan. Tambahkan sedikit kompleksitas di bagian depan, dan kasus sudut aneh di hilir menghilang.
supercat

1

Alasan lain yang belum diangkat adalah bahwa orang mungkin terlalu rumit memberikan solusi untuk memastikan bahwa Anda akan membutuhkan layanan mereka nanti untuk mendukung solusi ini. Dengan kata lain: untuk keamanan pekerjaan.


Tidak yakin mengapa ini dibatalkan, saya telah menemukan proyek yang sangat besar yang dikodekan oleh satu orang, yang menciptakan kerangka kerjanya sendiri, dan dibayar setiap jam hanya dengan mengerjakan proyek ini. Jika majikan membuatnya kesal, seluruh lini produk akan kacau. Butuh waktu berbulan-bulan bagi pengembang lain untuk benar-benar memahami kode tersebut, sementara itu akan membutuhkan beberapa menit bagi pembuat kode "yang tahu segalanya" untuk memperbarui kekacauan spageti-nya.
SSH

0

Mungkin masalah kesalahan klasik?

30. Pelapisan emas pengembang.

Pengembang terpesona oleh teknologi baru dan kadang-kadang ingin mencoba fitur-fitur baru dari bahasa atau lingkungan mereka atau untuk membuat implementasi mereka sendiri dari fitur apik yang mereka lihat di produk lain - apakah itu diperlukan dalam produk mereka atau tidak. Upaya yang diperlukan untuk merancang, mengimplementasikan, menguji, mendokumentasikan, dan mendukung fitur-fitur yang tidak diperlukan memperpanjang jadwal.

  • Steve McConnell, Pengembangan Cepat.

0

Ya kadang-kadang kita terlalu rumit kode untuk menghibur diri kita sendiri. Sebagian besar meskipun persepsi bahwa kode menjadi terlalu rumit berasal dari peserta yang tidak tahu atau Junior dalam proyek tersebut.


1
-1 Pengembang senior yang dengan pasti menyalahkan masalah pada pengembang junior mungkin tidak memahami motivasi untuk pekerjaan mereka sendiri atau pekerjaan orang lain. Jika pengembang junior mengalami kesulitan mengikuti kode Anda, maka IT IS terlalu rumit.
Brandon

Saya akan mengatakan bahwa jika pengembang Jr menemukan kode tidak mungkin untuk dipahami, itu adalah bau kode dan mungkin sebenarnya kode itu terlalu rumit, namun Anda menggunakan jauh untuk memperluas kuas di sini. Bau kode ini mungkin sebenarnya hanya ada karena pengembang Jr perlu bantuan untuk memahami teknik canggih, bukan teknik itu sendiri yang harus disalahkan.
P. Roe

-1

YA ... dan saya telah membayar harga terlalu banyak.

Papan tulis saya sekarang memiliki pernyataan dalam tanda bintang di bagian paling atas yang bertuliskan

"Jika itu tidak sederhana, itu tidak benar"

... dan setiap kali saya membuat prototipe sesuatu di papan tulis itu selalu menarik perhatian saya.

Ini benar-benar bekerja untuk saya karena desain saya yang kompleks menjadi jauh lebih sederhana yang diterjemahkan menjadi kode yang lebih bersih.

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.