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