«Давайте на всякий случай создадим микросервисы».
Мы все думаем, что мы программисты выше среднего. И, возможно, в колледже я чуть не провалил статистику, но что-то мне подсказывает, что это не так. Большинство из нас, вероятно, ходит с некоторой степенью бессознательной некомпетентности. Мы не знаем того, чего не знаем. Таким образом, мы ошибочно закрыты для некоторых советов, которые на самом деле весьма полезны.
За прошедшие годы я слышал некоторые крупицы мудрости, которые в тот момент казались смешными. Но через некоторое время я понял, что они выдерживают критику. Вот одни из лучших.
1. «Не торопитесь, напишите спецификацию».
Я обычно слышал это от людей, работающих над более крупными проектами, чем мой. Люди с гораздо более длительным сроком выполнения заказа. Так что я почти сразу отклонил это. Я думал, что правильное планирование - это роскошь, которую я не мог себе позволить. Особенно в таком стартапе, как наш. Я думал, что это предназначено для фирм, занимающихся производством корпоративного программного обеспечения, которые создают что-то с помощью Angular или чего-то подобного.
Но это далеко от истины. Все мы могли бы выиграть от усовершенствования дизайна. Потому что чем дольше вы решаете, что построить, тем больше у вас шансов сделать это правильно. Или, по крайней мере, не строить то, что вам не нужно.
Что бы очень помогло нам в недавнем проекте. Поскольку мы спешили с выходом на рынок, мы выбрали архитектуру, которая была гораздо более распределенной, чем это было необходимо. Другими словами, мы построили микросервисы вместо того, чтобы строить монолит. Это не только увеличило время вывода продукта на рынок, но и время, необходимое для внесения каких-либо изменений в дальнейшем. Простое исправление ошибки? Уже нет. Не тогда, когда вам нужно следить за журналом сбоев через три разных сервиса.
Так что не спешите писать спецификации - это почти всегда хорошая идея. Это просто мудрее альтернативы. Потому что в конечном итоге вы с большей вероятностью сэкономите больше времени благодаря более разумным решениям, которые вас заставляют принимать спецификации.
2. «Постройте как можно скорее».
Эти уроки полны противоречий. С одной стороны, я слышал, что написание спецификации может занять столько времени, сколько потребуется. С другой стороны, я слышал, что вам нужно как можно быстрее вынести что-то за дверь. Особенно в компании стартапов. Так что же дает?
Не имеет смысла так быстро пачкать руки, потому что трудно принимать рациональные решения относительно того, что вы строите. Когда вы продвигаетесь так быстро, вы пишете код как реакцию, а не действие. Похоже, это единственное, чего вам, вероятно, не следует делать.
Опять же, я узнал правду об этом на собственном горьком опыте. На самом деле технологии не существуют изолированно. Обычно это связано с бизнесом. И у бизнеса тоже есть ограничения на продукт. Такие вещи, как время, которые обычно не рассматриваются с чисто технической точки зрения, также имеют значение.
Мы находимся в процессе разработки инструмента моделирования торговой стратегии Chartmaster. Разрабатывается уже несколько месяцев. А несколько недель назад мы начали создавать контент, чтобы привлечь внимание к его скорому запуску. И, к удивлению никого, кроме нас, разговоры о вашей работе в Интернете на самом деле привлекают ценные отзывы. Настолько ценно, что в ответ мы обновляем дорожную карту каждые две недели.
То, что мы должны были сделать, было отправлено на рынок несколько месяцев назад. Самолетом из изоленты. Не имело бы значения, содержит ли он ошибки или не доработан. Это золото - это обратная связь. Таким образом, мы с самого начала включили в продукт реальный спрос. Дело не в том, что завершение разработки сначала не работает. Просто время важно в контексте бизнеса. Дело не только в коде. Это также касается маркетинга, контента, формирования аудитории и других факторов, которые предположительно имеют такое же значение, как и код.
3. "Сделайте это красиво".
Это больше связано с дизайном или бизнесом, чем с кодированием. Но это, наверное, самый увлекательный совет в этом списке. Я много раз слышал от многих людей, что важно, чтобы продукт казался «законным». Необязательно работать идеально. До тех пор, пока опыт кажется утонченным.
Для такого инженера, как я, это звучало бессмысленно по понятным причинам. Разве не лучше иметь чистый, хорошо протестированный, хорошо документированный код? Разве не важнее заставить его работать? Оказывается, клиенты не замечают технического мастерства напрямую. Но они действительно ощущают внешний вид конечного продукта.
Как бы бессмысленно это ни звучало, регулярно тратить время на полировку внешнего вида продукта, даже если это еще не сделано, - неплохая идея. Не только в том случае, если вы это демонстрируете или выпускаете раньше. Но даже внутренне наличие чего-то, что кажется законным, меняет мышление команды. Заставляет их чувствовать, что они не просто возятся в комнате общежития колледжа.
4. «Если есть сомнения, скопируйте».
Инновации - это главное в программном обеспечении. Либо это? По правде говоря, вам не нужно писать каждый фрагмент кода, как Uber. На самом деле, Uber, вероятно, не изобретал велосипед каждый раз на заре своего существования. В большинстве случаев то, что мы хотим построить, уже было построено раньше. И, вероятно, есть книга или доклад, в котором рассказывается, как именно это сделать.
Но сложно отделить свою ценность как инженера от изобретательности того, что вы разрабатываете. И я уверен, что я не одинок в этом. Поэтому большую часть своей карьеры я настаивал на технической гимнастике, просто чтобы доказать, что могу. При этом не хватает того, что лучшие решения обычно самые простые.
Так что, если вы застряли, оглянитесь вокруг. Скопируйте и вставьте от кого-то другого. На самом деле, даже если вы не застряли, оглянитесь вокруг. Зачем тратить драгоценное время на дизайн, если его уже разработал кто-то другой? Особенно, если вы просто пытаетесь решить проблему. Вы будете удивлены, как далеко вы сможете продвинуться, просто объединив лучшее, что уже сделали другие.
