Comments 18
Если вы оглядываетесь на свой старый код и внутренне съеживаетесь – это означает, что с тех пор вы чему-то научились и стали лучше
К сожалению не обязательно. Может просто контекст кода забыли и оттого он менее понятен (как будто плохо написан)
Да, такое тоже бывает. Но обычно, если код написан хорошо, небольшого времени на погружение в контекст хватает, чтобы в нём разобраться. А вот если есть проблемы с качеством кода, то погружение в контекст не сильно поможет, всё так же будешь думать "я не мог такое написать" :)
> если код написан хорошо, небольшого времени на погружение в контекст хватает
хорошо не обязательно означает просто, и еще более необязательно написанного Вами, сложность проекта, его история и пр. имеют первостепенное значение, погружение в контекст иногда просто нереально из-за размера кода и недостатка времени на его изучение, даже при большом опыте
ps
о книге Брукса «Мифический человеко-месяц .." - imho в большой степени навеяна культурой IBM, и далеко не лучшей практикой разработки OS 360 даже для того далекого времени
Закон тривиальности Паркинсона
Однажды я участвовал во встрече по обсуждению крупной фичи, и половину времени, отведённого на обсуждение, мы выбирали цвет кнопки на одном из экранов.
Закон тривиальности, на мой взгляд, первопричина неэффективности современной разработки. Логично что участники встречи сводят обсуждение до наиболее понятного общего уровня, невозможно дискутировать о том, чего не знаешь.
Но неверное толкование гибких методологий, которое исключает проектирование и анализ, превращает большинство обсуждений буквально в цирк: один рассказывает истории из жизни, другой гадает и говорит как ему кажется, третий поддакивает наиболее простым соображениям.
В своей практике придерживаюсь некоторых правил, чтобы справиться с этой проблемой:
Обсуждение ведётся в формате ответов на вопросы, указанных в агенде
Перед встречей всем выделяется время для подготовки
На встречу допускаются только участники с требованиями или результатами анализа
Просто прийти “обсудить” или "послушать" нельзя, даже если это менеджер
Ведущий может закончить встречу в любой момент, если правила выше не выполняются во избежание лишней траты времени
Если программа работает, то это значит, что количество ошибок в ней четное.
В частности, если ваш код скомпилировался с первого раза - напишите разработчикам компилятора, пусть исправят баг у себя. (с)
Поэтому настоящие программисты не фиксят баги, а документируют их, как особенности программы.
Работа заполняет всё время, отпущенное на неё.
"Плохой разработчик за год работы создаёт два новых рабочих места"
Статья отличная для инициации размышлений на эту тему, но поверхностная со второго закона (не расписаны причины до конца), это не вменяется в вину автору, просто личное мнение. Автору большое спасибо. Законы те повлияли и на написание этой статьи возможно, плюсы будто ставили любители обсуждать сарайчик возле АЭС хоть и это научно обоснованно))) Все указанные моменты лишь следствие и психология. Суть рядовые сотрудники точно не изменят (вероятность низка), не факт что и руководство сможет. Знать это конечно надо. Главное не кинуться сломя голову устранять все моменты, так как причина будет их далее порождать много и снова.
Закон Брукса к примеру, "руководитель проекта предлагал просто подключить ещё людей" может быть из вежливости или просто, чтобы показать свою озабоченность вопросом, попутно показав, что помочь не в его силах (или просто лень). Можно даже подумать из-за того что отказываемся от помощи сразу, сами будем и виноваты, при разборе полётов вышестоящими, нам же предложили помощь, а мы в отказ (явления в научных терминах не буду расписывать в этом комментарии). Это наши будни капиталистически-бюрократического мира, а не логичного и адекватного ;-)
Закон Иглсона, порой поработав пару часов, достаточно несколько раз отвлечься и уже кажется, что ты возвращаешься к чужому проекту, а если на следующий день, неожиданно прервавшись до этого...
Плюсую, все верно. Особенно закон тривиальности Паркинсона напрягает. Как много отсутствие компетенций в ИТ. Т. Е. не профессионализм сплош и рядом. Всем удачи.
Спасибо, подборка прекрасна:) я думала, мои наблюдение про количество людей на горящем проекте - случайность, а оказывается закон Брукса
А-ха-ха. Это продолжение "Прибить или приклеить" https://www.youtube.com/watch?v=EhtsPAdYOds&ab_channel=ComedyClub
Всю жизнь боролся с тем, что закон Брукса можно обойти. Не надо вводить разработчиков в проект, не надо присоединять к имеющейся команде. Надо чётко выделить конкретную задачу-фичу, минимально связанную с работой других, и тогда подключение действительно сокращает общее время разработки. Из минусов тут то, что действительно на это тратится время архитектора или технического руководителя и что не всегда удаётся выделить такие фичи. Но последнее говорит о низком качестве архитектуры в целом.
Законы мира информационных технологий