Как стать автором
Обновить

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

ПрограммированиеGTD
Из песочницы

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


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


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


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


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


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


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

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


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


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


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

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


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


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


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


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


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


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


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


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


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

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


Теги:советы начинающим программистам
Хабы: Программирование GTD
Всего голосов 23: ↑21 и ↓2 +19
Просмотры16.1K

Похожие публикации

Лучшие публикации за сутки