Apa yang Anda anggap sebagai prinsip pertama pemrograman?

59

Saya selalu bertanya pada diri sendiri "apa prinsip pertama dari ini?" setelah saya mempelajari hal-hal dasar dari sesuatu (mis pemrograman). Ini adalah pertanyaan yang menginspirasi, IMO, yang dapat memaksa Anda untuk memikirkan prinsip paling penting di balik sesuatu, terutama keterampilan seperti pemrograman.

Jadi, apa yang Anda pikirkan adalah prinsip pertama pemrograman? Saya akan memberikan jawaban saya di bawah nanti.

programming-languages 
— Weipeng L
sumber
Kami tidak berbicara tentang klub pertarungan.
— Pekerjaan

Jawaban:

97
  1. KISS - Keep It Simple Stupid
  2. KERING - Jangan Ulangi Diri Anda Sendiri
  3. YAGNI - Anda tidak akan membutuhkannya
— Tagihan
sumber
Kiss harus Keep It Simple Smart. Pertama kali Anda harus menulis ulang sejumlah besar kode Anda karena Anda tidak merancang cerdas dan dapat diperpanjang Anda akan setuju untuk ini. :)
8
Saya pikir KISS harus "Keep It Simple, Stupid!"
— Dennis C
Saya benar-benar bekerja pada sebuah posting blog tentang bagaimana keduanya adalah yang paling dekat dan paling disukai oleh hati programmer dan bagaimana pada saat yang sama mereka sedikit oxymorons karena sering kali Anda harus memilih satu dari yang lain
10
Saya juga akan menambahkan YAGNI.
3
@Programmin Tool - Saya tidak berpikir "bodoh" itu berlebihan. Saya pikir itu menyatakan bahwa kita memiliki kecenderungan untuk ingin menjadi "pintar" dan ini bermanifestasi sebagai kompleksitas yang tidak perlu. Seperti yang saya lihat, "orang bodoh" berusaha mengingatkan kita tentang kecenderungan ini dengan membantu kita mengingat apa yang pada awalnya kita anggap "cerdas" biasanya tidak.
— codekaizen
37

Tulis kode seperti jika Anda yang harus mempertahankan kode itu.

— Patrick Desjardins
sumber
Ini adalah heuristik yang sangat praktis, 3x :)
19
Tulis kode seolah-olah psikopat yang menggunakan kapak harus memeliharanya. FTFY.
— Lupa Titik Koma
10
... dan psikopat yang menggunakan kapak tahu di mana Anda tinggal.
— CAD bersekongkol
2
..., dan dia baru saja menajamkan kapaknya ...
— Roalt
1
... dan dia bekerja di sisimu.
— Broken_Window
29

Menjadi malas mungkin.

— Preston Guillot
sumber
2
Sekali lagi, terlalu umum, IMO. Ini menimbulkan pertanyaan "Seberapa malaskah jumlah kemalasan yang tepat, sebenarnya?", Karena jelas "ceroboh" adalah sesuatu yang tidak Anda inginkan juga.
Ini adalah referensi untuk perl "Kemalasan, Ketidaksabaran, dan Keangkuhan"
Jadi kita berbicara tentang berbagai jenis kemalasan? Saya pikir dengan "malas", Bob berarti "jangan repot-repot mengatur kode Anda sebelum kusut": D
2
Terlalu umum Dengan analogi itu semua variabel dan fungsi akan menjadi 1 huruf karena saya 'terlalu malas' untuk mengetikkan sesuatu yang bermakna. Anggap saja saya harus memeliharanya juga, maka mungkin Anda benar, karena saya akan membuatnya semudah mungkin dirawat.
— Kyle Ballard
3
@Kyle: Ya, itu intinya. "Kemalasan sejati" membuat segala sesuatu termudah untuk dirimu sekarang juga di masa depan. Yang ternyata sama dengan melakukan sesuatu dengan benar. Jika Anda melakukan sedikit pekerjaan sekarang tapi lebih banyak pekerjaan kemudian, Anda tidak menjadi "malas mungkin" :)
23

Zen, bagian I: Pemrograman hanya jalan, bukan jalan.

Pemrograman hanyalah teknik untuk mengajarkan komputer apa yang harus dilakukan. Agar berhasil dalam menciptakan perangkat lunak yang cepat dan andal berarti mengetahui algoritme, praktik terbaik, dan semua hal lainnya yang belum tentu terhubung ke Pemrograman (bahasa) Anda.

Zen, bagian II: Jika Anda terburu-buru, berjalanlah perlahan-lahan. Jika Anda benar-benar terburu-buru, lakukan jalan memutar.

Kedengarannya konyol, tapi jangan biarkan diri Anda masuk ke kompromi yang (benar-benar) dapat mengganggu Anda setelahnya. Saya mendapat aturan: Jika Anda adalah inti dari suatu program, cobalah untuk setepat dan sebaik mungkin. Jika Anda menggunakan metode dari inti yang jauh di dalam perangkat lunak Anda, cobalah untuk lebih cepat dalam pengkodean. Jika Anda melakukan pengkodean di atas keduanya, Anda bahkan bisa sedikit lebih ceroboh.

Kesalahan desain adalah yang paling sulit ditemukan dan / atau diperbaiki, langkah selanjutnya adalah kesalahan pemrograman pada bagian yang diandalkan semua orang, kemudian "bagian perangkat lunak pamer yang nyata". Jika Anda perlu memperbaiki kesalahan desain di akhir proyek, ummm, itu tidak baik ... ;-)

Zen, bagian III: Ketahui jalanmu, Neo.

Ketahui lingkungan, alat, dan hal-hal yang Anda andalkan setiap hari dan lakukan penyortiran agar berfungsi untuk Anda. Terbaik jika Anda menggunakan "lingkungan" pemrograman Anda begitu alami sehingga Anda bahkan tidak perlu memikirkannya. Jika Anda harus menyelesaikan pekerjaan, jangan memperkenalkan "barang baru yang mewah" tetapi lakukan pekerjaan Anda. Barang-barang ini dapat diperkenalkan dalam proyek baru, yaitu saat Anda memiliki waktu untuk mempersiapkan dan menggunakannya.

— Georgi
sumber
Eh, dan sekali lagi: Saya mendarat di tanah Zen sambil berbicara tentang pemrograman :)
@part III - jangan tambahkan "barang baru yang mewah" kecuali Anda dibayar untuk melakukannya!
— Jason
+1 untuk referensi Matrix. Saya seorang pengisap untuk yang baik (itu dan Zen. Buat saya berpikir tentang Python)
19

Kiss (tetap simpel, bodoh).

Memang mengajukan pertanyaan "Bagaimana Anda mendefinisikan sederhana?" Dan juga "Kapan ada sesuatu yang terlalu sederhana untuk tugas yang dihadapi?" Inilah sebabnya mengapa Anda tidak bisa menjadi programmer yang baik hanya dengan mengetahui prinsip pertama pemrograman.

— Dima
sumber
Saya pikir ini adalah aturan yang terlalu umum. Ini menimbulkan pertanyaan "bagaimana Anda mendefinisikan 'sederhana', sungguh".
3
dan jika kamu bodoh, bagaimana kamu tahu kalau itu sederhana?
— Steven A. Lowe
Itu bagus, Steven :)
1
"Inilah sebabnya mengapa Anda tidak bisa menjadi programmer yang baik hanya dengan mengetahui prinsip pertama pemrograman" - menyukainya
1
@Dima: Anda benar, maksud saya kualitas dan kesederhanaan (setidaknya dalam hal ini) sama-sama tidak dapat ditentukan, namun kita tahu kapan kita melihatnya, jika mata kita terlatih.
— Adriano Varoli Piazza
18

Optimalisasi prematur adalah akar dari semua kejahatan. - Donald Knuth

— Ryszard Szopa
sumber
Baik dalam implementasi ATAU desain.
16

Jangan menemukan kembali roda.

— Patrick Desjardins
sumber
Jawaban yang tepat untuk pertanyaan, apakah seseorang harus menemukan kembali atau tidak selalu "itu tergantung". Jadi "jangan menemukan kembali roda" hanya berjalan sejauh ini. Ini mungkin berfungsi sebagai heuristik yang baik sebagian besar waktu, tetapi tidak setiap waktu.
5
Beberapa "roda" perlu diciptakan kembali.
Katakan itu pada Dunlop. Dia menemukan ban pneumatik. Jika bukan karena dia, menciptakan kembali roda, kita akan mengalami perjalanan yang cukup bergelombang.
— Kibbee
3
Bagaimana dengan: Hanya menemukan kembali roda jika manfaatnya sepadan dengan biayanya
— e.James
16

Pahami masalahnya dulu!

— OscarRyz
sumber
Ah, akhirnya seseorang dengan yang ini. Kamu cium, yagni, keringkan semua yang kamu mau. Tidak ada gunanya jika Anda memprogram sesuatu secara gratis.
@ e-satis: Yeap, itulah yang saya pikirkan ketika saya pertama kali menjawab ini. Saya gulir untuk semua jawaban dan mengejutkan tidak ada yang diposting sebelumnya.
— OscarRyz
Jawaban yang bagus. Jam dan jam menjadi sia-sia ketika programmer tidak benar memahami persyaratan penuh masalah.
— Steve Wortham
Masalahnya adalah: bagaimana Anda tahu bahwa Anda memahami masalahnya?
— CamelCamelCamel
13

YAGNI - Kamu Tidak Akan Membutuhkannya . Gagasan di balik YAGNI adalah memprogram untuk kebutuhan Anda, bukan untuk fitur potensial yang prospektif. Premisnya adalah bahwa dengan mempertahankan apa yang Anda perlu program, Anda akan (antara lain) memotong kode mengasapi, mengurangi kompleksitas, menghindari fitur creep, dan mengurangi pembatasan pada apa yang dapat dilakukan (dan bagaimana hal itu dapat dilakukan) di masa depan.

Saya kira itu bekerja bersama-sama dengan desain modular: Fitur masa depan dapat ditambah tanpa mendesain ulang kode yang ada.

— Brian M. Hunt
sumber
12

Mengetahui kapan tidak memprogram.

— ctrlShiftBryan
sumber
apa sih artinya ini?
Dan kapan itu?
Terkadang Anda perlu mengatasi masalah pengguna secara berbeda - bukan hanya kode solusi.
Penghakiman manusia dan pengambilan keputusan adalah bagian dari segalanya; terkadang tidak ada gunanya mencoba mengotomatiskan penilaian.
— S.Lott
1
Maksudnya adalah bahwa banyak masalah pemrograman dapat diselesaikan lebih murah dan lebih tepat waktu dengan membeli dari aplikasi rak, komponen, atau perpustakaan.
— Gordon Bell
11

Kopi masuk, keluar kode.

— pengguna9282
sumber
3
Teh dalam kasus saya =)
+1 hmm lebih mirip "Kopi Masuk, Kode + banyak istirahat toilet?" :) Saya suka kopi dan teh, saya mengayunkan kedua arah ...
— Darknight
10

Jika tidak diuji, itu rusak.

— Raz
sumber
Saya setuju yang satu itu
7

Ada dua cara membangun desain perangkat lunak: Salah satu caranya adalah membuatnya sangat sederhana sehingga jelas tidak ada kekurangan, dan cara lainnya adalah membuatnya sangat rumit sehingga tidak ada kekurangan yang jelas. Metode pertama jauh lebih sulit.

- Charles Antony Richard Hoare

— Chris Vest
sumber
6

  1. Bedakan antara sebab dan akibat (bekerja dengan komputer)

  2. Bedakan antara fakta dan pendapat (bekerja dengan orang)

  3. Sesederhana mungkin, tetapi tidak sederhana (desain)

— Michael Easter
sumber
5

Pemrograman adalah cara, bukan tujuan. Atau mungkin, "Bisa bukan berarti harus."

— Kode Crash
sumber
5
  1. Pahami mengapa program ini akan membuat seseorang bahagia (jika tidak, mengapa Anda tidak bermain di luar dengan semua anak lain?). (Orang ini bisa jadi kamu.)
  2. Kembangkan model konseptual dari domain bisnis yang menangkap semua kompleksitas yang dibutuhkan, dan tidak lebih.
  3. Kembangkan model konseptual arsitektur perangkat lunak yang menangkap semua kompleksitas yang dibutuhkan, dan tidak lebih.
  4. Tanpa malu -malu menyingkirkan semua kerumitan lainnya.
— Dov Wasserman
sumber
kata baik! tidak bisa setuju lebih
— Antony
5

Menurut pendapat saya, prinsip yang paling penting adalah pengurangan kompleksitas dengan menciptakan abstraksi yang baik .

Ini termasuk

  • memahami masalah yang harus dipecahkan,
  • merancang solusi yang tepat untuk itu dan
  • mengimplementasikannya,
  • lebih disukai dengan cara yang membuat kode dimengerti dan dipelihara,

tetapi juga penentuan titik di mana berhenti membuat abstraksi dan turun ke sifat dasar dari teknologi implementasi (misalnya sistem database, bahasa pemrograman) untuk mencegah penciptaan kompleksitas tambahan yang dapat dihindari.

— mh
sumber
4

Program dengan audiens dalam pikiran. Dengan itu, jangan berasumsi bahwa apa pun yang Anda tulis tidak akan dibaca dan dikelola oleh Anda atau orang lain.

Sebagai akibatnya: Buktikan bahwa Anda memahami masalah yang Anda coba selesaikan dengan memberi nama variabel dan fungsi dan kelas Anda dengan baik!

— torial
sumber
4

itu tidak bekerja sampai Anda menunjukkannya dalam ujian

— Audun
sumber
6
Itu tidak benar, saya telah menulis banyak kode yang berfungsi dan tidak diuji! : D
1
"Saya belum mengujinya, saya hanya membuktikan bahwa itu benar" :)
— Daniel Daranas
4

Pikirkan dulu, kode nanti.

Anda sama sekali tidak sepintar yang Anda kira. Mengajukan pertanyaan. Belajarlah untuk menghargai rekan-rekan Anda.

Saat debugging, jawaban pertama hampir selalu salah.

Kode yang Anda tulis dengan tujuan membuang cenderung menjadi landasan proses yang jauh lebih besar. Jangan pernah meninggalkan apapun yang ditulis sembarangan.

— Mike Hofer
sumber
3

Setiap masalah dapat diselesaikan dengan lapisan tipuan lainnya.

— Joshua
sumber
Sebenarnya, memiliki terlalu banyak tipuan itu sendiri merupakan masalah yang menunggu untuk diidentifikasi dan diselesaikan. Jadi ..
diselesaikan ... dengan lapisan tipuan lainnya! =)
— Erik Forbes
Cukup aneh, itu benar. Lihatlah Musim Semi ...
3

Prinsip: Perangkat Lunak adalah Pengambilan Pengetahuan .

Konsekuensi: Banyak teknik untuk representasi pengetahuan, semua didasarkan pada Abstraksi . Memberi kami lapisan, tingkatan, enkapsulasi, pemisahan masalah.

Banyak teknik untuk representasi prosedur, semua didasarkan pada Sequence , Choice , Repetition .

— S.Lott
sumber
3

Selalu tulis kode seolah-olah orang yang akan mempertahankannya adalah pembunuh berantai psikotik yang tahu di mana Anda tinggal

Juga, jangan pernah berpikir Anda tahu segalanya tentang pemrograman, teruslah belajar

— Amy
sumber
2

Saya masuk ke pemrograman dengan cara belajar elektronik digital, jadi saya kira bagi saya gerbang logika dasar (bukan, dan, atau, menyiratkan, menyiratkan) adalah prinsip-prinsip pertama pemrograman.

— Bill the Lizard
sumber
2

Garbage in - Garbage Out Tidak peduli seberapa bagus antarmuka pengguna Anda jika datanya buruk.

— HLGEM
sumber
2

KERING, hampir semuanya memunculkan darinya. KISS adalah ujung lain dari tindakan penyeimbangan untuk memastikan Anda tidak mengejar keanggunan perangkat lunak ke tingkat kegilaan.

— Berdalih
sumber
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.