Saya telah menemui bahagian saya yang ditulis dengan indah, kod over-engineered ... satu saat saya berfikir "Itu adalah cara yang menarik untuk melakukan itu" dan minit seterusnya anda bertanya-tanya "apa jahat yang berlaku di sini!". · The Prinsip (You Are Not Gonna Need It) adalah cara yang baik untuk melawan over-engineering: fungsi hanya perlu dilaksanakan apabila anda membutuhkannya, bukan pada kemungkinan bahawa anda akan membutuhkannya. sekarang YAGNI sekarang Dalam istilah yang sangat mudah, over-engineering menjadikan reka bentuk perisian / sistem lebih kompleks daripada yang diperlukan; ini biasanya berlaku kerana anda ingin menambah fungsi tambahan kepada komponen anda untuk menyederhanakan pelaksanaan A, hanya untuk menambah fungsi untuk B nanti. Kami mempunyai kod pangkalan ini untuk menguruskan undangan; ia adalah warisan, kod pangkalan warisan dengan hutang teknikal yang menambah faedah. Semakin banyak anda cuba untuk bekerja pada kod warisan, semakin banyak sesuatu di tempat lain pecah. Anda mesti membalik semula dalam kebanyakan kes dan mula semua. Bekerja di sekitar kod warisan berakhir dengan mengumpul minat pada hutang teknikal; Pada mulanya, ini kelihatan seperti Hail Mary. Akhirnya, kita boleh bekerja pada ciri-ciri melanggar di seluruh aplikasi atau menambah lebih banyak hutang teknikal ke pangkalan kod. Penyelesaian ketiga yang kami datang dengan adalah abstraksi. Kami perlu mencari cara untuk membongkar ciri-ciri baru atau peningkatan kepada aplikasi, dan untuk mendedahkan dan berkongsi data di mana perlu. Pada mulanya, ini kelihatan seperti Hail Mary. Akhirnya, kita boleh bekerja pada kod pang Apabila bekerjasama dengan beberapa orang pada basis kod (yang hampir selalu berlaku), dan untuk syarikat yang lebih berminat dalam ciri-ciri penghantaran daripada kualiti kod, ulasan kod sentiasa menderita. Untuk masalah seperti over-engineering dan overabstraction, ulasan kod garis-per-garis tradisional sering kehilangan isu-isu sistematik ini. Anda memeriksa komponen yang dicipta beberapa minggu yang lalu untuk menyokong integrasi ciri-ciri, mengikuti prinsip DRY, dan menyedari bahawa kini terdapat 10 ciri-ciri bersambung / serupa yang bergantung kepada komponen. ulasan kod perlu ditingkatkan untuk menangkap isu-isu arsitektur ini dan memastikan bahawa keperluan ketergantungan antara komponen dipenuhi. Spaghetti Kode Kering Kami hidup dengan Injil DRY (Jangan Mengulang Diri) kerana ia menyederhanakan kerja, dan pengembang secara semula jadi malas (dalam cara yang baik). prinsip DRY berfungsi dengan baik dengan sistem orthogonal: komponen kecil yang mengandungi diri mereka sendiri dikombinasikan untuk membentuk sistem. . Sistem hendaklah terdiri daripada satu set modul yang bekerjasama, yang masing-masing melaksanakan fungsi secara bebas antara satu sama lain. Alıntılar - Pemrograman Pragmatik: Dari Pengembara kepada Guru. Ia lebih mudah untuk menggabungkan fungsi yang boleh digunakan semula yang anda cipta dengan satu sama lain dan meluaskan mereka apabila repository berkembang apabila mereka tidak bengkak dan berlebihan, pada titik di mana anda berakhir dengan sistem kaku yang terhubung begitu banyak dengan satu sama lain bahawa ia akan menjadi sukar untuk menghubungkan aspek-aspek kod yang tidak memenuhi peraturan yang tepat, anda akan mendapati diri anda menggandakan kod kerana membuatnya berfungsi untuk sambungan baru memecahkan sistem lama. Komponen yang kompleks Komponen anda tidak boleh hanya memberi tumpuan kepada mengelakkan pengulangan, tetapi juga kepada menjadi abstraksi kecil sistem keseluruhan; jika tidak, anda akan berakhir dengan komponen yang begitu kompleks bahawa mereka boleh dengan mudah memecahkan dengan satu perubahan kepada komponen yang disambungkan. Apabila mencipta kod yang boleh digunakan semula, pendekatan harus menulis kod yang tidak bergantung kepada mana-mana blok kod lain untuk berfungsi dengan cara tertentu. Reusability harus digunakan sebagai alat dan bukan matlamat; apabila anda mempunyai komponen UI yang boleh digunakan semula dengan logik perniagaan atau API dalam komponen yang sama, anda berada di jalan raya untuk over-abstraction. Ia bermula kecil, dan sebelum anda menyedari apa yang berlaku, penyakit telah melanda seluruh repository anda.Sekarang anda tidak boleh menggunakan semula komponen pada halaman yang berbeza dengan fungsi UI yang sama dan logik yang berbeza tanpa menambah logik / konteks Pattern untuk mengelakkan over-abstraction dan over-engineering Modulariti Modulariti Modulariti Modulariti Modularity melibatkan memecah sistem anda ke dalam kod / komponen yang lebih kecil dan bebas yang dipanggil modul. Sila berhati-hati dengan perkataan 'kurang'; ia adalah mungkin untuk mempunyai modul membengkak dengan lebih banyak kod daripada yang diperlukan, yang mewujudkan abstraksi yang berlebihan dan perlu dielakkan. Over-abstraksi sebenarnya hanya satu percubaan yang gagal untuk modulariti. modul anda harus dapat berfungsi secara bebas daripada modul lain, hanya mendedahkan data yang diperlukan. Fungsi Pertama Salah satu pendekatan yang baik untuk membina sistem orthogonal dan dengan mudah mengelakkan abstraksi yang berlebihan ialah membina dengan fungsi pertama, kemudian ciri-ciri; ini selaras dengan Arsitektur Berasaskan Komponen (mengasingkan komponen UI daripada komponen berstatus). Tahap fungsi akan memberi tumpuan kepada unit kode yang terkecil yang boleh digunakan semula yang dikumpulkan untuk melaksanakan ciri-ciri ini. ciri Login akan terdiri daripada fungsi berikut: mengumpul nama pengguna dan kata laluan (UI), mengesahkan data pengguna, mengalih ke profil pengguna / menolak data pengguna yang dikumpulkan. Tiada medali untuk kod yang berlebihan Selepas menulis setiap pelaksanaan kod, tanyakan kepada diri anda sama ada terdapat cara yang lebih mudah atau lebih mudah untuk mencapai hasil yang sama. Kebanyakan daripada kita telah mendengar cerita tentang kod yang boleh diedit atau bekerja pada oleh hanya satu orang dalam syarikat, yang bukan prestasi yang boleh dibanggakan. Menulis kod yang hanya boleh dikekalkan oleh anda kemungkinan besar bermakna ia terlalu canggih atau menggunakan prosedur yang tidak ortodoks. Seorang bekas pekerja syarikat dikenali kerana tidak memeriksa kod dan mempunyai program dan bahagian-bahagian pangkalan kod pada cakera kerasnya (bayangkan overhead untuk mengekalkan produk itu!). "We Run Out of Columns" - The Best, Worst Codebase oleh Jimmy Miller Saya telah mendapati diri saya menulis kod yang terlalu canggih kerana saya mahu menggunakan teknologi baru / paket / perpustakaan yang baru saya pelajari, tanpa mempertimbangkan sama ada ia adalah alat yang paling mudah untuk kerja. Akhir Dalam pencarian untuk menulis kod yang sempurna yang menjelaskan semua kes masa depan dan perjalanan masa yang mungkin, anda berakhir dengan basis kod yang berlebihan. Anda perlu menyerah kerana ia tidak mungkin untuk menulis kod yang sempurna, bertujuan untuk cukup baik yang memenuhi semua keperluan segera anda. Prinsip DRY adalah asas; pengulangan masih merupakan dosa dalam pembangunan perisian. Prinsip DRY harus diterapkan kepada sistem ortogonal untuk mencipta pangkalan kod yang dipisahkan, dengan setiap modul bebas dan bertukar data di titik mesyuarat yang berasingan(modul ciri). Ini akan membantu anda mencipta sistem yang mudah untuk mengekalkan dan memulihkan. Ingat bahawa mudah sentiasa lebih baik dalam pembangunan perisian.
