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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Права