Saya diminta untuk menulis konsep ini dengan masalah yang saya temui berulang-ulang ketika datang ke proyek baru: selama 5 tahun pengembangan komersial, saya terus-menerus "beruntung" datang ke proyek yang ditinggalkan oleh pengembang utama. Dan setiap kali saya mewarisi basis kode besar - hukum operasinya hanya dipahami oleh penciptanya. Saya, pada gilirannya, sudah setelah tahun pertama, memperoleh kebiasaan pengembangan melalui desain, dan desain melalui komentar. Yang ingin saya bagikan dengan Anda di bawah potongan:
Paradigma pembangunan melalui komentar
Ide: Merancang melalui komentar. Kode
- Ide
Penggagas gagasan dapat berupa Anda atau orang lain - misalnya, PM Anda (TimLead).
contoh sebuah ide: "Anda perlu menghapus nomor telepon dari karakter seperti '+, -, tanda kurung dan spasi', sehingga output hanya seperangkat angka. Fitur ini diperlukan untuk melaksanakan pencarian berdasarkan nomor telepon - dimasukkan dengan cara apa pun."
- Desain melalui komentar
Menulis komentar yang menggambarkan logika program.
contoh desain melalui komentar:
Spoiler<?php namespace App\Services; use App\Entity\Users; use Doctrine\ORM\EntityManagerInterface; use Doctrine\ORM\EntityManager; class PhoneService {
- Penulisan kode
Sekarang kita perlu mengubah proyeksi komentar kita menjadi kode:
contoh:
Spoiler <?php namespace App\Services; use App\Entity\Users; use Doctrine\ORM\EntityManagerInterface; use Doctrine\ORM\EntityManager; class PhoneService {
Untuk apa ini?
Mengapa saya perlu komentar, kode, dan itu jelas?
Banyak yang akan mengatakan bahwa kode itu adalah teks - dan mudah dibaca. Dan saya harus menyebutkan bahwa kode adalah metode untuk mengekspresikan pikiran Anda melalui sintaks bahasa yang Anda gunakan. Dan ketika kita menulis logika yang kompleks - kita menggunakan gaya kita sendiri, dalam banyak hal gaya unik menggunakan sintaksis ini. Tetapi jika kita berada pada tahap desain - kita akan menggambarkan logika kita dalam bahasa yang diterima secara umum, kemudian kembali ke kode setelah 3 tahun kita akan mengerti cara kerjanya dan kode kita. Sang pewaris, dengan susah payah bisa mengetahuinya. Menggunakan desain melalui komentar - mengurangi entropi proyek Anda dan membuat kodenya lebih indah.
Mengapa saya membutuhkan desain, dapatkah saya duduk dan menulis semuanya sekaligus?
Jika Anda mengajukan pertanyaan ini, maka Anda hanya perlu segera membaca " Kode Sempurna " oleh Steve McConnell . Di sana, konsep ini lebih dari diungkapkan.
Saya akan memberikan penawaran kecil:
Pada tahap desain kode, 75% kesalahan biasanya ditemukan. Jika mereka tidak ditemukan, saya harus refactor.
Dan memang, pada tahap desain - Anda dapat memahami bahwa logika bisnis yang disusun tidak akan berfungsi sesuai rencana, atau Anda dapat melihat pendekatan yang lebih baik untuk menyelesaikan masalah tertentu. Dan Anda tidak perlu kembali lagi nanti dan memperbaiki sepotong logika - yang tidak bekerja persis seperti yang dimaksudkan.
Apakah saya perlu mengomentari semuanya?
Saya memberikan contoh dasar di atas. Mereka sepenuhnya dimengerti dan tanpa komentar, tetapi saya masih menggunakan pendekatan IC-DC untuk mengimplementasikannya. Karena Saya tidak ingin kode saya bertambah entropi. Saya mengunjungi banyak proyek di mana sebagian besar proyek harus ditulis ulang dari awal karena entropi yang sangat besar di dalamnya. Pikirkan apakah Anda ingin proyek yang menghabiskan berbulan-bulan atau bertahun-tahun hidup Anda dihapus begitu saja. Jika jawabannya tidak, maka saya pikir selalu ada gunanya menggunakan pendekatan ini. Karena jika Anda meninggalkan proyek atau beberapa tahun kemudian, muncul teknologi baru yang dapat menutupi kebutuhan lebih baik daripada solusi lama Anda - IC-DC akan membantu Anda mengimplementasikan perubahan secara optimal, mencapai fungsi minimum, karena karyawan baru atau yang baru akan memahami bagaimana dan mengapa ia bekerja.