|
© 2025
Александр Легалов
Содержание
Сколько можно жрать неправильные бутерброды?
|
|
"Неправильно ты, дядя Федор, бутерброд ешь..."
Из мультфильма "Простоквашино"
|
Разговоры о правильном питании идут издревле и постоянно. Формируются новые диеты, проводятся периодические лечения и голодания. Со временем появляются новые диеты, усложняется их состав, изменяется регламент поведения. Но все равно многие продолжают жрать неправильные продукты и толстеть.
Это же касается языков и методов программирования, что в свое время отмечено и Никлаусом Виртом [Wirth[Wirth] Долой "жирные" программы. - Открытые системы. СУБД. 1996. № 06.]. Начиная с достаточно простых подходов, они, при увеличении размера программ и необходимости поддержки требуемых критериев качества, разрослись до неимоверных размеров. Попытки преодолеть ожирение выросли в создание различных парадигм программирования.
Существуют два пути выхода из тупика: или положится на ИИ, который будет порождать на выходе ожидаемое решение, независимо от того, как оно будет реализовано внутри, или продолжать искать пути, обеспечивающие более здоровое формирование программ (более полезные продукты).
Говоря о процедурно-параметрической парадигме программирования (4П), я естественно ориентируюсь на второй путь, который, на мой взгляд, позволяет упростить как начальное формирование программы, так и обеспечить ее последующее развитие за счет добавления новой функциональности. Этому должна способствовать эволюционная расширяемость данных и кода, лежащая в основе обработки альтернатив.
Но нужна ли подобная гибкость, когда существуют инструментальные средства, обеспечивающие в настоящее время весь технологический стек процесса разработки ПО? Не приведет ли это без ответственной разработки к тому, что в большом проекте будет непонятно, что и где расширяется, потому что все может быть распихано по разным (и может даже логически не связанным друг с другом) модулям?
Можно на это сказать, что безответственная хаотичная разработка приведет к плачевному результату при использовании любых языков программирования и инструментальных средств поддерживающих разработку ПО. Контроль нужен в любой из ситуаций и при любых процессах разработки. Поэтому подобные аргументы наверное сразу стоит отбросить из общего анализа существующих технических приемов, имеющихся в арсенале программистов. Но если говорить о современном процессе разработки программ, то можно в нем выделить следующие особенности, определяющие существующие подходы.
Гибкая итеративной разработка, например, с использованием ООП, сопровождается использованием различных трюков. В частности, к таким трюкам можно отнести промежуточные прослойки из ОО паттернов проектирования, а также различные принципы типа SOLID. В результате внутренние архитектурные решения программы зачастую не совпадают с архитектурой предметной области и, при добавлении новой функциональности, постоянно пересматриваются, так как используемые комбинации паттернов могут не учитывать то, что предлагают дополнительные требования.
Помимо этого часто предлагается в качестве приема, повышающего качества кода, использовать рефакторинг. То есть, написали код, используя различные трюки, а затем начали его улучшать. Затем снова расширяем функциональность, а потом снова рефакторим. Подобные модификации кода возможно иногда необходимы, но вряд ли их можно постоянно применять. И при этом необходимо, чтобы применение поддерживалось гибкими инструментальными средствами, что для современных систем программирования, особенно на уровне языков, вряд всегда обеспечивается.
То есть, имеем либо проблемы с поиском нужных трюков в нужном месте, либо c лишними телодвижениями по модификации уже написанного кода. И то, и другое ведут к снижению эффективности процесса разработки ПО.
Исходя из этого мысли о том, что дальнейшая разработка языковых и инструментальных средств, минимизирующих использование трюков и рефакторинга, обеспечивающие при этом гибкое расширение функциональности программы и ее постоянное развитие, необходимы. А подходы, применяемые в современных системах программирования не очень-то с этим справляются.
Одним из ключевых моментов, определяющим гибкость и возможности эволюционного расширения программы, является обработка альтернатив, различным способом реализованная в языках программирования. Замена прямого анализа типов во время выполнения на использование динамического полиморфизма во многом способствовало популярности ОО подхода и вытеснению процедурной парадигмы из массовой практики. В настоящее врем для процедурного подхода, в связи с повышением интереса к Go и Rust, происходит некоторый рененсанс. Но в целом вряд ли используемая в них статическая утиная типизация предлагает настолько прорывные решения, которые могут полностью вытеснить ОО полиморфизм.
Процедурно-параметрический подход, на мой взгляд, обеспечивает более гибкую поддержку динамического полиморфизма. Однако в настоящее время отсутствует стек технологий, который мог бы поддержать его практическое применение в различных предметных областях. Имеется по сути один лишь язык ПП программирования, реализованный на базе C (PPC), который пока находится на стадии доводки. Однако его использование уже позволяет писать программы в новом стиле, что демонстирует их гибкую эволюционную расширяемость по различным направлениям. При этом создается впечатление, что ИИ быстрее расчухает, что можно писать код такими способами, которые позволят "молниеносно" развивать программу без использования дополнительных трюков. Поэтому, пока разработчики языков и инструментов проснутся, прикладным программистам остается только писать жирные программы...
Содержание
|