Самый простой способ найти «правильное» решение - быстро избавиться от плохих.
Проектная документация. Документы с требованиями к продукту (PRD). Диаграммы топологии. Диаграммы UML. Список можно продолжать и продолжать, но в какой-то момент своей карьеры вы, вероятно, сталкивались с одним из них или работали над ним.
Вместо того, чтобы тратить время на создание функциональных возможностей или создание вещей, вы проводите бесчисленные часы и собрания, обсуждая и планируя. Труд возрастает, когда вы мучитесь над потенциальными интерфейсами и возможными взаимодействиями.
Вам следует тратить на это меньше времени.
Намного меньше.
Вместо этого вам следует сделать следующее: Исследовательское программирование.
Я не придумывал этот термин. Об этом я узнал изначально от Sandi Metz. Если вы не слышали о Санди, она блестящий инженер, оратор и писатель, написавшая книгу Практический объектно-ориентированный дизайн: Agile Primer Using Ruby (POODR).
Сэнди рассказывает о концепции исследовательского программирования в POODR и объясняет, как с ее помощью вы можете стать лучше и эффективнее разработчика. Писая больше кода быстрее и бросая вещи в стену, чтобы увидеть, что прилипнет, вы быстрее создаете функциональные вещи.
Требования могут измениться на полпути к написанию первых нескольких функций или методов, так зачем тратить так много времени на их составление, прежде чем писать?
Код бесплатный.
Вы можете писать страницы и страницы, а затем все это выбросить. Неважно. Не обращайте внимания на свой код (еще одно из учений Сэнди).
Что обычно происходит с длительными процессами планирования, так это то, что после того, как вы закончите и будете готовы приступить к программированию, вы тратите больше времени на написание шаблонных классов и модулей, чем на фактическую функциональность.
Что-то, что я начал делать с новыми функциями, я называю написание своего пути.
Проведите прямую линию от самого начала проекта до точки, в которой вы создадите базовый функциональный прототип.
Пишите только тот код, который доставит вас (или, как вы думаете, доставит вас) из пункта А в пункт Б.
По сути, это сводится к тому, что вы пишете вещь как можно быстрее с минимальным количеством кода (независимо от того, насколько дерьмово это выглядит), пока она не заработает.
Некоторые люди называют это MVP или минимально жизнеспособным продуктом, и это нормально, но с одним отличием состоит в том, что написание своего пути требует большего давления. MVP по-прежнему включает этапы планирования и проектирования. Проложить себе путь - это как выстрел из дробовика.
Вот еще одна аналогия:
У вас закончились боеприпасы для вашего программного ружья, и теперь вы используете его как прославленный мушкетон. Загрузите в него любой код, который может работать как снаряд, и выстрелите в общем направлении прототипа.
Каждый раз, когда вы хотите остановиться и провести рефакторинг некоторых функций или потратить несколько минут, чтобы СУШИТЬ какой-то код, остановитесь!
Представьте, что вас буквально преследуют зомби (или менеджеры проектов) с таблицами и диаграммами. У вас нет времени перезагружать. Вы должны заставить что-то работать сейчас. Вы можете перестать дышать (дизайн) позже.
Я не говорю, что все планирование и дизайн - это плохо, в некоторых случаях может быть чрезвычайно полезно потратить немного времени на размышления об интерфейсах и взаимодействиях. Главное здесь - использовать его как инструмент и не тратить на это слишком много времени. Это полезность, а не барьер для входа.
Всегда помните: напишите по-своему .
Чтобы узнать больше о мудрости Сэнди Мец, прочтите эту замечательную статью Кевина Кима, в которой есть одни из лучших цитат!
