?

Log in

No account? Create an account

Ср, 24 мар, 2010, 00:34
Качество в программировании

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

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

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

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

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

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

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

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

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

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

Ср, 24 мар, 2010 01:13 (UTC)
pigdeon

Качество - вещь эфемерная, во-многом in the eye of the beholder. Но желающих за него подискутировать - навалом. Вот и этот туда же. Из зернистых мыслей могу добавить: "соблюдай границы архитектуры [программной системы]". Умельцы натянуть презерватив на глобус - найдутся.

Ср, 24 мар, 2010 09:32 (UTC)
hardsign

В рамках нашей работы¤ самое важное - архитектурный контроль. Чтобы был некто, у кого в голове была бы цельная картина мира, отход от которой в сторону карался бы немедленным расстрелом на 10 лет. Хотя это, скорее, средство, чем цель :)

Ср, 24 мар, 2010 10:32 (UTC)
egorius

Архитектура безусловно важна, но и в рамках самой распрекрасной архитектуры можно понаписать очумелого кода...

Ср, 24 мар, 2010 15:20 (UTC)
conjuncte

Как вариант - дать почитать каждому "совершенный код". Там таких мыслей - вагон. И тележка. И список литературы в придачу

Ср, 24 мар, 2010 21:13 (UTC)
egorius

Слишком она необъятная, чтобы дать «почитать». Мне же хочется ообойтись не вагоном мыслей, а основополагающей тележкой.
Кроме того, у нас языковой нюанс: PL/SQL. Основа, конечно, всё та же, но есть специфика, и примеры программ всё равно придётся подыскивать.

Чт, 25 мар, 2010 22:13 (UTC)
conjuncte

Если запишите на видео, поделитесь, пожалуйста, ссылкой :)

Пн, 19 апр, 2010 08:53 (UTC)
n1919

как написать простую программу если постановка задачи сложная ?

Пн, 19 апр, 2010 18:07 (UTC)
egorius

Есть методы. Сводятся они, в сущности, к одному: надо так или иначе разбить сложную задачу на несколько более простых. Тогда в каждый отдельный момент времени можно не думать о всей (сложной) задаче, а ограничиваться одной (простой) её частью.