Mengapa kepintaran dianggap berbahaya dalam pemrograman oleh sebagian orang?


89

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.

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

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


116
Saya pikir mungkin Anda salah paham - kepintaran dalam diri seseorang adalah kebajikan, tetapi kepintaran dalam suatu sistem adalah sifat buruk. Sistem dan kode tidak boleh pandai, mereka harus sejernih kristal. Sering kali diperlukan individu yang pandai untuk menciptakan hal-hal seperti itu.
nlawalker


15
@nalkalker: Saya rasa saya mengerti sekarang. Orang menggunakan kata "pintar" ketika merujuk ke kode sebagai antonim untuk "jelas" atau "sederhana" karena mereka benar-benar bermaksud menggunakan kata yang merupakan antonim untuk "jelas" atau "sederhana".
Larry Coleman

2
@ Darry: Saya tidak yakin apa yang akan disiratkan. Pintar seperti dalam inventif, orisinal, cerdik, dan secara implisit menggunakan hal-hal dengan cara yang belum pernah Anda lihat sebelumnya. Kadang-kadang itu bagus (banyak pola desain yang pintar) tetapi keasingan solusi juga bisa membuatnya sulit untuk dikerjakan.
doppelgreener

2
Apakah tidak ada lagi kode komentar? Di situlah Anda menjelaskan kepintaran, sehingga mereka yang mengikutinya bisa mengerti. Seperti Anda dalam waktu 6 bulan.
Phil Lello

Jawaban:


207

Solusi sederhana lebih baik untuk pemeliharaan jangka panjang. Dan itu tidak selalu hanya tentang keakraban bahasa. Garis yang kompleks (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 ada alasan konkrit yang terukur untuk implementasi itu, itu "terlalu pintar".

Mencari tahu apa yang terjadi semakin sulit saat kompleksitas tumbuh 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.


7
+1 Kata bagus. Saya pikir ini hal yang seimbang. Jika saya dapat mengharapkan seseorang dengan jumlah pengetahuan yang cukup untuk memahami kode dengan sedikit memikirkan dirinya sendiri, Anda dapat memilih yang pintar dan mungkin menambahkan komentar. Jika dibutuhkan empat kali lebih lama untuk memahami kode hanya karena seseorang ingin membuktikan keterampilan pengkodean mereka - nah! Jika seseorang cukup pintar untuk menghasilkan solusi yang cerdas, mereka harus cukup pintar untuk memutuskan apakah itu dapat dimengerti atau tidak. Kalau tidak, itu hanya pamer.
Anne Schuessler

Paragraf terakhir yang saya suka. Sisanya benar, tetapi disayangkan.
Orbling

Sepertinya Anda telah melihat kode sumber ke Zend PHP :)
Tim Post

+1 Pola sederhana mungkin tidak berkinerja sebaik pola pintar , dan seperti yang Anda katakan, terserah kepada kami sebagai pengembang untuk terus mendorong amplop "pintar" dengan memahaminya.
Stephen Furlani

3
Sebagai seseorang yang harus membenarkan melakukan sesuatu yang "pintar" ketika itu benar-benar hanya "minimal, benar secara ortogonal", saya ingin menambahkan bahwa ada beberapa subjektivitas pada pertanyaan tentang apa sebenarnya yang pintar. Sebagai contoh, beberapa orang akan selalu ingin menulis if FuncX() then return true, else return false, dan tidak akan pernah ingin Anda hanya menulis return FuncX(). Saya tidak bercanda, saya benar-benar sudah bicara. Karena orang ingin tempat untuk menggantung breakpoints mereka, atau sesuatu. :-)
Warren P

102

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


8
Di sisi lain, jika Anda menulis kode sepintar yang Anda bisa, Anda harus belajar men-debug-nya, dan dengan melakukannya Anda menjadi lebih pintar. Atau semacam itu.
James McNellis

11
@ James: Atau Anda baru saja gagal. ;)
Josh K

10
@Josh K: Saya selalu tahu CIUMAN sebagai "Keep It Simple, Stupid!" - en.wikipedia.org/wiki/KISS_principle
Orbling

1
@Orbling: Saya mengingatnya secara berbeda, oh well, sekarang saya tahu.
Josh K

1
"Tetap sederhana dan bodoh" , menurut Wikipedia ? :) Apakah ini berarti menjaganya agar tetap sederhana itu bodoh atau untuk membuatnya sederhana, Anda pasti bodoh ? : P
Mateen Ulhaq

83

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


5
+1 untuk kutipan yang bagus dan untuk menjadi jawaban pertama tanpa asumsi tersirat bahwa sesuatu tidak dapat menjadi sederhana dan pintar
Larry Coleman

15
Yang penting adalah programmer yang seharusnya pandai, bukan kodenya.
Kristopher Johnson

Cara kutipan yang lebih baik maka idiot menyalahgunakan kata pintar dengan cara pintar.
Derek Litz

30

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.


3
Solusi sederhana untuk masalah kompleks adalah tentang sepintar yang bisa didapatkan siapa pun.
JeffO

meskipun selalu ada peringatan bahwa Anda tidak ingin terlalu menyederhanakan hanya karena pengelola tidak dapat kode (atau membacanya).
Ken Henderson

@confusedGeek - tetapi jika Anda tahu programmer pemeliharaan tidak bisa mengatasinya, maka solusi pintar menjadi bom waktu. Saldo adalah kunci di sini - dan ini hanya berlaku jika Anda mengetahui tim pemeliharaan. Jika Anda tidak tahu, maka menjadi jelas dalam kepintaran Anda adalah yang terbaik yang dapat Anda lakukan.
Michael Kohne

1
@Michael, kendala kinerja mungkin mengharuskan kode Anda pintar. Maka tugas pengelola untuk belajar, dan jika mereka tidak bisa, merekrut pengelola baru.
Stephen Furlani

@Stephen, jika kode PERLU menjadi pintar, programmer harus sangat berhati-hati untuk menjelaskan MENGAPA perlu, sehingga pengelola tidak harus mulai dari awal.

26

Mengutip Brian Kernighan:

“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. "


"... Kecuali kamu menggunakan definisi pintar dan kode yang benar-benar sederhana untuk dimengerti dan di-debug."
Derek Litz

Tergantung pada kamus mana yang Anda jempol, saya kira. Dalam pengalaman saya, kode "pintar" - mudah dipahami atau tidak - masih mengeksploitasi konjungsi yang beruntung dalam spesifikasi. Bahkan jika itu jelas, itu harus ditandai jika asumsi seperti itu dapat berubah dan tidak boleh bocor ke bagian kode yang berbeda.
peterchen

Anda benar, tetapi saya ingin menambahkan peringatan bahwa itu tergantung pada betapa mudahnya bahasa dan implementasinya dibaca dan dipahami, dan komentar Anda mungkin hanya derau kode alih-alih sesuatu yang bermanfaat. Dan walaupun lazim menggunakan kata pintar untuk menyatakan kebalikannya, kita harus berusaha untuk menjadi lebih jelas sehingga orang lain tidak dapat salah memahami hal-hal untuk keuntungan mereka sendiri.
Derek Litz

Tidak keberatan dengan hal itu :)
peterchen

22

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


16

"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 kata pintar . 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.


5
Saya akan memutuskan ini jika Anda tidak berkhotbah tentang protokol sosial dan "orang-orang [sic]".
Jason Baker

2
Tidak apa-apa dan terima kasih sudah mengingatkan saya. Saya cenderung terlalu berkhotbah. Tetapi saya sangat tersinggung oleh beberapa (banyak?) Ketidakmampuan dan / atau keengganan programmer untuk berurusan dengan perilaku manusia biasa, dan kurangnya empati dan introspeksi yang saya lihat di bidang kami. Mungkin saya harus memberi tanda kutip pada "orang orang" dan bukan huruf miring. Bahasa Inggris bukan bahasa pertama saya, saya hanya tidak tahu bagaimana caranya agar lebih singkat bahwa, untuk menjadi pengembang yang hebat, Anda harus memahami tidak hanya kode, tetapi juga orang. MENURUT OPINI SAYA.
fzwo

Mengedit jawaban saya. Lebih jelas / kurang ofensif sekarang?
fzwo

+1 untuk kalimat pertama, yang sebenarnya telah saya simpulkan setelah mendapatkan beberapa jawaban pertama.
Larry Coleman

Ya, terima kasih telah menjelaskan bagaimana pintar digunakan oleh orang-orang bodoh dalam konteks ini!
Derek Litz

9

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 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 di dalamnya 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.


8

Good Clever - rasio tinggi antara baris kode yang pintar vs baris yang ada di dalam pilihan yang tidak pintar. 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", "anggun", "ringkas", atau "singkat".


Jawaban yang menarik, tetapi apakah kode yang Anda sebut "Bad Clever" sebenarnya disebut sebagai "cantik", dll., Oleh siapa pun selain orang yang menulis kode tersebut?
Larry Coleman

2
Tergantung. Dalam Objective-C / C ++ / C, fenomena biasanya terbatas pada individu. Di Perl dan Ruby, sering kali seluruh komunitas akan memiliki nilai bersama tentang Bad Clever sebagai "cantik", "elegan", dll.
user8865

1
@ user8865: juga, kode "Good Clever" akhirnya menjadi jauh lebih mudah untuk di-debug daripada yang asli karena ada menurut definisi Anda 3 kali lipat lebih kecil dari itu.
Larry Coleman

2
Ah, jadi program Perl adalah - sekarang hampir secara definisi - Pintar Sangat Bagus :) Senang tahu!

7

Saya harus bertanya-tanya tentang definisi pintar setiap orang.

Secara pribadi, saya merasa seperti saya pintar ketika mengambil masalah yang sulit dan rumit, dan mengimplementasikannya dengan cara yang sangat sederhana dan lurus ke depan, 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 .."


1
LOL tentang tl; dr, seberapa lambat menurut Anda programmer membaca? Ya, saya benar-benar membenci penyalahgunaan kecerdasan di sini yang berarti kebalikan dari apa yang sebenarnya. Pengembang dan manajer Dumb / Ignorant / Evil benar-benar menggunakan ini untuk membenarkan tidak mempekerjakan seseorang yang mereka pikir mungkin "terlalu pintar".
Derek Litz

6

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 seringkali didasarkan pada apa yang dapat dilakukan oleh anggota tim yang paling tidak terampil, sehingga sangat relatif terhadap lingkungan.


Luar biasa: "terlalu pintar sering didasarkan pada apa yang dapat bekerja dengan anggota tim yang paling tidak terampil"
Orbling

tergantung pada lokasi Anda ini agak kurang dari "sangat baik" di kali :-)
Bill

Siapa yang peduli dengan anggota tim yang paling tidak terampil? Hampir setiap tim (meskipun saya yakin ada beberapa pengecualian) memiliki setidaknya satu anggota yang sama sekali tidak punya bisnis memanggilnya seorang programmer.
dsimcha

1
Semoga Anda membuat mereka menjadi lebih baik, tetapi bahkan ketika itu tidak berhasil, Anda masih harus berurusan dengan mereka sebagai anggota tim dan mereka harus dapat berpartisipasi dalam beberapa pekerjaan. Saya saat ini melihat ini dalam ekspresi lambda. Banyak orang yang bekerja dengan saya belum mendapatkannya sehingga mereka melihat mereka terlalu pintar. Ini sangat disayangkan karena mereka memecahkan banyak masalah kita dengan cukup efisien dan elegan, tetapi jika tidak ada orang tingkat menengah yang mendapatkannya, mereka akan pergi ke manajemen untuk perangkat lunak yang tidak didukung.
Bill

@ Bill: Fungsi Lambda ??? Siapa pun yang tidak dapat memahami sesuatu yang sesederhana itu, bahkan setelah secara eksplisit diminta untuk mempelajarinya, tidak memiliki bisnis untuk menjadi programmer profesional.
dsimcha

6

Terkadang saya sangat pintar sehingga saya salah.


1
Itu bisa terjadi. Dan terkadang, ada yang salah, itu benar.
bobobobo

Mereka menyebut teori-teori itu John. Teori bisa dan harus salah sesekali :), bukan berarti kita harus berhenti menjadi pintar dan berusaha untuk menjadi sepintar mungkin. Bagaimana lagi kita akan menjadi pemimpin di dunia ini! "Ah, tapi jangkauan pria harus melebihi genggamannya - atau untuk apa surga?"
Derek Litz

4

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 tersebut.


+1 untuk menggunakan "murah" sebagai hal positif dalam pengembangan
Gary Rowe

Saya telah melihat terlalu banyak kode 'pintar' yang tidak performant!
HLGEM

Ada metrik yang lebih berharga, tetapi itu bisa menjadi yang baik tergantung pada proyek, dan seringkali mereka bertentangan satu sama lain sehingga Anda harus menekankan satu sama lain agar dapat berhasil.
Derek Litz

3

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.


Ya, atau karena mereka tidak memikirkan lelaki berikutnya, atau apa pun. Saya tidak yakin saya akan mengaitkan dengan egoisme intelektual apa yang dapat dijelaskan dengan cukup oleh kebiasaan malas dan tidak terpikirkan. Tetapi kenyataannya adalah, jika kode Anda tidak dapat dipahami pada pandangan pertama, itu membutuhkan komentar, dan jika kode + komentar lebih panjang (dalam LOC atau waktu) daripada cara lain, Anda bekerja lebih keras daripada yang Anda butuhkan.
Dan Ray

Jawaban yang bagus, (tidak bisa +1, tidak ada yang tersisa, nanti). Jika orang tidak menghabiskan waktu untuk menulis kode pintar dan orang lain tidak menghabiskan waktu untuk memahaminya, lebih memilih kode sederhana yang tidak rumit, bahkan jika kurang efisien. Maka tidak ada kemajuan dalam keterampilan akan terjadi.
Orbling

Jawaban Terbaik. Mantra: tulis garis dasar yang sederhana, kode pembuka yang braindead dan lambat ketika semua bangun ... dan kemudian berikan komentar ketika Anda merebusnya menjadi satu-liner yang tidak dapat dibaca. Itulah cara Anda mempelajari semua trik kotor dalam bahasa Anda!
Droogans

Jika saya menggunakan kepintaran Anda dengan cara berbelit-belit, saya pribadi telah menulis beberapa kode berbelit-belit yang dibuat dapat dipahami melalui pencatatan. Walaupun saya tidak berencana untuk menulis kode yang berbelit-belit, pada saat itu, itu menghemat waktu saya, tetapi saya menambahkan # TODO yang mungkin harus ditulis ulang menjadi sederhana jika kita perlu memodifikasinya secara signifikan.
Derek Litz

3

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 bisa dimengerti menunjukkan kepintaran konstruktor tetapi mengambil ide sederhana dan membuatnya kompleks menunjukkan konstruktor ingin dilihat sebagai pintar.


Ya, itu ide egosentris ingin menjadi pintar yang membuat basis kode Anda berbelit-belit. Anda baik, atau tidak pintar. Sayangnya, pada tahap pembelajaran awal orang berpikir mereka lebih pintar daripada mereka. Kemudian mereka menyadari betapa tidak pintarnya mereka dan kemudian benar-benar menulis kode pintar begitu mereka mengisi kekosongan dalam pengetahuan.
Derek Litz

2

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


2
Cukup adil, tetapi apakah jawaban Anda berubah jika orang yang tidak dapat menemukan kode tidak terbiasa dengan semua fitur bahasa?
Larry Coleman

2
Itu berbeda, setidaknya IMO. Jika seseorang tidak terbiasa dengan fitur-fitur bahasa, maka mereka tidak dalam posisi untuk menilai apa yang pintar atau tidak.
Joe D

@Larry: Belum tentu. Saya akan berasumsi bahwa orang yang membacanya adalah pada tingkat kemahiran dasar / rendah maju. Dan jika itu mulai menjadi kompleks yang tidak dapat diperbaiki, maka inilah saatnya untuk memasukkan komentar blok yang menjelaskan apa yang seharusnya dilakukan oleh kode tersebut, yang akan membantu membangun kerangka acuan untuk memahami apa yang sebenarnya dilakukan. Komentar harus tingkat tinggi, - tuliskan perhitungannya, jelaskan prosesnya; jangan ulangi kodenya. Seseorang di harus (idealnya) dapat memahami kode ketika dia membacanya. Itulah tujuannya.
Michael K

2

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 keadaan sistem yang hampir terputus dari kode "pintar" (seperti file yang dibuka sebelumnya, koneksi jaringan, database, 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.


1

"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 adalah dua kali lebih keras daripada menulis kode di tempat pertama. Karena itu, jika kamu menulis kode secerdas mungkin, kamu, menurut definisi, tidak cukup pintar untuk debug itu."


1

Karena apa yang tampak seperti kepintaran untuk pengembang dalam ledakan kreativitas hanya dapat lulus sebagai kekacauan dan hanya menjadi terbaca , unmaintainable blok teka-teki jelas bagi 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) 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 memang 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 masalah 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 hebat seharusnya tidak mengharuskan pengelola berada di 100% sepanjang waktu untuk memahaminya. Kode yang baik itu pintar. Kode yang bagus bisa hampir sama efisien, tetapi lebih baik di banyak aspek lainnya. Kode yang hebat seharusnya tidak memerlukan IDE dengan 15 tampilan untuk mengikuti desain aplikasi Anda.

Catatan: hei, saya sudah menulis beberapa hal yang saya pikir pintar tapi itu menarik perhatian WTF? dari - jika bukan co-developer saya - mulut manajer saya. Harus melihatnya dari sudut pandang mereka.


Terima kasih atas jawabannya. Anda tampaknya setuju dengan yang lain yang mengatakan bahwa "pintar" tidak berarti apa yang saya pikirkan.
Larry Coleman

1

Saya cenderung pintar , tetapi saya berusaha untuk menjadi elegan .

Kembangkan kode sekarang sehingga orang lain tidak akan mencoba dan menghindari nanti .


1
Ayo ... pintar adalah sinonim untuk anggun, otakmu sudah dipasarkan. Ya, saya mengada-ada, itu artinya otak Anda dipengaruhi oleh pemasaran, bukan kebenaran.
Derek Litz

Elegan: sederhana dan pintar. @DerekLitz +1 untuk apa pun cromulent.
kevpie

1

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 pernah melihat jawaban, dan saya telah bekerja dengan pengembang yang telah mengatakan secara eksplisit bahwa mereka lebih suka untuk menjaga semuanya "penyebut umum terendah".

Keseluruhan budaya barat modern adalah LCD, saya kira itu berarti pemrograman juga harus; tidak baik.
Orbling

@Orbling: Ya, tapi jangan lupa kepuasan instan.
Larry Coleman

Saya suka poin pengalaman Anda. Sangat menyedihkan bahwa orang tidak berjuang untuk perbaikan berulang dan berinvestasi satu sama lain dengan berbagi pengetahuan dan pemahaman. Sebaliknya mereka lebih suka kita menjadi roda penggerak di roda sehingga kita dapat dengan mudah diganti ketika saatnya tiba. Dengan melakukan ini kami menghambat kemajuan. Kami juga menjual diri kami pendek ...
Derek Litz

1

Saya kenal seorang pria; dia mungkin orang paling cerdas yang pernah saya temui. Dia pastinya adalah seorang pembuat kode yang tidak bisa dipercaya, mungkin lebih baik daripada yang pernah saya alami seumur hidup dalam hal pemrograman pemrograman. Dia menulis kode seperti sedang mengetik dokumen kata dan dapat membalik daftar yang tertaut seperti yang tidak akan Anda percayai. Jika Anda ingin berbicara tentang menulis beberapa kode rumit yang serius, dia laki-laki 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 diberikan kepadanya melalui IDE atau kerangka kerja, ia akan menggulung alat super-optimalnya sendiri.

Sementara saya mengagumi kemampuannya untuk melakukan hal-hal rumit ini, yang saya butuhkan adalah seseorang yang dapat menyelesaikan masalah dan melanjutkan. Tidak bagus untuk mengatakan, atau mengakui, 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.


Maaf, terlepas dari kualitas orang yang Anda temui ini dapat membuat kode hal-hal rumit, dia bodoh. Orang bisa dan bodoh, terlepas dari sifat mereka yang lain. Pernyataan Anda tentang apa yang benar-benar Anda inginkan dari pengembangan jelas bagi orang yang berbakat. Jika dia benar-benar cerdas, Anda harus membantunya dan menghadapinya alih-alih membiarkannya melakukan hal-hal bodoh dengan bakatnya. Anda melakukan tindakan merugikan padanya dan semua orang di sekitarnya dengan menjadi menganggur dan mengeluh di belakangnya. Jika dia tidak pandai kamu harus memecatnya, maka mungkin dia akan mendapatkannya.
Derek Litz

Saya memang memiliki hubungan dengan sumber daya utama yang telah berurusan dengan orang-orang cerdas setiap hari selama beberapa dekade dan beberapa dari mereka hanya kehilangan beberapa pengetahuan untuk menjadi produktif dalam lingkungan tim. Mereka dapat mengatasinya sendiri jika Anda setidaknya memberi tahu mereka tentang masalahnya.
Derek Litz

1

"Pintar" dalam konteks ini berarti "terlalu pintar untuk kebaikannya sendiri", yaitu 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.


0

Saya lebih suka solusi sederhana, saya sangat suka cara ruby. Ketika Anda ingin, misalnya, menjumlahkan 2 elemen pertama dalam daftar. pertama Anda memotong daftar untuk membuatnya memiliki ukuran = 2 dan kemudian Anda menjumlahkannya.

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

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

Mengutip kembali untuk konteks dan dan pemahaman yang lebih mudah:

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

Apa yang ditulis Brian Kernighan di sini jelas merujuk pada konvolusi, dan dia 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 men-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 cerdik. 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 menjadi cukup populer di industri penyalahgunaan kata 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 dapat 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 bahwa mereka pintar dengan melakukan hal-hal dengan cara baru yang tidak otomatis, dan terus-menerus menciptakan hal-hal baru ketika tidak ada keuntungan daripada mendapatkan dan memahami komunitas yang lebih besar dan menggunakan kembali ide-ide pintar sebanyak mungkin.

Saya perlu mengklarifikasi meskipun yang sering mendapatkan pemahaman lebih sulit daripada menciptakan Anda sendiri. Karena masalah umum dalam industri untuk tenggat waktu yang tidak realistis, menciptakan tenggat 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. Hal ini juga didasarkan pada kenyataan 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 peristiwa dan bagaimana dia memahami mereka
  • Seorang karyawan GitHub yang menyatakan bahwa mereka menghindari mempekerjakan orang pintar di Y-Combinator
  • Banyak diskusi dan pembelajaran yang berlangsung di komunitas Python. Komunitas Python sangat kritis terhadap ide-ide baru, tetapi tidak menampik ide-ide baru yang tidak mereka pahami, dan Anda biasanya dapat melihat fitur-fitur yang pada 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 dapat 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 ...


-1

Karena seringkali orang tidak tahu bahasa, idiom, dan pola. Mereka bisa mengambil buku dan mempelajarinya, tetapi mereka tidak. Dan karena orang-orang itu Anda harus menulis kode sederhana.

Itu bukan kepintaran. Itu pengetahuan.


2
Saya tentu saja tidak setuju dengan ini (meskipun tidak bernilai -1). Dengan argumen ini Anda bisa mengatakan bahwa Anda tidak akan menerapkan pola Komando untuk menangani tumpukan transaksi Undo / Redo karena pengelola baru keluar dari sekolah dan tidak mengerti apa yang sedang terjadi. Pada titik tertentu Anda harus mengatakan bahwa jika mereka tidak mengetahuinya, mereka perlu mempelajarinya.
Ken Henderson

@confusedGeek Benar sekali, di mana Anda menarik garis pada ketidaktahuan?
Orbling

@Orbling, jujur ​​itu bagian yang sulit dan sedikit banyak tergantung pada situasinya. Panduan umum yang cenderung saya gunakan adalah jika pengembang yang cukup berpengalaman (berpengetahuan luas dalam teknologi yang digunakan) dapat melakukan grok, maka itu mungkin ok. Jika mereka tidak bisa maka itu perlu di refactored (atau meninjau praktik perekrutan).
Ken Henderson

@confusedGeek Aye, kedengarannya masuk akal. Tes lakmus mungkin, dapatkah pengembang dengan kaliber yang sama seperti diri Anda memahami dengan mudah apa yang telah Anda lakukan dengan cukup cepat. Jika tidak dan ada cara yang lebih mudah, maka perlu diubah. Terkadang tidak ada cara yang lebih mudah.
Orbling

-1. Jangan kode untuk penyebut umum terendah. Kompleksitas yang tidak perlu itu buruk, tetapi jika beberapa kepintaran membuat kode secara substansial lebih KERING, dll. Mungkin sepadan.
dsimcha

-1

Aku tidak bisa menemukan kata disiplin disebutkan di mana saja di sekitar sini, jadi saya akan chip. Saya tidak ingin memposting yang jawaban, tetapi untuk berbagi wawasan yang berbeda tentang masalah ini, mungkin salah satu yang pertanyaan awal tidak ada dalam pikiran .

Pengembang yang cerdas adalah hal yang baik.

Namun, sebelum kepintaran muncul sifat-sifat lain. Seperti yang mungkin Anda sadari, saya akan berbicara tentang disiplin . Pengembang yang cerdas dan tidak disiplin bisa sangat buruk untuk pemeliharaan sistem jangka panjang.

Misalkan ada bug atau persyaratan baru masuk. Pengembang yang cerdik mungkin segera menyadari bahwa beberapa perbaikan lokal akan menyelesaikan pekerjaan dalam 2 menit. Jika pengembang itu didisiplinkan, ia akan menahan diri untuk tidak menerapkan perbaikan tersebut ke kode sumber dan, sebaliknya, akan menemukan cara yang berarti untuk menyusun perilaku yang diinginkan ke sistem. Dengan cara ini, pada saat diperlukan untuk memodifikasi potongan kode tertentu pengelola akan memiliki waktu yang mudah untuk memahami kode dan menerapkan perubahan baru tanpa merusak apa pun. Jika tidak, Anda bisa mendapatkan gambarnya.


"Pemukulan Akan Terus Sampai Moral Meningkatkan"
agas

Arti @gnat? Untuk membersihkan sedikit; Saya tidak mengambil disiplin sebagai sesuatu yang dipaksakan pada pengembang. Itu adalah sifat kepribadian yang baik. Satu yang biasanya dikembangkan oleh orang pintar setelah beberapa waktu memelihara perangkat lunak. Masalahnya datang dengan orang-orang pintar yang belum berada dalam posisi pengelola cukup dan meninggalkan bom pintar di mana-mana untuk ditemukan orang lain.
dkateros
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.