Непонятные имена — это нечитаемая программа, а нечитаемую программу тяжело сопровождать.
Рассмотрим случаи, в которых может потребоваться рефакторинг имен:
Случай 1 — изменение правил. Можно составить разные правила образования имен и следовать сначала одним правилам, потом, уточнив эти правила, следовать другим. Неизменным должно оставаться только одно правило: все имена в проекте должны быть построены по одним правилам.
Случай 2 — частичный рефакторинг имен. Если по каким-либо причинам изменили правила составления имен, то следует обновить все имена, не подходящие под новые правила.
Случай 3 — невозможность однозначного предсказания будущего. Любой проект развивается. На этапе создания может оказаться, что спроектированная структура не полна или сначала предполагалась одна структура, а затем стала очевидной другая, более предпочтительная структура.
Случай 4 — рефакторинг имен, на ваш взгляд, не нужен: вы уже заканчиваете работу над проектом, не планируете в будущем его поддерживать и вам все равно, что о вас подумают люди, которым придется разбираться в вашем коде.
Квалифицированные программисты тратят некоторое время на вычищение своего кода для простоты его последующего использования. Ясность кода определяется ясностью имен данных, понятностью назначения и последовательности действий, ясностью имен процедур и объектов.
1.12. ПРОБЛЕМА ТИПОВЫХ ЭЛЕМЕНТОВ В ПРОГРАММИРОВАНИИ
Под типовыми элементами, или "кубиками", понимаются какие-то отдельно изготовленные типовые части, из которых можно было бы собирать множество программ. Проблема "кубиков" присуща не только программированию, и в разных областях она проявляется по-разному.
Область машиностроения наряду с такими "кубиками", как болты, гайки, оперирует множеством нетиповых элементов. Например, левое крыло и правое крыло автомобиля хотя и очень похожи друг на друга, но не могут быть взаимозаменяемыми и могут использоваться лишь в конкретной модели автомобиля. В области машиностроения значительные усилия проектировщиков расходуются на проектирование элементов. Количество элементов, из которых состоят получающиеся конструкции, обычно не превышает нескольких сотен.
Наиболее полно решена проблема "кубиков" в отрасли радиоэлектроники. Резисторы, емкости, лампы, транзисторы, микросхемы, ряды функциональных блоков являются стандартизованными и взаимозаменяемыми. В данной области проектировщики решают задачи синтеза искусственных систем из десятков и даже сотен тысяч элементов.
Программы являются наиболее сложными искусственными системами, у которых общее количество элементов (операторов) может достигать нескольких миллионов. Новые технологии программирования используют все новые и новые, как правило, более крупные, типовые элементы построения программ.
Первыми укрупненными типовыми элементами были подпрограммы. До сих пор библиотеки математических методов обычно поставляются в виде набора подпрограмм. Сложность даже простейшего, весьма распространенного такого типового элемента, как редактор текстов характеризуется уже десятком подпрограмм.
Для тиражирования таких элементов программ, как редактор текстов, система иерархического меню, элементов диалога типа "заполнения бланков" фирма "Borland Inc." предложила применять TPU — Turbo Pascal Unit (модуль OBJ в ряде языков). TPU-файл позволил использовать механизм сокрытия в секции Implementation неинтересных внутренних подпрограмм и внутренних данных и, наоборот, вне файла механизм сокрытия обеспечил открытость вызова только полезных для пользователя процедур и использование внутренних глобальных переменных, описанных в секции Interface. После этого нововведения программисту для использования, например, редактора, написанного не им, надо знать лишь информацию, описанную в секции Interface. Механизм сокрытия информации в пределах файла был введен еще в целый ряд компиляторов разных языков. Реализация механизма сокрытия упростила задачу использования "кубиков".
Объектно-ориентированные языки программирования дали четыре новых механизма использования кубиков:
1) механизм классов, порождающих при выполнении любое количество однотипных объектов, например, ряд однотипных кнопок;
2) возможность тиражирования объектов от породившей программы во все новые программы;
3) динамически линкуемые библиотеки с порождающими объекты классами;
4) механизм сборки программ из "кубиков" — объектов в процессе их выполнения.
Первый механизм облегчил развитие систем визуального программирования, при работе в которых значительная часть программы может быть создана путем отбора мышкой стандартных "кубиков".
Второй механизм привел к возникновению объектно-ориентированных СУБД, поставляющих программам не только данные, но и код, обрабатывающий эти данные.
Третий и четвертый механизмы позволили попытаться строить гибкие программы, обладающие свойством возможного развития при изменении условий их эксплуатации. Впервые возможность реализации получили идеи эволюционного программирования. Идеи прошлых технологий эволюционного программирования были явно недостаточными для обеспечения гибкости программ, что для длительного развития в изменчивой внешней среде требовало невозможного однозначного предсказания будущего. Согласно третьему механизму возникли СОМ-технологии. На основе четвертого механизма из базы готовых "кубиков П-объектов" создаются все новые "кубики" и из них новые программы.
Таким образом, в теории программирования проблема "кубиков" остается важнейшей проблемой, поэтапное решение которой уже позволило создавать самые большие по количеству составных частей искусственные системы — программы. Второй аспект проблемы "кубиков" — удешевление программных разработок за счет повторного использования во все новых программах частей, созданных в предшествующих разработках. Если есть "кубики", то в технологии программирования необходимо включить методы, облегчающие синтез цельных систем из отдельных "кубиков".
ВЫВОДЫ
• Проектирование — высокоинтеллектуальный процесс. Для понятия теории проектирования необходимо оперировать множеством терминов и определений, такими как проектная ситуация, технология, оптимизация программных разработок. Все это говорит о необходимости тщательно подходить к изучению словарного аппарата теории проектирования.
• Программы в основном представляют собой сложные системы из миллионов машинных инструкций. Сложность определяется четырьмя основными причинами: сложностью задачи; сложностью управления процессом разработки; сложностью описания поведения отдельных подсистем; сложностью обеспечения гибкости конечного программного продукта.
• При разработке программного обеспечения следует использовать следующие общие принципы: частотный; модульности; функциональной избирательности; генерируемости; функциональной избыточности; "по умолчанию".
• Одной из важнейших составляющих успешного проектирования является системный подход, предусматривающий всестороннее исследование сложного объекта.
• При создании и развитии ПО рекомендуется применять следующие общесистемные принципы: включения; системного единства; развития; комплексности; информационного единства; совместимости; инвариантности.
• В программировании существуют различные парадигмы, приводящие к разным подходам при написании программ: процедурно-ориентированный; объектно-ориентированный; логически-ориентированный; ориентированный на правила; ориентированный на ограничения; параллельное программирование, а также многие другие.
• Необходимо помнить, что проектирование неотъемлемо от различных стандартов (ГОСТ, ANSI, проекта) и их следует соблюдать как при оформлении документации, так и для унификации вашего проекта.
• Программы создаются, эксплуатируются и развиваются во времени, проходя свой жизненный цикл. Характерная особенность жизненного цикла ПО — отсутствие этапа утилизации.
• В процессе выполнения проекта предусматриваются отдельные моменты времени, которые характеризуются законченным оформлением результатов всех работ, выполненных разработчиками до данного момента. Согласно ГОСТ возможны следующие стадии разработки: ТЗ; ЭП; ТП; РП; внедрение. Возможны также и нестандартные этапы и стадии. Набор этапов и стадий отражает результаты проектирования самого процесса проектирования.