Junior и методы рационального мышления

Многое, что кажется совершенно очевидным для опытного разработчика, оказывается неочевидным для начинающего. Я не говорю про написание кода, знание паттернов и тп. Это касается способа мышления ^[1] в целом: как решить проблему, как спросить, как не вызвать гнев наставников своих старших. Сегодня попробуем поговорить об этом.

Методы рационального мышления ^[1] (здесь) — это вопросы, которые стоит задавать на каждом этапе обдумывания проблемы. С их помощью можно быстрее прийти к правильному решению и эффективнее построить свою работу.

Вопрос 1. В чём причина?

По закону подлости, при первом запуске приложения что-то обязательно не будет работать. Для начала стоит попробовать самостоятельно определить причину ошибки. Самый простой способ — посмотреть в консоль. Возможно, текста ошибки будет достаточно, чтобы понять как её исправить.

Вопрос 2. Сделал ли я всё, что мог?

Даже если текст ошибки не помог, не стоит спешить к людям с вопросом. Для начала нужно убедиться, что было сделано всё, что возможно. Проверить можно примерно по такому списку:

1. Я проверил документацию приложения на предмет решения этой проблемы
2. Я погуглил и ничего не нашёл
3. Я погуглил на английском языке и ничего не нашёл
4. Ни один из найденных советов мне не помог

Если везде ответ положительный, то переходим к следующему пункту.

Вопрос 3. Кажется, я озадачен. Почему?

Нет ничего страшного в том, чтобы спросить у своего ментора/наставника/начальника/друга о решении проблемы. Возможно, вам просто забыли про неё рассказать. Однако вопрос не должен состоять только из слов «что-то не работает», в него следует вложить все имеющиеся входные данные. Грамотно построенный вопрос экономит время вашего наставника и помогает работать эффективнее. Попробуйте проверить вопрос на «полноту»:

1. Указан текст ошибки
2. Указан кейс, при котором вы столкнулись с ошибкой (вплоть до команд запуска)
3. Указаны испробованные методы решения

Profit! В кратчайшие сроки вы получите решение проблемы и глубокое уважение от коллег. Итак, вперёд к разработке задач.

Вопрос 4. Моё решение полностью решает проблему?

Теперь поговорим о том, чем стоит завершать выполнение любой задачи. Подсказка: правильным вопросом самому себе.

Если это баг, то стоит проверить: проблема исправлена или замаскирована? Например, есть функция, которая должна возвращать число, но она (внезапно) возвращает строку. Преобразованием результата в месте вызова функции можно замаскировать проблему. Но, возможно, стоит сделать преобразование внутри неё и тем самым исправить проблему окончательно.

Фича или баг, не поленитесь в конце проверить все возможные кейсы. Как показывает практика, фраза «должно работать» вызывает страшные баги и ещё более страшное недовольство с принимающей стороны.

Вопрос 5. Почему я уверен в этом?

Сразу же разберём пример: настало время интегрировать разные части большого приложения. Бекенд, связанный с задачей джуниора, был давно разработан. Он запускает фичу на своей стороне и… все виснет! Довольно быстро он определяет, что завис бекенд. Можно было бы сразу сказать: «Проблема не на моей стороне», скинуть задачу и пойти по своим делам. Но Рациональный джуниор подумает: «Если задача бекенда помечена как завершённая, вероятно, её протестировали. Почему я уверен, что проблема в бекенде?». И буквально через полчаса выяснит, что отправляет данные в бесконечном цикле.

Вопрос 6. Почему это было сделано?

Стоит принять за данность, что вокруг работают разумные люди и глупости писать не станут (по крайней мере, нарочно). Когда кажется, что кем-то написаная строчка в коде лишняя, стоит десять раз подумать перед её удалением. Даже если это полностью решает поставленную проблему. Самые вероятные способы ничего не пропустить:

1. Посмотреть последний commit message с изменением этой строки
2. Посмотреть привязанную к commit задачу (часто указывается в commit message)
3. Посмотреть кто делал commit и спросить у него, предварительно рассказав про свою задачу

В заключение хочу добавить одно: не обязательно следовать всем заветам из этой статьи, но обязательно думать постоянно и думать самостоятельно.

Автор: markitosha

Источник ^[2]