Bagaimana Anda tahu jika Anda telah menulis kode yang mudah dibaca dan mudah dirawat?


336

Bagaimana orang tahu jika kode yang telah dibuat mudah dibaca, dimengerti, dan dipelihara? Tentu saja dari sudut pandang penulis, kode dapat dibaca dan dipelihara, karena penulis menulis dan mengeditnya, untuk memulai. Namun, harus ada standar objektif dan terukur yang digunakan oleh profesi kita untuk mengukur kode.

Tujuan-tujuan ini terpenuhi ketika seseorang dapat melakukan hal berikut dengan kode tanpa saran ahli dari penulis asli:

  • Dimungkinkan untuk membaca kode dan memahami pada tingkat dasar aliran logika.

  • Dimungkinkan untuk memahami pada level yang lebih dalam apa yang dilakukan kode untuk memasukkan input, output, dan algoritma.

  • Pengembang lain dapat membuat perubahan yang berarti pada kode asli seperti perbaikan bug atau refactoring.

  • Seseorang dapat menulis kode baru seperti kelas atau modul yang memanfaatkan kode asli.

Bagaimana kita mengukur atau mengukur kualitas kode sehingga kita tahu itu dapat dibaca, dimengerti, dan dipelihara?


154
Tautan wajib (untuk sekali tidak ke xkcd): osnews.com/images/comics/wtfm.jpg
Jerry Coffin

3
Saya hanya dengan ceroboh mengatakan bahwa Anda tahu ketika Anda melihatnya tetapi argumen ini pada dasarnya cacat dan memalukan bahkan dalam bentuk aslinya, apalagi diterapkan ke kode sumber.
Konrad Rudolph

6
"Tentu saja menurut Anda, kode Anda dapat dibaca" - tidak terlalu jelas!
UncleZeiv

24
Saya akan mengatakan Anda tahu ketika Anda melihatnya beberapa bulan setelah Anda menulisnya.
JeffO

2
@ asfallows: Saya menunjukkan beberapa kode kepada istri saya, dan dia pikir itu kode yang sangat buruk, karena dia bisa membacanya! (Terlalu banyak kata dalam bahasa Inggris yang terlihat di dalamnya, dan tidak cukup karakter @ [! ^ $ & *) ...)
gnasher729

Jawaban:


370

Rekan Anda memberi tahu Anda setelah meninjau kode.

Anda tidak dapat menentukannya sendiri karena sebagai penulis, Anda tahu lebih banyak dari yang dikatakan oleh kode itu sendiri. Komputer tidak dapat memberi tahu Anda, karena alasan yang sama dengan itu tidak dapat memberi tahu apakah sebuah lukisan itu seni atau bukan. Oleh karena itu, Anda memerlukan manusia lain - yang mampu memelihara perangkat lunak - untuk melihat apa yang telah Anda tulis dan memberikan pendapatnya. Nama formal dari proses tersebut adalah peer review .


6
Tidak ada yang mengalahkan pengujian empiris.
Insinyur Dunia

25
+1 Audiens Anda yang paling penting adalah rekan-rekan Anda yang tenggelam, bersama Anda, dalam mengetahui mengapa dan bagaimana masalah yang sedang Anda kerjakan dan solusinya. Kode yang baik mencerminkan pemahaman rekan Anda saat ini tentang hal ini. Dengan asumsi tim itu mampu, bijaksana, dan terbuka untuk ide-ide baru, "rekan Anda mengatakan yang baik / dapat dipertahankan" adalah, dalam pengalaman saya, definisi yang lebih baik sejauh itu.
Doug T.

69
Dalam pengalaman saya, ini hanya bekerja ketika rekan Anda tahu apa yang baik dan apa yang buruk. Kalau tidak, akan terdengar seperti ini: "Anda harus menulis kode itu dengan metode yang sama, itu lebih mudah untuk menemukan kode"
Rangi Lin

12
@RangiLin, well, kolega Anda mungkin benar.

11
@Rangi Anda harus bekerja dengan kolega yang Anda miliki. jika mereka menemukan kode Anda sulit itu adalah masalah dengan kode Anda. Dalam jangka panjang, Anda dapat mendidik mereka, atau mencoba untuk mendapatkan rekan-rekan yang lebih baik (Anda dapat memindahkan atau Anda dapat mempengaruhi proses perekrutan) ... Oh ya, dan melakukan selalu ingat bahwa mereka mungkin benar.
MarkJ

220

Terkadang, cara terbaik untuk mengetahui, adalah kembali ke kode yang Anda tulis enam bulan lalu dan mencoba dan memahami apa yang harus dilakukan.

Jika Anda memahaminya dengan cepat - itu bisa dibaca.


28
Ya, itu kedengarannya bagus (dan itu benar), tetapi itu bukan pendekatan yang sangat baik untuk memutuskan apa / bagaimana yang harus dilakukan hari ini ...
Michael Durrant

10
Pembedahan menyarankan perlu beberapa saat dan Anda harus melakukannya dengan hati-hati ...
deworde

3
Saya mungkin membatalkan jangka waktu untuk meninjau kembali ke satu bulan, atau bahkan kurang, untuk kunjungan ulang pertama. Saya pikir itu tergantung pada kompleksitas proyek dan domain, serta pendekatan mental Anda. Saya menemukan bahwa dalam enam bulan, saya terganggu dengan melihat peluang refactoring atau optimisasi menggunakan alat atau teknik yang saya pelajari sejak saya pertama kali menulis kode, bukan keterbacaan nyata.
Chris Bye

1
@MichaelDurrant Setiap kali Anda meninjau kode lama Anda akan menemukan bagian-bagian yang seharusnya ditulis berbeda dan kemudian Anda akan memperhitungkannya untuk kode yang Anda tulis "hari ini". Ya, perlu waktu untuk mempelajari cara menulis kode yang baik.
dj18

1
@MichaelDurrant masih seperti ini, karena Anda dapat mempelajari hal-hal tidak jelas yang Anda lakukan enam bulan lalu, dan tidak melakukan hal-hal itu hari ini.
djechlin

94

Ini:

  1. dapat dipertahankan jika Anda dapat mempertahankannya .
  2. mudah dipelihara jika orang lain dapat memeliharanya tanpa meminta bantuan Anda
  3. dibaca jika orang lain , membaca itu, benar mengerti desain, tata letak dan niat

Tes sesungguhnya untuk 1. adalah (seperti yang dikatakan Alex di Paris dan quant_dev ) bahwa Anda dapat mengambilnya kembali setelah beberapa bulan melakukan sesuatu yang lain.

Tes untuk 2. dan 3. adalah orang lain dapat mengambilnya, dan mencari tahu cara memperluas atau memperbaiki kode Anda sambil mengikuti alur desain Anda. Jika mereka tidak dapat memahami desain, bagaimana hubungannya dengan ruang masalah, atau bagaimana kode Anda dimaksudkan untuk digunakan, mereka akan meretas solusi di seluruh gabah.

Ada aturan praktis, prinsip (yaitu, aturan praktis seseorang menulis dengan baik dan memberi nama) dan segala macam saran yang dapat menuntun Anda ke arah yang benar, atau jauh dari perangkap umum. Tak satu pun dari mereka akan menjamin kualitas yang Anda minta.


2
Bagaimana dengan mempertimbangkan jumlah waktu yang dihabiskan untuk memperbaiki bug atau memodifikasi perilaku yang ada sebagai faktor rawatan? Sepotong kode yang membutuhkan lebih sedikit waktu untuk melakukan perubahan yang sama seharusnya lebih mudah dikelola bukan?
VCD

1
Tergantung; kadang-kadang membuat modifikasi dengan baik akan memerlukan refactoring (yang dapat Anda katakan diperlukan karena kode yang dapat dibaca membuatnya jelas itu tidak dimaksudkan untuk digunakan seperti itu), yang membutuhkan waktu lebih lama daripada meretas dalam kasus khusus (yang didorong oleh kode yang tidak terbaca karena tujuannya tidak jelas. ).
berguna

30

Jika kode Anda mengikuti prinsip-prinsip SOLID dan KERING dan memiliki serangkaian unit test yang baik di sekitarnya, kode itu mungkin dapat dipertahankan.

Apakah bisa dibaca? Membacanya. Apakah nama metode dan variabel masuk akal? Bisakah Anda mengikuti logika program tanpa masalah? Jika jawabannya ya, maka kodenya dapat dibaca.


8
... dan setelah Anda membacanya, berikan kepada orang lain untuk mencoba membaca.
jcmeloni

19
Ini bukan tes yang sangat bagus. Banyak aplikasi dari aturan-aturan itu bersifat subyektif, dan Anda hampir selalu dapat membaca kode Anda sendiri setelah itu ditulis.
DeadMG

1
"Jika jawabannya adalah ya, maka kodenya dapat dibaca" ... oleh Anda . Untuk melihat apakah itu dapat dibaca oleh orang lain, orang lain harus mencoba membacanya.

2
IMO, SOLID berlebihan. Terutama 'S.' Itu atau semua orang salah baca.
Erik Reppen

Saya telah menjalankan berkali-kali ke dalam kode yang KERING dan SOLID namun mengerikan. Prinsip-prinsip berikut dapat memberikan kesan yang salah bahwa apa yang Anda tulis bukan omong kosong.
Jakub Arnold

24

Membaca Cara Menulis Kode yang Tidak Dapat Dipertahankan - Pastikan pekerjaan seumur hidup oleh Roedy Green, tertawa, dan belajar.

... cara menulis kode yang sangat sulit dipertahankan, sehingga orang-orang yang datang setelah Anda akan membutuhkan waktu bertahun-tahun untuk membuat perubahan yang paling sederhana sekalipun. Lebih lanjut, jika Anda mengikuti semua aturan ini secara religius, Anda bahkan akan menjamin diri Anda untuk pekerjaan seumur hidup, karena tidak seorang pun kecuali Anda memiliki harapan di neraka untuk mempertahankan kode ...

Esai memberi Anda banyak contoh cara menulis kode yang buruk, menggunakan banyak contoh lucu. Itu terus menjelaskan bagaimana memanfaatkan ejaan Miss Kreatif , Reuse of Names , teknik Reuse of Global Names yang sangat dihargai sebagai Pribadi .

Dengan cara yang lucu, esai ini mengajarkan Anda cara menghindari semua contoh kode yang tidak dapat dibaca dan tidak dapat dipelihara.

Sebenarnya, saya merasa sulit untuk percaya bahwa ada orang yang akan menulis kode dengan kesamaan dengan contoh dalam teks. Saat itulah saya masih baru sekolah. Tapi, setelah bekerja selama beberapa tahun saya melihat kode dari teks setiap hari ...


Lihat juga waterfall2006.com/gorman.html Refuctoring adalah proses mengambil sepotong kode yang dirancang dengan baik dan, melalui serangkaian perubahan kecil yang dapat dibalik, membuatnya sepenuhnya tidak dapat dipelihara oleh siapa pun kecuali Anda sendiri.
Sjoerd

22

Terlepas dari bagaimana kelihatannya, ada beberapa langkah yang cukup objektif yang dapat Anda pertimbangkan. Buku-buku seperti C ++ Standar Pengkodean , Refactoring , dan Clean Code memiliki daftar panjang kriteria untuk menilai kode Anda dengan, melihat hal-hal seperti nama yang bermakna, ukuran fungsi, prinsip-prinsip seperti kopling dan kohesi, desain objek, pengujian unit, penyempurnaan berurutan, dll.

Daftar ini terlalu besar untuk dapat diterima dalam daftar periksa, tetapi Anda membaca buku dan memilih beberapa hal penting untuk dikerjakan, kemudian setelah beberapa bulan membacanya lagi untuk meningkatkan lebih lanjut.


4
+1 untuk pembelajaran tambahan dan tidak berusaha menjadi sempurna dalam semalam
dj18

19

Buktinya ada di puding. Perhatikan apa yang terjadi setelah menyerahkannya kepada orang yang cukup kompeten. Jika mereka tidak perlu mengajukan banyak pertanyaan terkait dengan kesulitan kode, Anda telah melakukan pekerjaan dengan baik.

Ini adalah pelajaran awal dalam karier saya. Seorang mentor berkata, "Dokumentasikan semuanya, sehingga Anda dapat melarikan diri dari program nanti. Jika Anda tidak mengantisipasi pertanyaan ketika jawabannya masih segar di benak Anda, Anda harus mencari jawabannya ketika tidak."


10
Berhati-hatilah bahwa orang mungkin menahan diri untuk tidak mengajukan pertanyaan karena takut mengungkapkan ketidaktahuan mereka. Anda bahkan mungkin menganggap orang-orang itu sebagai 'cukup kompeten' di tempat pertama karena kecenderungan mereka untuk menahan diri dari mengeksposnya. Jadi kekurangan pertanyaan mungkin bukan hal yang baik kecuali Anda tahu Anda berdua tulus.
Hermann Ingjaldsson

1
@HermannIngjaldsson - Cukup adil. Tentu saja jika mereka tidak kompeten dan sesuatu rusak, Anda akan segera mendengarnya. "Tolong!!!!"
MathAttack

ini tampaknya hanya mengulangi apa yang dinyatakan dalam jawaban teratas
nyamuk

17

Saya membaca semua jawaban, dan saya perhatikan tidak ada yang menyebutkan kompleksitas kode.

Ada korelasi yang erat antara kompleksitas kode dan keterbacaan / pemeliharaan. Ada banyak algoritma penghitungan kompleksitas kode, tetapi saya hanya akan berbicara tentang cara kerja penghitungan kompleksitas McCabe.

Pada dasarnya, penilaian McCabe membaca kode Anda dan menghitung jumlah "jalur" unik yang ada di dalamnya. Jika Anda menggunakan McCabe sebagai pembilang dan baris kode sebagai penyebut, Anda juga mendapatkan perkiraan "keterbacaan" yang cukup baik.

Jika Anda memiliki 10 baris kode, dan ada 300 jalur melalui kode itu, itu adalah beberapa kode yang tidak dapat dipertahankan (sulit untuk diubah dengan aman dan mudah), dan itu mungkin tidak terlalu mudah dibaca. Sebaliknya, jika Anda memiliki 300 baris kode, tetapi hanya ada 1 jalur yang melewatinya (tidak memiliki kondisi), keduanya dapat dibaca dan mudah dikelola.

Namun di mana McCabe jatuh dalam contoh terakhir itu. Jika saya punya 300 baris kode tanpa syarat, ada peluang bagus saya melakukan "copy / paste reuse", dan jelas itu juga bukan hal yang baik. Jadi ada metrik seluruh sistem yang Anda terapkan selain McCabe - seperti deteksi kode duplikat atau hampir duplikat.


2
Ini seharusnya jawabannya. Mengukur. Jawaban lain lebih banyak pendapat daripada fakta, jika saya bisa memahaminya, pasti bagus? Pengukuran pertama menggunakan analisis kompleksitas, kemudian refactor manusia untuk mencari duplikasi, dll.
Jon Raynor

1
Paragraf terakhir Anda yang menyebutkan kelemahan skor McCabe dibagi dengan LOC dan cenderung membatalkan seluruh gagasan. Jika Anda membutuhkan 300 jalur melalui kode Anda, mengapa Anda pikir itu akan membuat kode lebih mudah dikelola untuk menggunakan lebih banyak baris? Itu seperti mengatakan bahwa jika sebuah buku menyajikan ide-ide rumit, itu harus menjadi buku yang sangat besar daripada mencoba berkomunikasi secara ringkas. -1.
Wildcard

8

Satu hal yang akan saya bagikan adalah jika kode tersebut dibangun dalam "modul," dan ketika saya mengatakan bahwa saya maksudkan bahwa Anda dapat mengubah satu hal dalam sebuah modul dan membuatnya mudah bekerja dengan keseluruhannya. Ini menghilangkan efek antara hal-hal yang tidak terkait. Juga:

  • Kode mudah digunakan kembali
  • Kode Anda fleksibel (ini terkait dengan modul bangunan)
  • KERING - Jangan Ulangi Diri Anda Sendiri

Saya sangat merekomendasikan membaca, The Pragmatic Programmer.


8

Beberapa Tes / Indikator:

  • Matikan IDE. Masih bisakah Anda membaca kode Anda sendiri? Ketika ada bug, apakah cukup mudah untuk melacaknya dengan tangan dan mencari tahu kelas apa yang Anda perlukan breakpoint untuk mencari tahu di situlah masalahnya? Atau ketika Anda menggunakan IDE apakah Anda hanya tidak repot dan hanya melangkah dari awal?

  • Apakah debug sering menjadi permainan wack-a-mole di mana memperbaiki satu bug menciptakan 2+ lebih.

  • Dari tarikan pelatuk hingga sesuatu yang bermanfaat benar-benar terjadi, berapa banyak pemanggilan metode yang dibutuhkan? Berapa banyak metode yang melewati parameter yang persis sama atau sebagian besar persis sama ke pemanggilan metode lain?

  • Berapa banyak file yang harus Anda buka untuk hanya menambahkan metode baru yang sederhana ke kelas?

  • Pikirkan pola dan praktik yang telah Anda adopsi. Apakah Anda melakukannya karena mereka masuk akal atau karena seseorang meyakinkan Anda bahwa "itu satu-satunya cara untuk melakukannya?" atau karena Anda menginginkannya di resume Anda atau karena beberapa rockstar dev mengatakannya.


3
Membaca kode tanpa IDE tampaknya bodoh, terutama sebagai ukuran keterbacaan. Jenis metrik ini menghasilkan "solusi" gaya notasi Hongaria yang benar-benar merusak keterbacaan pada akhirnya.
rubenvb

8

Bagaimana orang tahu kalau kode yang dibuatnya mudah dipelihara dan dibaca?

Anda dapat menemukan kode yang mudah dikelola dan dibaca dengan mencari properti ini:

  1. Objek, metode, dan / atau fungsi selalu melakukan satu hal.
  2. Metode dan / atau fungsi ringkas (seperti dalam "singkat tapi komprehensif").
  3. Objek, metode, dan / atau fungsi pada dasarnya melakukan apa yang menurut Anda seharusnya dilakukan berdasarkan nama mereka.
  4. Kode yang diperuntukkan untuk digunakan kembali sebenarnya dapat digunakan kembali.
  5. Last but not least, jika Anda dapat segera menguji unit kode, Anda kemungkinan telah menulis kode modular tanggung jawab tunggal.

Bagaimana kita tahu jika kita telah menulis kode yang cukup berantakan dan tidak dapat dipelihara? Adakah konstruk atau pedoman untuk mengetahui apakah kami mengembangkan perangkat lunak yang berantakan?

  1. Jika Anda membaca metode dan tidak jelas apa tujuannya, ini tidak bagus dan mungkin tidak dapat dipelihara pada kondisi terburuk.
  2. Jika tampaknya tidak sederhana, mungkin itu tidak sederhana dan itu adalah tanda kode yang tidak dapat dipelihara atau kode yang akan segera menjadi tidak dapat dipelihara.
  3. Jika ada kurangnya simetri (konsistensi) di seluruh basis kode, Anda mungkin melihat kode yang tidak dapat dipertahankan.

Saya tidak setuju bahwa contoh refactoring Anda lebih jelas. Saya setuju kode asli perlu bekerja, tetapi murni dalam hal kejelasan dan maksud komunikasi saya pikir yang asli jauh lebih baik. Saya sangat curiga terhadap setiap refactoring yang mengklaim itu meningkatkan kejelasan saat memperkenalkan regex.
Roy

1
@ Roy, ya, cukup adil. Saya mungkin seharusnya tidak pernah menambahkan sampel kode itu. Memang, hampir 3 tahun yang lalu, tetapi bahkan kemudian, saya mungkin seharusnya tidak menggunakan PHP (saya merasa ngeri hanya melihatnya sekarang), dan saya seharusnya tidak menggunakan regex karena itu adalah salah satu hal yang beberapa orang dapat melihat dan langsung mendapatkannya tetapi untuk orang lain, tidak peduli seberapa ringkas, regex segera dimatikan. Saya akan mengedit jawaban dan menjatuhkan contoh kode. Terima kasih atas komentarnya.
Wil Moore III

Bagaimana suatu benda dapat melakukan satu hal?
Koray Tugay

@ KorayTugay Pikirkan seperti ini. Jika suatu objek mendeskripsikan lebih dari satu konsep kohesif tunggal, Anda akan tercium.
Wil Moore III

6

Dalam satu kata, Pengalaman .

Untuk memulai, Anda perlu melakukan pekerjaan dasar, jadi saya tidak bisa merekomendasikan lebih tinggi bahwa programmer harus meluangkan waktu untuk membaca buku-buku seperti Refactoring , yang akan menyediakan beberapa alat yang lebih penting dalam gudang programer yang akan meningkatkan kemampuan Anda untuk mempertahankan kode, dan Kode Bersih yang telah ditulis oleh beberapa talenta paling dikenal di bidang kami, dan yang menggambarkan hampir semua yang perlu Anda pahami untuk memastikan kode Anda bersih dan dapat dibaca.

Namun tidak ada jumlah bacaan yang merupakan pengganti pengalaman susah payah. Anda benar-benar harus bekerja dengan kode untuk sementara waktu agar dapat sepenuhnya menghargai perbedaan yang dapat diberikan oleh perhatian pada kualitas kode. Dengan mengalami kesenangan bekerja dengan kode yang bersih dan diperhitungkan dengan baik, serta rasa sakit bekerja dengan kode spaghetti, Anda belajar untuk lebih memahami apa yang sebenarnya ingin diajarkan oleh para penulis buku-buku ini kepada Anda, tetapi Anda melakukannya dalam konteks yang lebih luas kode produksi langsung nyata, di mana kualitas dari apa yang Anda lakukan benar-benar penting, dan memengaruhi kemampuan Anda untuk bekerja dengan mudah dengan kode Anda setiap hari.

Ini juga membantu untuk memiliki seorang mentor yang baik, atau rekan dengan pengalaman untuk mengkonfirmasi bahwa Anda menempatkan upaya dalam menulis kode ke standar yang tinggi. Ini hanya salah satu alasan mengapa ulasan kode bisa sangat berguna. Menggunakan alat pengecekan kode dan format juga bisa menjadi bantuan yang sangat berguna untuk memastikan bahwa Anda menjaga semuanya tetap bersih. Namun tidak ada yang sebanding dengan pengalaman yang diperoleh selama bertahun-tahun menulis perangkat lunak, sehingga Anda secara otomatis menemukan diri Anda menulis kode yang bersih, mudah dibaca, dan terstruktur hanya untuk kemudahan pemeliharaan, dan semua karena Anda sudah terbiasa menerapkan praktik terbaik untuk itu. panjang.


3

Tanpa puritan: lebih suka gaya fungsional. Sebagian besar bahasa hari ini (.NET, Ruby, Python, Javascript, dll.) Mendukung dan mempromosikannya (mis. LINQ, underscorejs).

Sangat mudah dibaca.

var recentTopCustomers = OrderList
    .Where(o => o.Date >= DateTime.Now.AddDays(-5))
    .Where(o => o.Amount > 1000)
    .OrderBy(o => -o.Amount)
    .Take(10)
    .Select(o => o.Customer);

Ini memaksa setiap node untuk memiliki satu, fokus niat meminjamkan untuk kejelasan tujuan. Dan karena setiap tugas yang terpisah terisolasi muncul, menghubungkan, dan menata ulang node (operasi) untuk tujuan yang berbeda adalah sepele. Ini memudahkan perawatan.


2

Kode yang dapat dibaca dan dipelihara: Kode yang, pada pandangan pertama, seorang programmer dapat memahami dengan baik untuk dapat dengan mudah:

  • gunakan kembali melalui antarmuka, atau
  • debug itu, atau
  • ubah perilakunya. (tambah / hapus fitur), atau
  • mengoptimalkannya
  • menguji

Ini bermuara pada 'kejelasan'. yaitu Berapa banyak pertanyaan yang harus ditanyakan programmer dari segmen kode tertentu sebelum mereka yakin bahwa mereka 'memahami apa yang dilakukannya dengan cukup baik' untuk mencapai tugas saat ini di tangan tanpa menimbulkan efek samping yang tidak diharapkan.

Buku 'Code Complete, by Steve McConnell' membahas hal ini dengan sangat rinci.

Dia melewati berbagai metrik yang dapat Anda gunakan untuk menentukan apakah kode berkualitas baik.

Lihat contoh di sini: http://books.google.co.id/books?id=3JfE7TGUwvgC&lpg=PT376&pg=PT389#v=onepage&q&f=false


ini tampaknya tidak menambahkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam jawaban sebelumnya
nyamuk

Saya pikir salah satu hal paling penting yang ditambahkan adalah referensi ke Kode Lengkap, yang tidak ada jawaban sebelumnya menyebutkan. Buku itu adalah salah satu buku paling signifikan dan berpengaruh yang berfokus pada penulisan kode yang dapat dibaca dan dipelihara. Siapa pun yang telah membaca buku itu tidak perlu bertanya 'Bagaimana Anda tahu jika Anda telah menulis kode yang mudah dibaca dan mudah dirawat?'.
JW01

... maka, menurut pendapat saya, saya percaya hal terbaik yang dapat diperoleh siapa pun jika mereka benar-benar tertarik menulis kode yang dapat dikelola adalah membaca buku itu. Oleh karena itu, dengan banyak menit pemikiran yang cermat, (yang seringkali jauh lebih banyak pemikiran daripada SO moderator), saya pikir ini bukan hanya jawaban yang memadai untuk pertanyaan OP, tetapi juga yang terbaik .
JW01

2

Minimalkan efek samping (idealnya tidak ada)

Fungsi yang menyebabkan 3 perubahan pada status di luar ruang lingkupnya sendiri jauh lebih sulit untuk dipikirkan dan dipelihara daripada yang hanya memasukkan sesuatu dan mengeluarkan sesuatu yang lain. Anda tidak bisa hanya tahu apa fungsinya, Anda harus mengingat apa yang dilakukannya dan bagaimana itu memengaruhi semua fungsi relevan lainnya.

Untuk OOP meminimalkan efek samping juga berarti kelas dengan anggota lebih sedikit, dan lebih sedikit anggota yang dapat memodifikasi status kelas, karena fungsi anggota dapat memodifikasi keadaan di luar milik mereka dan memiliki efek samping (mereka dapat memanipulasi internal kelas, misalnya). Ini juga berarti kelas dengan anggota data yang lebih sedikit sehingga tidak ada banyak metode untuk merusak dan lebih sedikit efek samping yang dapat ditimbulkannya.

Sebagai contoh sederhana, bayangkan mencoba merancang struktur data mewah yang dapat mempertahankan sortedstatus yang digunakannya untuk menentukan apakah akan melakukan pencarian biner atau linear. Dalam kasus seperti itu, mungkin berguna untuk memisahkan desain menjadi dua kelas. Memanggil sortedkelas yang tidak disortir mungkin akan mengembalikan struktur data kelas lain yang selalu menjaga isinya diurutkan. Sekarang Anda memiliki lebih sedikit efek samping (karena itu lebih sedikit rawan kesalahan dan lebih mudah untuk memahami kode) serta kode yang lebih luas berlaku (desain sebelumnya akan boros baik dalam pemrosesan dan efisiensi intelektual manusia untuk array kecil yang tidak perlu disortir).

Hindari Ketergantungan Eksternal yang Berlebihan

Anda mungkin dapat mengimplementasikan kode yang paling singkat yang bisa dibayangkan dengan penggunaan kembali kode maksimum dengan menggunakan 13 pustaka yang berbeda untuk menyelesaikan tugas yang relatif sederhana. Namun, itu mentransfer overhead intelektual ke pembaca Anda dengan harus membuat mereka mengerti setidaknya bagian dari 13 perpustakaan yang berbeda. Kompleksitas yang melekat ini harus segera dihargai oleh siapa saja yang mencoba membangun dan memahami perpustakaan pihak ketiga yang mengharuskan menarik dan membangun selusin perpustakaan lain agar berfungsi.

Ini mungkin pandangan yang sangat kontroversial tetapi saya lebih suka beberapa duplikasi kode sederhana untuk ekstrem yang berlawanan asalkan hasil akhirnya diuji dengan baik (tidak ada yang lebih buruk daripada kode kesalahan yang tidak terulang yang digandakan berkali-kali lipat). Jika pilihannya adalah antara 3-baris kode duplikat untuk menghitung produk vektor silang atau menarik perpustakaan matematika epik hanya untuk mengurangi 3 baris kode, saya sarankan yang pertama kecuali seluruh tim Anda bergabung dengan perpustakaan matematika ini , pada titik mana Anda mungkin masih mempertimbangkan untuk hanya menulis 3 baris kode daripada 1 jika itu cukup sepele dengan imbalan manfaat decoupling.

Penggunaan kembali kode adalah tindakan penyeimbangan. Menggunakan kembali terlalu banyak dan Anda mentransfer kompleksitas intelektual dengan cara satu-ke-banyak, karena dalam 3 baris kode sederhana yang Anda simpan di atas ada biaya yang mengharuskan pembaca dan pengelola memahami lebih banyak informasi daripada 3 baris kode . Ini juga membuat kode Anda kurang stabil, karena jika perpustakaan matematika berubah, mungkin juga kode Anda. Gunakan kembali terlalu sedikit dan Anda juga melipatgandakan overhead intelektual dan kode Anda berhenti mengambil manfaat dari perbaikan pusat, jadi ini adalah tindakan penyeimbang, tetapi gagasan bahwa itu adalah tindakan penyeimbangan patut disebutkan karena mencoba untuk menghapus setiap bentuk kecil dari duplikasi sederhana dapat menyebabkan untuk hasil yang sama sulitnya untuk dipertahankan, jika tidak lebih, dari ekstrem yang berlawanan.

Tes omong kosong itu

Ini diberikan tetapi jika kode Anda tidak menangani semua kasus masukan dan melewatkan beberapa kasus tepi, lalu bagaimana Anda dapat mengharapkan orang lain untuk mempertahankan kode yang Anda tulis yang bahkan tidak Anda dapatkan sebelum ditransfer ke mata dan tangan mereka? Cukup sulit untuk membuat perubahan pada kode yang berfungsi sempurna, apalagi kode yang tidak pernah benar di tempat pertama.

Selain itu, kode yang lulus tes menyeluruh umumnya akan menemukan lebih sedikit alasan untuk berubah. Itu berkaitan dengan stabilitas yang bahkan lebih dari suci untuk dicapai daripada pemeliharaan, karena kode stabil yang tidak perlu diubah tanpa dikenakan biaya pemeliharaan.

Dokumentasi Antarmuka

Prioritaskan "hal-hal apa yang dilakukan" daripada "bagaimana hal-hal itu lakukan" jika Anda tidak dapat mencurahkan waktu yang sama untuk mendokumentasikan keduanya. Antarmuka yang jelas yang jelas dalam niatnya tentang apa yang akan dilakukan (atau setidaknya, apa yang seharusnya dilakukan) dalam semua kasus input yang mungkin akan menghasilkan kejelasan konteks untuk implementasinya sendiri yang akan memandu dalam memahami tidak hanya bagaimana untuk menggunakan kode, tetapi juga cara kerjanya.

Sementara itu kode yang tidak memiliki kualitas ini di mana orang bahkan tidak tahu apa yang seharusnya dilakukan adalah SOL, tidak peduli seberapa baik didokumentasikan rincian pelaksanaannya. Manual 20 halaman tentang bagaimana kode sumber diimplementasikan tidak berharga bagi orang-orang yang bahkan tidak tahu persis bagaimana seharusnya digunakan dan apa yang seharusnya dilakukan dalam semua skenario yang mungkin.

Untuk sisi implementasi, prioritaskan mendokumentasikan apa yang Anda lakukan secara berbeda dari orang lain. Sebagai contoh, Intel memiliki hierarki volume terbatas untuk kernel raytracing mereka. Karena saya bekerja di bidang ini, saya dapat mengenali sebagian besar dari apa yang dilakukan kode mereka sekilas tanpa menyaring dokumentasi. Namun, mereka melakukan sesuatu yang unik yaitu gagasan melintasi BVH dan melakukan persimpangan secara paralel menggunakan paket ray . Di situlah saya ingin mereka memprioritaskan dokumentasi mereka karena bagian-bagian kode itu eksotis dan tidak biasa dari sebagian besar implementasi BVH historis.

Keterbacaan

Bagian ini sangat subyektif. Saya tidak terlalu peduli tentang keterbacaan dari jenis yang dekat dengan proses pemikiran manusia. Kode yang paling terdokumentasi dengan baik menggambarkan hal-hal di tingkat tertinggi masih sulit bagi saya untuk mengikuti jika penulis menggunakan proses pemikiran aneh dan berbelit-belit untuk memecahkan masalah. Sementara itu kode singkat menggunakan 2 atau 3 nama karakter sering kali lebih mudah bagi saya untuk memahami jika logikanya sangat mudah. Saya kira Anda bisa mengintip ulasan dan melihat apa yang disukai orang lain.

Saya lebih tertarik pada pemeliharaan dan, yang lebih penting, stabilitas. Kode yang tidak menemukan alasan untuk berubah adalah kode yang tidak memiliki biaya perawatan.


1

Saya akan mengatakan satu cara untuk mengetahui apakah anggota tim baru dapat mengambil kode, memahaminya, dan memodifikasinya untuk memperbaiki cacat / memenuhi persyaratan baru dengan relatif mudah.


1

Berikut adalah teknik yang saya suka gunakan:

Perlihatkan kode ke salah satu programmer rekan Anda dan minta mereka menjelaskan kepada Anda apa yang dilakukannya. Perhatikan hal-hal ini.

1) Jika mereka tidak dapat dengan mudah menjelaskan tujuan dari blok refactor kode itu.
2) Jika mereka harus melompat ke bagian kode lain untuk memahami bagian saat ini, refactor.
4) Setiap kali Anda merasakan keinginan untuk berbicara selama proses, bagian kode itu perlu refactoring. (Kode tidak berbicara sendiri).


Dengan asumsi programmer sebaya paling tidak sama berpengalaman dan membaca ke dalam bahasa pemrograman dan idiom-idiomnya. Semua teknik seperti ini dapat menyebabkan orang menulis kode dalam subset dari ekspresi bahasa dalam upaya yang salah untuk membuat int dapat dimengerti oleh anggota tim yang paling junior sekalipun. Hasilnya adalah kumpulan kode yang lebih besar dalam subset bahasa yang dumbed. Dan tidak peduli berapa banyak Anda membodohi subset bahasa, 500KLOC kode subset bahasa kecil akan selalu lebih banyak bekerja untuk mempertahankan daripada kode 200KLOC yang menggunakan subset yang lebih ekspresif.
user1703394

ini tampaknya hanya mengulangi apa yang dinyatakan dalam jawaban teratas
nyamuk

-1

Kode yang paling bisa dikelola adalah kode yang tidak ada. Jadi, alih-alih menambahkan jumlah LOC, kode baru yang 'mengurangi' jumlah LOC (bahkan jika sedikit kurang terpelihara bila dilihat secara terpisah) dapat membuat basis kode total lebih mudah dikelola hanya dengan mengurangi ukurannya. Jadi aturan utama untuk kode yang bisa dipelihara:

  • memaksimalkan KERING.

Kedua, tidak ada yang lebih buruk untuk pemeliharaan daripada ketergantungan tersembunyi. Jadi untuk aturan nomor 2:

  • Jadikan semua dependensi Anda eksplisit.

Ketiga, tidak semua programmer sama-sama mahir dalam memelihara atau menulis menggunakan teknik-teknik khusus atau fitur-fitur bahasa yang lebih canggih. Menurunkan seluruh basis kode akan memberi Anda basis kode besar yang karena ukurannya sulit untuk dipelihara. Mengizinkan fitur teknik canggih dan idiom di seluruh kode akan membuat semua kode hanya dapat dipelihara oleh pengembang senior yang juga buruk. Kunci untuk mempertahankan adalah layering berbasis tingkat keterampilan Misalnya:

Pustaka lintas proyek: pengembang senior, belakang penuh trik kode / idiom / teknik Pustaka spesifik proyek dan sistem backend: pengembang medior, hindari hal-hal yang paling canggih dan sulit untuk dijelaskan. Lanjut usia akan melewati kode ini mencari peluang peningkatan KERING.

Front-end: junior devs, gunakan panduan gaya yang ketat dan serangkaian teknik yang harus dihindari oleh konstruksi dan idiom bahasa. Medior devs akan memeriksa kode ini untuk mencari peluang KERING dan logika bisnis tersembunyi.

Jadi untuk aturan nomor 3:

  • Lapiskan kode Anda dengan tingkat keahlian pengembang dan tulis kode yang dapat dipelihara sesuai dengan itu.

saya


1
ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 25 jawaban sebelumnya
nyamuk

@gnat, saya berharap untuk menambahkan 'nuansa' ke banyak penyederhanaan (berpotensi berbahaya) di jawaban lain. Terutama dengan poin 3.
user1703394

1
@ user1703394 pertanyaan ini dan jawabannya adalah komunitas wiki. Jika Anda merasa jawaban yang ada dapat ditingkatkan, Anda dapat mengeditnya bahkan tanpa hak "edit posting pengguna lain".

-2

Tidak pernah terlalu mudah mencoba untuk menulis kode yang mudah dibaca dan mudah dirawat, tetapi tidak sulit untuk menulis kode yang mudah & terpelihara.

OOAD adalah kata empat huruf tetapi sulit untuk dipahami dalam satu langkah - ikuti Analisis & Desain berorientasi objek

  1. Selalu mulai dengan pengumpulan persyaratan yang baik dan pernyataan Masalah yang tepat

    • mulai dengan beberapa kasus penggunaan yaitu; Interaksi dialog sistem-pengguna
  2. Anda harus menyimpan objek Anda secara longgar digabungkan dan memastikan kode Anda tidak akan mengulangi - ikuti KERING [Jangan ulangi diri Anda sendiri]

    • kapan saja Anda melihat duplikat, cari tempat untuk merangkum
  3. kode Anda terbuka untuk ekstensi dan ditutup untuk modifikasi - OCP [Prinsip terbuka-tertutup]
  4. Ketika Anda mengubah kode Anda selalu ingat - Jangan Membuat masalah untuk menyelesaikan masalah, TI hanya menyatakan tidak mengubah fungsi Anda yang ada
  5. Unit menguji kode Anda
    • selalu uji kode Anda ketika ada kesalahan
  6. Saat bekerja pada fungsi selalu ingat untuk mengikuti OOP dasar (prinsip berorientasi objek) dan teknik untuk memastikan aplikasi Anda dirancang dengan baik sejak awal.
    • Objek harus melakukan apa yang ditunjukkan namanya
    • Setiap objek harus mewakili konsep tunggal
  7. Selalu ingat pernyataan masalah sistem, dan di mana konteks / perangkat lunak domain berfungsi
  8. Lakukan beberapa pekerjaan kertas juga- ya itu bekerja untuk saya
    • memiliki beberapa cetakan dari hal-hal terkait UI dan diagram UML selalu berfungsi
    • Anda bahkan dapat memiliki tangkapan layar sesi brainstorming dari papan tulis juga
  9. Layout arsitektur
  10. Terapkan prinsip desain jika memungkinkan
  11. Dokumentasi
    • selalu dokumentasikan kode Anda
    • atur indentasi di IDE dan dokumentasikan itu juga

1
Ini adalah teori yang tidak menjawab Bagaimana kita mengukur atau mengukur kualitas kode sehingga kita tahu itu dapat dibaca, dimengerti, dan dipelihara? pertanyaan
Jan Doggen

Sepakat !! tetapi jika kita mengikuti prinsip-prinsip yang disebutkan di atas maka mudah untuk mengukur kualitas kode, dapat dibaca, dimengerti dan jelas dapat dipelihara. Perbaiki saya jika saya salah.
Narender Parmar

Saya tidak tahu mengapa jawaban saya dibatalkan, bahkan saya sudah membahas poin-poin utama
Narender Parmar
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.