Seberapa 'sederhana' solusi KISS yang sebenarnya? [Tutup]

12

Saya akui : Saya punya masalah "Keep It Simple and Short" sebagian besar waktu karena mencoba membuatnya sesuai dengan buku yang saya baca, pola-desain yang saya dengar dll memberi saya antusiasme - antusiasme yang datang dari perasaan bahwa saya berada di jalan yang benar menuju kesempurnaan yang mungkin.

Di sisi lain, ya, itu memberi tekanan ekstra pada saya dalam hal memberikan tenggat waktu kadang-kadang ...

Tetapi setiap kali saya berkata pada diri sendiri, "Lain kali jadikan itu sederhana, Anda bodoh!" Saya merasa sulit untuk membuatnya "sederhana" ketika kali berikutnya datang, karena itu mulai terasa aneh ... dan tidak nyaman setelah beberapa saat.

Lalu saya mulai menilai pemahaman saya tentang 'sederhana' ...

Apakah SIMPLE berarti terlalu pendek sehingga bekerja tetapi sulit untuk mempertahankan dan memperluas?

Apakah SIMPLE berarti melanggar banyak prinsip OOP?

Apakah SIMPLE berarti curang?

Apakah SIMPLE berarti hanya memenuhi tenggat waktu tanpa kesepakatan? dll.

Sebenarnya apa itu?

Pertanyaannya adalah : Dapatkah Anda menulis definisi SEDERHANA dari SIMPLE dalam hal prinsip KISS? -jika ada.

Terima kasih!

design-patterns

— kue pensil
sumber

4

Itu "Tetap sederhana, bodoh!", Tidak pendek. dan setelah menulis itu, saya melihat bahwa Anda benar-benar mengetahuinya tetapi tidak ada tautan hapus komentar di halaman seluler ...

— yannis

4

Saya tidak pernah menemukan sesuatu yang begitu singkat sehingga sulit untuk diperpanjang. Saya telah menemukan BANYAK hal yang merupakan monster besar yang hampir tidak dapat dipelihara karena mengubah satu hal menghancurkan segalanya.

— Ben Brocka

1

Saya pikir kesalahan kebanyakan orang dalam mencoba memahami KISS adalah mereka berpikir solusinya harus begitu sederhana, itu sudah jelas . Yang benar adalah bahwa menemukan solusi sederhana adalah segalanya tetapi sederhana. Ini sangat sulit !!! Setelah Anda menemukannya, semua orang berpikir "oh, itu sudah sangat jelas , mengapa saya tidak melihatnya sebelumnya?"

— Treb

2

KISSing yang baik sulit untuk dijelaskan atau didefinisikan secara tepat, tetapi begitu Anda melakukannya dengan benar, Anda akan tahu. Teruslah berlatih!

— Cascabel

1

Maaf, ini dimigrasikan di sini, bukan hanya ditutup secara langsung, tetapi ini meriah di luar topik di sini.

35

Mari belajar KISS Prancis:

La perfection est atteinte, non pas lorsqu'il n'y plus rien à ajouter, mais lorsqu'il n'y plus rien à retirer. - Antoine de Saint-Exupéry

Yang diterjemahkan ke:

Kesempurnaan tercapai, bukan ketika tidak ada lagi yang ditambahkan, tetapi ketika tidak ada lagi yang tersisa untuk diambil. - Antoine de Saint-Exupéry

— mouviciel
sumber

2

Seharusnya "Kesempurnaan adalah ketika tidak ada yang dihapus"

— normanthesquid

2

Ini adalah kutipan yang bagus tetapi tidak memiliki saran praktis.

— c_maker

2

Anda dapat membuat jawaban ini lebih sederhana (alias lebih sempurna) jika Anda menghapus bagian Prancis. :)

— Phil

1

@ Phil: Au contraire, mon ami.

— Gilbert Le Blanc

14

Skenario

Anda perlu memotong dan mencubit.

Solusi A: Tidak KISS

masukkan deskripsi gambar di sini

Solusi B: CIUMAN

masukkan deskripsi gambar di sini

Adapun definisi yang tepat : Sulit untuk menentukan skala absolut untuk mengukur kesederhanaan. Sebagian besar karena kesederhanaan sejati menghalangi pemahaman yang sebenarnya tentang masalah yang dihadapi, dan itu jarang dapat dicapai. Tetapi katakanlah solusi A dan B menggambarkan perbedaan antara solusi yang cenderung ke arah kerumitan dan kesederhanaan masing-masing.

— back2dos
sumber

Ini membuatku tersenyum.

— c_maker

Sangat ganas, bukan?

— NoChance

2

Bukan itu. Anak kucing saya tidur dengannya. Karena itu, tanpa kekerasan.

— Thomas Eding

11

"Jadikan sesederhana mungkin, tetapi tidak sesederhana" -Einstein

Menyimpan kode sesederhana mungkin, tetapi tidak sederhana tergantung pada masalah yang dipecahkan. Selama masalah yang dipecahkan cenderung berubah, demikian juga KISS.

Ada keseimbangan antara over-engineering (oh man ini sepertinya tempat yang bagus untuk memamerkan keterampilan Pola Desain saya!) Dan under-engineering (jika saja saya menggunakan pabrik saya tidak akan memiliki kopling ini yang menyebabkan saya membuat 20 perubahan kode ...). Tujuannya adalah rawatan.

— P.Brian.Mackey
sumber

1

"Jaga kompleksitas siklomatik Anda ke nilai yang seharusnya, dan tidak ada nilai lain". "Beli rumah dengan rasio pinjaman dengan nilai serendah mungkin, tetapi tidak lebih rendah". "Makanlah sarapan sebaik mungkin, tetapi tidak lebih baik". "Beli serendah dan jual setinggi yang Anda bisa, tetapi tidak lebih rendah / lebih tinggi". "Tumbuh setinggi yang Anda bisa, tetapi tidak lebih tinggi". + Msgstr "Buat nama variabel seserius mungkin, tetapi tidak ada yang lebih bermakna". "Berikan persentase usaha setinggi mungkin, tapi jangan lebih tinggi". "Tidak ada 'aku' di 'tim', tapi ada satu di 'tinggi'". "Berhenti dan cium mawar, tetapi hanya ketika ada mawar". "Tuliskan commen

— psr

11

Sederhana tidak berarti melanggar prinsip pemrograman yang baik. Bahkan, itu berarti lebih banyak kebalikannya.

Apakah SIMPLE berarti terlalu pendek sehingga bekerja tetapi sulit untuk mempertahankan dan memperluas?

Tidak. Menjadi sulit untuk dipertahankan dan diperluas adalah gejala kompleksitas yang besar. Bahkan, saya menemukan bahwa membuat kode dapat diperluas mengarah ke kode yang lebih sederhana, karena Anda tidak berurusan dengan setiap kasus, Anda dapat menjaga kode dasar tetap sederhana.

Apakah SIMPLE berarti melanggar banyak prinsip OOP?

Tidak. Sebagian besar prinsip OOP dirancang untuk menjaga kode tetap bersih dan lebih teratur, yang pada akhirnya, lebih sederhana.

Apakah SIMPLE berarti curang?

Tidak. Menulis keras untuk mempertahankan kode & peretasan dengan kedok menjaga tenggat waktu adalah.

Apakah SIMPLE berarti hanya memenuhi tenggat waktu tanpa kesepakatan? dll.

Batas waktu dan kesederhanaan kode Anda adalah dua masalah terpisah. Menulis kode sederhana tidak membutuhkan waktu lebih lama untuk menulis (walaupun ini adalah kesalahpahaman umum).

— GSto
sumber

Mungkin Anda pikir saya menderita kesalahpahaman itu, tapi saya pikir solusi sederhana yang ideal tidak selalu menjadi hal pertama yang terjadi pada kami, jadi kadang-kadang pada awalnya membutuhkan waktu lebih lama untuk menulis kode yang lebih sederhana - kemudian Anda membuat waktu itu dan lebih banyak lagi dengan tidak harus berurusan dengan kompleksitas.

— Cascabel

6

Ini sangat sulit untuk dijelaskan karena sederhana tidak berarti hal yang sama untuk semua orang.

Contoh. Beberapa pengembang berpikir itu ?:sederhana tetapi yang lain berpikir ifpernyataan lebih baik. Ketika turun ke level ini, Anda tidak bisa menyenangkan semua orang.

Secara umum, cara sederhana tanpa kerumitan . Untuk memahami kesederhanaan, kita perlu memahami kompleksitas.

Ada dua jenis kompleksitas:

Kompleksitas esensial mengacu pada situasi di mana semua solusi yang masuk akal untuk suatu masalah harus rumit (dan mungkin membingungkan) karena solusi "sederhana" tidak akan cukup menyelesaikan masalah. - Wikipedia

Kompleksitas tak disengaja adalah kompleksitas yang muncul dalam program komputer atau proses pengembangannya (pemrograman komputer) yang tidak penting untuk masalah yang harus dipecahkan. - Wikipedia

Anda dapat memeriksa kompleksitas esensial dengan pertanyaan-pertanyaan berikut:

Apakah solusi ini sederhana? Bisakah saya menjelaskannya kepada rekan saya dalam rentang beberapa menit dan mereka mendapatkannya? Apakah ada solusi yang lebih sederhana untuk masalah ini? Jika ya, adakah trade-off antara solusi rumit versus solusi sederhana? Bisakah kita hidup dengan pertukaran itu? Sebagai contoh, banyak programmer membuat kesalahan dengan mengoptimalkan semuanya mikro dan solusi mereka (dan kode juga) menjadi terlalu rumit.

Memeriksa kompleksitas tidak disengaja Anda:

Apakah kodenya sederhana? Jika saya kembali ke sana dalam tiga bulan, berapa lama bagi saya untuk membangun konteks di otak saya sehingga saya dapat membuat perubahan yang perlu saya buat? Apakah semua yang ada dalam kode sumber saya memiliki tujuan yang jelas dan menyampaikan tujuan tersebut secara efektif kepada saya dan pengembang lainnya ? Seberapa sulit untuk menguji kode saya? Biasanya semakin rumit kode Anda, semakin sulit untuk menguji unit, jadi saya biasanya menggunakan ini sebagai ukuran kompleksitas. Anda biasanya menginginkan kelas dan metode yang kecil, diberi nama baik dan fokus. Pola desain biasanya membantu Anda mencapai ini juga.

Jika Anda mendapati diri Anda ingin menggunakan pola desain hanya karena Anda baru saja membacanya, itu mungkin akan memperkenalkan kompleksitas yang tidak disengaja. Jika Anda menemukan diri Anda ingin memasukkan sesuatu karena Anda berpikir 'pintar' itu mungkin akan menimbulkan kompleksitas yang tidak disengaja.

Saya harap ini membantu dan jangan lupa: Sederhana bukan berarti MUDAH .

— c_maker
sumber

1

+1 untuk mendefinisikan kesederhanaan dalam hal kompleksitas esensial dan tidak disengaja.

— Zach

2

Saya selalu merasa prinsip-prinsip di balik X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) patut diperhatikan. Saya tidak selalu berhasil dalam tujuan ini.

Secara khusus, saya harus selalu mengingatkan diri sendiri ... "Jangan menambahkan fungsionalitas baru kecuali jika Anda mengetahui beberapa aplikasi nyata yang akan membutuhkannya.", Dan "Jika Anda bisa mendapatkan 90 persen efek yang diinginkan untuk 10 persen pekerjaan, gunakan solusi yang lebih sederhana. "

— nwahmaet
sumber

1

Pertanyaannya adalah: Dapatkah Anda menulis definisi SEDERHANA dari SIMPLE dalam hal prinsip KISS? -jika ada.

Tidak.

— Jeremy
sumber

3

Tidak yakin ini harus menjadi jawaban. Jika Anda tidak dapat memberikan definisi seperti itu, maka Anda seharusnya tidak menjawab IMHO. Jika menurut Anda definisi pasti tidak mungkin secara umum, Anda harus menguraikan alasannya.

— back2dos

Yang saya sukai dari jawaban ini adalah bahwa ia mengikuti prinsip KISS pada surat itu! +1

— Treb

sederhana kadang-kadang bisa sangat rumit.

— GSto

@ back2dos itu klaim yang lebih kuat; Saya tidak berkeliling memposting jawaban "Saya tidak tahu".

— Jeremy

0

Sederhana - dalam konteks khusus ini adalah kebalikan dari kompleks. Sederhana tidak perlu berarti: Setiap orang yang berpikiran bodoh harus memahaminya - tetapi Anda harus memastikan, bahwa Anda dapat memahaminya, bahkan jika Anda belum menulisnya sendiri.

Kompleksitas dapat dicapai dengan referensi yang sulit dipahami - singkirkan itu! Banyak file / kelas terhubung satu sama lain - tidak mungkin! Dan kode yang rumit (artinya: loop dirantai, beberapa lapisan ITE, dll.) - tidak ada yang mau membaca itu.

Menurut pendapat saya: Sangat mudah untuk menambahkan fungsi lain, di kelas Anda juga dapat menambahkan fungsi pribadi, sehingga Anda tidak mengacaukan antarmuka. Jadi mengapa tidak menggunakan keunggulan ini dan membatasi Anda fungsi / prosedur hingga 50 baris. Mungkin bahkan kurang. Dapatkan beberapa nama yang bermakna. Dengan cara ini, Anda membuat sebagian besar komentar usang. Dengan cara ini fungsi Anda mudah dibaca, mudah dimodifikasi / diperluas.

Tentu saja ... beberapa kalimat terakhir akan berfungsi sebagai: Di kelas ada ketersediaan untuk mendefinisikan fungsi pribadi, cukup gunakan kemungkinan ini untuk membagi fungsi menjadi 50 liner sehingga lebih mudah dibaca (jangan lupa nama baik, jadi kamu tidak perlu banyak berkomentar).

TETAPI: Jauh lebih sederhana (!) Untuk membaca semuanya jika ada fullstop yang menunjukkan: Saya selesai berpikir, mari kita lanjutkan dengan yang berikutnya.

Itulah yang akan saya definisikan sederhana.

— Philipp Wendt
sumber