К хорошим постам habrahabr.ru/post/135340/ и habrahabr.ru/post/171261/

• Почему большинство программистов не любят «читать чужой код»?
• Почему рефакторинг и внесение изменений становятся серьезной проблемой?
• Почему так часто случается, что легче переписать с нуля?
• Почему одни программисты называют других хорошими или плохими словами?

Конечно, многие из вас обнаружат, что предлагаемые ниже ответы на эти вопросы весьма знакомы, но возьмите эту статью на заметку, так как кидать линк зачастую все же существенно комфортнее, чем распинаться в объяснениях и доказательствах очевидного.

• Лапша
• Абстрагирование
• Слабосвязная архитектура
• Код из головы?

Лапша

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

Казалось бы, можно возрадоваться, но есть два обстоятельства из суровой реальной жизни, не заметных за розовыми очками.
1. Любая программа содержит ошибки. Поэтому ее нужно сопровождать.
2. В любую программу рано или поздно нужно вносить изменения. Поэтому ее нужно сопровождать.
3. Любая программа или ее части могут стать компонентами другой программы. И оригинальные решения придется сопровождать.

Каждую программу имеет смысл писать с учетом того, что некто будет сопровождать ее. Ваш код будут читать другие программисты, и только по вашему коду они будут делать выводы о вашем моральном облике. Аксиома, не правда-ли?

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

Так бывает, когда в одном компоненте одновременно находятся:
— финальный вывод и получение данных;
— обработка данных заведомо различной природы;
— развернутые алгоритмы в телах вложенных условий.

На самом деле, казалось бы, зачем выносить в отдельный метод (функцию) код в пару строк? Для кого-то это будет удивительным, но смысл в этом есть.

Абстрагирование

Сильнейшим приемом программирования является абстрагирование — разделение программы и всех ее компонентов на части.

• Бизнес-логика приложения распределяется по системе классов, исходя из предметных сущностей, функционала, этапов и типов обрабатываемой-передаваемой информации (MVC)
• Приложение состоит из нескольких практически несвязанных компонентов. Часто они даже пишутся на разных ЯП, и взаимодействуют через API. Например, для толстой игрушки — слой БЛ, физика, звук, растеризатор. Физика и графика — Ogre на С++, бизнес-логика, GUI и звук — Lua или Python. Для веб-сайта — раздельные компоненты веб-сервера, интерпретатора, CMS на интерпретируемом языке, отдельных программ для обработки изображений и видео, драйвер и движок БД.
• Внутри одного класса разделение действий на разные методы (функции) по функциональному признаку. Отделены приватные методы, хотя бы для того, чтобы обозначить процессинг данных, актуальный только для внутренних целей класса, и информацию, имеющую значение и ценность для пользователя класса.

Слабосвязная архитектура

Слабосвязная архитектура — это медвежья сила в программировании. Именно благодаря ей на свет появились, например, такие хорошие вещи, как CodeIgniter, YII, jQuery, Chomium, Half Life, Counter Strike — список огромен.

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

Например, в классе выделяется одна или несколько, заведомо малое количество «диспетчерских» функций, которые для выполнения задач вызывают другие, в том числе приватные методы класса.

Высокоуровневые примеры известны всем пользователям фреймворков — есть наборы компонентов, которые можно применять или не применять в зависимости от реальных потребностей.

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

Тут есть еще одна сильная сторона — именно центральному компоненту имеет смысл посвящать большое количество внимания, и таким образом вероятно экономится время на документирование и комментирование остальных. Сама по себе возможность расставить приоритеты позволяет экономить время.

Удачным решением является применение слабосвязной архитектуры на различных уровнях приложения. Тогда даже самая сложная схема Data Flow будет легкочитаемой.

Код из головы?

Всегда присутствует сооблазн сесть, и написать решение одним махом, из головы. Сам этим часто грешу.

На этапе написания кода в большинстве случаев проблем не возникает. Проблемы появляются потом — освещено в начале статьи.

Главным неприятным последствием всех проблем является потери времени. Зачастую эти потери времени огромны и фатальны по своим последствиям. А предупредить и минимизировать их не так уж сложно.

Тут имеет смысл сделать паузу и рекомендовать набрать в гугле фразу «проектирование программ». Все найденные методы будут графическими, простыми и доступными для понимания.

Смысл прост:
— уделив большее внимание анализу задачи,
— отделив при анализе методы (в том числе программирование, фреймворки, алгоритмы) от целей,
— не выделяя слишком большой приоритет какому-то одному из элементов на схеме выше («нам важно все»),
… экономим огромное количество времени, денег, сил, а также прокачиваем собственную репутацию в глазах коллег.

Проектирование программ — не менее важный и полезный этап, чем освоение ЯП, знакомство с библиотеками, фреймворками и технологиями.

Можно весьма сильно продвинуться вперед, и эффективно решить проблемы, обозначенные выше, уделив достаточное внимание этому прекрасному аспекту программирования.