Разработка программного обеспечения приносит с собой изрядное количество парадигм, шаблонов и принципов. Многие из них принимают форму законов о разработке программного обеспечения.
Некоторые законы о разработке программного обеспечения касаются только практики кодирования. Другие дают представление о более широких аспектах разработки и дизайна продукта. И некоторые выходят за эти границы, сообщая нам о закономерностях, которые применимы к жизни, какой мы ее знаем.
Вот десять интересных законов разработки программного обеспечения.
Закон Брукса
«Добавление рабочей силы в поздний проект сделает его позже».
Закон Брукса взят из книги Фреда Брукса Мифический месяц человека 1975 года. Он основан на предположении, что члены команды и необходимые месяцы взаимозаменяемы.
Это не так - особенно при разработке программного обеспечения (или разработки любого продукта, если на то пошло). Почему? Из-за времени, необходимого для того, чтобы знакомить людей с проектом и держать его в курсе последних событий.
Закон Конвея
«Любая часть программного обеспечения отражает организационную структуру коммуникации, которая его создала».
Мелвин Конвей сформулировал этот закон разработки программного обеспечения в 1967 году. Закон Конвея касается дизайна продукта. Это наблюдаемое явление, когда коммуникационные структуры влияют на выпуск программного обеспечения.
Итак, сплоченная группа со скоординированным поведением создает программное обеспечение со связанными функциями и кодом. Между тем, более расслабленная, децентрализованная команда создает более модульное программное обеспечение.
Закон Мерфи
«Если что-то может пойти не так, так и будет».
Это самый известный и универсально применимый закон в этом списке. Закон Мерфи проявляется во всех сферах управления проектами, разработки программного обеспечения и жизни в целом.
В разработке программного обеспечения закон Мерфи подчеркивает ключевой момент: компьютеры делают то, что вы говорите им, а не то, что вы от них хотите.
Закон Хофштадтера
«Это всегда занимает больше времени, чем вы ожидаете. (Даже с учетом закона Хофштадтера.) "
Сколько времени это займет? - один из самых страшных вопросов в разработке программного обеспечения. Причину этого объясняет закон Хофштадтера. Это относится к другому закону: закону Паркинсона, который утверждает, что работа расширяется, чтобы заполнить время, доступное для ее завершения.
Между законом Хофштадтера и законом Паркинсона практически невозможно дать точную оценку времени завершения.
Закон Линуса
«Если внимательно присмотреться, все ошибки будут неглубокими».
Этот закон немного «поверхностен» по своей формулировке. Ошибки становятся мелкими только в том случае, если дополнительные глаза принадлежат людям, обладающим навыками для решения проблемы. Взгляд непрофессионала не избавит от сложной ошибки.
Однако принцип остается в силе. Закон Линуса - напоминание о ценности совместной работы в отделе разработки. Часто при решении задач две головы лучше, чем одна.
Закон Гудхарта
«Когда мера становится целью, она перестает быть хорошей мерой».
Примером закона Гудхарта в разработке программного обеспечения являются строчки кода. Строки кода позволяют измерить размер программного продукта. Но при использовании в качестве цели качество кода падает.
Вместо этого строятся строки, которые необходимо доработать или вырезать из программного обеспечения, создавая беспорядочную пластину спагетти-кода.
Закон Галла
«Сложная работающая система выросла из простой работающей системы. Сложная система, созданная с нуля, не будет работать ».
Мы видим это во многих сложных жизненных системах, например, сама жизнь началась с одноклеточных организмов. Разработка программного обеспечения ничем не отличается.
Закон Галла, если он верен (что, похоже, так и есть), является хорошей причиной для начала разработки программного продукта с минимально жизнеспособного продукта (MVP).
Закон Завинского
«Каждая программа пытается расширяться до тех пор, пока не сможет читать почту. Те программы, которые не могут расширяться, заменяются теми, которые могут ».
Говоря о сложности, закон Завински предполагает, что после создания продукция продолжает расширяться. Они добавляют больше функциональных областей, пока больше не смогут расширяться.
Примеры расползания функций иллюстрируют закон Завинского в разработке программного обеспечения. Раздутые программы скоро будут отброшены в пользу более оптимизированных вариантов.
Закон Иглсона
«Любой собственный код, который вы не просматривали шесть или более месяцев, с тем же успехом мог быть написан кем-то другим».
Многие считают Иглсона оптимистом, предполагая, что шесть месяцев - это щедрый срок. В любом случае закон Иглсона подчеркивает необходимость четких, эффективных комментариев и четких стандартов кодирования. В конце концов, даже первоначальный программист не смог впоследствии расшифровать беспорядочный код.
Закон Любарского
«Всегда есть еще одна ошибка».
Наконец, для всех ваших передовых методов программирования, обновлений и обслуживания всегда есть еще одна ошибка, которую нужно исправить. Или еще кое-что, что нужно настроить, или добавить, или изучить. В конце концов, работа программиста никогда не кончится.
Итак, помните, что когда дело доходит до разработки программного обеспечения, готовое лучше, чем идеальное.
Многочисленные законы разработки программного обеспечения
Независимо от закона, принципа или шаблона, в каждом законе о разработке программного обеспечения есть что-то свое. Это может быть интересное открытие, полезный урок или простой интерес.
Это лишь некоторые из шаблонов и парадигм, которые используются при разработке программного обеспечения.
