Есть такой принцип KISS (keep it simple). Я как-то затрагивал эту тему на выступлении, но тут еще не было. По моим ощущениям это основополагающий принцип, который кто-то недооценивает, кто-то не понимает. Предложу такую формулировку:
Целью является простота. Почему? Легко (дешево и быстро) изменять, а значит поддерживать. Если у нас продукт, а не разовая разработка, то поддержка важна.
Простота на первом этапе достигается через примитивизм (собственно, лозунг KISS).
При этом начиная с какого-то масштаба примитивизм приводит к сложности. Тогда, чтобы код оставался простым его нужно усложнять (уже вспоминаются DRY, паттерны проектирования и т.п.).
Крайне важно уметь ловить этот момент, чтобы не делать оба вида технического долга: слишком много кода из-за примитивизма и слишком сложный код из-за антипримитивизма.
В целом, простой код писать сложно. Это ремесло: нужен отработанный навык, чтобы сразу понимать где какую технику применить и где на что заложиться.
Это очень хорошо видно по студентам: им еще как-то удается сделать код работающим, но крайне редко простым.
Многие начинающие программисты снижают качество кода из-за того, что просто не успевают относительно других программистов. У них еще не хватает навыка сделать с первого раза хорошо, а на рефакторинг с размышлениями времени нет.
В итоге, простота кода – это прежде всего понятность. И это сложно.
Кстати, это относится и к уровню выше: приложению и изменяющимся требованиям во времени: при увеличении требований по качеству технический лидер (архитектор, если есть выделенная роль) должен постепенно так же “закручивать гайки”: вводить все больше практик, повышающих качество кода. Если этого не делать, то в какой-то момент начнется активный конфликт бизнеса и программистов: бизнес требует качество и не снижать заметно скорость, а программисты говорят, что у них 0 покрытие тестами и без заметных затрат увеличить качество поставок невозможно.