Лично для меня ответ прост и понятен — надо узнать какой цели хотят добиться решением задачи и какой результат ждут. При это сама задача уже не является аксиомой, а только одним из вариантов решения. Надо понимать, что задачи часто приходят от не подготовленных людей, которые могут не знать каких-то тонкостей реализации или особенностей используемой платформы. Если бездумно следовать задаче, то рано или поздно возникнет патовая ситуация, в которой будет страдать как сам разработчик, так и конечный пользователь. Заметьте, даже не постановщик задачи, а конечный пользователь, которому потом надо будет работать с тем, что было реализовано.
Современных молодых, но не менее опытных программистов, отличает уже подход к принятию задачи.
Ради эксперимента иногда отдавал задачу молодому и перспективному сотруднику в виде «как есть», т.е. без «разжёвывания» и декомпозиции. Конечно же такие задачи совсем зеленому и неопытном сотруднику давать нельзя, по понятным причинам. Мидл же должен, в моем понимании, разобраться с тем что надо сделать в задаче и предложить как минимум 1-2 пути решения, возможно отличающихся от того, который описан в задаче. Так же мидл должен уметь самостоятельно собрать недостающую информацию, по другому «изучить предметную область».
Немного отвлекусь. Постановка задачи крайне сложная тема для каждого. Часто постановщик задачи сам не знает чего хочет и какого результата ждет. В 99% случаев это ведет к провалу задачи и негативу со стороны постановщика задачи - "вы не так делаете, вы не понимаете, вам лень работать". Я тут вижу только один выход - быть кремнем и не принимать задачу пока постановщик не поймет, что все таки он ждет. Это сложно, но так делать надо, умные люди поймут и примут такую позицию, а глупые просто забудут про задачу и придумают что-то новое. Жаль не всегда полезное.
За редким исключением эксперимент приводил к одному результату — исполнитель задачи идет за разъяснениями к руководителю. Это правильный путь, но не самый эффективный с точки зрения трудозатрат. При этом исполнитель неосознанно ждет от своего руководителя что то скажет как надо делать задачу и распишет ее как можно подробнее. В этом виден некоторый инфантилизм и нежелание думать. Как раз то, чем грешат молодые мидлы.
Спустя столько воды мы пришли к тому, о чем писал в начале статьи — как же все таки должен думать программист. Особенно это важно понимать когда появляется необходимость разобраться в готовом продукте, который ты видишь первый раз. Да в принципе это касается всего, даже личной жизни.
Условно разделим ход мыслей на несколько частей:
- анализ задачи и попытки выявить конечные потребности (срочно исправить баг или сбой, тоже является конечной потребностью)
- изучение предметной области (читаем код, изучаем воркфлоу, ищем ключевые точки)
- подбор вариантов решения (чем больше вариантов тем выше вероятность ошибиться и выбрать неверный, но и на одном зацикливаться не стоит, он точно так же может быть неверным)
- «примерка» выбранного варианта на свою картину понимания (сложное понятие, картина понимания — это то, как я понял принцип работы продукта и протекающих через него бизнес-процессов)
- уточнение деталей
- реализация
В принципе все. Части надо уточнить и сделать более емкими и понятными.
А теперь давайте остановимся на каждой части подробнее.
Анализ задачи и попытки выявить конечные потребности. Читаем задачу думаем и пытаемся понять что же в итоге хочет получить постановщик задачи. Не всегда это получится сделать сразу, потому что другие люди мыслят по другому, а программисты часто получают «профдеформацию», из-за которой понять ход мыслей «не программиста» сложнее.
Если задача касается каких-либо частей разрабатываемого продукта — лезем туда, «тыкаем» кнопочки и смотрим что происходит, читаем задачу заново, сверяем с тем что видим на экране.
Если задача касается какого-то нового направления или функции, или совсем не касается разрабатываемого продукта, то изучаем бизнес-процесс. Тут базой является бизнес процесс (хотя в первом варианте тоже есть бизнес-процесс, но его не сразу видно).
В результате в голове должен собраться пазл. Не знаю как у других (поделитесь опытом), но у меня в голове сразу возникают возможные варианты решения. Даже минуя период понимания задачи как таковой — если есть варианты решения, значит задачу понял и добился цели этого этапа.
Изучение предметной области. Тут сложнее и проще одновременно. Много думать не надо, надо изучать. На этом этапе мы исследуем сперва бизнес-процесс (в контексте этапа, бизнес-процесс — это среда, в которой будет «работать» задача), потом программные продукты, реализацию существующих частей, окружение, в котором работает код, и зависимости.
Не маловажным является изучение архитектуры приложения (конечно, если ранее с ней не работал, но в любом случает надо посмотреть были ли правки архитектуры, и если были, то какие). Со временем в голове всегда будет находиться архитектура приложения, его внешние зависимости (но это не исключает наличие документации, она должна быть, другого варианта просто нет).
Когда собрали все части предметной области в голове, можно переходить к вариантам решения
Подбор вариантов решения. Будем надеяться, что ранее изучили и узнали все что требуется. Теперь можно начать думать по настоящему. Выбрать правильный вариант пророй бывает крайне сложно. В первую очередь потому что за выбранные вариант надо нести ответственность. Ответственность — самый большой страх практически каждого, увы.
Каждый вариант должен отвечать нескольким требованиям:
- решать задачу
- должен быть реализуем за адекватное время
- не ломать архитектуру приложения
- не вносить «мусор» и лишние «костыли» (ха-ха, «лишние»)
- удобен для использования конечным пользователям
Выбрали варианты? Теперь пробуйте выбрать тот, который окажется полезнее. Тут две крайности — делается быстро, но разовое решение, делается дольше, но универсальное. Надо выбирать что-то среднее. Не закладывайте в код возможности, которые сейчас не нужны, но «возможно потребуются» в будущем. Эти возможности лягут «мертвым грузом» с вероятностью 60-70%. Об этом говорит мой опыт разработки (о ужас, более 14 лет уже о_О).
«Примерка» выбранного варианта на свою картину понимания. А если я сказу, что выбранный вариант неверный? Вы ответите — не может быть! Я же перебрал кучу вариантов, подобрал самый удобный и правильный!
Пусть будет так, но что будет, если начнем его делать? Какова вероятность, что ничего не сломается? Как раз на эти вопросы надо ответить на этом этапе. У ansible есть специальный режим работы, при котором он «проигрывает» плейбук, но не вносит никаких изменений на оборудовании. Dry run. Аналогично надо в голове «проиграть» реализацию, посмотреть на что повлияет. И только после того, как убедились, что вариант не ломает ничего (честно-честно, не ломает) идем дальше. А если все-таки есть шанс сломать — идем назад и ищем еще варианты.
Уточнение деталей. Перед реализацией могут потребоваться какие-то дополнительные данные, примеры. Даже картинки, которые надо куда-то встроить, надо собрать заранее. Если собрал все, что может потребоваться, то вперед — реализация.
На этом этапе надо понимать, что ничего не мешает писать код или проводить другие работы. Сеть работает, лицензии на прикладное ПО живые, стул удобный, кофе налит, свет есть.
Реализация. Наконец-то мы пишем код! Не спешите радоваться, тут свои подводные камни. С высокой долей вероятности при написании кода найдется то, что не учли ни при постановке задачи, ни при выборе вариантов.
Что ж, бывает. Но не стоим на месте и двигаемся дальше. Важно не паниковать. Ответьте на вопрос — новые данные мешают реализации или только вносят уточнение? Если только вносят уточнение, то вам повезло, двигаемся дальше.
А если мешают реализации, то возвращаемся как минимум на три этапа назад, а порой и к самому началу. Правда тут дедлайн — пожар, не успеваем, все сгорит!
Как раз этого варианта боятся многие и не могу принять ответственность за выбранный вариант реализации.
Не торопимся и делаем как надо, а не как заставляют.
