Як Валера взяв в команду стажиста і почав вчити його проектування

Початок
Валера раніше працює тимлидом в однієї великої IT-компанії однієї великої середньоазіатської країни. У роботі знаходиться кілька великих проектів і, судячи з сяючим особам фахівців з маркетингу і продажу, незабаром їх стане значно більше. На цю ж думку Валеру наводить запрошення на нараду, яке він отримав від технічного директора. Тема наради — розширення напрямки освітніх систем.

На наступний ранок в залі для нарад зібралися ключові співробітники напрямку. Технічний директор (для тих, хто з ним ще не знайомий, — його звуть Іван) одразу перейшов до суті питання: «Вітаю усіх! Як ви знаєте, деякий час тому ми поставили перед собою мету розширити присутність на ринку і для цього відкрили новий офіс продажів. Так ось, ця стратегія спрацювала. Через місяць ми підписуємо договір на розробку та впровадження платформи дистанційної освіти. Проект дуже цікавий, але поки що не про це. Щоб його потягнути, нам потрібно терміново формувати нову команду в напрямку освітніх систем.»

«Опачькі!» — промайнуло в голові у Валери. Він ясно розумів, що зараз на ринку дуже мало вільних розробників, і за місяць знайти потрібну їх кількість буде практично неможливо. Він поділився цими думками з колегами. Подискутувавши деякий час, учасники наради прийшли до наступного рішення. З інших команд напрямки в нову буде виділено три сильних спеціаліста. І у всі команди будуть прийняті стажисти — вчорашні студенти або старшокурсники, яких потрібно буде навчити. Навчити швидко, щоб зобов'язання за всіма проектами не постраждали. Валера стає тимлидом нової команди. Вирішено.

Через два тижні в новий кабінет нової команди невпевнено зайшов молодий хлопець. Він підійшов до столу Валери і представився: «Ержан — ваш стажист». Валера вперше побачив людину, з якою до цього тільки листувався в пошті, давав завдання і перевіряв їх рішення. І з яким йому довгий час належить працювати на одному з найбільш важливих проектів компанії.

«Сідай», — махнув у бік стільця наш герой — «Я той самий Валера, який заочно мучив тебе останні півтора тижні. У нас в компанії діє правило, що до кожного стажисту закріплюється наставник. Він допомагає стажисту в виконанні завдань, дає рекомендації, що і в якому порядку вивчати. Загалом, моє завдання — розповісти тобі все те, що я знаю сам. З усіма питаннями також звертайся до мене». Ержан посміхнувся: «Супер! Я думаю, це допоможе мені в рази швидше увійти в курс справи і почати вирішувати реальні завдання». Валера відзначив про себе, що у хлопця правильна мотивація.

Мотивація мотивацією, але Йому ще потрібно було зрозуміти, як за кілька тижнів з людини, пошарпаного вітчизняною системою освіти, зробити фахівця, здатного самостійно вирішувати завдання. І вирішувати їх якісно і в строк. Для цього потрібно буде систематизувати весь той досвід, який Валера отримав за довгі роки своєї кар'єри, і постаратися швидко передати його стажисту. Завдання не просте, але воно того варто. Дивись, хто-небудь потім книгу про це напише.

А взагалі, на чому сконцентруватися? Що відрізняє поганого програміста від хорошого? Чому одному ти боїшся дати завдання, знаючи, що доведеться постійно підключатися, відстежувати статус і переписувати половину коду, а іншому дав постановку, пояснив деталі і спокійно пішов займатися своїми справами? Може один з них добре знає мову програмування, а інший не дуже? Ні, не те. Валера надивився на людей, проштудировавших не одну книгу по мові програмування, але не вміли спроектувати найпростішого додатка. Так, почекайте… спроектувати… Ось воно! Хороший розробник зобов'язаний вміти проектувати. І на розвитку цього навику потрібно сконцентруватися в першу чергу.

Тепер потрібно донести це Ержану. Валера почав несподівано: «Вимоги змінюються завжди». Побачивши здивований погляд свого співрозмовника, він продовжив: «Твоє основне завдання як розробника — реалізація вимог користувачів створюваної системи. Так от, користувачі — дуже вітряні створення і ніколи відразу не знають, що їм потрібно. Тільки після того, як вони побачать першу версію системи, їх вимоги починають прояснюватися і часто сильно змінюватися. І ти повинен писати код так, щоб кожен раз, коли ти будеш дізнаватися, що функціонал повинен працювати по-іншому, ти радів. Тому що створений тобою дизайн дозволить легко реалізувати ці вимоги, і система стане трішки краще.»

Валера витратив ще деякий час, пояснюючи Ержану чому правильне проектування так важливо. Він розповів про те, як на ранніх етапах своєї кар'єри працював з погано спроектовані системами. Необхідність навіть найменшої зміни в них викликала панічний страх у всієї команди. Адже ніхто не знав, в якому місці після цієї зміни система зламається. І добре, якщо про поломку повідомлять тестувальники. Ситуації, коли про це повідомляли бізнес-користувачі, які не належали до найбільш приємним спогадам Валери.

Валера резюмував: «Система, яку ми почнемо розробляти через кілька тижнів, велика і складна. І ти не будеш сидіти там на виправлення багів. Ти будеш повноцінним учасником розробки. Так що будь готовий до занурення у світ гнучкого об'єктно-орієнтованого проектування». «Завжди готовий!» — вискочила з підсвідомості Ержана почута в якомусь фільмі фраза. А ще він подумав, що йому починає тут подобатись.

Перший день. Перші істини
Коли на наступний день Ержан прийшов на своє робоче місце, перше, що він побачив, було дві книги, що лежать біля монітора. «Досконалий код» Стівена Макконнелла і «Ідеальний програміст» Роберта Мартіна. Попросивши Валеру пояснити, чому на столі лежать саме ці книги, у відповідь він почув: «Перша книга розповідає про якості хорошого коду. Друга книга розповідає про якості хорошого програміста. Мені здається, вони відмінно доповнюють один одного. Одного без іншого не буває. Прочитавши ці книги, ти зможеш значно прискорити свій розвиток. До того ж, хороші книги надихають. Це важливо для успіху.»

Закінчивши з книгами, Валера коротко пояснив, яку систему вони будуть розробляти. Не так давно Міністерство освіти створило Інститут дистанційної освіти, перед якими поставив завдання розробити нову модель надання освітніх послуг. У результаті народилася концепція майданчика, на якій викладачі з різних вузів публікують свої курси, а студенти на підставі навчального плану вибирають потрібний для себе набір. Кожен викладач вказує ціну проходження свого курсу. І студенти на підставі відношення ціни і якості вибирають оптимальний для себе варіант. Інститут припускає, що цей механізм призведе до стимулювання конкуренції між викладачами та в цілому підвищить якість дистанційної освіти.

«А наша компанія повинна розробити платформу для запуску цієї моделі», — продовжив пояснювати Валера — «Це веб-рішення і писати його ми будемо на платформі .NET і мовою C# зокрема. Пропоную зараз обговорити модулі системи і вибрати той, у розробці і проектуванні якого ти будеш брати участь.» Після нетривалого обговорення колеги вирішили, що це буде модуль перевірки виконаних завдань.

Ноутбук Ержана досі був у спеціалістів технічної служби, які встановлювали на нього всі необхідні інструменти. Так як віддадуть його тільки завтра, Валера вирішив використати цей час, щоб поки не обговорювати деталі конкретної задачі, а замість цього донести до Ержана ті речі, які повинен розуміти кожен програміст. І чим раніше він їх зрозуміє, тим краще.

Валера почав зі свого улюбленого питання: «Що таке об'єктно-орієнтоване програмування і для чого його придумали?» Ержан здивувався простоті питання і тут же відповів: «Це знає будь-який студент. Об'єктно-орієнтоване програмування дозволяє описати в коді об'єкти реального світу. Припустимо, є автомобіль, у нього є колеса і інші механізми. Ми можемо створити відповідний клас і за допомогою нього керувати автомобілем і використовувати його в програмі.»

Настав час Валери: «Те, про що ти розповів, вірно. Але це не головне. Насправді, головна мета ООП — боротьба зі складністю. Поясню, про що я. До появи ООП домінуючою моделлю розробки було процедурне програмування. Але у міру того, як системи ставали складніше, процедурний підхід почав пробуксовувати. Супровід і розвиток коду стало займати дуже багато часу. А все із-за того, що процедури не дозволяли належною мірою відокремити компоненти системи один від одного; зміна одних процедур впливало на поведінку інших. ООП придумали для того, щоб вирішити цю проблему. Об'єктний підхід дозволяє розділити програму на незалежні і ізольовані компоненти. І зміна одних ніяк не впливає на поведінку інших. До того ж, мозок людини дуже слабкий і не може в один момент часу охопити всю систему цілком. А клас дозволяє концентруватися на окремій частині системи, розуміти і працювати з нею, зменшуючи загальну складність завдання.»

Подумавши пару секунд і згадавши свій перший проект, Валера додав: «Ще важливо усвідомлювати, що використання ООП-мови автоматично не дає всі ці переваги. Мені доводилося бачити, як на тому ж C# писали повністю процедурний код з усіма супутніми проблемами. Потрібно розуміти об'єктно-орієнтоване програмування і об'єктно-орієнтоване проектування і вміти їх правильно використовувати. Тоді тебе чекає щасливе і плідна кар'єра. І ще ти не подумай, що зараз застосовують лише ООП. Існують і інші підходи, кожен з яких використовується в своїй області. Але для нас, як для розробників корпоративних систем, ООП дуже важливо.»

Почавши з ООП, наступним логічним кроком було розповісти Ержану про слабку пов'язаності (або loose coupling, якщо користуватися англомовною термінологією). Класи дозволяють розділити код системи на окремі частини — це добре. Але ще більш важливо, щоб ці частини якомога менше знали один про одного і були максимально незалежні. Тоді зміни в одному класі не будуть впливати на інший клас. До того ж, систему буде зручно розробляти командою програмістів, розподіливши незалежні компоненти між ними. Слабка зв'язаність — якість, до якого потрібно прагнути всіма силами. Але зробити це складніше, ніж здається. Зв'язки між компонентами системи можуть проявлятися різними способами, як явно, так і неявно.

Через деякий час, витрачений на пояснення, Валера подивився на замислене обличчя Ержана і поспішив його заспокоїти: «Не переживай, якщо ти не до кінця розумієш, про що я кажу. Ми в компанії фанати гнучких методик розробки і в проектуванні дотримуємося такого ж підходу. Починаючи із завтрашнього дня ти візьмешся до реальної задачі і поступово будеш відточувати свої навички. А на сьогодні теорії вистачить. Пропоную тобі пройтися по офісу, подивитися, як тут все влаштовано, і познайомитися з людьми.»

Ержан поспішив скористатися порадою Валери. Решту часу він витратив на спілкування зі своїми новими колегами. І кожен з них видавав Ержану порцію нової інформації. Так, він дізнався, що існує магічна абревіатура SOLID, що описує основні принципи об'єктно-орієнтованого проектування. А ще виявляється розумні люди придумали готові рецепти для вирішення різних завдань програмування. Вони називаються патерни проектування. Звичайно, Ержан відразу мало що зрозумів, у нього лише з'явилося стійке бажання у всьому цьому розібратися і навчитися писати крутий софт.

Так пройшов перший день Ержана в його новій компанії. Після того, як годинник показали 18-00, він попрощався з колегами і попрямував додому. Але через кілька хвилин повернувся, взяв із столу «Досконалий код», ще раз махнув всім рукою і вийшов з кабінету.

Продовження слідує…

P. S. Ця початкова стаття із серії статей про тимлида Валеру, стажиста Ержана і гнучке проектування. В наступних статтях буде описаний тернистий шлях, на якому Ержан буде реалізовувати вимоги, писати багато коду і паралельно вивчати принципи гнучкого об'єктно-орієнтованого проектування.

P. P. S. найпершу статтю про Валеру можна знайти на тут.

P. P. P. S. Всі збіги з реальними людьми та подіями вигадані.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.