9 Критерии качества программы

      Комментарии к записи 9 Критерии качества программы отключены

Помечено: ,

В этой теме 0 ответов, 1 участник, последнее обновление  Васильев Владимир Сергеевич 2 мес., 2 нед. назад.

  • Автор
    Сообщения
  • #3585

    Когда-то давным-давно, в одной далекой-предалекой галактике, когда я сдавал в университете на первом курсе экзамен по программированию, у меня в билете был вопрос «Критерии качества программы». Я на него, естественно, не ответил. То есть, не ответил правильно, поскольку тогда у меня был только один критерий — «Программа работает». Шло время, и я постепенно начинал понимать, что для качественной программы этого мало.

    Мы не будем рассматривать такие банальные вещи как производительность, требуемый размер оперативной памяти, время компиляции, и так далее. По большому счету эти критерии не представляют собой особого значения.

    Для того, чтобы правильно оценивать качество программы, необходимо понимать, какие ресурсы расходуются при проектировании и программировании и какие при этом преследуются цели. Легко заключить, что идеальная программа, или идеальный подход к программированию это такая программа или такой подход, который позволяет достигать поставленной цели, затратив при этом минимальное количество ресурсов.

    Если вы не являетесь демосценером, кулхацкером, GNU-шником, БэХоЦе-шником или каким-либо другом фанатиком, а являетесь здоровым, полноценным и здравомыслящим человеком, то у вас должна быть одна конечная цель — создать конкурентноспособный продукт, выпустить его на рынок и заработать деньги. Для достижения этой цели, естественно, необходимо работать, то есть, затрачивать определенные ресурсы.

    В процессе создания программы затрачивается два типа ресурсов: время и деньги. При этом, ценность ресурса «время» я ставлю на несоизмеримо более высокий уровень нежели стоимость ресурса «деньги». Время — самый ценный ресурс. Тезис этот не мой, но я с ним согласен на все 120%. Да и в общем-то сомневаться тут и не в чем — потраченное время, в отличие от потраченных денег, невозможно восполнить. Помните старый советский кинофильм «Сказка о потерянном времени»?

    Время — не деньги!

    Чем меньше вы тратите каждый из отдельно взятого ресурса, тем лучше. Это очевидно и даже банально, поэтому не будем останавливать на этом наше внимание. Первый критерий, достойный внимания состоит в следующем. Чем шире спектр проблем, которые вы можете решить, затратив ресурс «деньги» там, где остальным приходится расходовать ресурс «время», тем лучше ваша программа.

    Следование вышеупомянутому критерию заставит вас писать легко масштабируемые программы. Предположим, в вашей программе два потока и она обслуживает одно сетевое соединение. Много ли изменений вам придется внести, чтобы ваша программа смогла так же стабильно работать в десятки тысяч потоков и столько же постоянно возникающих и обрывающихся сетевых соединений? Много?.. — Плохо! Мало?.. — Хорошо! Нисколько?.. — Прекрасно! Нисколько, и при этом нет никакого оверхеда на масштабируемость, так как вся масштабируемость заложена в compile-time-овых структурах, свойствах и механизмах, и имеет полноценный data driven подход?.. — Идеально!

    Зарисовка из жизни

    Вариант первый, как это обычно бывает:

    — Мне нужна программа!
    — Давай много денег и вот тебе уже и программа!
    — А теперь нужно чтобы эта программа обслуживала в сто раз больше пользователей!
    — Хм… Видимо придется все переписать… 🙁

    Вариант второй, уже неплохо:

    — Мне нужна программа!
    — Давай много денег и вот тебе уже и программа!
    — А теперь нужно чтобы эта программа обслуживала в сто раз больше пользователей!
    — Купи комп в сто раз мощнее 😉

    Вариант третий, и самый лучший:

    — Мне нужна программа!
    — Давай много денег и вот тебе уже и программа!
    — А теперь нужно чтобы эта программа обслуживала в сто раз больше пользователей!
    — Установи прогу на сто компов 🙂

    Лучше день потерять

    Цель никогда не бывает одна. После достижения первой цели появится вторая, после второй третья, и так далее. Например, целями можно назвать вывод на рынок новых версий программ. Отсюда следует следующий критерий. Чем больше процесс достижения текущей цели позволит вам сэкономить ресурсов во время достижения следующей цели, тем лучше ваша программа.

    Здесь речь идет о шаринге во всевозможных его проявлениях, а также о готовности программы к изменениям. Это и написание всевозможных движков и библиотек (то есть чтобы было что повторно использовать) и требования к культуре программирования (то есть чтобы повторное использование было легким и удобным) и так далее. Одним словом, критерий призывает тратить как можно меньше ресурсов на одноразовый код и как можно больше на повторно используемый.

    Помните мультик «Крылья, ноги и хвосты»? Была там такая фраза: «Лучше день потерять, потом за пять минут долететь». Эта фраза очень хорошо отражает процесс создания программного обеспечения. День потерять — создание движка (библиотеки, и так далее, то есть вновь используемого кода), за пять минут долететь — создание конкретной программы на движке (то есть одноразового кода).

    Вот, пожалуй, два основных критерия, от которых можно протянуть еще пару десятков производных. Резюмировать можно следующим образом: экономьте ресурсы, при этом в первую очередь — время. Лучше потратить деньги, чем время. Стремитесь к тому, чтобы работа, проделанная в прошлом, позволяла вам экономить ресурсы в будущем.

Для ответа в этой теме необходимо авторизоваться.