Архитектура программ и прибыль

Архитектура программ напрямую определяет прибыль, которую можно получить от заказчика за разработку программы. Чем лучше архитектура, тем больше прибыль и меньше проблем.

Задача архитектора – создать архитектуру достаточно гибкую и модифицируемую, но не чрезмерно гибкую. Обе границы гибкости грозят проблемами и неприятностями.

Слишком жесткая архитектура будет дорого стоить при модификации (тут мы сильно отличаемся от строителей – в программы часто требуется добавлять новую функциональность). Например, наша программа берет данные из MS Excel 2007. Все работало замечательно, пока не вышла версия MS Excel 2010. Конечно, заказчик хочет добавить в систему поддержку новой версии и вот тут его и ждет сюрприз. Архитектор системы настолько жестко привязался к бинарному формату версии 2007, что для поддержки XML формата версии 2010 требуется фактически переписать всю систему заново. И цена этой работы получится соответствующая – как минимум больше половины стоимости исходной работы. Я думаю, вы будете примерно также удивлены, если вам скажут, что на вашу машину не ставятся зимние шипованные колеса и для того, чтобы можно было ездить зимой, нужно поменять всю машину или, как минимум, кузов и привода. "Кое-что из приборов и руль, наверное, получится не трогать, но остальное точно под замену", ‑ уверенно сообщает вам мастер на авто-сервисе.

Обратный вариант – слишком гибкая архитектура – тоже ничем хорошим не светит. Вы просили сделать вам автомобиль, а получили самолет-амфибию с возможностью ездить по дорогам. Ну т.е. ездить он, конечно, может. Но вот цена… ну и еще – чтобы по дорогам ехать нужно "немного сконфигурировать систему" – колеса привинтить, крылья отвинтить. "Не сложно, не переживайте, да и инструкция же есть. Да, вы этого не просили, но нам так было удобнее – вот будут у нас другие клиенты, а у нас уже готовы и самолет и корабль. Правда, нужно их немного доработать…" Хотя конечно, уверенности что новые клиенты будут, нет. С таким-то подходом… Меня очень напрягают программы, которые для своей работы требуют от меня совершенно не нужных мне действий, но это немного другой разговор, до него мы еще доберемся. Пока же я думаю, основную идею вы поняли – слишком гибко тоже плохо. Обычно это дорого и неудобно.

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

Нечетные числа

Чаще всего я вижу что проверку что число четное делают так:

 if (n % 2 == 0)

Тут проблем нет. А вот с нечетным часто получается засада. Проверка

 if (n % 2 == 1)

не работает для отрицательных числел, т.к. результатом n%2 для отрицательных нечетных чисел будет -1, а не 1. Но об этом постоянно забывают.

Правильно писать (n%2 != 0).

А вообще проще и надежнее проверять последний бит (n & 1 == 1). Да и выполняется эта операция быстрее. Но тогда нужно рассказывать студентам про биты... :)

Цитата

"– Oui, – расцвел Макс. И начал говорить. Иностранные языки Макс изучал одним и тем же манером: использовал свой язык как мачете, прорубаясь сквозь непроходимые дебри неправильных глаголов, времен и причастий. По мере того как он говорил, на лице дежурного сержанта выражение учтивого недопонимания постепенно сменилось выражением полного непонимания. Сотни лет потратили французы, чтобы приспособить свой язык, небо и гортань для производства той чудесной музыки, какую являл собой французский язык. А вот этот стоящий перед ним человечек каким-то непостижимым образом сумел превратить эту музыку в длинную цепочку диких, бессмысленных выкриков.
Дежурный сержант, потеряв вскоре терпение, прервал этот поток на полувыкрике.
– Что, что вы пытаетесь мне сказать?
– Что значит «что»? – не понял Макс. – Я же говорю с вами на французском языке!
Дежурный сержант, немного подавшись вперед, невозмутимо спросил:
– А сейчас вы тоже говорите на нем?
Этот болван даже не понимает своего родного языка, подумал Макс."

"Узы крови.", Сидни Шелдон.

P.S. Это я к чему - мало выучить синтаксис языка. Надо еще научиться на нем писать программы.

Вопросы по курсу Технология проектирования

Модно нынче стало автоматическое тестирование... Начал вот вопросы писать для курса Технология проектирования ПО.

1.       Жизненный цикл программного проекта.

a.       Разработка, не работает, получили бабла, забили нафиг.

b.      Анализ, прототип, разработка, тестирование, внедрение.

c.       Договорились об откате, ничего не делаем, сдали что есть.

d.      Нашли дураков, перезаказали им, ждем бабла.

2.       Для чего предназначен этап анализа?

a.       Для проведения анализа.

b.      Для сдачи анализов.

c.       Пройти флюорографию.

3.       Для чего предназначен этап проектирования?

a.       Для обучения рисованию маркерами на доске.

b.      Для проектирования.

c.       Показать что мы знаем слово UML и это круто.

4.       Для чего предназначен этап тестирования?

a.       Для сдачи тестов (каждый в команде выбирает свой тест).

b.      Чтобы убедиться что ничего не работает.

c.       Чтобы убедиться что хоть что-то работает.

d.      Для понимания что же мы сделали.

5.       Для чего предназначен этап внедрения?

a.       Для внедрения шпионов и жуков заказчику.

b.      Для поиска нефти  в недрах.

c.       В недрах тундры выдры в гетрах тырят в вёдра ядра кедров.

d.      Для установки сделанного заказчику.

6.       Для чего предназначен этап сопровождения?

a.       Чтобы заказчик не отвертелся.

b.      Чтобы ничего не упало.

c.       Чтобы еще напилить денег.

7.       Что такое проект?

a.       Договоренность с заказчиком о получении денег

b.      Договоренность с заказчиком о решении его проблемы за деньги

c.       Сговор сотрудников, желающих заняться программированием

8.       Кто такой менеджер проекта? Чем он занимается?

a.       Пьет кофе и говорит по телефону

b.      Выбивает деньги и потом их же и получает

c.       Руководитель команды

d.      Если не можешь остановить бардак, возглавь его

Стиль кодирования

Что такое стиль кодирования

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

Наверное, все в школе писали сочинения. Так вот, сочинение, или, другими словами, изложение своих мыслей на бумаге, ничем не отличается от написания кода! Код – это такое же изложение мыслей, только вместо букв русского языка используются специальные коды. Ведь даже название соответствует – язык программирования.

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

При написании текста у вас нет никаких шансов обойти правила грамматики и правила оформления текста, если конечно вы хотите, чтобы ваш труд читали. Вы соблюдаете падежи, расставляете знаки препинания, выделяете абзацы. Если текст большой, вы разбиваете его на главы, параграфы и т.д. Глядя на текст, записанный без знаков препинания и единым монолитным блоком, на меня накатывает такая тоска, что и читать его не хочется. Написание кода не отличается ничем. Правда желающих увильнуть от правил оформления и написания кода значительно больше. Кто-то пытается написать код в один блок, а то и в одну строку… Кто-то экономит место в тексте сокращая имена и названия переменных до совершенно не понятных… А ведь даже простое разделение кода на блоки с помощью пустых строк, значительно упрощает чтение кода, как разбиение на абзацы упрощает чтение текста.

Правила написания кода называются стилем кодирования (code style). О нем я и хочу поговорить в этой лекции.

Почему важно писать код понятно

Конечно, вы можете сказать – ну а зачем мне надо писать код понятно? Разумеется, это "надо" зависит от ваших целей. Если вы пишите текст для себя, а книги "в стол" и никому не собираетесь их показывать – пишите как хотите, тут правила не нужны. Если же вы рассчитываете на продажу своих книг и всемирное признание – пишите так, чтобы читатель мог вас понять и оценить ваш талант.

Если вы пишите код для себя, просто из интереса – пишите как хотите, лишь бы вам было приятно. Если же вы работаете в команде, то пишите по правилам. Почему? Представьте, что вы написали насколько удивительный и прекрасный код, что на его понимание вашему коллеге потребовалось полчаса времени. А в проекте работает 10 человек. И вот на один кусочек кода 300 минут рабочего времени улетело в трубу. Еще один такой кусочек – еще столько же. А в рамках большого проекта эта цифра вырастает в дни и недели, и прибыль, как я рассказывал, утекает прямо из рук. Причем ничем не обоснованно. Просто вы так написали код.

Кто не согласен считать деньги, просто представьте себя на месте пациента, которому врач говорит, что не может его полечить, так как его лечащий врач ушел в отпуск, а в карточке болезни записал такое, что и понять нельзя. Или надо еще раз пройти все анализы или ждать, пока ваш врач выйдет из отпуска. Мне кажется, это не очень-то хорошо и приятно. А легко ли будет новому человеку, пришедшему в ваш проект, влиться в команду и начать приносить пользу? А легко ли будет заменить вас на проекте на время вашего отпуска? Если нет, значит это ваша проблема в первую очередь. Если, конечно, вы собираетесь вообще ходить в отпуск и не собираетесь работать на одном и том же проекте годами (а проекты, бывает, идут и по десятку лет!).

Очень хочу чтобы вы поняли меня правильно. Я не говорю, что нужно писать такие примитивные книги, чтобы их понял кто угодно, даже тот, кто не в теме. Я не говорю, что нужно писать такой код, чтобы было понятно даже школьнику. Вовсе нет. Я надеюсь, вы понимаете, чем отличается "примитивно" от "понятно" и "интересно". С кодом то же самое: код должен быть понятен и прост, но не примитивен.

Права

C++ на первом курсе это жестоко

После перерыва в 6 лет снова начал писать на C++ (раньше писал на нем больше 10 лет). После C# впечатление шага назад.

Одно не пойму - зачем на 1 курсе давать C++. Язык сложный, очень гибкий...

На C# я могу объяснить, что вывод на консоль это Console.WriteLine. А на C++ мне надо объяснять что такое using namespace, что такое include и т.д. и т.п. И дальше выбор - или идти с cout и объяснять модификаторы, либо с printf, что ничем не проще.

А ввод с консоли это вообще отдельная песня...

Или вот вызывают pow(i, 2). Если i типа int, то компилятор говорит что не может выбрать метод между параметрами double и float. Студенты от этой ошибки просто шалеют. Или pow(i, 1/3) - тут другая радость. Разумеется что 1/3 приводится к целому и ничего не работает. Объясняю что надо писать (float)1/3, чтобы им было понятно что это дробь и компилятору тоже. Мне это понятно, но человеку только пришедшему... хорошо если с pascal в запасе... вот так вот по голове...

Рассказал что if (a=1) это типовая ошибка. Что & и && это разные опреаторы. Разумеется не помогает. Все равно ошибаются.

Точки-с-запятой и скобки

Некоторым студентам так понравилось ставить точки-с-занятой после конца строки, что они подошли к вопросу с излишним фанатизмом.
В результате получаются такие конструкции:

if (a == b);
{
  // выполнится не зависимо от условия
}

Или так:

for (int i=0; i<10; i++);
{
   // выполнится один раз, без цикла
}

Ну и со скобками в блоках конечно тоже беда:

for (int i=0; i<10; i++)
  a++;
  b++;

К сожалению, выравнивания еще мало - надо бы еще скобки блока поставить. Иначе b++ в цикл не войдет.