Велосипедів в нашій справі багато. Найпростіші, найпоширеніші завдання вже хтось зробив до вас — це факт. Кожна з таких завдань може мати мільйон рішень, напевно кожен програміст хоч раз в житті написав власне сортування або якісь інші прості речі. Тому боротьба з велосипедами — винаходом того, що вже безліч разів до вас винайдено — одна з болючих тем в нашій галузі.
Мій особистий лайфхак
За 20 з хвостиком років в програмуванні я прийшов до такого висновку: все вже давно кимось написано. Робота з базою, робота з legacy-системою, робота з UI, робота з призначеним для користувача введенням та інше — все це вже хтось колись написав і, швидше за все, не один раз. Застереження: якщо ми, звичайно, говоримо про поширені мови програмування типу Java, С #, Python і ін. Якщо це тільки що з’явилася мова, то дуже ймовірно, що там ще не написано нічого.
Я дійсно рекомендую працювати на поширеній мові. І не тільки тому, що це простіше і багато вже написано. Працюючи на новому мовою, вам складніше знайти роботу на ринку, у вас невиразна ситуація з майбутнім, доводиться вибирати роботу з того що є, а не те, що подобається. Але повернемося до теми.
Якщо ви працюєте на поширеній мові, немає сенсу писати те, що вже написано. Причому якщо ми розглядаємо С #, то там майже все написано Microsoft, тому ви просто берете вже готове рішення і його імплементіруете. Навіщо винаходити нове колесо? Не потрібно використовувати власне криве рішення, якщо є набагато більш витончене і правильне.
Самостійно ви пишіть тільки те, що стосується бізнес-логіки, предметної області та питань, специфічних для вашої компанії. Це не може бути написано ніким іншим, крім вас.
Спочатку шукаємо готове рішення
Насправді це теж зовсім нетривіальне завдання. Особливо, якщо ви працюєте в кривавому Ентерпрайз і у вас є купа проектів. У багатьох випадках дізнатися, чи не написано там те, що вам потрібно, практично неможливо. Я для себе це питання вирішив наступним чином: питаю сусідів по кімнаті / по поверху, не писали вони щось схоже. Якщо не писали, на цьому пошуки і закінчуються. Тому що шукати те, що могло бути написано 15 років тому – без толку. Якщо говорити про ентерпрайз софт, то в багатьох випадках навіть якщо вирішувалося щось щодо схоже на вашу задачу, це може бути тільки схожим. Може трапитися так, що адаптація цього рішення для вашого завдання вийде дорожче, ніж написати це з нуля.
Якщо ви джуніор-мідл фахівець, то з’ясовувати, чи не написано це кимось — це взагалі не ваша робота. Це вже розмова для фахівців синьйора +, тімліда або архітектора. Чи робимо задачу заново або використовуємо готове рішення — це вже питання архітектурний. Тут є велика кількість підводних каменів, які фахівці нижчого рівня просто не побачать.
Якщо ви синьйор, то вам потрібно навчитися будувати нетворкінг. Ваша результативність як фахівця багато в чому визначається вмінням налагодити контакти з людьми всередині компанії, ніж ваші hard skills. Якщо ви добре перезнайомилися і подружилися з іншими командами, дуже ймовірно, що ви будете вирішувати складні завдання, що вимагають тижнів кодування, набагато швидше. Просто за рахунок того, що знаєте у кого спитати та взяти вже готове рішення, а не писати все заново. Чомусь цей аспект більшість програмістів ігнорують.
📢 Підпишись на наш Ютуб-канал! 💡Корисні відео для програмістів вже чекають на тебе!
🔍 Обери свій курс програмування! 🚀 Шлях до кар’єри програміста починається тут!
Алгоритм дій
- Спочатку перевіряєте, не написаний чи кимось раніше такий функціонал, як вам потрібен. Якщо це робота з чимось поширеним (робота з базою, робота з UI та ін.) – це точно написано, ви не повинні писати це самі. Ви повинні використовувати готовий фреймворк. Поговоріть з командою, якій будете використовувати фреймворк для даного випадку і працюйте з ним.
- Якщо питання пов’язане з бізнес-логікою, з вашої предметною областю і специфічними для вашої компанії речами — запитуємо колег вашого ж проекту, писали вони щось подібне. Якщо немає — пишемо самі.
Підключення мега бібліотек і створення залежностей
Залежності — це погано. Якщо ми говоримо про ентерпрайз — це прям дуже погано. Серйозно. Рішення додати мега бібліотеку і викликати її в один рядок з одного боку заманливо, але при цьому створює купу побічних ефектів. Я взагалі проти використання бібліотек з сумнівною потрібністю. Тому таке рішення ви не повинні приймати самостійно.
Якщо ви фахівець рівня джуніор-мідл, з таким рішенням ви повинні прийти до свого тімліда. Якщо ж ви тімліда або архітектор, то рішення абсолютно на вашій совісті. Ви повинні тверезо зважити, що отримаєте від цієї бібліотеки, скільки це викличе залежностей і наскільки ймовірно, що ці залежності вийдуть вам боком. Також було б добре подивитися, чи не використовував хтось на вашому проекті аналог цієї бібліотеки. Проекти, особливо в Ентерпрайз, тривають по багато років, тому можливо, що у вас вже є залежність на схожу бібліотеку і легше використовувати її. Дуже поширена ситуація, коли в одному проекті знаходяться дві абсолютно аналогічні та конкуруючі між собою бібліотеки. Один програміст вибрав одну, інший — іншу, не подивившись, що одну вже використовують.
