Многое, что кажется совершенно очевидным для опытного разработчика, оказывается неочевидным для начинающего. Я не говорю про написание кода, знание паттернов и тп. Это касается способа в целом: как решить проблему, как спросить, как не вызвать гнев наставников своих старших. Сегодня попробуем поговорить об этом.
Методы рационального (здесь) — это вопросы, которые стоит задавать на каждом этапе обдумывания проблемы. С их помощью можно быстрее прийти к правильному решению и эффективнее построить свою работу.
Вопрос 1. В чём причина?
По закону подлости, при первом запуске приложения что-то обязательно не будет работать. Для начала стоит попробовать самостоятельно определить причину ошибки. Самый простой способ — посмотреть в консоль. Возможно, текста ошибки будет достаточно, чтобы понять как её исправить.
Вопрос 2. Сделал ли я всё, что мог?
Даже если текст ошибки не помог, не стоит спешить к людям с вопросом. Для начала нужно убедиться, что было сделано всё, что возможно. Проверить можно примерно по такому списку:
- Я проверил документацию приложения на предмет решения этой проблемы
- Я погуглил и ничего не нашёл
- Я погуглил на английском языке и ничего не нашёл
- Ни один из найденных советов мне не помог
Если везде ответ положительный, то переходим к следующему пункту.
Вопрос 3. Кажется, я озадачен. Почему?
Нет ничего страшного в том, чтобы спросить у своего ментора/наставника/начальника/друга о решении проблемы. Возможно, вам просто забыли про неё рассказать. Однако вопрос не должен состоять только из слов «что-то не работает», в него следует вложить все имеющиеся входные данные. Грамотно построенный вопрос экономит время вашего наставника и помогает работать эффективнее. Попробуйте проверить вопрос на «полноту»:
- Указан текст ошибки
- Указан кейс, при котором вы столкнулись с ошибкой (вплоть до команд запуска)
- Указаны испробованные методы решения
Profit! В кратчайшие сроки вы получите решение проблемы и глубокое уважение от коллег. Итак, вперёд к разработке задач.
Вопрос 4. Моё решение полностью решает проблему?
Теперь поговорим о том, чем стоит завершать выполнение любой задачи. Подсказка: правильным вопросом самому себе.
Если это баг, то стоит проверить: проблема исправлена или замаскирована? Например, есть функция, которая должна возвращать число, но она (внезапно) возвращает строку. Преобразованием результата в месте вызова функции можно замаскировать проблему. Но, возможно, стоит сделать преобразование внутри неё и тем самым исправить проблему окончательно.
Фича или баг, не поленитесь в конце проверить все возможные кейсы. Как показывает практика, фраза «должно работать» вызывает страшные баги и ещё более страшное недовольство с принимающей стороны.
Вопрос 5. Почему я уверен в этом?
Сразу же разберём пример: настало время интегрировать разные части большого приложения. Бекенд, связанный с задачей джуниора, был давно разработан. Он запускает фичу на своей стороне и… все виснет! Довольно быстро он определяет, что завис бекенд. Можно было бы сразу сказать: «Проблема не на моей стороне», скинуть задачу и пойти по своим делам. Но Рациональный джуниор подумает: «Если задача бекенда помечена как завершённая, вероятно, её протестировали. Почему я уверен, что проблема в бекенде?». И буквально через полчаса выяснит, что отправляет данные в бесконечном цикле.
Вопрос 6. Почему это было сделано?
Стоит принять за данность, что вокруг работают разумные люди и глупости писать не станут (по крайней мере, нарочно). Когда кажется, что кем-то написаная строчка в коде лишняя, стоит десять раз подумать перед её удалением. Даже если это полностью решает поставленную проблему. Самые вероятные способы ничего не пропустить:
- Посмотреть последний commit message с изменением этой строки
- Посмотреть привязанную к commit задачу (часто указывается в commit message)
- Посмотреть кто делал commit и спросить у него, предварительно рассказав про свою задачу
В заключение хочу добавить одно: не обязательно следовать всем заветам из этой статьи, но обязательно думать постоянно и думать самостоятельно.
Автор: markitosha
