С самого начала, мы проектировали наши продукты в соответствии с концепцией меньшего объема кода. При малейшей возможности мы разделяем сложные задачи на простые. Мы нашли решения простых задач, которые легче не только воплощать или поддерживать, но и понимать, и использовать. Все это — часть того, как мы отличаемся от конкурентов; вместо того, чтобы разрабатывать продукты, которые делают больше, мы разрабатываем те, которые делают меньше.
* Меньшим объемом программы легче управлять.
* Меньший объем программы — меньше кода, а это значит
* Меньше скучной работы по сопровождению (и более счастливый персонал).
* Меньший объем программы снижает стоимость изменений — так что вы можете быстрее адаптироваться к обстоятельствам. Вы можете менять свои решения без того, чтобы менять мегабайты кода.
* Меньше кода — меньше ошибок.
* Меньше кода — меньше техподдержки.
Какие функции оставить, а какие исключить — тут решение тоже связано с уменьшением объема программы. Не бойтесь отказать в выполнении запроса, который слишком труден. Если функция не является абсолютно критичной — вы сэкономите время и усилия, уменьшите путаницу тем, что откажетесь от нее.
Тише едешь — дальше будешь. Появилась идея — подождите неделю, прежде чем ее воплощать, посмотрите, будет ли она казаться такой же хорошей, когда шум спадет. Помаринуйте идею — и, может быть, за это время вам в голову придет еще более простое решение.
Поощряйте контрпредложения от программистов.
Вот что хорошо было бы от них слышать: «Если делать это как вы предлагаете — на это уйдет 12 часов. Но я могу сделать это за час. В таком случае программа будет делать
Также ищите обходные пути вокруг необходимости написания большего количества кода. Можете ли вы изменить экран так, что он предложит клиентам альтернативный путь — без того, чтобы менять модель программы? Например, можно ли предложить пользователям загружать картинки только определенного размера — без того, чтобы производить обработку изображений на сервере?
Для каждой функции, которая попадает в вашу программу, спрашивайте себя: а нет ли другого способа ее добавить, используя меньшее количество кода? Пишите только тот код, который вам нужен, и не более того. Ваше приложение будет более поджарым — и более здоровым.
«Секрет» хорошего программирования совсем не в том, что именно воплотить в коде — а в том, что оставить за его рамками. В том, чтобы определить, где сильные и слабые места программы, и решить, где нужно просто оставить свободное место, вместо того чтобы заполнять его функциональностью.
Самое важное правило разработки программного обеспечения — еще и наименее известное. Сложность программы растет не пропорционально ее размеру... И программа из 2000 строк потребует не в два раза больше времени, а гораздо больше, чем программа в половину этого размера.
Выбирайте инструменты, которые заинтересовывают и стимулируют вашу команду
Счастливый программист — продуктивный программист. Вот почему мы оптимизируем удовлетворенность работой, и вам тоже стоит это делать. Выбирайте инструменты, базируясь не только на стандартах отрасли или производительности. Смотрите на неосязаемые факторы: чувствуется ли в инструменте страсть, гордость и мастерство? Будете ли вы по-настоящему счастливы, работая в этой среде восемь часов в день?
