Законы программирования, о которых вы, возможно, не слышали
У программиста широкий перечень правил, которых он должен придерживаться в работе. Это и правила хорошего синтаксиса, и соблюдение метода разработки, и общие стандарты кода в компании.
Но помимо этого, есть ещё множество принципов, которые очень точно описывают профессию программиста. С некоторыми из них стоит познакомиться.
Принцип раздувания
«Каждая программа развивается до тех пор, пока не сможет читать почту. Программы, которые не способны так развиться, вытесняются теми, что смогут».
Это правило имеет множество вариаций, но официальной принято считать Закон о программном обеспечении, или Закон Завинского. Впервые он был упомянут в книге «Искусство программирования для Unix» (The Art of UNIX Programming). Речь идёт о тенденции программ увеличивать функциональность с течением времени и, как следствие, усложняться. Этот принцип заложен также в функцию ползучести, которая гласит:
«ПО расширяет функциональность до тех пор, пока не задействует все предоставленные ресурсы».
Она имеет негативную окраску и противопоставляется основным целям программирования.
Принцип «Чем хуже – тем лучше»
«ПО, которое имеет ограничения, но простое в использовании, более востребовано пользователем и рынком, чем не имеющее ограничений, но сложное для понимания».
Ричард П. Габриэль впервые упомянул это правило в эссе, написанном им о качестве программного обеспечения, в конце 1980-х годов. В развитии этой идеи он пишет, что разумно разобраться в одной проблеме, которую ваше ПО стремится решить, довести функцию до совершенства. Надо быть проще. Чем больше вы расплываетесь в идеях, тем более неуправляемым станет проект и тем более невостребованным он будет.
В случае игнорирования вы сталкиваетесь с принципом Питера:
«Каждый комплексный проект неизбежно становится сложным для понимания даже для собственных разработчиков».
Он исходит из более широкого Принципа Питера о продвижении по карьерной лестнице сотрудников с ограниченной компетентностью. Результат – все сотрудники компании оказываются некомпетентными. Этот же принцип легко спроецировать на ПО, и он тоже будет верным.
Закон Иглсона
«Ваш код, который вы не просматривали 6 или более месяцев, выглядит так, будто его написал кто-то другой».
Это демотивационное высказывание говорит о том, что никто не идеален. Вы можете считать себя гениальным программистом прямо сейчас, но всегда есть что-то большее, пространство для роста. Если вы когда-либо оглядываетесь на старый код и съеживаетесь – это означает, что вы узнали что-то новое с тех пор.
Иными словами, если вы не увидите в старом проекте ничего, что можно улучшить – это верный признак стагнации или деградирования.
Правило наименьшего удивления
«Если необходимая доработка имеет высокий коэффициент изумления, возможно, её стоит переработать».
Правило впервые появилось в IBM Systems Journal в 1984 году, а широкую огласку получило благодаря книге «Искусство программирования для Unix». Оно касается тонкого баланса между инновациями и знакомством с ними: если ПО слишком отличается от других подобных и не соответствует ожиданиям пользователей, то они вероятно его не примут. Лучше стремиться к дополнительным улучшениям, которые достаточно велики, чтобы впечатлить, но достаточно малы, чтобы казаться знакомыми.
Закон кибернетической энтомологии
«Всегда есть ещё один баг».
В СМИ это правило часто носит название закона Кибернетической энтомологии Любарского. Его принцип справедлив для всех программистов: независимо от того, насколько вы четко пишете код, тщательно тестируете модули, и как часто вы реорганизуете классы, всегда найдётся какая-то ошибка.
В некотором смысле это принцип освобождения. Хотя все мы должны стремиться к отсутствию ошибок, важно помнить, что перфекционизм - это враг добра.
Закон Кернигана
«Отладка кода вдвое сложнее, чем его написание. Поэтому, если вы пишете настолько умный код, насколько это возможно, вы по определению недостаточно умны, чтобы его отладить».
Брайан Керниган – один из авторов фундаментальной книги «The C Programming Language». Суть закона: напишите хороший код, читаемый, простой, какой угодно, но только не умный. В противном случае вы создадите полную противоположность тому, что принято считать лучшим кодом.
Роберт К. Мартин объясняет – речь идет не только об отладке:
«Действительно, соотношение времени, затраченного на чтение и письмо, составляет более 10 к 1. Мы постоянно читаем старый код как часть усилий по написанию нового. Облегчаем чтение, упрощаем запись».
Правило 90-90
«Создание 90% кода ПО занимает 90% заложенного времени разработки. Оставшиеся 10% – ещё 90% времени».
Эта небольшая пословица Тома Каргилла лежит в основе того, почему программирование может быть расстраивающим: независимо от того, насколько близко вы подбираетесь к решению задачи, на самом деле вы далеки от завершения. Когда думаете, что вот-вот закончите – вы находитесь только на середине пути.
В шуточной манере аналогичный закон составил Дуглас Хофштадтер:
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера».
Закон Паркинсона
«Работа заполняет всё время, отпущенное на неё».
Этот принцип, придуманный историком Паркинсоном ещё в 1955 году, является более широким принципом, и идет рука об руку с Правилом 90-90, описанным выше: сколько бы времени вы не заложили на проект, он будет разрабатываться до самой последней минуты. В разработке ПО «ранняя сдача» в значительной степени является мифом.
Закон Паркинсона является причиной того, что правильные сроки имеют решающее значение, если вы хотите закончить и отправить свое ПО. Вот почему современные профессиональные программисты часто рекомендуют гибкие принципы управления проектами и соответствующие инструменты.
Закон Брука
«Добавление рабочей силы на поздних стадиях ПО затягивает его выпуск».
В следующий раз, когда будете срывать сроки сдачи проекта, помните – добавление кодеров не ускорит процесс. Более того, вероятно, это займет даже больше времени. Вам не только нужно ввести новых кодеров в суть дела, но и им работать с уже существующими кодами. Необходимо вводить больше документации и бюрократии, чтобы держать всех на одной волне. Кроме того, из-за ускользающего времени возникнет больше конфликтных ситуаций.
Отладка резиновой утки
Здесь обойдёмся без цитаты, так как это скорее полезная техника. Речь идёт о публикации The Pragmatic Programmer, рассказывающая о методе отладки, когда вы объясняете свой код неодушевлённому объекту, например, резиновой утке. Это задействует разные области вашего мозга, и вы быстрее находите ошибки.
Благодаря описанной мудрости вы подойдёте к карьере программирования с реалистичными ожиданиями. Останется лишь малость – выучить язык программирования и найти подходящее место работы.