Робота в реальному проекті: поради програмістам-початківцям

5 січня
Олег Мерінов, Senior Development TeamLeader
Робота в реальному проекті: поради програмістам-початківцям
На роботі я багато спілкуюся з інтернами та джуніорами — вчорашніми студентами, які приходять у проектні команди з університетів. Влаштовуються інженерами, а досвіду не мають. Протягом багатьох років я помічав, що проблеми, з якими вони стикаються на перших етапах, одні й ті самі.

У своїй статті для Tproger я вирішив розповісти про деякі важливі моменти, які доводиться обговорювати чи не з кожним, хто поки не займався ніякими проектами, крім навчальних. Я спеціалізуюся на .NET, але ці поради цілком можна застосувати до будь-якої мови, хоч до Java, хоч до Python. Адже всі ми маємо зробити одне й те саме: написати, протестувати, зарелізити та підтримувати.

ОЦІНКА ВИМОГ

Згадую себе студентом: ледь отримавши задачу, я сідав кодити. Думаю, це нормально, а вже для студента просто природно — кидатись у бій, тільки тримавши умову. Але краще спочатку задуматися про те, чого від вас хочуть — неважливо, лабораторна це чи ваша частина комерційного проекту.

  • Важливо уважно прочитати умови задачі та вислухати коментарі керівника або старшого колеги

Багато хлопців, зокрема талановитих, добре пораються з будь-якими навчальними завданнями, швидко схоплюють суть і вважають, що добре зрозуміли, що потрібно зробити. Вони рухаються далі, концентруються на деталях, а коли приходять за два дні (добре) чи тиждень (гірше), з'ясовується, що написаний ними код не працює чи працює не так, як потрібно.

  • Не соромтеся ставити запитання

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

Коли ви зрозуміли задачу і навіть знайшли ідеальне рішення — поділіться ним, розкажіть алгоритми, які спали вам на думку. Реакція старшого колеги відразу підтвердить чи спростує вашу здогадку, дасть підґрунтя для подальшого дослідження.

  • Діліться своїми ідеями

Це теж суперечить шкільному стереотипу: відмінникам категорично не можна давати списувати. І багато молодих інженерів за звичкою бояться розповісти, що вони придумали. Але тільки отримавши відгук на свій варіант розв’язання, ви розширюєте картину світу — можливо, це дозволить подивитись на задачу з іншого, потрібного вам боку.

  • Дізнайтеся про обмеження

У реальному проекті це може виявитися чи не найголовнішим. Запитайте, скільки даних надходитиме на вхід застосунку, яке планується навантаження. Така інформація допоможе і при проектуванні рішення, і при його здачі.

  • Ще одна порада: робіть блок-схеми.

Зізнайтеся, ви ж їх не малюєте? Я знаю, багато хто впевнений, усе це сортування “бульбашкою” — просто дурниці. Насправді в майбутньому це допоможе вам, бо схематичний опис рішення дозволить дуже швидко донести до колег вашу ідею.

Що простіше: зобразити схему з трьома блоками та зв'язками між ними чи списати половину аркуша А4? До того ж, картинку простіше сприймати, а читати довгі тексти нікому не хочеться.

  • Зверніть увагу на UML — мову, якою можна писати і фізичні моделі бази даних, і концептуальні моделі, і діаграми послідовності викликів, і багато іншого.

ОЦІНКА СКЛАДНОСТІ

Про оцінку складності часто забувають, а згадують лише тоді, коли при виході у продакшен звалюються величезні обсяги даних і продуктивнисть системи просідає.

Ґрунтуючись на блок-схемах, діаграмах послідовності викликів і компонентів, існуючих обмеженнях, ви можете оцінити складність задачі.

РОЗРОБКА

Головне запитання: як писати? Один проджект-менеджер висловився досить точно: “Треба писати без багів завжди”. І тут найголовніше: naming convention і code style.

  • Naming convention — угода про імена

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

  • Code style — стандарт оформлення коду

Тій самій меті служить і стиль оформлення коду, необхідний для уніфікації. Програмний код, розроблений різними людьми, має читатися так, ніби його написав один програміст. Тому прийшовши у проект, у першу чергу потрібно зрозуміти, які naming convention і code style тут використовують. Пам'ятайте, що суворе їх дотримання є також знаком поваги до колег, який вони обов'язково оцінять.

Var — хороша практика, що дозволяє будь-якому розробнику читати код з листа. Проте багато компаній роблять для проектів власні конвенції. Але для проекту, що запускається, простіше за все взяти готові конвенції. Зараз багато спільнот і компаній їх публікують, є навіть цілі бібліотеки, де можна перевірити код на помилки стилю. У своїх прикладах Microsoft продає велосипеди, а я буду рахувати податки.

article img
  • Пишіть простий код!

Елементарна порада, дотримуватися якої дуже складно. Якщо інженер не до кінця продумав виконання задачі, не зміг зробити декомпозицію (не розбив задачу на складові частини) — у методі ми бачимо 500 рядків коду. Це не так страшно, але важливо повернутися назад і подумати над декомпозицією ще раз.

Чому код має бути простим? Зараз код маєте тільки ви і, можливо, викладач. Потім ним володітиме велика команда, якій потрібно розбиратися в його нюансах із максимально можливою швидкістю.

  • Щоб код став простіше, потрібно ввести слабку зв'язаність компонентів

Уявіть, ви написали складний код, повернулися, розбили на складові частини. У прикладі з податками в мене є якийсь клас, що рахує суму податку. Я розбив на клас, який представляє працівника, і на клас, який у залежності від адреси чи іншої логіки повертає відсоток податку — це приклад слабкої зв'язаності. Але можна ввести додаткові елементи, наприклад, інтерфейс для класу taxEvaluator для employee.

Що таке IoC?

article img

Цей патерн називається Inversion of control. У мікросервісах слабка зв'язаність призводить до масштабування системи. Коли у нас є інтерфейс, ми можемо ізолювати наш основний клас із логікою та протестувати його.

  • Коментар — це важливий і корисний елемент роботи.

Коли ви пишете складний алгоритм, коментарі допоможуть зрозуміти, що там узагалі відбувається, особливо вони важливі для регулярних виразів. Я пишу регулярний вираз, а за 15 хвилин забуваю, що він робить.

  • Перевіряйте аргументи.

Це розповсюджена проблема молодих інженерів: вони впевнені, що все написали чітко і перевірок написане ними не потребує. Але це не так!

article img

У цьому прикладі ми викидаємо виняток, але не завжди маємо це робити.

Взагалі виняток — це особлива тема. Щоб зрозуміти, що з ним робити, можна почитати “Програміст — прагматик” Дейва Томаса та Енді Ханта. Книга стара, але дуже цікава, там хороші і здорові ідеї, коли викидати, коли ні, коли вважати, що це помилка бізнес, а не програмного рівня. Але в нас tax evaluator = null — це ключова функціональність і без неї ми працювати не можемо, тому викидаємо виняток.

Коли до нас приходить порожній об'єкт із працівником — employee, то ми знову нічого не можемо зробити, бо на цьому зав'язана вся логіка.

  • Винятки потрібно обробляти
article img

“Try catch” необхідно використовувати або з типізованими винятками, або коли ми не знаємо, яке виключення прилетить. Треба залогувати, але ні в якому разі не повертати такі конструкції.

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

Можна прибрати “try catch”, обробити виняток як бізнес-кейс і логувати. Записуйте в логи хід виконання ваших алгоритмів і програм, тому що під час розробки ваш софт доступний через дебагер і ви завжди можете подивитись, що відбувається. Але коли виняток іде туди, куди ви не маєте доступу, то тільки логи можуть вам допомогти.

UNIT TEST

Розробник має писати юніт-тести. Зрозуміло, чому цим не займаються, але писати їх варто. Подивіться на методики написання юніт-тестів — коли ви робитимете власні, то інакше проектуватимете ваші рішення, програми і задачі.

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

ЗБІРКА, ДЕПЛОЙ, КОНФІГУРАЦІЯ

article img

Що ми робимо після того, як щось написали? Ми робимо збірку, потім зібрані елементи десь зберігаємо, потім деплоїмо.

Це цикл життя від моменту створення до деплоя, і цей код використовуватиме кінцевий користувач. Я написав, які інструменти можна використовувати: створити автоматичну збірку можна за допомогою PowerShell і msbuilt; зберігати — у ProGet, і далі ми можемо деплоїти отримані пакети. Це трохи складно.

РОБОТА НАД ПОМИЛКАМИ, ЗМІНА ВИМОГ

Ми все зрозуміли, все запрограмували, протестували, віддали, а замовник каже: все не те.

Що робити? Повертатися до самого початку і питати: що не так? Якщо змінилися вимоги — уточнити їх та пропрацьовувати далі.

ЩО ПОЧИТАТИ?

  • Брайан У. Керніган, Денніс М. Рітчі “The C Programming Language” — досить стара. Вона справила на мене велике враження. Багато в чому не про мову програмування, а про правильний майнд-сет.
  • Макконнел “Code Complete” — маст-рід.
  • Дейв Томас, Енді Хант “The Pragmatic Programmer”.
  • Альфред Ахо “Data Structures and Algorithms” — занудна, завжди, коли читаю, засинаю. Так, вона читається складно, але вона дуже класна.
  • Джон Влісідіс, Ральф Джонсон, Ричард Хелм, Еріх Гамма “Design Patterns” — книга для тих, хто планує писати об'єктно-орієнтованими мовами програмування. Вона теж задає правильний майнд-сет. Коли я просто читав, то нічого не зрозумів, але коли почав працювати, перечитав, і книга почала допомагати.
  • Мартін Фаулер “Catalog of Patterns of Enterprise Application Architecture” — про архітектуру додатків. Фаулер вніс величезний внесок в індустрію, написав різні патерни, на основі яких створено багато ПЗ.