Комментарии 42
Полностью поддерживаю.
При обнаружении ошибки, котрорая затрагивает каскад проблем, дополнительно вношу в специальный раздел в базе знаний (у нас это Confluence), где собраны правила разработки, условия и т.д.
Зачем документировать проблему, если можно сделать так, что бы проблема больше не появлялась? А это можно сделать в 90% случаев.
Затем, что прийдёт новый человек, не знакомый с культурным background'ом, и реализует эти же грабли в другом месте. Документирование - это очень сильное колдунство, не нужно от него отказываться.
На самом деле будет так. Придёт новый человек, пройдёт по граблям и его ткнут в документацию. Смачно и с большим удовольствием ткнут, но проблему это не решит.
Т.е. я не призываю отказываться от документации, но в 90% если проблема системная, то это означает, что нужно менять процессы или архитектуру, а не документировать где грабли в проекте разложены.
А теперь скажите, что проще - дать кому-то почитать определенный кусок текста и уже работать с вопросами/предложениями или тратить время на объяснения того же самого + все, что выше? Я молчу про ситуации, когда держатель знания уходит из компании, и с ним уходит весь наработанный опыт, который его коллеге, если не повезет, придется вывозить самому, а такое случается сплошь и рядом. Отказываться от документации пусть и сомнительных решений, даже в небольшой компании, видится не очень дальновидным поступком.
Алгоритм претерпел изменения:
Это ещё не синьор.
У синьора вот так:
Узнать о проблеме
Локализовать проблему
Загуглить проблему и решениеПофиксить проблему
Не понятно за что заминусовали комментарий выше, сеньор, если решения в гугле нет - как раз таки должен найти решение сам, иначе какой он сеньор, или это уже уровнем выше? ))
Сеньор, который не пользуется опытом других, может конечно и сеньор, но обычно по ряду факторов (не по знаниям) в большей части компаний будет считаться плохим вариантом для найма.
Сеньор, который не пользуется опытом других
Я не писал, что синьор не пользуется опытом других. Я написал, что он не "загуглит проблему и решение". Максимум - это уже точное решение проблемы (команда в терминал, название свойства, путь к конфигу и т. д.).
Да, если проблема для специалиста новая - он идёт гуглить что за проблема. Но для помидоров такие ситуации случаются не часто.
Hidden text
Инструктор на занятиях по инженерному делу задал такой вопрос будущим офицерам: — Представьте себе, что трехметровая мачта с флагштоком упала. В вашем распоряжении сержант и отделение из восьми человек. Ваши действия? Посыпались предложения, как с помощью тех или других технических приемов установить мачту. — Неправильно, все неправильно! — сказал в ответ инструктор. — Вы просто должны приказать: "Сержант, поставьте мачту на место".
если решения в гугле нет
Если решения в гугле нет - это триггер, что с вероятностью 99.9999% ты прямо сейчас творишь какую-то дичь и нужно внимательно пересмотреть подход.
Я зачеркнул гугл потому, что у синьора есть опыт решения задач и он их решает.
Ещё я нарочно убрал весь бред про базу знаний, перепроверку всего кейса, разбирательства в причинах и т. д. Если ошибка из-за того, что число округляется в неправильную сторону - то да, тут можно и поправить 1 строку в коде. Но в ситуациях, когда нужно разбирательство, синьор не тратит своё время на это, а делегирует мидлу или даже джуну.
У настоящего сеньора проблемы решаются сами при самом его присутствии.
Загуглить проблему и решение (при необходимости)
Вот кстати я намеренно написал про гуглёжку, потому что очень часто, даже зная решение, можно нагуглить либо решение лучше, либо почитать про подводные камни.
Я отдаю себе отчёт, что я не знаю всё на свете, поэтому если у меня есть возможность почитать несколько мнений, было бы глупо не воспользоваться этим.
Синьор делает так:
Узнает о проблеме
Локализует проблему
Фиксит проблему
Пишет про проблему в блог или на Хабр, чтобы Google смог проиндексировать страницу и показывать её в поиске джунам :)
Надо всегда исправлять не последствия, а причину баги ^.^
Спасибо за статью. Второй "алгоритм" справедлив и для джунов и для всех вообще, включая обычных юзеров которые просто настраивают свой домашний компьютер. Это надо доносить ещё до школьников на уроках информатики. Не понял в чём тут "фишка" в этой статье. Это же стандартный подход к любой проблеме с аппаратной или программной частью. Не понимаю почему у автора ушло на понимание этого 10 лет.
Чем хороший программист отличается от плохого
а как же классика: у хорошего программиста меч зеленый, а у плохого - красный?
two weeks of coding might save you two hours of thinking
Все хорошо, но проблема-то была в том, что вообще в принципе Excel файл использовался :) И во втором алгоритме (зря заминусовали человека выше) можно вообще было не гуглить или напугать, понять что принятый ответ ответом не является и т.д...
Я не синьор (да и вообще не программист официально), но для меня лично переломным стало понимание того, что нужно прочитать и осознать что тебе пишет компилятор/интерпретатор (а если есть возможность - то вообще линтер). Причем сделать это перед тем, как гуглить. Возможно и гуглить не нужно будет, и в голове больше отложится.
Анализ начинается еще на уровне постановки задачи
Только вот не всегда такой подход позволен. Рынок айти перегрет, из за высокой конкуренции всё больше решает время, а не качество работы. В каждой компании, где я работал, кроме последней, код на 110% состоял из легаси, к которому нужно было прикручивать новый функционал. Для этого функционала по всем правилам хорошего кода нужно было рефакторить монолиты нулевых, потому что иначе кроме как на костыли новый код не подвесить. То же с багами, корни которых шли откуда то, где только бог помнит как работает приложение. Я часто пытался вместо костылей досконально разобраться в причинах, плюс, видно было, что те, кто работал до меня, тоже пытались. Почему же мы нам всем пришлось бросить и пофиксить баги без разбора причин? График. Не уложишься в него - уложатся конкуренты. Программирование перестало быть искусством, оно стало бизнесом. В моих петах и на текущей работе в стартапе код гораздо чище и понятнее, чем в компаниях гигантах. И это печально :с
Словоблудие. Статья об очевидных вещах.
Советую немного переделать этот список. Перед тем, как приступать к решению задачи, надо сначала подготовиться, сделать домашнее задание, и разобраться в том, что решать, и надо ли ее решать вообще. Если сразу приступать к решению, можно попросту потратить время зря.
Для меня, это больше выглядит так:
Узнать о проблеме
Проанализировать проблему
Для начала выяснить, проблема ли это или так задумано by design, нужно ли вообще что-то менять
Понять, почему это произошло, какие действия привели к проблеме
Собрать информацию о том, как воспроизвести проблему
Найти источник проблемы (root cause)
Понять, какие части затронуты проблемой, какие последствия
Оценить проблему
Насколько критична
Насколько решабельна, прикинуть как быстро ее можно решить (estimate)
Приоритизация решения (возможно проблема не так важна и ее можно дропнуть)
Определиться кто и как ее должен решать (не факт, что это вы или ваша команда)
Спланировать решение
Только сейчас уже решение (или делегирование) проблемы (включая гуглежь и прочее), когда мы знаем, с чем имеем дело, и имеем полную картину.
Проверка решения, тесты. Убедиться, что проблема решена, и что наше решение не поломало ничего нового.
Дальше уже рассказывать друзьям и делиться опытом.
Даже если это мидл, или джун, все равно советую хотя бы поверхностно пройти по анализу, чтобы понять, стоит ли за это браться, или может лучше заняться чем-то более значительным. Иначе, такой сеньор может погрязнуть во всех этих мелких проблемах вместо того, чтобы заниматься более серьезными вещами.
Спасибо за статью! Но, кмк, стоит, как минимум дополнить про изменения что приходят в самом коде по мере набора опыта. У меня как-то был показательный пример на работе. Одновременно от одного заказчика вели два проекта. Один был относительно большой, с установками в куче стран, раздутым бюджетом и, конечно же, не менее раздутым штатом разношерстных программистов. Там начальство считало что чем больше у него людей, тем круче. И был маленький проект. По функционалу примерно 25% от большого. Но там удалось провести кадровую идею, что лучше меньше, да лучше. Проекты шли много лет, цифры прыгали, но среднее соотношение программистов было 20 к 3. При этом стек и архитектура были почти одинаковые. А однажды для какой-то там сертификации заказчик запросил посчитать количество кода и там и там. И тут выяснилось, что в маленьком проекте кода больше. Не сильно, но, тем не менее. Примерно на 20%. Толстое американское начальство меня тогда вызвало и попросило внести тут ясность. И ему на пальцах было объяснено, что скажем, какой-то дополнительный мелкий функционал на форме требует добавления 3 строк. Это вот ровно тот код, что делает ровно то, что нужно. При этом защита от дурака к нему это еще 3 строки. А грамотная обработка ошибок это еще 6. Так вот большой проект останавливается на 1 стадии, а второй - делает все. Начальство поулыбалось, но выводов не сделало. В итоге большой проект со скандалом еще через пару лет закрыли. А маленький жив до сих пор.
От старого го*нокодера: Ты не можешь пофиксить мозги всех разработчиков этого мира,- поэтому если что-то сдохло и надо пофиксить срочно,- то фикси. Иногда и на "гуглить" нет времени,- когда с момента расплывчатого запроса "у нас заказы не приходят" до момента конкретного ответа "всё заработало" должна пройти -1 (минус! одна) минута.
Ага,- включить доп.шагом unit test... Ну да,- поток сырых данных, в которых надо выловить "кривоту", и есть минут пять что бы вставить в процедуру кусок с логированием и запустить рабочий(!) прогон.
PS Но, в общем да, если сидишь на стуле ровно, то можно начать писать контрагентам о том, какой хреновый фреймворк используют ихние программеры. Можно потом даже нагуглить про то, в каких жестоких муках рождался фреймворк и почему он такой ущербный... :)))
PPS Да, вишенка на торте,- основываясь на собственной экспертизе, можно потом написать разрабам про то, откуда (с наибольше вероятностью) выросли ноги у ошибки. Через полгода источник проблемы, возможно, пофиксят...
Всем добра! Аминь!
В принципе, весь ремонт электроники и микроэлектроники именно на таких же принципах и основан. Но там еще более очевидно, что устранять надо причину, а не следствия.
Чем хороший программист отличается от плохого, или почему нужно выходить за рамки