Перевод поста "10 Programming Proverbs Every Developer Should Know" Кевина Панга. Оригинал тут
Поговорки выражают общеизвестные истины или жизненные уроки в короткой и запоминающейся форме. Я считаю, что это отличный способ вести дела - и в личной жизни, и на работе. Поэтому я выделил 10 поговорок, которые каждый программист должен иметь в своем арсенале.
1. Нет дыма без огня
Расслабьтесь, это, скорее всего, очередные учения у пожарников :)Плохо спроектированный код, как правило, имеет некоторые общие признаки:
1) Гигантские классы и/или методы
2) Большие блоки закомментированного кода
3) Дублирование логики
4) Глубоко вложенные if/else блоки
Разработчики часто называют это как "код с душком" (code smells), но я считаю, что термин "коптящий код " или "дымящийся код " больше выражает уровень опасности, которой обладает данный код. Если вы не исправите проблему, лежащую в основе, позже она вернется, чтобы сжечь вас.
2. Унция профилактики стоит фунта лечения
Хорошо, уговорили :) Автомобильная компания Toyota в 1980-х прославилась эффективностью благодаря революционному подходу к борьбе с браком. Каждый работник получил возможность остановить производство, если заметит проблему в своем секторе. Идея заключалась в том, что лучше остановить производство и исправить проблему как можно раньше, чем продолжать производство бракованных деталей, замена / починка / аннулирование которых позже обойдется гораздо дороже.
Программисты часто делают неверное предположение, что продуктивность = быстрое производство кода. Многие программисты принимаются кодировать без предварительного обдумывания дизайна. К сожалению, подход Leeroy Jenkins к разработке программного обеспечения приводит к неряшливому и хрупкому коду, который требует постоянного контроля и патчей - даже, если требуется заменить всего одну строчку. Таким образом, производительность должна измеряться не только временем, которое затраченным на написание кода, но и временем, затраченным на его отладку. Быстрый выигрыш может обернуться дорогостоящими потерями, если не быть осторожным.
3. Не кладите все яйца в одну корзину
Bus factor для команд разработчиков определяется как "общее количество ключевых программистов, недееспособность которых (например, если попадут под автобус) повергнет проект в такой хаос, что его дальнейшее развитие станет невозможным."
Иначе говоря, что произойдет, если вы потеряете главного разработчика команды? Будут ли дела идти как обычно дальше или всё остановится?
К сожалению, большинство команд разработчиков ожидает второй вариант. Такие команды превращают своих программистов в доменных экспертов, которые занимаются только теми вопросами, которые попадают в область их компетенции. На первый взгляд, это довольно разумный подход. Если такое работает в автомобилестроении, почему бы и не для команд разработчиков? В конце концов, неразумно ожидать, что каждый член команды будет разбираться во всех нюансах, имеющихся в приложении, да?
Проблема в том, что разработчика нельзя просто взять и заменить. Этот метод хорошо работает до тех пор, пока все члены команды вместе, но сразу же перестает работать, как только доменный эксперт выбывает из команды из-за перехода в другое место, болезни или если его вдруг собьет автобус. Крайне необходимо, чтобы команда имела резерв. Ревизии кода, парное программирование, общее владение - благодаря этим практикам каждый член команды хотя бы поверхностно будет знаком с другими частями разрабатываемой системы, а не только с той частью, разработкой которой он занимается.
4. Что посеешь, то и пожнешь
"Программист-прагматик" о теории разбитых окон:
Не оставляйте "разбитые окна" (неудачные конструкции, неверные решения или некачественный текст программы) без внимания. Как только вы их обнаружите, чините сразу. Если нет времени на надлежащий ремонт, забейте окно досками. Наверняка вы сможете закомментировать ошибочный фрагмент или вывести на экран сообщение "В стадии разработки", или использовать фиктивные данные. Необходимо предпринять хотя бы малейшее действие, чтобы предотвратить дальнейшее разрушение, и показать, что вы контролируете ситуацию.В двух словах: хороший код порождает хороший код так же , как и плохой код порождает плохой код. Никто не хочет разбираться в плохом коде, и никто не хочет уродовать красивый код. Пишите правильно, и у вашего кода будет гораздо больше шансов выдержать экзамен временем.
Мы видели, как безошибочные, функциональные системы быстро портились, как только окна начали разбиваться. Существуют и другие факторы, которые вносят свой вклад в порчу программ, и мы коснемся некоторых из них далее, но небрежность ускоряет порчу быстрее, чем любой другой фактор.
5. Поспешишь - людей насмешишь
Менеджеры, клиенты и программисты становятся более нервными с каждым днем. Все должно быть сделано, и сделано должно быть сейчас. Из-за этого все труднее бороться с соблазном использовать хаки и быстрые решения.
Нет времени для тщательного юнит-тестирования новой фичи? Ладно, это работает для одного написанного теста. Мы всегда сможем вернуться к этому позже.
Загадочная ошибка при обращении к свойству Y объекта? Обернем этот кусок кода в try/catch. Мы должны ловить рыбу побольше!
Знакомо? Все мы иногда делаем так. В некоторых случаях это простительно. В конце концов, у нас есть сроки и менеджеры с клиентами, которых надо удовлетворить. Но если начать злоупотреблять этим, то очень скоро вы погрязнете в ненадежном коде, полном хотфиксов, дублирующейся логики, непротестированных решений и оберточной обработки ошибок. Вы должны найти золотую середину межды "сделано" и "правильно сделано".
6. Семь раз отмерь, один раз отрежь
Термин "Гибкая разработка" слишком часто используется и злоупотребляется программистами как оправдания для пропуска фазы планирования /проектирования разработки программного обеспечения. Мы творцы, и поэтому мы получаем удовольствие, видя реальный прогресс в конечном продукте. Удивительно, что UML-диаграммы и case-средства не могу удовлетворить это желание. Поэтому мы, разработчики, зачастую начинаем кодировать без малейшего понятия, что мы делаем и куда мы движемся. Это как пойти обедать, когда еще не решил, куда хочешь пойти. Ты голоден и хочешь как можно скорее найти ресторан и заказать столик. Вместо этого, ты садишься в свою машину и думаешь, что по дороге что-нибудь решишь. В итоге, получается дольше, потому что ты ездишь зигзагами и остановишься в ресторане, в котором будут долго готовить. В конце концов, ты, вероятно, получишь свою еду :) , но, скорее всего, мясо будет не таким, как ты хотел, и все это займет больше времени, чем, если бы ты предварительно позвонил и заказал столик в ресторане, в который бы хотел пойти.7. Когда твой инструмент - молоток, то все похоже на гвозди
А ведь я говорил, что для этого проекта нужен Active Record! Программисты имеют склонность быть ограниченными в выборе инструментов. Если однажды что-то сработало для одного проекта, то мы будем настаивать в использовании этого же во всех последующих проектах. Изучить что-либо новое может быть трудно и, порой, безрезультатно. Мы думаем "Это будет проще, если я все сделаю, как в прошлый раз." Немного таких мыслей, и мы просто будем использовать то, что есть, даже если это не совсем подходит в данном случае.
Легко использовать то, чем умеешь пользоваться, но в долгосрочной перспективе лучше выбирать более подходящие инструменты. Иначе вы будете забивать квадратные колышки в круглые отверстия до конца вашей карьеры.
8. Молчание - знак согласия
I see nothing. Nuh-thing.Это связано и с теорией разбитых окон, и инертностью программирования, только в большем масштабе. Сообщество программистов именно сообщество. Профессия отражается на каждом. Чем больше плохого кода "на свободе", тем больше он преобретает статус кво. Если вы не пытаетесь хороший, чистый, отвещающий требованиям SOLID код, вам придется работать с ним день за днем сначала.
Кроме того, если вы увидели плохо спроектированный код, вы должны попытаться исправить это вместе с автором кода. Хочу отметить, в такой ситуации нужно использовать чувство такта. В общем, программисты признают, что не знают всего о разработке программного обеспечения, и оценят ваш жест. Мы все получаем пользу, когда помогаем друг другу. Закрывая глаза на проблемы, мы только усугубляем их.
9. Лучше синица в руке, чем журавль в небе
Есть время, когда нужно обсуждать архитектуру системы и возможные рефакторинги, а есть время, когда все это нужно реализовывать. Важно взвесить все за и против пересмотра чего-либо уже работающего только ради того, чтобы сделать это немного чище. Это, конечно, замечательная цель, но всегда будет иметься код, который вы хотите отрефакторить. Мир программирования слишком изменчив, чтобы держать код постоянно неустаревшим. Но в какой-то момент вы должны предоставить результат заказчикам. Вспоминается простой факт: невозможно делать две вещи одновременно. Чем больше времени вы проводите за рефакторингом старого кода, тем меньше времени остается на создание нового. Нахождение золотой середины очень важно для введения в эксплуатацию вашей системы в срок.
10. С властью приходит и ответственность
Программное обеспечение, бесспорно, стало неотъемлемой и важной частью нашей жизни. Поэтому практика разработки хорошего программного обеспечения важна как никогда. Одно дело, когда имеется ошибка в игре Пинг-пог, и совсем другое, если ошибка в системе навигации космических кораблей или в системе управления воздушными полетами. Slashdot недавно опубликовал статью, в которой рассказывается, как из-за незначительных сбоев в Google News акционеры потеряли $1.14 биллиона. Случаи, наподобие этого, показывают, какой властью мы наделены. Немного страшно представить, что код, который вы пишете сегодня, хотите вы того или нет, однажды может быть повторно использован в критически важной системе. Пишите соответственно.
1 коммент.:
класс
Отправить комментарий