Многое, что кажется совершенно очевидным для опытного разработчика, оказывается неочевидным для начинающего. Я не говорю про написание кода, знание паттернов и тп. Это касается способа мышления в целом: как решить проблему, как спросить, как не вызвать гнев наставников своих старших. Сегодня попробуем поговорить об этом.
Методы рационального мышления (здесь) — это вопросы, которые стоит задавать на каждом этапе обдумывания проблемы. С их помощью можно быстрее прийти к правильному решению и эффективнее построить свою работу.
Вопрос 1. В чём причина?
По закону подлости, при первом запуске приложения что-то обязательно не будет работать. Для начала стоит попробовать самостоятельно определить причину ошибки. Самый простой способ — посмотреть в консоль. Возможно, текста ошибки будет достаточно, чтобы понять как её исправить.
Вопрос 2. Сделал ли я всё, что мог?
Даже если текст ошибки не помог, не стоит спешить к людям с вопросом. Для начала нужно убедиться, что было сделано всё, что возможно. Проверить можно примерно по такому списку:
- Я проверил документацию приложения на предмет решения этой проблемы
- Я погуглил и ничего не нашёл
- Я погуглил на английском языке и ничего не нашёл
- Ни один из найденных советов мне не помог
Если везде ответ положительный, то переходим к следующему пункту.
Вопрос 3. Кажется, я озадачен. Почему?
Нет ничего страшного в том, чтобы спросить у своего ментора/наставника/начальника/друга о решении проблемы. Возможно, вам просто забыли про неё рассказать. Однако вопрос не должен состоять только из слов «что-то не работает», в него следует вложить все имеющиеся входные данные. Грамотно построенный вопрос экономит время вашего наставника и помогает работать эффективнее. Попробуйте проверить вопрос на «полноту»:
- Указан текст ошибки
- Указан кейс, при котором вы столкнулись с ошибкой (вплоть до команд запуска)
- Указаны испробованные методы решения
Profit! В кратчайшие сроки вы получите решение проблемы и глубокое уважение от коллег. Итак, вперёд к разработке задач.
Вопрос 4. Моё решение полностью решает проблему?
Теперь поговорим о том, чем стоит завершать выполнение любой задачи. Подсказка: правильным вопросом самому себе.
Если это баг, то стоит проверить: проблема исправлена или замаскирована? Например, есть функция, которая должна возвращать число, но она (внезапно) возвращает строку. Преобразованием результата в месте вызова функции можно замаскировать проблему. Но, возможно, стоит сделать преобразование внутри неё и тем самым исправить проблему окончательно.
Фича или баг, не поленитесь в конце проверить все возможные кейсы. Как показывает практика, фраза «должно работать» вызывает страшные баги и ещё более страшное недовольство с принимающей стороны.
Вопрос 5. Почему я уверен в этом?
Сразу же разберём пример: настало время интегрировать разные части большого приложения. Бекенд, связанный с задачей джуниора, был давно разработан. Он запускает фичу на своей стороне и… все виснет! Довольно быстро он определяет, что завис бекенд. Можно было бы сразу сказать: «Проблема не на моей стороне», скинуть задачу и пойти по своим делам. Но Рациональный джуниор подумает: «Если задача бекенда помечена как завершённая, вероятно, её протестировали. Почему я уверен, что проблема в бекенде?». И буквально через полчаса выяснит, что отправляет данные в бесконечном цикле.
Вопрос 6. Почему это было сделано?
Стоит принять за данность, что вокруг работают разумные люди и глупости писать не станут (по крайней мере, нарочно). Когда кажется, что кем-то написаная строчка в коде лишняя, стоит десять раз подумать перед её удалением. Даже если это полностью решает поставленную проблему. Самые вероятные способы ничего не пропустить:
- Посмотреть последний commit message с изменением этой строки
- Посмотреть привязанную к commit задачу (часто указывается в commit message)
- Посмотреть кто делал commit и спросить у него, предварительно рассказав про свою задачу
В заключение хочу добавить одно: не обязательно следовать всем заветам из этой статьи, но обязательно думать постоянно и думать самостоятельно.
Комментарии (10)
xcore78
20.11.2018 23:28В этом алгоритме не хватает очень важного шага:
«Если мне ничего не помогло за полчаса, я должен обратиться за помощью».
Иначе можно всю жизнь прожить, предполагая, что «вокруг работают разумные люди и глупости писать не станут». В оригинале, на который негласно ссылается автор своим заголовком, учили проверять гипотезы.markitosha Автор
21.11.2018 10:42Действительно, наверное стоит добавить этот шаг явно) Я не предлагаю не спрашивать, я предлагаю подготовиться к вопросу: попробовать доступные методы и проверить все на своей стороне
FairTopLin
21.11.2018 09:29markitosha Коротко и по делу, спасибо. В повседневной практике сталкиваюсь с такого рода поведением младших сотрудников. С самыми простыми задачами всё достаточно прозрачно, а вот какое относительно оптимальное время на разбор более объемной задачи по алгоритму выше? С какой периодичностью вы интересуетесь статусом задачи?
markitosha Автор
21.11.2018 11:22спасибо!
В начале выполнения больших задач я прошу сотрудника 2 раза в день делать отчеты по задаче в устном или письменном виде: на каком этапе задача, что попробовал, почему выбрал то или иное решение, что будет делать дальше и тд. За полдня он вполне успевает что-то сделать и не успевает уйти совсем не в ту сторону. Каждый отчет обсуждаем и корректируем направление решения. По мере роста сотрудника переходим на менее подробные рассказы и только один раз в день
SquareRootOfZero
21.11.2018 09:30Пропущен «Вопрос 0: а где, собственно, возникает проблема?» Постоянно наблюдаю это. Начиная со студентов каких-нибудь компьютерных наук: вот он делает задание, которое первый раз видит, в среде, которую первый раз видит, на языке, который первый раз видит. Как бы надо это делать? Написать «hello world», проверить, что компилится, проветить, что запускается, проверить, что действительно выводит надпись «hello world». Далее мелкими шагами двигаться в сторону задания, которое требуется выполнить, на каждом шаге проверяя, что всё ещё компилится, всё ещё запускается, всё ещё делает то, что ты ожидаешь. Чем больше опыт — тем крупнее шаги можно себе позволить. В пределе, когда уже совсем-совсем обалдел знаниями, наверное, можно будет позволить себе написать сразу целиком всю портянку, и она скомпилится, запустится и сделает всё как надо. Наш студент, однако, не идёт инкрементальным путём и сразу пишет портянку, после чего, разумеется, не может понять, чего это она не компилится. Пытаешься помочь — и, разумеется, тоже не можешь понять, как подступиться к этому дикому поделию студенческой мысли, в которое вместо знаний вложены дикие представления данного студента о программировании. Ладно студенты — на stackoverflow реальные разработчики вываливают простыни в стиле «я вот тут читаю через порт данные с прибора, конвертирую и отправляю по сети, а там происходит обработка, почему у меня вот в этом коде при сложении двух положительных чисел иногда вдруг получаются отрицательные?» (пример утрирован совсем не так сильно, как хотелось бы!) Далее простыня кода, там всё — и чтение через порт с прибора, и отправление по сети, и т. д., и т. п. SSCCE (в процессе составления которого, вероятно, ты сам и поймёшь суть, и найдёшь решение своей проблемы)? Не, не слышали. Изолировать проблему, прежде чем устанавливать её суть? Ну зачем это, мир же сложен во всём его многообразии, давайте сразу комплексно подходить…
markitosha Автор
21.11.2018 11:26Полностью разделяю вашу боль. Планирую делать цикл статей на тему рационального мышления и посвятить этому вопросу отдельную статью (а может даже две: декомпозиция задач и искусство дебага)
dimka11
21.11.2018 15:49Тут описана проблема отсутствие фундаментальных знаний. По идее прежде, чем писать код, нужно изучить IDE, язык программирования, алгоритмы и т.д. Тогда все пойдет намного быстрее и понятнее.
SquareRootOfZero
22.11.2018 10:04А как их изучить, не пиша…
пися… нувыпонеликод? Человек — не компилятор, чтобы загрузить в голову формальную грамматику языка и сразу всё зауметь, безо всякой практики. А подход к практике зачастую вот такой, как я выше описал.
jetcar
21.11.2018 14:01советы конечно полезные и не только для джуниоров, у джуниоров обычно другая проблема это не понимание того что одну и туже задачу можно решить кучей способов, обычно в голову приходит 1-2 очень простых способа и всё вспоминая себя я не понимал почему архитектор забирал себе на первый взгляд простые таски на додумывание, по мне херак-херак и продакшен чё там думать, теперь же с 10+ годами опыта работы в разных проэктах разной сложности наоборот не всегда понятно почему же джуниоры и не только не видят проблемы в придложенном решении вроде же очевидно что если так сделать то следующий разработчик который на этот код посмотрит будет переделывать
formatko
спасибо, закинул своим коллегам)