Блог

Через два часа мне предстоит побывать ведущим вебинара "Как с помощью инструментария разработчика сделать программный код эффективным" (зарегистрироваться и поучаствовать можно здесь). Докладчикам будет целая команда российского Intel (к двум изначальным презентерам из нижегородского центра, Екатерине Антаковой и Галине Санжарлинской, должен присоединиться кто-то из московского офиса).

В рамках личной подготовки в роли ведущего я решил немного вспомнить свое уже довольно далекое, но все же еще не забытое программистское прошлое. И я написал пару постов, с рассуждениями на тему Нужно ли бороться за эффективность программного кода? В каких случаях и зачем? Как? 2.0. И в последнем из них к разговору подключился еще один программист со стажем, Андрей Анненков.[spoiler] И хотя мы с ним давно знакомы и были даже в серьезных совместных делах, в этом разговоре при некоторых расхождению по некоторым вопросам, в одной теме у нас с ним вышло просто явное недопонимание, что называется на ровном месте.

Дело в том, что под словом "эффективный код" я (как, кажется, и мои сегодняшние собеседники) подразумеваю "хорошо использующий вычислительные ресурсы". Проще говоря, в данном случае "быстрый" (в первую очередь) и "занимающий минимум памяти" (во вторую).
Андрей же, напомнив классиков программирования (в первую очередь Йодана), сказал, что главной характеристикой программного кода, является не "эффективный", а "хороший". И что основная стратегия программирования заключается в создании "работающего кода", а уже потом – "эффективного".

Вот этого места предыстории хотелось бы продолжить.

Вот тут и заключается наше с ним недопонимание! Ведь мои посты были посвящены именно этому же тезису! По-моему, это хорошо видно из заголовка поста, где обозначен вопрос "Нужно ли…?"

Кто давно не перечитывал "Структурное проектирование и конструирование программ" Э.Йодана, или делал это давно, искренне советую перечитать. Хотя бы замечательную первую главу с рассуждениями о том, что такое "хорошая программа" и "хороший программист", с замечательной историей о суперпрограммисте, путешествующим в ньйоркской подземке.

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

На второй пункт хочу отдельно обратить внимание: тезис о "жизненном цикле" является не очевидным! Именно за него бились в 60-70-е годы классики программирования, доказывая, что нужно заниматься не только разработкой ПО, но и его поддержкой и развитием.

А раз вы тут разделили задачу на две части, отделив "цели" (создание ПО – техзадание) и выделенные на это ресурсы, то понятно, что проблема сводится к решению классической оптимизационной задачи. Которая, в свою очередь, может формулировать в двух разных поставновках:

1. Достижение целевого максимума при ограничениях на ресурсы
2. Обеспечения минимума ресурсов для достижения определенного целевого уровня.

В очень упрощенной и частной постановке вопроса:
1. Достижения максимального быстродействия при заданном времени разработки
2. Достижения нужного быстродействия за минимальное время.

Я думаю, что в 90% разработки ПО основной стратегией является вторая (о чем, кажется, писал и АА). Но есть и 10%, где нужно применение первой.

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

И еще один момент: обе задачи должны решаться в комплексе, в увязке.

Да, основной стратегией разработки ПО является создание работоспособного кода (функционал), а уже потом – достижение эффективности ("вылизование").

Но понятно, что для "вылизывания" нужно иметь такие возможности. Потому что вы можете использовать GW-Basic (который поставлялся в составе MS-DOS до версии 4) для быстрого написания кода по решению какого-то уравнения, а потом обнаружить, что создать из него машинный код невозможно (только в режиме интерпретатора).

Ровно, как и наоборот: выбрав Ассемблер для создания быстрой АСУ, вы изначально рискуете никогда проект не закончить…

В общем, с этих вопросов мне и хотелось бы начать сегодняшний разговор, через 1:30 (время летит…)