Get best of the week

Kode murni: sebab dan akibat



Penulis: Victor Svirsky, Pengembang Python Senior / Pemimpin Tim, DataArt

Berapa banyak programmer, definisi begitu banyak, apa itu kode bersih. Saat wawancara, saya sering mendengar bahwa kode yang baik adalah kode yang mudah dibaca. Saya setuju, tetapi seperti pengalaman pribadi saya katakan, ini hanya puncak gunung es.

Bel pertama yang memberi tahu kita bahwa kode tidak lagi bersih adalah peningkatan waktu pengembangan fungsionalitas baru dan peningkatan cakupan regresi pada sedikit perubahan dalam sistem. Hal ini disebabkan oleh fakta bahwa hutang teknis terakumulasi, komponen-komponen dalam sistem sangat terhubung erat, dan tidak ada autotest. Alasan untuk ini mungkin:

  • Eksternal - seperti tekanan dari bisnis dan keinginannya untuk mendapatkan fungsionalitas baru lebih cepat.
  • Internal - proses pengembangan yang kurang berkembang dan interaksi dalam tim, kurangnya kontrol dan standar pengembangan atau kurangnya kompetensi dangkal.

Jangan menunda pekerjaan pada kualitas kode dan arsitektur dalam kotak yang panjang. Selama sprint, penting untuk dapat memisahkan tugas yang bernilai langsung ke bisnis (tugas dengan fungsi baru) dan tugas teknis yang hanya memiliki efek tidak langsung pada bisnis. Proporsi pemisahan tergantung pada keadaan proyek saat ini, kerangka waktu dan jumlah tangan yang bebas.

Apa itu kode bersih?


Ternyata mengatakan bahwa kodenya bersih dan sistem dirancang dengan benar, mudah membaca kodenya tidak cukup. Ia harus memiliki kualitas lain:

  • . . , . , , .
  • , , . , . . , . , .
  • . . . -, OWASP.
  • — , . , , . , , . , .
  • . , . , .

Untuk menghindari penilaian subyektif terhadap kualitas kodenya, istilah "bau kode" atau "kode stok" diperkenalkan pada tahun 1961. Ini adalah sekelompok aturan dan rekomendasi yang secara jelas menentukan apakah sudah saatnya melakukan refactoring. "Bau" menyebabkan pembusukan kode, dan pengembang harus selalu berusaha untuk menghilangkannya. Perlunya refactoring langsung mengikuti dari bau kode, dan dengan mencegah penyebabnya, kita dapat menghindari konsekuensinya. Anda dapat membaca lebih lanjut tentang tanda-tanda kunci bahwa Anda harus mulai refactoring dalam buku Martin Fowler “Refactoring. Meningkatkan kode yang ada. "

Haruskah saya menulis kode bersih?


Pasti sepadan! Tapi tidak selalu dan tidak di mana-mana, ada baiknya terlalu memperhatikan kebersihan.

Jangan lupa tentang kegunaan dan kehidupan kode Anda. Misalnya, jika Anda dihadapkan dengan tugas mengembangkan konsep - PoC (Proof of concept), dan Anda membuktikan bahwa tumpukan teknologi yang dipilih melakukan tugas, kode Anda akan menjadi tidak relevan dalam satu atau dua minggu. Itu tidak sepadan dengan upaya untuk meningkatkan fungsi ini.

Ada pendapat bahwa tidak perlu memantau kualitas kode atau bagian dari sistem yang akan segera diganti. Dan ini tidak benar karena beberapa alasan. Pengerjaan berkualitas tinggi akan membuat transisi atau integrasi dengan bagian-bagian baru lebih mudah, lebih mulus dan lebih cepat. Ini tentu akan menyederhanakan hidup dalam kasus-kasus di mana beberapa versi kode harus didukung pada saat yang sama. Jumlah kesalahan regresi dengan kode bersih akan berkali-kali lebih sedikit. Juga, jangan lupa bahwa tidak ada yang lebih permanen daripada sementara. Mungkin tugas untuk memperbaiki bagian kode ini selama beberapa bulan akan terletak pada tumpukan.

Apa yang akan membantu meningkatkan kode Anda?


Kebanyakan pemrogram bermimpi menulis kode dengan cepat dan indah, sehingga semuanya bekerja dengan sempurna saat pertama kali. Tetapi tidak semua orang berhasil membuat kode tidak hanya berfungsi, tetapi dapat dimengerti. Bagaimana cara sukses dalam menulis kode bersih? Ada dua cara - pengorganisasian diri dan kerja tim.



Pengorganisasian diri


Pertimbangkan beberapa cara yang mungkin untuk meningkatkan kualitas kode individual. Rekomendasi ini cocok untuk pengembang di tingkat mana pun.


  1. , — . — . IDE ( ) , , . IDE , . — .

    . , .
  2. open source
    . , . , . !

  3. , . . . , , 10, , . .

    . -, .

  4. . . . .

    . .


  5. . . - . , .

    — , , , , .


  6. , . — .
  7. !

    , .


Sebagian besar tugas diselesaikan dalam tim. Sangat penting untuk berbagi tanggung jawab atas kualitas di antara para pesertanya. Semakin besar tim, semakin sulit untuk menjaga produk dalam kondisi baik. Mari kita pertimbangkan beberapa pendekatan retensi kode dalam kondisi di atas.

  1. Tinjauan Kode
    Ini adalah prinsip sederhana untuk memahami dan mengeksekusi. Setidaknya dua orang, termasuk pembuat kode, memeriksa kode tersebut.

    Ada beberapa hal yang perlu dipertimbangkan ketika memeriksa kode Anda:

    • Salah satunya adalah memeriksa apakah kode melanggar aturan perjanjian kode. Ini adalah proses yang dapat dan harus diotomatisasi menggunakan penganalisa statis dalam CI (integrasi berkelanjutan).
    • Lainnya adalah pemeliharaan kode dan penanganan kesalahan yang tidak dapat diverifikasi secara otomatis.
    • , , . , ?

  2. (Continuous integration)

    , .

    , :

    • . . , . , , .
    • , , .
  3. (Coding onventions)

    . , . , , .

    , , , . . , , . , . , . .

    , , . — , - .

    . , . .


  4. , . , , .

    , . , . , , .

    -. . , . . , .


  5. , , . . , .

    , :

    • ? , . , .
    • ?
    • ()?
    • ?
    • — ?

    , , . , .


  6. , . SonarQube. :



    • — . , . , .


    • , — DRY (Don’t repeat yourself).


    • . . . , .


    • , , , .


    • . , . , .

***


Kesalahan dalam kode ini mirip dengan jejak karbon. Sama sekali tidak mungkin untuk melarikan diri, dan kelebihan pembuangan saja tidak akan membunuh manusia atau alam di sekitarnya. Namun demikian, untuk mengurangi efek negatif dari tinggal seseorang di planet saat ini tampaknya merupakan kebutuhan alami. Dengan cara yang kira-kira sama, menulis kode bersih adalah tanggung jawab setiap pengembang. Apa pun jalur yang Anda pilih, Anda harus berusaha menulis kode yang berfungsi dan dapat dimengerti.

Nah, jika Anda tidak bisa mengubah kemurnian menjadi jimat, mengingat umur kode kami dan mengevaluasi kelayakan perbaikan lebih lanjut. Hal utama yang perlu diingat tentang orang-orang: pengguna yang dapat gagal bahkan sebagian kecil dari sistem yang dikembangkan oleh kami, dan insinyur yang harus mendukung sistem ini.

More articles:


All Articles