Дэниэл Лемайр, профессор Сomputer Science в Университете Квебека в Монреале (Канада), рассуждает о том, что чем проще код, тем лучше. Судя по комментариям к колонке, дискуссия вокруг принципа проектирования KISS («Keep it short and simple») будет продолжаться всегда. 
В детстве я был тем самым «ботаном» и очень любил тратить кучу времени на чтение. Тогда у нас не было интернета, мы даже не могли себе это вообразить, поэтому я пополнял свой словарный запас, читая справочники и энциклопедии. В итоге мой вокабуляр был довольно странным для ребёнка. Я мог легко жонглировать сентенциями, которые никто вокруг меня не мог понять. А взрослые, конечно, вознаграждали меня особым вниманием, когда я использовал неизвестные им слова.
Программировать я тоже научился относительно юным, быстро впитав всю информацию, которую нашёл. Когда я узнал о структурированном программировании, то отверг все «более примитивные» методологии. Затем я познакомился с объектно-ориентированным программированием - и это был конец структурированного программирования. Потом я получил представление о функциональном программировании и подумал, что снова достиг другого уровня. А позже стал фанатом метапрограммирования. И так далее.
В этом не было ничего хорошего. Я по-прежнему использую иногда «длинные слова», но не специально. По большей части я стараюсь писать короткими и простыми предложениями.
Мне потребовалось много времени, чтобы понять, что тот же принцип верен и для программирования. Если вы можете написать программу, используя только простейший синтаксис, это победа.
Тут я должен объяснить. Конечно, если вы используете более обширный словарь, длинные и «напыщенные» предложения, многие люди будут думать, что вы умнее. Похожая штука срабатывает и в программировании. Если вы можете запилить метапрограммирование, чистое функциональное программирование, немного Ассемблера и нейронную сеть в одну программу, то многие программисты будут впечатлены вашими навыками.
Однако есть и минусы. Ваши очевидные умственные способности не впечатляют тех, кто «тоже так может». Я встретил немало студентов и преподавателей, преуспевших в использовании слов, о существовании которых знает только 1% населения, и таких же имён философов, но в какой-то момент это перестаёт работать. Собеседники просто закатывают глаза и идут по своим делам. Если у вас собеседование с Джеффом Безосом или Питером Тилем, цитирование известных людей или использование «длинных слов» может вызвать не тот эффект, который хотелось бы.
Точно такой же аргумент работает и для программирования. Вы могли бы поразить сверстников своим умением использовать замыканий в Javascript и ряде других языков с функциональными чертами, но это уже не так впечатлит людей, которые уже несколько десятилетий знают, что это такое. Вы никак не убедите Линуса Торвальдса, что вы хороши, потому что используете все возможности последних языков программирования.
Если вы привыкли «казаться умным», то в конечном счёте можете попасть впросак и даже не понять, что происходит. Существует разница между быть и казаться, как известно, и у действительно умных людей нет необходимости в последнем.
Длинные слова и «причудливые» методы программирования являются... асоциальными. Они превращают вас в изгоя. Даже люди, которые считают, что вы действительно умны, устанут работать с вами. Раздражает сотрудничество с программистами, которые пускают в ход тяжёлую артиллерию всякий раз, когда предоставляется хотя бы маленький шанс.
Сложность плохо масштабируется. Намного проще продолжать начатую работу, свою или чужую, если заложена простая и понятная основа. Есть причина, по которой мы все еще преподаём три закона Ньютона: они сильны, потому что их можно выразить так просто. Простой фрагмент кода легче использовать повторно. Мне нравится концепция «упрощённого программирования», под которой я имею в виду настолько простой код, что найдутся желающие покритиковать его простоту. Поначалу это звучит странно: можно ли вообще критиковать кого-то за излишнюю простоту? Конечно, можно.
Paul Gehrman. Полностью согласен. Самая большая проблема — количество хипстеров, влившихся в ряды программистов. Они всегда пытаются ухватиться за самые новые тенденции (ORM, TDD и т. д.). И они не способны контролировать свой нарциссизм. Другая проблема заключается в том, как программирование преподаётся в наших школах. Оно оторвано от реальности и от решения настоящих проблем эффективным образом.
MaverickDoe. Есть причина, по которой были изобретены более сложные программные парадигмы. И это было сделано не для того, чтобы выглядеть или звучать умно. Это было решение проблем, унаследованных программистами, которые оказались вынуждены пробираться через горы неуправляемого кода. Выбор этого пути часто может привести к коду, который повторяется повсюду, трудно модифицируем без нарушений других частей системы и т. Д. И я часто слышу: «О, всё в порядке, мы отрефакторим его позже, если это станет необходимым». Я ещё не видел программиста, которому всегда давали бы время для рефакторинга кода, который «и без того работает, а значит, не трогай».
Steve Naidamast. За свои 42 года в разработке я всегда придерживался правила, которое всячески продвигалось в мои дни мейнфреймов: пишите для наименее опытного человека, которому может понадобиться поддерживать ваш код. Это правило всегда сохраняло мой код очень лёгким для чтения и поддержки. Чего ещё желать хорошему техническому менеджеру?
vladest. Если вы считаете, что простые реализации одинаково полезны, подумайте дважды. Если вы выберете быстрый и лёгкий путь, как сделал Вейдер, вы станете на тёмную сторону.
Igor Sarcevic. Написание простого кода на самом деле очень сложное занятие. Вы должны иметь дествительно глубокое понимание базовых концепций. Переход от сложных идей к более простым — это, как правило, признак технической зрелости. Она приходит со временем, спустя много лет написания кода.
Kyle. Фокус на «простом коде» также может быть ловушкой. Хороший код — это баланс между выражением ваших намерений и минимизацией сложности. Чем меньше кода, тем лучше, даже если код при этом более сложный. В то же время, избыточная сложность уменьшит преимущества, получаемые от сокращения объёма кода. Как правило, после того, как вы отбросите все вещи, которые МОГУТ однажды понадобиться, и определите необходимые ПРЯМО СЕЙЧАС, то можете выразить это в коде, используя краткие и простые конструкции.
Paul. Я не согласен с тем, кто меньше количество кода — это хорошо, даже если код при этом более сложный. Большая часть стоимости программы заключается в её поддержке. Если сложный код работает на миллисекунду быстрее, это не имеет особо значения. Но если вам потребуется больше времени, чтобы понять, что именно вы делали полгода назад (а у кого-то другого на это уйдут часы), тогда сложность обойдётся дороже, чем несколько дополнительных строчек кода. При этом, если скорость в приоритете, то сложность ради скорости приемлема. В целом более простой код лучше выражает ваши намерения. Особенно для кого-то, кто читает ваш код в первый раз.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.