Блог

Үлкен кәсіпорынмен жұмыс тәжірибесі және одан не үйренуге болады

Юрий Мельников

Мен әдетте өз компьютерімде іске қосып, тестілеуге болатын қосымшалар жасайтынмын. Бірақ қазір мен мұндай мүмкін, бірақ негізсіз жобамен жұмыс істеп жатырмын.

Бұрын мен негізінен ноутбугымда оңай іске қосылатын жобалармен жұмыс істейтінмін. Кодты іске қосып, дерекқорды Docker-де көтеріп, бәрін жергілікті түрде тексеріп, содан кейін орналастыруға болатын. Ең нашар жағдайда іске қосуға он минут кететін, бірақ мен толықтай автономды болдым.

Содан кейін мен нағыз кәсіпорынмен кездестім.

Жоба Java тілінде жазылған, он беске жуық модульден тұрады және ондаған гигабайтты құрайды. Бұл тестілеу және жөндеу үшін қажет дерекқорды есептемегенде. Мұның бәрін "жолдағы" MacBook Air-де іске қосу екіталай. Тіпті қуатты стационарлық компьютер де әрдайым орындай алмайды.

Сондықтан барлық жұмыс тесттік стендтер арқылы жүреді. Мұнда нюанстар басталады:

  • егер біреу құрастыруды іске қосса, стенд басқалар үшін кем дегенде жарты сағатқа бұғатталады;

  • орналастыру алдында әріптестерді ескерту және жобаны ешкімнің құрастырмайтынына көз жеткізу қажет;

  • кез келген кішкентай қате бір сағат жоғалған уақытқа айналады.

Алғашында бұл үйреншікті емес еді. Даму үнемі күтумен айналысатын сияқты көрінді. Бірақ уақыт өте келе мен процесті басқаруға мүмкіндік беретін бірнеше ереже жасадым.

1. Мини-орта жергілікті түрде

</b>Жобаны толықтай көтеру мүмкін емес, бірақ микро-стендті жинауға болады: тек қажетті модульдер және сыртқы қызметтерге арналған заглушкалар. Бұл негізгі логиканы "тізеде" тексеруге мүмкіндік береді.

2. Тесттер — опция емес, қажеттілік

</b>Бұрын мен юнит-тесттерге "пайдалы қосымша" ретінде қарайтынмын. Енді әр тест — жарты сағаттық бос уақыттың азаюы екенін түсінемін. Кейде гипотезаны тексеру үшін кішкентай интеграциялық тест жазу оңайырақ, құрастыруға уақыт жұмсағаннан гөрі.

3. Кішкентай өзгерістер

</b>Егер тапсырманы бірнеше кішкентай pull request-ке бөлуге болса — бөлу керек. Кодтың кішкентай бөлігі болса, тәуекел азаяды және тексеру жылдамырақ болады.

4. Code review фильтр ретінде

</b>Әріптестермен кросс-ревью міндетті кезең болып табылады. Көбінесе екінші көз адамның өзі жіберіп алуы мүмкін нәрсені байқайды. Қателер құрастыруға дейін анықталады — және бұл сағаттарды үнемдейді.

5. Орналастыруды жоспарлау

</b>Стендте іске қосу — бұл ресурс, және оны басқару қажет. Бізде бейресми ереже бар: "өз терезеңді" алдын ала келісіп ал, басқаларға кедергі жасамау үшін.

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

Негізінде, мұндай жағдайлар мүлдем басқа ойлау стилін қалыптастырады: сіз бірінші орналастыруға дейін қателерді жібермеу үшін жазуды үйренесіз.