9 законов, которые должен знать каждый в IT

В разработке программного обеспечения есть несколько идей, рекомендаций и наблюдений, которые можно назвать законами или принципами. Это не строгие формулировки, которые действуют универсально во всех ситуациях, но они обеспечивают важные рамки, которые влияют на процесс разработки. Эти принципы могут существенно повлиять на производительность организаций, команд и отдельных лиц. Всем, кто занимается разработкой программного обеспечения, полезно знать и помнить про них.

Этот принцип озвучил Фредерик Брукс еще в 1975 году в его книге «Мифический человеко-месяц». Он звучит так: «добавление дополнительных сотрудников в отстающий проект может привести к его дальнейшей задержке».

Почему это происходит? Добавление нового члена в команду требует затрат времени и ресурсов на обучение и введение его в курс дела. Новичок нуждается в информации о проекте, используемых подходах и устройствах, а также в синхронизации с другими участниками команды. Это занимает время и замедляет работу всей команды.

Однако это вовсе не означает, что надо полностью отказываться от расширения команды. Некоторые проекты требуют увеличения числа участников, чтобы ускорить процесс разработки или реализовать более сложные задачи. Можно использовать различные методы и подходы к организации командной работы, такие как разделение работы на подзадачи и делегирование их участникам с определенными навыками и компетенциями.

«Когда мера становится целью, она перестает быть хорошей мерой».

Это означает, что как только конкретный показатель превращается в цель, люди начинают оптимизировать свое поведение, чтобы соответствовать этому показателю, часто в ущерб основной цели, которую он должен был представлять.

Мы часто стремимся к результатам, которые трудно поддаются количественной оценке, и в результате полагаемся на показатели, которые в конечном итоге направляют наши усилия в противоположном направлении.

Это может быть:

Чтобы избежать этой ловушки, не обязательно отказываться от подхода, основанного на данных. Однако необходимо учитывать, по крайней мере, несколько показателей, которые будут определять усилия команды.

«При достаточном количестве пользователей API становится не так важно, что вы обещаете в контракте: все наблюдаемые изменения вашей системы будут зависеть от чьих-либо действий».

Суть закона заключается в том, что по мере того как ваш API привлекает все больше пользователей, люди начинают полагаться на поведение, которое разработчики не планировали и не документировали. Со временем даже небольшие, недокументированные фичи или крайние случаи становятся «функциями», от которых зависят пользователи, что делает изменения или улучшения в API более сложными, не нарушая при этом чьих-либо интересов.

Этот закон подчеркивает проблемы поддержания обратной совместимости и управления ожиданиями по мере роста и эволюции систем.

«Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации».

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

Обратный маневр Конвея — это следствие закона Конвея. Оно предполагает, что если мы хотим, чтобы архитектура нашего программного обеспечения приобрела определенную форму или структуру, мы должны сначала организовать наши команды и схемы взаимодействия таким образом, чтобы они отражали желаемую архитектуру. То есть командам необходимо кросс-функциональное взаимодействие и совместная работа.

«При достаточном количестве наблюдателей ошибки выплывают на поверхность». Сформулирован Эриком Рэймондом, назван в честь Линуса Торвальдса.

Закон отражает суть сотрудничества с открытым исходным кодом, когда широкое участие сообщества помогает выявлять и исправлять ошибки более эффективно, чем в закрытых системах. Идея заключается в том, что чем больше людей проверяют код, тем выше вероятность того, что кто-то заметит и устранит ошибки, которые другие могут пропустить.

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера».

Закон Хофштадтера служит напоминанием о том, насколько часто мы бываем неточны при оценке времени, необходимого для выполнения задач, особенно при разработке программного обеспечения.

Он подчеркивает важность учета резервного времени и управления ожиданиями.

«Отладка кода вдвое сложнее, чем его написание. Поэтому, если вы пишете настолько умный код, насколько это возможно, вы по определению недостаточно умны, чтобы его отладить».

Написание слишком сложного кода может быть опасным для обслуживания системы. Если код написан с чрезмерной сложностью, отладка становится еще более сложной задачей, поскольку сначала необходимо расшифровать логику, прежде чем устранять какие-либо проблемы.

Простота в кодировании — это ключ к успеху: написание понятного, поддерживаемого кода облегчает его отладку и улучшение в долгосрочной перспективе.

«В иерархической системе каждый индивидуум имеет тенденцию подниматься до уровня своей некомпетентности».За успех часто приходится платить. Во многих случаях людей продвигают на все более высокие должности в зависимости от их достижений. Однако наступает момент, когда требования, предъявляемые к этой роли, могут превысить их возможности.В разработке программного обеспечении это часто наблюдается, когда успешных разработчиков продвигают на руководящие должности. Часто предполагается, что лидерские качества и навыки работы с программным обеспечением естественным образом развиваются вместе с техническими знаниями, но это не всегда так. Квалифицированный программист не обязательно обладает такими же способностями к управлению людьми, руководству командами или выполнению стратегических требований руководства, что может привести к возникновению проблем в его новой роли.

Одна из упрощенных формулировок: «20% усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата».

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

Вывод заключается в том, что сосредоточение внимания и усилий на наиболее эффективных областях — как правило, на 20%, которые дают 80% результатов, — приводит к большему успеху, чем чрезмерное распыление усилий. Это также подчеркивает, что качество перевешивает количество и что реальные результаты важнее, чем просто объем произведенной продукции. Определение приоритетов в том, что действительно движет компанией, помогает достичь более значимых и устойчивых результатов.

Мы в компании L-TECH, придерживаемся только тех принципов, которые положительно влияют на процесс разработки программного обеспечения. Таким образом мы более эффективно обслуживаем своих клиентов и сотрудничаем внутри команды.