Пет-жобалар: оларды дұрыс жасау және күйіп кетпеу

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

Міне, осында маңызды бетбұрыс. Pet-жоба стартап емес. Бұл жаттығу құралы. Егер сен бұл нәрселерді шатастырсаң, күйіп кетесің. Неге көп pet-жобалар аяқталмайды? Себебі тым үлкен scope, нақты мақсат жоқ, негізгі жұмыспен араласып кетеді, "бұл міндетті түрде сәтті болуы керек" деген күтілімдер. Нәтижесінде нәтиже жоқ, мотивация төмендейді, жоба тасталады, және мәселе сенде сияқты көрінеді. Бірақ мәселе бастапқыда тәсілде болды.

Бұл менде қазір қалай көрінеді. Бұрын мен пет-жобаларды өнім жасауға тырысу ретінде жасайтынмын. Қазір зертхана ретінде. Мысалы: жаңа фреймворкты (Laravel, Symfony) сынап көру, архитектураны (DDD, агрегаттар, шекаралар) тестілеу, техникалық шешімді тексеру. Бұл енді "қызмет жасау" емес. Бұл "гипотезаны тексеру".

Бірінші ереже: үлкен жоба жасама. Uber клоны емес, маркетплейс емес, стартап емес. Бір шектеулі модуль жаса, мысалы CSV импортын валидациямен, есептілік, сыртқы API-мен интеграция, рөлдер жүйесі. Бұл жұмыста шын мәнінде кездесетін нәрсе.

Екінші ереже: нақты сценарийлерді қайтала. Абстрактты тапсырмалар емес, сен кездесетіндер: деректерді өңдеу, кезектермен жұмыс, интеграциялар, валидация, қателер. Пет-жоба шынайы жұмысқа ұқсас болуы керек, ойыншыққа емес.

Үшінші ереже: пет-жобаны архитектура зертханасы ретінде пайдалан. Бұл DDD-ны сынап көруге, шекаралармен ойнауға, құрылымды тестілеуге ең жақсы орын. Өйткені сен продакшенге қауіп төндірмейсің, қателесуге, қайта жасауға болады. Бірақ ең маңыздысы техникалық гипотезаларды тексеру мүмкіндігі. Мысалы, бізде былай болды: Laravel-де уақыттың едәуір бөлігі bootstrap-қа кететінін түсіндік. Және идея пайда болды — кіріктірілген DI-контейнерді жылдамырақ, мысалы PHP-DI-мен ауыстырып көру. Бенчмарктер бойынша ол жылдамырақ көрінді. Бірақ бенчмарктер — бұл жүйе емес. Сұрақ басқа болды: енгізу қаншалықты қиын, бұл ағымдағы кодқа қалай әсер етеді, архитектураны бұзбай ма. Мұндай нәрселерді продакшенде тестілеуге болмайды. Міне, осында пет-жоба идеалды орта. Сен оқшауланған жобаны көтеріп, кітапхананы енгізіп, интеграцияны тексеріп, нақты күрделілікті түсініп, содан кейін ғана шешім қабылдай аласың. Бұл жағдайда пет-жоба "ойнау" емес, инженерлік полигон.

Төртінші ереже: негізгі жұмыспен араластырма. Ең жиі қате: күндіз жұмыс істейсің, кешке "өнім құруға" тырысасың. Нәтижесінде шамадан тыс жүктеме, фокусты жоғалту, күйіп кету. Пет-жоба уақыт бойынша шектелуі керек, тапсырма бойынша шектелуі керек. Жасап, тәжірибе алып, әрі қарай жүре бер.

Бірақ даму құралы ретінде бұл ең жақсы форматтардың бірі. Себебі сен стекті кеңейтесің, тәсілдерді сынайсың және тәжірибе жинайсың. Тәжірибемен бірге сапа да өзгереді. Бұрын менің жобаларым инфрақұрылымсыз, CI/CD-сыз, жай ғана сервердегі код болатын. Қазір, мысалы, CI/CD, қалыпты деплой, инфрақұрылым, сапа құралдары. Бұл жинақталған тәжірибенің көрінісі. Және бұл тағы бір маңызды сәт. Пет-жобалар сенің өсуіңді көрсетеді. Егер бір жылдан кейін оларды сол қалпында жасасаң, сен өспейсің. Егер тәсіл, құрылым, құралдар өзгерсе, бәрі дұрыс бағытта деген сөз.

Қысқаша айтқанда, пет-жоба — бұл өнім емес, пет-жоба — бұл жаттықтырғыш, оның мақсаты - дағдылар, ақша емес. Егер оны дұрыс пайдалансаң, ол хаотикалық оқудан гөрі көп нәрсе береді.