it-swarm-id.com

Mengapa kepintaran dianggap berbahaya dalam pemrograman oleh sebagian orang?

Saya telah memperhatikan banyak pertanyaan belakangan ini berkaitan dengan teknik abstraksi yang berbeda, dan jawaban yang pada dasarnya mengatakan bahwa teknik yang dimaksud "terlalu pintar." Saya akan berpikir bahwa bagian dari pekerjaan kita sebagai programmer adalah menentukan solusi terbaik untuk masalah yang kita berikan untuk dipecahkan, dan kepintaran sangat membantu dalam melakukan itu.

Jadi pertanyaan saya adalah: apakah orang-orang yang berpikir teknik abstraksi tertentu terlalu pintar menentang kepintaran per se , atau apakah ada alasan lain untuk keberatan?

EDIT: Combinator parser ini adalah contoh dari apa yang saya anggap kode pintar. Saya mengunduh ini dan melihatnya sekitar setengah jam. Kemudian saya melangkah melalui ekspansi makro di atas kertas dan melihat cahaya. Sekarang setelah saya memahaminya, tampaknya jauh lebih elegan daripada kombinator parser Haskell.

89
Larry Coleman

Solusi sederhana lebih baik untuk pemeliharaan jangka panjang. Dan itu tidak selalu hanya tentang keakraban bahasa. Garis yang rumit (atau garis) membutuhkan waktu untuk mencari tahu bahkan jika Anda seorang ahli dalam bahasa yang diberikan. Anda membuka file dan mulai membaca: "ok, sederhana, sederhana, mengerti, ya, WTF ?!" Otak Anda berhenti dan Anda sekarang harus berhenti dan menguraikan garis yang rumit. Kecuali jika ada alasan konkrit yang terukur untuk implementasi itu, itu "terlalu pintar".

Mencari tahu apa yang terjadi semakin sulit seiring dengan meningkatnya kompleksitas dari metode pintar menjadi kelas pintar menjadi pola pintar. Selain dari pendekatan terkenal, Anda harus mencari tahu proses pemikiran yang masuk ke menciptakan solusi "pintar", yang bisa sangat sulit.

Yang mengatakan, saya benci menghindari pola (ketika penggunaannya dibenarkan) hanya karena seseorang mungkin tidak memahaminya. Terserah kita sebagai pengembang untuk terus belajar dan jika kita tidak memahami sesuatu, itu adalah alasan untuk mempelajarinya, bukan untuk menghindarinya.

207
Adam Lear

Prinsip CIUMAN

Tetap sederhana, bodoh. Solusi cerdas sangat bagus, tetapi sering kali solusi langsung paling sederhana adalah yang terbaik.

“Debugging dua kali lebih sulit daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk men-debug itu. "

Brian Kernighan

102
Josh K

Orang bodoh mengabaikan kompleksitas; kaum pragmatis menderita; para ahli menghindarinya; jenius menghapusnya. - Alan Perlis

83
Martijn Verburg

Solusi terbaik tidak selalu merupakan solusi yang paling pintar. Terkadang solusi sederhana sama baiknya.

Dalam Perangkat Lunak Anda selalu perlu berpikir dalam hal pemeliharaan. Jika sepotong kode terlalu pintar untuk seseorang yang akan memeliharanya, saya akan mengatakan bahwa kepintaran tidak sepadan.

30
Geek

Mengutip Brian Kernighan:

"Debugging dua kali lebih keras daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk men-debug itu."

26
peterchen

kepintaran adalah alat; dengan sendirinya itu tidak berbahaya. Itu hanya menjadi berbahaya dalam konteks di mana itu tidak perlu.

22
Steven A. Lowe

"Pintar", ketika diterapkan pada kode, hampir selalu hanya eufemisme untuk "rumit".

Membaca kode yang bagus, jelas, dan sederhana sudah cukup sulit. Membaca kode "pintar" seperti mempelajari puisi latin lagi.

Kebingungan muncul karena "pintar" sebagai atribut seseorang memiliki arti yang sama sekali berbeda. Kasus ini juga dapat dilihat sebagai contoh mengapa mendesain perangkat lunak untuk orang sungguhan itu sulit: Karena mereka ambigu.

Dan karena beberapa programmer menderita untuk memahami protokol sosial yang diikuti kebanyakan orang, yang melarang mereka untuk secara langsung mencela kode sebagai "rumit yang tidak perlu", mereka mungkin merasa sulit untuk membedakan antara dua makna dari Kata --- pandai. Bertentangan dengan apa yang mungkin dipikirkan beberapa orang, saya pikir pada akhirnya "orang-orang" yang lebih baik (artinya: orang yang memiliki empati dan introspeksi serta kesabaran) menjadi pengembang yang lebih baik. Karena mereka tahu untuk siapa menulis.

16
fzwo

Kebanyakan orang berfokus pada kepintaran dari aspek "Kode ini membutuhkan terlalu banyak penguraian untuk mencari tahu apa yang dilakukannya" dan semua hal buruk yang sejalan dengan itu seperti

  1. Tidak ada orang lain yang bisa mengetahuinya, apalagi memeliharanya/debug itu.
  2. Orang yang menulis bahkan tidak tahu apa fungsinya.
  3. Mungkin sebenarnya tidak terlalu cemerlang untuk memulai
  4. dll ....

Semua poin bagus, tapi ada aspek negatif lain dari kepintaran dan itu adalah masalah ego lama. Ini menyebabkan masalah di sepanjang baris

  1. Seseorang yang terlalu "Cerdas" untuk menggunakan solusi orang lain. Mengapa mencari apa yang telah dilakukan orang lain ketika Anda dapat menemukan cara Anda sendiri menguliti kucing yang sama?
  2. Seseorang yang berpikir bahwa mereka telah menemukan solusi paling keren untuk suatu masalah akan sering menolak untuk mengambil masukan apa pun.
  3. Jangan biarkan siapa pun memodifikasi kode "mereka" meskipun ada masalah yang jelas atau perubahan sepele diperlukan.
  4. Sebaliknya, mereka berpikir mereka pintar dan perlu menggunakan teknik "terbaru" untuk membuktikan seberapa pintar mereka tetapi gagal untuk mendapatkan pegangan yang baik dalam hal itu baik dalam proyek pribadi atau kode non-produksi sebelum memasukkannya ke bagian penting dari sistem.

Kita semua kadang-kadang bersalah karena terlalu banyak ego, tetapi ketika hal itu menghalangi tim, itu menjadi masalah.

9
MIA

Good Clever - rasio tinggi antara baris kode yang pandai vs baris dalam alternatif yang tidak pandai. 20 baris kode yang menyelamatkan Anda dari penulisan 20000 adalah Extremely Good Clever. Good Clever adalah tentang menyelamatkan diri Anda dari pekerjaan.

Bad Clever - rasio rendah antara baris kode tertulis ditulis vs baris kode disimpan. Satu baris kode pintar yang menyelamatkan Anda dari penulisan lima baris kode adalah Bad Clever. Pintar pintar adalah tentang "masturbasi sintaksis".

Sebagai catatan: Bad Clever hampir tidak pernah disebut "Bad Clever"; sering bepergian dengan alias "cantik", "elegan", "ringkas", atau "singkat".

8
user8865

Saya harus bertanya-tanya tentang definisi pintar setiap orang.

Secara pribadi, saya merasa telah menjadi pintar ketika saya mengambil masalah yang sulit dan rumit, dan mengimplementasikannya dengan cara yang sangat sederhana dan mudah, sambil mempertahankan tingkat efisiensi yang dapat diterima.

tl; dr saya merasa pintar ketika, selama ulasan kode, pengulas saya mengatakan "wow, itu lebih mudah daripada yang saya pikir akan menjadi", sebagai lawan dari "wtf semua ini .."

7
Avatar_Squadron

Terkadang saya sangat pintar sehingga saya salah.

6
John

Selain dari jawaban teori yang terdaftar, sering kali ini digunakan dalam konteks terlalu pintar untuk orang lain.

Bergerak antara tim intensif kinerja tingkat atas dan tim pemeliharaan tingkat menengah kadang-kadang untuk melihat perbedaan kehidupan nyata dalam apa yang "terlalu pintar".

Mengesampingkan argumen teori, terlalu pintar sering didasarkan pada apa yang dapat dilakukan oleh anggota tim yang paling tidak terampil, sehingga sangat relatif terhadap lingkungan.

6
Bill

Performan, perawatan, tepat waktu, dan murah adalah cara saya mengukur solusi. Saya kira pintar juga bisa menjadi bagian dari solusi selama tidak berdampak negatif pada kualitas-kualitas itu.

4
Heath Lilley

Jika kode pintar + jumlah komentar yang diperlukan untuk membuatnya dimengerti kode <= kode sederhana, maka saya katakan pergi untuk kode pintar. Setiap saat.

Saya pikir masalah muncul ketika orang yang menulis "kode pintar" sengaja gagal mengomentari dengan benar, karena hanya dengan itu pada awalnya tidak dapat dipahami generasi masa depan yang menemukan itu harus menghabiskan waktu "menghargai" seberapa pintar itu.

3
thesunneversets

Saya teringat akan sebuah kutipan yang saya lihat dikaitkan dengan banyak orang yang berbeda, seperti kutipan yang baik sering.

Mengutip:

Setiap orang yang cerdas dapat membuat kompleks yang sederhana, dibutuhkan kejeniusan untuk membuat kompleks menjadi sederhana.

Mengambil ide yang kompleks dan menyederhanakannya sehingga dapat dimengerti menunjukkan kepintaran dari konstruktor tetapi mengambil ide yang sederhana dan menjadikannya kompleks menunjukkan bahwa konstruktor ingin dilihat sebagai pintar.

3
Pickle Pumper

Menurut pendapat saya, kepintaran bukan masalah. Biasanya kita dapat membuat kebingungan tentang kode "pintar" (tanpa sarkasme) dan "wawasan". Apa yang saya lihat sebagai masalah, adalah kenyataan bahwa biasanya kode "pintar" (dengan sarkasme) berisi persyaratan tidak terlihat yang tersirat, membuatnya lebih sulit untuk di-debug dan dipertahankan sepanjang waktu.

Ada beberapa algoritma yang dikenal pintar. Quicksort adalah satu, IMO.

Kode "Pintar" (dengan sarkasme) biasanya membuat asumsi tentang variabel yang ditetapkan dan status sistem yang hampir terputus dari kode "pintar" (seperti file yang dibuka sebelumnya, koneksi jaringan, basis data, dll ...).

Jumlah data yang harus Anda muat di otak Anda untuk mempertahankan kode "pintar" dengan benar biasanya besar untuk memiliki rasio biaya-manfaat yang baik.

2
Machado

Jika solusi 'pintar' sulit untuk dipecahkan, maka itu tidak boleh digunakan. Misalnya, jika melalui efek samping Anda dapat mengontrak perhitungan yang rumit ke satu baris, itu pintar. Tetapi jika dibutuhkan satu jam bagi orang lain untuk mengetahui apa yang Anda lakukan di dunia, itu terlalu pintar.

2
Michael K

Saya kenal seorang pria; dia mungkin orang paling cerdas yang pernah saya temui. Dia jelas merupakan seorang pembuat kode yang tidak dapat dipercaya, mungkin lebih baik daripada yang pernah saya alami seumur hidup dalam hal pemrograman pemrograman. Dia menulis kode seperti sedang mengetik dokumen Word dan dapat membalik daftar yang tertaut seperti yang tidak akan Anda percayai. Jika Anda ingin berbicara tentang menulis kode rumit yang serius, dia adalah lelaki Anda dan jika saya mengalami masalah yang sangat sulit, saya selalu menoleh kepadanya. Namun, mengerjakan proyek bersamanya dalam pengaturan tim sangat menyiksa. Dia tidak dapat langsung menargetkan masalah bisnis dan memberikan solusi yang logis, efisien, dan ringkas untuk itu. Baginya, daftar kode 1000 baris akan lebih baik daripada 100. Alih-alih menggunakan alat yang disediakan kepadanya melalui IDE atau kerangka kerja, dia akan menggulung alat super-dioptimalkan sendiri. Ini adalah semua baik dan bagus kecuali ketika anggota tim lain sedang menunggunya untuk menyelesaikan sesuatu, atau kita memiliki tenggat waktu.

Sementara saya mengagumi kemampuannya untuk melakukan hal-hal rumit ini, yang saya butuhkan adalah seseorang yang dapat menyelesaikan masalah dan melanjutkan. Ini tidak baik untuk dikatakan, atau diakui, tetapi kadang-kadang dalam sebuah bisnis, waktu adalah segalanya dan Anda harus menyelesaikan masalah dan melanjutkan hidup Anda, Anda selalu dapat kembali lagi nanti dan menolaknya untuk memperbaiki kode Anda. Ada garis tipis antara menjadi pintar dan juga menjadi sakit di pantat. Moto saya untuk tim saya selalu, apa hal paling sederhana yang akan berhasil dalam situasi ini dan kemudian pergi dari sana. Kadang-kadang sederhana tidak selalu jawabannya tetapi tempat yang bagus untuk memulai.

1

"Pintar" dalam konteks ini berarti "terlalu pintar untuk kebaikannya sendiri", mis. Sesuatu yang berfungsi sekarang tetapi akan menjadi mimpi buruk untuk dipahami dan diubah di kemudian hari.

Terutama jika itu adalah trik yang mengeksploitasi fitur yang tidak jelas dari bahasa pemrograman, atau memanfaatkan efek samping yang aneh, atau merupakan cara yang sangat aneh untuk memecahkan masalah dalam bahasa target.

1
Andres F.

Karena apa yang tampak seperti kepintaran bagi pengembang dalam ledakan kreativitas dapat dengan mudah lulus sebagai kekacauan dan hanya menjadi tidak dapat dibaca, tidak dapat dipelihara blok teka-teki tidak jelas untuk orang lain.

Tetap saja, blok teka-teki yang bagus, pintar, berkinerja baik, tetapi jika Anda memiliki pengalaman, Anda akan sering menyadari bahwa itu akan merugikan bisnis Anda (bukan Anda, pengembang) di lebih banyak untuk mempertahankan hal itu pada medium- atau jangka panjang. Jadi, Anda lebih suka menenangkan semangat sesama pengembang saat mereka dibawa.

Kecuali, tentu saja, jika ada alasan untuk kepintarannya. Dan jika ada dokumentasi yang bagus yang disertai dengan hal-hal membingungkan yang baru saja Anda tulis. Anda berkomentar sepotong kode pintar, kan? Jelaskan niatnya, mengapa harus seperti, dan bagaimana perilakunya?

Jika tidak ada justifikasi, maka itu mungkin hanya masalah optimasi prematur, rekayasa berlebihan, atau jenis YAGNI. Jika dibutuhkan 15 level tipuan untuk melakukan sesuatu yang sederhana, maka ada kemungkinan Anda juga termasuk dalam kategori sebelumnya. Dan jika itu tidak didokumentasikan, maka itu hanya masalah.

Kode yang hebat seharusnya tidak mengharuskan pengelola berada di 100% sepanjang waktu untuk memahaminya. Kode yang baik itu pintar. Kode hebat bisa hampir sama efisiennya, tetapi lebih baik dalam banyak aspek lainnya. Kode yang hebat seharusnya tidak memerlukan IDE dengan 15 tampilan untuk mengikuti desain aplikasi Anda.

Catatan: hei, saya telah menulis beberapa hal yang saya pikir pintar tapi itu membuat WTF keluar - jika bukan rekan pengembang saya - mulut manajer saya. Harus melihatnya dari sudut pandang mereka.

1
haylem

Saya cenderung pintar, tapi saya berusaha keras untuk menjadi anggun.

Kembangkan kode sekarang yang orang lain tidak akan coba dan hindari nanti.

1
kevpie

"Kode pintar" adalah kode apa pun yang harus dipikirkan oleh programmer dengan sangat keras atau menggunakan keterampilan tingkat lanjut untuk menulisnya. Masalah dengan itu mengabaikan perlunya "kepintaran margin" tertentu, paling baik diungkapkan oleh Brian W. Kernighan:

"Debugging dua kali lebih keras daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk debug itu."

1
Alex

Ini adalah pemahaman saya tentang masalah ini, berdasarkan pengalaman saya dan jawaban lainnya:

  1. Kode yang membutuhkan kepintaran untuk menulis, tetapi keluar dibaca dan dipelihara tidak dianggap berbahaya. Namun, sebagian besar pengembang tidak akan menyebut kode semacam itu "pintar"; mereka dapat menggunakan istilah yang berbeda seperti "elegan". Mungkin ada atau tidak ada perdebatan tentang apakah kode tersebut ada.
  2. Kode produksi yang membutuhkan waktu dan upaya yang signifikan untuk memahami bahkan oleh pengembang berpengalaman yang mengenal bahasa itu "pintar" dan dianggap berbahaya oleh semua orang.
  3. Kode produksi yang memerlukan waktu dan upaya yang signifikan oleh pengembang yang tidak berpengalaman dianggap berbahaya oleh sebagian orang. Saya telah melihat jawaban, dan saya telah bekerja dengan pengembang yang telah mengatakan secara eksplisit bahwa mereka akan lebih memilih untuk menjaga semuanya sebagai "common denominator terendah".
1
Larry Coleman

Biasanya ketika Anda harus 'pintar' untuk menyelesaikan masalah dalam kode. Jika solusi dan tidak terlalu mudah maka Anda akan mendapatkan banyak wajah bingung atau efek samping aneh ketika mengasumsikan kondisi tertentu (yang mungkin 100% benar pada saat menulis kode)

Jadi pintar == membingungkan == buruk :( Tapi itu juga luar biasa karena saya menggunakan mereka untuk solusi praktis untuk masalah terbatas.

0
user2528

Saya lebih suka solusi sederhana, saya sangat suka cara Ruby. Bila Anda ingin menjumlahkan 2 elemen pertama dalam daftar. Pertama Anda memotong daftar untuk membuatnya memiliki ukuran = 2 dan kemudian Anda jumlahkan itu.

Saya ingat bahwa setelah saya menggunakan 1 daftar, bukan 3 dan membuat satu fungsi besar yang sangat sulit untuk dipertahankan/diubah.

di dunia todays kita tidak harus mengorbankan kejelasan kode untuk kinerja (kecuali c ++, mereka tidak harus melakukannya, tetapi mereka akan melakukannya).

0
IAdapter

Mengutip ulang untuk konteks dan dan pemahaman yang lebih mudah:

"Debugging dua kali lebih keras daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk debug itu."

Apa yang ditulis Brian Kernighan di sini jelas merujuk pada konvolusi, dan ia secara keliru menggunakan kata pintar.

"Debugging dua kali lebih keras daripada menulis kode di tempat pertama. Karena itu, jika Anda menulis kode [berbelit-belit] mungkin, Anda, menurut definisi, tidak cukup pintar untuk debug itu."

Lilitan:

A thing that is complex and difficult to follow.

Pintar:

Showing intelligence or skill; ingenious

Programmer yang berpendidikan tahu bahwa kode sederhana itu cerdas. Kode yang sepintar mungkin harus sederhana menurut definisi. Programmer yang berpendidikan juga akan menghindari bekerja dengan dan menulis kode berbelit-belit seperti wabah. Mereka juga akan mengubah kode berbelit-belit menjadi kode pintar setiap kali mereka memiliki kesempatan. Kode biasanya mulai berbelit-belit dan mendekati kepintaran sebagai pengetahuan tentang domain dan pemahaman kemampuan kognitif manusia dalam pemrograman lebih baik dipahami melalui pengalaman dan berbagi pengetahuan.

Karena popularitas kutipan ini dan Brian Kernighan yang cukup populer di industri penyalahgunaan Firman ini memiliki dampak sosial yang negatif dan saya jujur ​​ingin melihat yang ditangani oleh pria itu sendiri. Sebelum menulis artikel ini saya mencoba untuk melihat apakah saya bisa mengirim email kepadanya, tetapi, saya tidak dapat menemukan informasi kontak email yang saya mengerti :(.

Dampak sosial negatif yang saya lihat adalah programmer lain mengucilkan rekan-rekan mereka yang lebih pintar, karena mereka sekarang melihat kepintaran sebagai masalah. Masalah sebenarnya adalah teman sebaya bodoh yang berpikir mereka pintar dengan melakukan hal-hal dengan cara baru yang tidak otomatis, dan terus-menerus menciptakan hal-hal baru ketika tidak ada keuntungan selain mendapatkan dan memahami komunitas yang lebih besar dan menggunakan kembali ide-ide pintar sebanyak mungkin.

Saya perlu mengklarifikasi bahwa --- sering mendapatkan pemahaman lebih sulit daripada menciptakannya sendiri. Karena masalah umum dalam industri untuk tenggat waktu yang tidak realistis, menciptakan batas waktu Anda sendiri untuk masalah ceruk yang lebih kecil akan digunakan untuk menghemat waktu. Ini didasarkan pada pengamatan bahwa hal-hal yang berguna dan dapat digunakan kembali biasanya menargetkan ceruk yang lebih besar, atau memberikan abstraksi yang berguna untuk penemuan. Ini juga didasarkan pada fakta bahwa orang-orang menargetkan ceruk besar untuk menghasilkan lebih banyak uang, ketika seringkali ini membuat alat ini sangat sulit digunakan karena kerumitan yang terlibat dalam membuat sesuatu yang dapat digunakan untuk area aplikasi yang luas.

Dampak sosial negatif lainnya adalah ini mencegah kemajuan dan keinginan untuk memahami karena dalam dunia egosentris kita, kita akan segera menyangkal kurangnya pemahaman kita sendiri dan menghapus kode sebagai berbelit-belit meskipun, setelah dipahami, idenya sebenarnya cukup pintar.

TODO Saya ingin mengutip beberapa referensi tetapi saya juga ingin kurangnya referensi untuk tidak menghalangi kemampuan saya untuk berbagi informasi sehingga saya akan dengan cepat mengutip apa yang saya ingat sebagai sumber informasi saya dan mungkin saya akan menemukan info aktual beberapa hari (atau Anda dapat menemukannya untuk saya! :)

  • Pembicaraan Guido Van Rossum tentang loop acara dan bagaimana ia memahami mereka
  • Seorang karyawan GitHub yang menyatakan bahwa mereka menghindari mempekerjakan orang pintar di Y-Combinator
  • Banyak diskusi dan pembelajaran yang terjadi di komunitas Python. Komunitas Python sangat kritis terhadap ide-ide baru, tetapi tidak mengabaikan ide-ide baru yang mereka lakukan tidak mengerti, dan Anda biasanya dapat melihat fitur yang awalnya terlihat berbelit-belit melihat cahaya hari sebagai fitur/paket bahasa inti.
  • Pengalaman dan pendapat profesional saya sendiri berdasarkan pengamatan 10.000 kaki saya. Saya tidak bisa benar-benar melihat hal-hal spesifik untuk dicerahkan dari semua jalan di atas sana :( Semoga pengalaman dan pengamatan Anda akan memberi tahu Anda hal yang sama dan orang lain dapat berkomentar di bawah ini untuk memberikan jawaban ini beberapa manfaat.

Jangan ragu untuk menambahkan kutipan Anda sendiri! Juga, jangan ragu untuk menambahkan koma ke teks saya. Saya belum menyegarkan pengetahuan saya tentang penggunaan koma dalam bahasa Inggris dalam beberapa waktu ...

0
Derek Litz