ПМ - Project manager (руководитель проекта).
Ты говоришь, что чайник только 5 будет закипать. ПМ настаивает, что клиент очень просит и это нам крайне важно, ты под натиском прогибаешься и решаешь что-то думать. Кидаешь пакетик в чайник, заливаешь водой и ждешь когда вода покоричневеет. Четко понимаешь, что надо будет не забыть отмыть чайник, ибо так останутся кольца от чая и возможно плесень. Наливаешь получившуюся крашеную воду для клиента, ПМ с довольной рожей говорит: ну видишь, можно же. А ты думаешь, что не хотел бы что бы тебе так делали... Но обстоятельства требуют. И только ты расслабился, как влетает ПМ и говорит: ты хоть пробовал это?
Ты осознаешь что походу вкуса нет... Пробуешь оправдаться, но тут ПМ тебя перебивает и говорит: да при чем тут вкус, он же не кипяток и ты быстро начинаешь думать что делать. Думаешь докипятить долго и находишь готовое решение - старый кипятильник в шкафу. Кидаешь его в кружку, включаешь в розетку, оно греется, а ПМ на тебя смотрит и говорит: кхм... Мы же не можем оставить такую зависимость от кабеля... И ты понимаешь что решение неплохое просто надо допилить, наивно полагая что ты пошел в правильном направлении. Ты находишь аккумулятор, подсоединяешь, и вот все работает, хоть тут даже ПМ осознает, что тут что-то не так. И тут прилетает интрига... ПМ-а нету час, два... Ты начинаешь думать что они или обсуждают твое увольнение, или ПМ-а где-то потеряло, может он уже сам решил допилить. Но тут влетает ПМ и без капли объяснения говорит: клиент очень доволен, надо так же быстро сделать макароны. Ты в недоумении - мол да ладно, оно сработало, идешь и смотришь на чайник и думаешь, а что еще в нем можно сделать. Но так как это вечер пятницы, думаешь, что хватит с тебя таких приключений и договариваешься с ПМ-ом на понедельник.
Вот он понедельник. Ты полон сил и переспав с осознанием, что натворил в пятницу, вспоминаешь про макароны. Без задней мысли всыпаешь макароны в чайник. Доливаешь воды и включаешь. Проходит минута и ты понимаешь, что макароны воду не красят и как понять, что они готовы будет не так просто. Но... открыв чайник тебя наполняет крайнее удивление. Макароны действительно покрасили воду. Но запах чая возвращает тебя в реальность где ты вспоминаешь свое TODO: помыть чайник. С учетом, что времени нет, потому что ПМ сейчас опять прилетит, ты перемешиваешь эту чепуху и думаешь - да ладно, задача та стояла - сварить их и быстро, а не цвет, запах, спишем на неточно данные технические требования. Но тут ты понимаешь, что макарохи совсем не чай и привинтить к ним кипятильник, что бы пока несли их они дошли - не вариант, потому что клиент поймет что это суп, а не макароны. Что бы не портить всю малину ты кипятишь кипятильником вторую воду, но уже в ведре на половину полном. Казалось бы: что здесь происходит, но нет, идея тут все же есть. Ведро накрываем дуршлагом выливаем чайник с коричневыми макарохами в дуршлаг и накрываем крышкой, паром макарохи дойдут до клиента в доваренном виде. Влетает ПМ, ты говоришь с довольным лицом, что все готово, вручаешь ему ведро с крышкой, кипятильник, аккумулятор. У ПМ-а радость на лице плавно перетекает в удивление или шок, но вроде недовольства невидно. Он говорит: “ну ладно” и забирает ведро. Ты явно осознаешь что это все плохо кончится и пока есть свободное время обновляешь резюме, но ПМ-му говоришь о нюансах: ведро не открывать пока подключен аккумулятор - категорически нельзя.
Спустя некоторое время приходит новый разработчик и видит это все:
Чайник, ведро, дуршлаг, кипятильник и аккумулятор.
Логичные вопросы назревают в голове разработчика:
Зачем кипятильник, когда есть чайник.
А не убьет кого-то аккумулятором.
Почему чайник внутри черный.
Какой шанс если плохо нести ведро - кипятильник утонет, коротнет и все взорвется.
И классические вопросы: как это вообще работало, так как ни документации, ни старого разработчика и второй вопрос зачем так было делать.
Можно продолжать, но давайте сделаем некоторые выводы уже:
ПМ облажался, потому что боится сказать, что нормальные решения требуют нормального количества времени заказчику.
Разработчик не привык к таким темпам и решал ради результата пренебрегая последствиями.
TODO: - делаются тогда, когда реально в этом месте что-то вылезет или очень редко. У тебя либо сразу есть время сделать нормально, либо оно и потом не появится. Но бывают исключения.
Похожие процессы иногда могут требовать совершенно разных подходов. И иногда нормальное решение лежит совсем рядом.
Страх - самый большой наш враг и из-за него появляются недоговорки, отмазки, страх признать, что ты человек и быстрее чем “свое быстро” ты нормально не сделаешь, страх сказать заказчику, что нам нужно точное техническое документирование и конкретные требования, страх спросить у более опытного, на форуме или семинаре. Разработчики ходят на семинары, и реально половина не понимает зачем. Да рассказывают, так спроси если не понял, этот эксперт и выступает что бы люди поняли, чтобы увидели больше.
Отсутствия опыта формируют костыли, которые часто заставляют нас делать решения, которые полностью ведут нас в неправильном направлении. Как корабль: недосмотрел где полюс, ошибся на 2-3 градуса, вроде мелочь, но через неделю движения в этом направлении, это могут быть сотни, а то и тысячи километров, что бы поправить этот косяк.
Разработчики часто думают, что ПМ умен и все проблемы - его проблемы. Но он тоже человек и тоже может ошибаться. Ему тоже надо помогать и подсказывать как правильно и почему что-то может пойти не так.
Если нет времени на документацию, но ты четко понимаешь, что код будет непростым - оставь просто 2-3 комментария. Что бы после твоего отпуска, ты или другой разработчик смог поправить косяк в твоем коде. Комментарии в коде - это нормально, а вот закомментированный - код нежелателен.