Тише едешь — дальше будешь. Появилась идея — подождите неделю, прежде чем ее воплощать, посмотрите, будет ли она казаться такой же хорошей, когда шум спадет. Помаринуйте идею — и, может быть, за это время вам в голову придет еще более простое решение.
Поощряйте контрпредложения от программистов.
Вот что хорошо было бы от них слышать: «Если делать это как вы предлагаете — на это уйдет 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])
Оптимизируйте для счастья
Выбирайте инструменты, которые заинтересовывают и стимулируют вашу команду
Счастливый программист — продуктивный программист. Вот почему мы оптимизируем удовлетворенность работой, и вам тоже стоит это делать. Выбирайте инструменты, базируясь не только на стандартах отрасли или производительности. Смотрите на неосязаемые факторы: чувствуется ли в инструменте страсть, гордость и мастерство? Будете ли вы по-настоящему счастливы, работая в этой среде восемь часов в день?
Это особенно важно при выборе языка программирования. Вопреки общему мнению, языки программирования не равноценны. В то время как на любом языке можно написать практически любую программу, хороший язык сделает вашу задачу не просто возможной и терпимой, а радостной и дающей силы. Мы о том, что маленькие детали ежедневной работы должны приносить радость.
Счастье заразительно. Счастливые программисты поступают правильно. Они пишут простой, читабельный код. Они придерживаются ясных, выразительных, читабельных подходов. Им нравится то, что они делают.
Мы нашли наше программистское счастье в языке Ruby — и мы поделились им с другими разработчиками через нашу платформу Rails. И Ruby, и Rails проповедуют идею оптимизации для людей и их счастья. Мы приглашаем вас опробовать эту комбинацию.
В общем, вашей команде нужно использовать инструменты, которые станут любимыми. Мы говорили тут о языках программирования, но то же верно для программ, платформ и всего остального. Выберите инструменты, которые не оставят разработчиков равнодушными. Вы получите мотивацию, и, как следствие, лучший продукт.
Какие инженеры вам нужны
Причина того, что я хотел создавать наше приложение на Ruby on Rails, в том, что эта платформа элегантна, продуктивна и красиво спроектирована. Она привлекает инженеров, которые заботятся именно об этом... а это именно такого рода инженеры, какие вам нужны, потому что они создают именно такие красивые, элегантные и продуктивные программы, которые вам нужны, чтобы завоевать рынок.
— Чарльз Джолли (Charles Jolley), Управляющий Директор, Nisus Software
[26] (из Signal vs. Noise)
Говорит код
Слушайте, когда ваш код сопротивляется
Прислушивайтесь к своему коду. Он будет высказывать предложения. Он будет сопротивляться. Он расскажет, где стоят ловушки. Он предложит новые пути решений. Он поможет вам держаться модели меньшего объема программы.
Что, добавление новой функции требует недель времени и тысяч строк кода? Это код говорит вам, что, возможно, существует более легкий способ. Нашли более простое решение, которое можно воплотить за час вместо десяти? Это код вам подсказывает. Прислушайтесь.
Ваш код подскажет вам решения, которые дешевы и легки. Замечайте, когда появляется более простой путь. Разумеется, функция, которую легко сделать, может быть не в точности такой, какую вы себе представляли вначале – ну и что? Если она работает достаточно хорошо и оставляет вам больше времени на другие дела – оставьте ее.
Послушайте
Не беспокойтесь о дизайне; если вы прислушиваетесь к своему коду, хороший дизайн появится сам... Прислушивайтесь к техническому персоналу. Если сотрудники жалуются на то, как трудно вносить изменения — отнеситесь к этому серьезно и дайте им достаточное количество времени на исправления.
— Мартин Фаулер (Martin Fowler), Chief Scientist, ThoughtWorks
[27] (из Is Design Dead?
[28])
Если бы программистам платили за то, чтобы убирать код...
Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше.
— Николас Негропонте (Nicholas Negroponte)
[29], профессор медиа-технологий, MIT (из And, the rest of the (AIGA Conference) story
[30])