Недавно запущенные проекты на Хекслете очень хорошо показывают системные ошибки начинающих разработчиков. В этой статье я описал некоторые паттерны, следование которым поможет решать задачи быстрее и лучше.
Помощь друга
Тупить над задачей, когда ты не знаешь с какой стороны подступиться — это нормально. Но главное — вовремя останавливаться. Если время анабиоза затягивается больше, чем на один день, то пришло время попросить помощь друга. Идеально, если рядом с вами есть старший товарищ, которому можно задать вопрос. Если нет, то в сети полным полно мест (например, наше сообщество в Telegram), где вам могут подсказать и сдвинуть с мертвой точки.
Будучи руководителем, я всегда прошу своих разработчиков (в первую очередь начинающих), не тратить больше 2 часов на задачу. И если они не могут сдвинуться с места, то сигнализировать о проблеме.
Начинающие разработчики часто стесняются спрашивать помощи и не хотят выглядеть глупо (в реальности глупо не спрашивать помощи), а некоторые считают, что это непрофессионально. При этом я, как стейкхолдер, наоборот, хочу получать обратную связь как можно быстрее. В итоге, чем больше человек уходит в себя, тем больше приходится контролировать процесс, что создает сложности всем.
В моей практике были случаи, когда именно эта проблема становилась причиной увольнения.
Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика
От простого к сложному
Главный тезис звучит так: “Не делай сложного, пока не заработало простое”.
На протяжении многих лет я наблюдаю одну и ту же картину. Зеленый разработчик решает задачу гораздо быстрее опытного только потому, что двигается небольшими шагами, добавляя новые возможности только после того, как он заставил работать то, что проще.
Почему так происходит?
- Классическая недооценка сложности, программисты законченные оптимисты
- Быстрое рабочее решение — это быстрая обратная связь. Использование написанного решения почти моментально дает пищу для размышления, указывает на ошибки и недостатки архитектуры.
Заметьте, что это никак не противоречит тезису о том, что над архитектурой нужно думать. Думать нужно, но осторожно. Чем больше вариантов использования вы начинаете придумывать, тем ниже ваши шансы на то, что задача вообще будет сделана. С опытом это меняется. Многие задачи раскладываются в голове автоматически, и вы уже знаете, как нужно делать, но в начале пути такого не будет.
Пока я писал этот абзац, меня осенило. Последний год я активно занимаюсь скалолазанием (в основном, боулдеринг). И у скалолазов есть такое понятие, как “разложить трассу”. То есть спортсмен смотрит на трассу и прикидывает, как он ее преодолеет. Чем более опытен скалолаз, тем лучше он это делает. Так вот, многие скалолазы говорят о том, что понимание того, как разложить трассу (без пролезания) начало приходить к ним через многие годы тренировок и совершенных ошибок.
Стоя на плечах гигантов
Писать свои велосипеды во время обучения — это прекрасно. Делать тоже самое в промышленном программировании — это дорога в ад. Предлагаю пошаговую инструкцию как правильно реализовывать новую задачу, которая вполне может звучать как “написать функцию”:
- Первым делом нужно изучить стандартную библиотеку языка. Как минимум, посмотреть список входящих в нее функций и модулей. Очень часто там уже есть то, что нужно для наиболее простых задач.
- Посмотреть стороннюю библиотеку, решающую эту задачу. Если вы не очень хорошо понимаете, что вам нужно, то ищите через Гугл ссылки на Stackoverflow. Там, скорее всего, есть ответ. Кстати, искать надо по-английски, на русском шансов на успех почти нет. Если вы понимаете задачу, то в гугл надо вбивать следующий запрос:
github <language> <keyword>. Например, для поиска парсераiniфайлов вnodejs, нужно вбить следующее:github nodejs ini parser. - Если первые два пункта не дали результата, поискать подобную библиотеку в языке, который считается наиболее продвинутым в данной области (или просто знаком вам).
Этот принцип я применяю в своей жизни гораздо шире, чем описано выше. При построении любой системы я сначала изучаю то, как делают лучшие. Например, это касается организации серверной инфраструктуры, мониторинга, работы с ошибками. Человек, который никогда не видел сервисов, подобных AWS и Datadog, вряд ли самостоятельно дойдет до тех решений, которые используют эти сервисы.
Стейкхолдеры
Что такое "идеальное решение", и чем оно отличается от универсального решения?
Универсальное решение — это мечта многих программистов. Писать софт так, чтобы он учитывал все возможные теоретически варианты использования, был максимально гибок и расширяем. Думаю, что для многих есть причинно-следственная связь “универсальное решение” -> “идеальное решение”.
На самом деле так писать софт не только не нужно, но и вредно. У любой задачи (если она не for fun), есть заказчик, он же cтейкхолдер. Стейкхолдеры обеспечивают возможности для системы и являются источником требований для системы. Следовательно, идеальность решения можно рассматривать только на основе обратной связи от стейкхолдеров. А для них идеальное решение это то, которое максимально соответствует требованиям, причем не только с точки зрения конечного результата, но так же и с точки зрения затраченных ресурсов.
Теперь пара очевидных выводов:
- Варианты использования, которых не было в требованиях, нужно обсуждать, а не кодировать с их учетом (универсально же!)
- Если при реализации всплывают неучтенные моменты, их также нужно обсуждать, а не принимать решения самостоятельно (если нет договоренностей о другом поведении).
