Kebetulan dalam beberapa tahun terakhir saya telah menjahit Frankenstein, dan tidak memahat patung porselen lucu gembala dan sapuan cerobong. Saya membuat solusi berdasarkan Magento 2. Ini berarti bahwa sumber materi bagi saya adalah impian setiap arkeolog. Lapisan budaya dengan jejak berbagai "era" dan "peradaban". Ini dapat digunakan untuk mempelajari pengembangan pemikiran programmer di komunitas PHP / JS selama dekade terakhir.

Dan ini hanya dasar, dan tambahan adalah modul pihak ketiga yang perlu diintegrasikan di dalamnya. Di sini sudah mungkin untuk menemukan manifestasi dari kecerdasan luar angkasa. Beberapa modul diciptakan oleh makhluk yang dikembangkan, sangat mirip dalam berpikir dengan pencipta dasar, tetapi Anda menemukan orang-orang yang Anda ingin mengambil penulis dengan pundak, melihat ke dalam matanya dan bertanya dengan ramah: " Dari mana asalmu planet, asli? "

Debugger membantu menjahit Frankenstein dari bahan semacam itu. Di bawah ini adalah teknik pengkodean top pribadi saya, yang dapat menyulitkan kehidupan siapa pun, seperti saya, menggunakan debugger setiap hari dalam hidupnya. Ini kecil, dengan empat posisi, tetapi setiap kali saya menemukan sesuatu seperti ini ketika debugging, saya sedih. Mungkin posting saya akan mengurangi jumlah kesedihan di dunia, atau mungkin tidak. Setidaknya saya akan mencoba.

Kebingungan dan enkripsi kode

Ini di luar kompetisi. Saya menemukan beberapa kali dengan modul yang membutuhkan ionCube untuk bekerja, dan saya dapat mengatakan bahwa hal terakhir yang akan saya lakukan adalah meletakkan modul serupa di proyek saya. Saya sepenuhnya mendukung minifikasi kode JS, terutama ketika sumber yang biasa ada di dekatnya, tetapi kebingungan dan enkripsi adalah kejahatan yang disaring dan terkonsentrasi. Saya memberi tahu Anda ini sebagai Integrator.

IV. Kode baris tunggal

Menyimpan pada baris kode adalah yang paling tidak berbahaya di daftar saya:

if ($cond) aaa(); else bbb(); 

Menggantung dua langkah pada baris ini selama langkah demi langkah pelaksanaan program (perhitungan kondisi, pelaksanaan cabang true atau false ). Tidak apa-apa, Anda hanya perlu mengingat berapa kali Anda melakukan step-over pada baris ini, dan melacak nilai $cond dalam daftar variabel. Seiring waktu, otomatisme telah berkembang.

Lebih buruk sedikit adalah bahwa Anda tidak dapat menetapkan breakpoint tanpa syarat pada cabang true atau false . Alih-alih satu klik dalam IDE, Anda harus bekerja dengan mouse / keyboard sedikit lebih lama, menambahkan breakpoint bersyarat.

Pilihan ideal adalah ketika setiap langkah yang dapat dieksekusi (kondisi, true -light, false -light) berada di barisnya sendiri:

 if ($cond) aaa(); else bbb(); 

III. Hasil ekspresi

Menggunakan ekspresi dalam kondisi:

 if (exp()) ... 

siklus:

 foreach (exp() as $item) ... 

sebagai parameter:

 foo(exp(), ...) 

dan hasil kembali:

 return exp(); 

tidak hanya membuat kode "lebih padat", membuatnya lebih mudah untuk dipahami, tetapi juga membuat debugging lebih sulit - Anda hanya tidak melihat nilai-nilai eksekusi ekspresi dalam daftar variabel debugger. Saya harus menambahkan jam tangan ( pertanyaan yang menarik, dan jika Anda memantau generator melalui jam tangan, apakah ini akan memengaruhi pelaksanaan program? ).

Pilihan ideal adalah variabel sementara:

 $exp = exp(); if ($exp) ... 

II Banyak titik keluar

Sering kali saya menemukan rekomendasi untuk hanya memiliki satu titik keluar dari fungsi dan berkali-kali saya menemukan pelanggaran terhadap rekomendasi ini (contoh yang ditemukan, tetapi tipikal):

 public function onEvent($event) { if($event == 'entrance') { return 'entranceRoute'; } else if($event == 'exit') { return 'exitRoute'; } return 'defaultRoute'; } 

Berikut ini opsi yang lebih benar:

 public function onEvent($event) { $result = 'defaultRoute'; if($event == 'entrance') { $result = 'entranceRoute'; } else if($event == 'exit') { $result = 'exitRoute'; } return $result; } 

Itu saja, saya tidak perlu menyebarkan breakpoint pada setiap return atau melakukan step-out dari baris pertama (jika kode panggilan memberi saya kesempatan untuk melihat hasilnya dalam variabel terpisah) untuk memahami bagaimana eksekusi berakhir. Bayangkan sebuah fungsi dengan 120 baris dan 22 kembali di dalam? Dan saya membatalkan ini sendiri dan saya curiga ini bukan batasnya.

I. Panggilan Metode Cascading

Favorit saya adalah metode cascading :

 $collection ->addFilterByProduct(...) ->addShowInStoresFilter(...) ->addPublicFilter(...) ->addApprovedStatusFilter(...) ->addCreatedAtLessThanNowFilter(...); 

Jika saya perlu masuk ke dalam metode addApprovedStatusFilter() , yang berbasis antarmuka dan diimplementasikan dalam beberapa kelas yang berbeda (kelas tertentu ditentukan pada saat runtime), hal yang paling sederhana adalah menetapkan breakpoint pada $collection dan memeriksa semuanya pada gilirannya ( addFilterByProduct , addShowInStoresFilter , addPublicFilter ) ke tempat yang tepat. Jika Anda menggabungkan ini menggunakan ekspresi dalam parameter dan hasil yang dikembalikan, maka path menjadi sepenuhnya tidak menutup. Dalam aslinya, kode ini terlihat seperti ini:

 $collection ->addFilterByProduct($this->getProduct()) ->addShowInStoresFilter($this->_storeManager->getStore()->getId()) ->addPublicFilter() ->addApprovedStatusFilter() ->addCreatedAtLessThanNowFilter(); 

Ya, dengan metode cascading, kode menjadi lebih mudah dibaca, tetapi mendebitnya menjadi lebih sulit. Saya tidak menentang kaskade set'er (sebagai aturan, saya tidak menetapkan debut):

 $answerModel ->setAuthorName(...) ->setStatus(...) ->setCreatedAt(...) ->setAuthorEmail(...) ->setCustomerId(...) ->setHelpfulness(...) 

Tetapi kode yang berisi logika yang mungkin harus didebit, atau mungkin bahkan oleh saya sendiri, lebih baik untuk menulis " sekolah lama " (Saya melakukannya sendiri):

 $collection->addFilterByProduct(...); $collection->addShowInStoresFilter(...); $collection->addPublicFilter(...); $collection->addApprovedStatusFilter(...); $collection->addCreatedAtLessThanNowFilter(...); 

Apakah menjadi lebih sulit untuk dipahami?

Atau di sini adalah rekomendasi untuk gaya pemrograman yang baik:

 ladder.up().up().down().up().down().showStep(); 

Lihat ini dari sudut pandang integrator, yang harus masuk ke dalam down kedua.

Ringkasan

Saya tidak bermaksud bahwa teknik-teknik ini digunakan dalam kode mereka oleh " alien ". Tidak sama sekali, sebagian besar mereka, sebaliknya, ditujukan untuk mengurangi jumlah kode. Tetapi teknik ini menyulitkan debugging. Seseorang tidak memiliki kecepatan komputer, dan untuk mencapai kode masalah, integrator harus terlebih dahulu memindai (tidak mengerti, yaitu memindai) kemajuan program pada titik-titik kunci. Semua hal di atas, karena di satu sisi tugas meningkatkan pemahaman kode, pada kenyataannya, selama debugging, pemahaman ini terhambat. Mereka tidak mengganggu di lokasi kode, tetapi mengganggu untuk sampai ke area masalah, yang, pada umumnya, membutuhkan pemahaman yang nyata.

Penafian

Hal tersebut di atas adalah hasil dari deformasi profesional pribadi dan mungkin berbeda dari pendapat berdasarkan deformasi profesional lainnya.