Меньший объем программы

Меньший объем программы

Сохраняйте код как можно более простым

Вам кажется, что имея в два раза больше кода, ваша программа будет только вдвое сложнее. На самом деле, каждый раз, когда вы увеличиваете объем кода, сложность программы возрастает экспоненциально. Каждое маленькое дополнение, каждое изменение, каждая взаимозависимость и каждое предпочтение имеют каскадный эффект. Продолжайте безбоязненно добавлять код, и вы получите страшный Большой Ком Грязи — до того, как это заметите.

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

Главное здесь — переформулировать любую сложную задачу, требующую много кода, в простую задачу, которая требует кода намного меньше. Возможно, вы уже не будете решать в точности ту же задачу — это нормально. Решить 80% первоначальной задачи, затратив 20% усилий — это большой выигрыш. Первоначальный вариант задачи обычно никогда не является настолько важным, чтобы затрачивать в пять раз больше времени на ее решение.

Меньший объем программы значит, что вам не придется теряться в догадках. Вместо попыток предугадать проблемы в будущем, вы решаете только сегодняшние проблемы. Почему? Страхи, которые вы питаете по поводу будущего, как правило, не оправдываются. А потому не толкайте себя в болото, пытаясь бороться с призраками.

С самого начала, мы проектировали наши продукты в соответствии с концепцией меньшего объема кода. При малейшей возможности мы разделяем сложные задачи на простые. Мы нашли решения простых задач, которые легче не только воплощать или поддерживать, но и понимать, и использовать. Все это — часть того, как мы отличаемся от конкурентов; вместо того, чтобы разрабатывать продукты, которые делают больше, мы разрабатываем те, которые делают меньше.

* Меньшим объемом программы легче управлять.

* Меньший объем программы — меньше кода, а это значит

* Меньше скучной работы по сопровождению (и более счастливый персонал).

* Меньший объем программы снижает стоимость изменений — так что вы можете быстрее адаптироваться к обстоятельствам. Вы можете менять свои решения без того, чтобы менять мегабайты кода.

* Меньше кода — меньше ошибок.

* Меньше кода — меньше техподдержки.

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

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

Поощряйте контрпредложения от программистов.

Вот что хорошо было бы от них слышать: «Если делать это как вы предлагаете — на это уйдет 12 часов. Но я могу сделать это за час. В таком случае программа будет делать x и не будет делать y.» Почувствуйте, как программа сопротивляется добавлению лишних функций. Научите программистов отстаивать свою точку зрения на то, как лучше написать программу.

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

Для каждой функции, которая попадает в вашу программу, спрашивайте себя: а нет ли другого способа ее добавить, используя меньшее количество кода? Пишите только тот код, который вам нужен, и не более того. Ваше приложение будет более поджарым — и более здоровым.

Нет кода более гибкого, чем отсутствие кода!

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

— Брэд Эпплтон (Brad Appleton), инженер-программист (из There is No CODE that is more flexible than NO Code![23])

Сложность растет не пропорционально размеру

Самое важное правило разработки программного обеспечения — еще и наименее известное. Сложность программы растет не пропорционально ее размеру... И программа из 2000 строк потребует не в два раза больше времени, а гораздо больше, чем программа в половину этого размера.

— The Ganssle Group[24] (из Keep It Small[25])