Качество в программировании

Есть такая мысля подготовить на работе учебный курс про то, как писать качественные программы™, а не убогие приложения®. Раскопал своих подвалов, перелопатил разных книжек по теме, повспоминал что-то из своей практики... Получается, что рецептов существует вагон, но глобальных принципов™ совсем немного. Братья-и-сёстры-программисты, посмотрите, пожалуйста, не забыл ли чего важного?

Начинать следует, по-видимому, с того, что такое качество применительно_к (вспоминаем Пирсига, конечно). Некий стандартный ответ таков: качественная программа должна обладать рядом свойств, как то: переносимость, надежность, эффективность, удобство использования, тестируемость, понятность, модифицируемость, универсальность (недостающее вписать). Из них конкретно для моей работы важнейшими я считаю понятность и модифицируемость.

Самый глобальный принцип, из которого следуют все другие, таков: будь проще! Широко известен под именем KISS. Не плодить сущности без необходимости (Оккам), упрощать до тех пор, пока возможно, но не более того (Энштейн), красота в простоте (все, кому не лень) и т. д. Простота с большой вероятностью положительно скажется не только на понятности и модифицируемости, но и на других свойствах.

Ясно, что простую программу написать труднее, чем сложную. Но как именно это сделать? Оставайтесь с нами...

Выбор подходящей парадигмы. Особенно важно в контексте PL/SQL, в котором переплетаются как минимум процедурное и декларативное программирование (есть и объекты, но они прикручены сбоку). Тут вспоминается Кайт со своей мантрой: всё надо делать на SQL, а уж если не выходит — тогда браться за PL/SQL.

Не повторяйся! Оно же DRY. Каждый фрагмент знания должен быть представлен в системе единственным образом, дублирование допускать нельзя (не только кода, но и всего вообще). Посвящается любителям copy-paste.

«Разделяй и властвуй», оно же функциональная декомпозиция (если идти сверху вниз), оно же абстракция (если идти снизу вверх). Лежит в основе структурного программирования (да и объектно-ориентированного тоже, да наверное и любого другого).

Ортогональность: концептуально независимые вещи должны быть независимыми и в реализации. Имеет смысл рассматривать вместе с предыдущим. «Разделяй и властвуй» говорит о том, что задачу надо дробить на части, а ортогональность объясняет, на какие и как они должны друг с другом взаимодействовать. Из этого принципа следуют стандартные советы минимизировать область видимости и вообще избегать побочных эффектов, разделение спецификации и реализации, взаимодействие через интерфейсы...

Ясность мысли. Код должен отражать смысл происходящего и быть выразительным. Здесь можно до бесконечности перечислять советы об осмысленности имён, небольшом уровне вложенности, форматировании кода, неиспользовании заумных конструкций и т. п.

Пожалуй, что и всё, если концентрироваться именно на простоте. Практически любой принцип можно рассматривать на разных уровнях (на уровне операторов, на уровне модуля, на уровне системы), при этом из них выводятся все известные советы по стилю программирования. Что думаете?