Бойлерплейт — бұл жаман емес

Сіз міндетті түрде естіген боларсыз: «Қарапайым тапсырма үшін неге сонша код керек?», «Неге жай ғана жазып қоймасқа?», «Бұл сіздің архитектураңыз тек қана қиындатады». Әдетте бұл сөздер бойлерплейтпен алғаш рет кездескенде айтылады: DTO, мапперлер, қабаттар, модельдерді бөлу. Мен оларды түсінемін. Себебі менде де сол реакция болды.

Мен қатаңырақ архитектурамен алғаш жұмыс істей бастағанда, бұл мені ашуландырды. Бір өріс қосып, бірнеше класты өзгертесің: DTO, мапперлер және тағы бірнеше қабаттар. Сонда «Мен сол тапсырма үшін 3 есе көп код жазып жатырмын» деген сезім пайда болады. Қысқа қашықтықта бұл рас.

Әсіресе, егер сен бұған дейін, мысалы, Active Record-пен жұмыс істеген болсаң, онда модель = бәрі, логика тікелей ішінде, деректер, валидация, мінез-құлық — бәрі бір жерде. Сен жай ғана жазасың және бәрі жұмыс істейді, тез, ыңғайлы, артық ештеңесіз. Мәселе бірден басталмайды. Ол жүйе өскен кезде басталады.

Типтік сценарий. Алдымен бір модель, аздаған логика, бәрі түсінікті. Кейін observers қосылады, оқиғалар қосылады, тексерулер қосылады, бизнес-логика шашырай бастайды. Бір сәтте не болып жатқанын түсінбей қаласың.

Ең ауыр сәт бұл өзгерістер. Мысалы, сенде бір дереккөз болды (жергілікті база). Кейін сыртқы API немесе басқа сақтау түрі пайда болды, немесе деректерді алу әдісін өзгерту қажет. Кенеттен саған бәрін өзгерту керек: контроллерлер, модельдер, бизнес-логика. Өйткені бәрі тікелей байланысты.

Міне, осы жерде бойлерплейт не үшін қажет екені түсінікті болады. Құрылым бар кезде, домен бөлінген, инфрақұрылым оқшауланған, әр қабаттың модельдері бар, маппинг бар, дереккөзді өзгерту жүйені бұзбайды. Сен тек инфрақұрылымдық қабатты өзгертесің. Қалғаны өзгеріссіз қалады. Бұл негізгі идея, бойлерплейт "көп код жазу" емес, бойлерплейт - бұл "өзгерістер аймағын шектеу".

Енді абстракция деңгейі туралы. Көптеген адамдар оны «күрделендіру» деп қабылдайды. Іс жүзінде бұл жай ғана жұмыстың басқа деңгейі. Сіз "мәліметтер қорына қалай сақтау керек" деп ойлауды тоқтатып, "мән деген не", "оның қандай ережелері бар", "жүйе қалай жұмыс істеуі керек" деп ойлай бастайсыз. Инфрақұрылым екінші орынға шығады, ал жүйенің мінез-құлқы бірінші орынға шығады. Иә, бұл үшін қосымша код жазу қажет. Бірақ бұл код жүйені болжамды етеді, өзгерістерді жеңілдетеді және болашақта қателер санын азайтады.

Boilerplate командада ерекше маңызды. Себебі қайталанушылық = болжамдылық. Құрылым бірдей болғанда, жаңа әзірлеуші тезірек бейімделеді, кодты оқу оңайырақ, кодты шолу оңайырақ. Ол "мұнда бәрі қалай ұйымдастырылған" деп ойламайды, ол мұны қазірдің өзінде біледі. Міне, осы жерде ойлау өзгерісі орын алады. Алдымен "неге сонша шаблондық код керек" деп ойлайсың, кейін "жақсы, оның барлық жерде бірдей болғаны" деп түсінесің. Иә, boilerplate-ті кодогенерация, шаблондар және AI арқылы ішінара автоматтандыруға болады. Бұл қалыпты жағдай. Себебі оның мақсаты - құрылымды бекіту.

Және соңғысы. Архитектура — бұл күрделендіру емес. Бұл бақылау. Егер сенде кішкентай жоба болса, иә, оңайырақ болуы мүмкін. Бірақ жүйе өсе бастағанда, хаос артық кодтан қымбатқа түседі. Қысқаша айтқанда, құрылымсыз сен бастамада тезірек боласың. Құрылыммен сен қашықтықта тезірек боласың. Таңдау әрқашан бірдей, қазір тез немесе кейін тұрақты. Бойлерплейт — бұл тұрақтылық үшін төлем. Егер сен мұны қабылдасаң, сен бір функциядан ұзақ өмір сүретін код жаза бастайсың.