Основи конструювання (Software Construction Fundamentals)
Фундаментальні основи конструювання програмного забезпечення включають:
• Мінімізація складності
• Очікування змін
• Конструювання з можливістю перевірки
• Стандарти у конструюванні
Перші три концепції застосовуються не тільки до конструювання, але і проектування, і лежать в основі сучасних методологій управління життєвим циклом програмних систем.
1.1 Мінімізація складності (Minimizing Complexity)
Основною причиною того, чому люди використовують комп'ютери в бізнес-цілях, є обмежені можливості людей в обробці і зберіганні складних структур і великих обсягів інформації, зокрема, протягом тривалого періоду часу. Це міркування є однією з основних рушійних сил в конструюванні програмного забезпечення: мінімізація складності. Потреба у зменшенні складності впливає на всі аспекти конструювання і особливо критична для процесів верифікації (перевірки) та тестування результатів конструювання, тобто самих програмних систем.
Зменшення складності у конструюванні програмного забезпечення досягається при приділення особливої уваги створенню простого і легко читається коду, нехай і на шкоду прагненню зробити його ідеальним (наприклад, з точки зору гнучкості або проходження тих чи інших уявленням про красу, витонченості коду, спритності тих чи інших прийомів, що дозволяють його скоротити на шкоду розмірами і т.п.). Це не означає, що повинно обмежуватися застосування тих чи інших розвинених мовних можливостей використовуваних засобів програмування. Це передбачає "лише" надання більшої значущості читаності коду, простоті тестування, прийнятного рівня продуктивності та задоволенню заданих критеріїв, замість постійного вдосконалення коду, не оглядаючись на терміни, функціональність та інші характеристики та обмеження проекту.
Мінімізація складності досягається, зокрема, проходженням стандартам (обговорюються в темі 1.4 "Стандарти у конструюванні"), використанням низки специфічних технік (висвітлюються в 3.3 "Кодування") і підтримкою практик, спрямованих на забезпечення якості в конструюванні (3.5 "Якість конструювання") .
1.2 Очікування змін (Anticipating Changes)
Більшість програмних систем змінюються з часом. Причин цьому - безліч. Очікування змін є однією з рушійних сил конструювання програмного забезпечення. Програмне забезпечення не є ізольованим від зовнішнього оточення (як системного, так і з точки зору галузі діяльності, для автоматизації завдань і проблем якого воно застосовується). Більше того, програмні системи є частиною змінюється середовища і повинні змінюватися разом з нею, а, іноді, і бути джерелом змін самого середовища.
Очікування змін підтримується рядом технік, представлених в темі 3.3 "Кодування".
1.3 Конструювання з можливістю перевірки (Constructing for Verification)
"Конструювання для перевірки" (а саме такий сенс закладений в оригінальна назва даної теми) припускає, що побудова програмних систем повинно вестися таким чином, щоб сама програмна система допомагала вести пошук причин збоїв, будучи прозорою для застосування різних методів перевірки (і, до речі, внесення необхідних змін), як на стадії незалежного тестування (наприклад, інженерами-тестувальниками), так і в процесі операційної діяльності - експлуатації, коли особливо важлива можливість швидкого виявлення та виправлення виникаючих помилок.
Серед технік, спрямованих на досягнення такого результату конструювання:
• огляд, оцінка коду (code review)
• модульне тестування (unit-testing)
• структурування коду для і спільно з застосуванням автоматизованих засобів тестування (automated testing)
• обмежене застосування складних або важких для розуміння мовних структур
1.4 Стандарти в конструюванні (Standards in Constructing)
Стандарти, які безпосередньо застосовуються при конструюванні, включають:
• комунікаційні методи (наприклад, стандарти форматів документів і <оформлення> утримання)
• мови програмування і відповідні стилі кодування (наприклад, Java Language Specification, що є частиною стандартної документації JDK - Java Development Kit і Java Style Guide, що пропонує загальний стиль кодування для мови програмування Java)
• платформи (наприклад, стандарти програмних інтерфейсів для викликів функцій операційного середовища, такі як прикладні програмні інтерфейси платформи Windows - Win32 API, Application Programming Interface або. NET Framework SDK, Software Development Kit)
• інструменти (не в термінах середовищ розробки, але можливих засобів конструювання - наприклад, UML як один зі стандартів для визначення нотацій для діаграм, що представляють структура коду і його елементів або деяких аспектів поведінки коду)
Використання зовнішніх стандартів. Конструювання залежить від зовнішніх стандартів, пов'язаних з мовами програмування, використовуваним інструментальним забезпеченням, технічними інтерфейсами і взаємним впливом Конструювання програмного забезпечення та інших областей знань програмної інженерії (в тому числі, пов'язаних дисциплін, наприклад, управління проектами). Стандарти створюються різними джерелами, наприклад, консорціумом OMG - Object Management Group (зокрема. Стандарти CORBA, UML, MDA, ...), міжнародними організаціями з стандартизації такими, як ISO / IEC, IEEE, TMF, ..., виробниками платформ, операційних середовищ і т.д. (Наприклад, Microsoft, Sun Microsystems, CISCO, NOKIA, ...), виробниками інструментів, систем управління базами даних ит.п. (Borland, IBM, Microsoft, Sun, Oracle, ...).
Розуміння цього факту дозволяє визначити достатній і повний набір стандартів, які застосовуються у проектній команді або організації в цілому.
Використання внутрішніх стандартів. Певні стандарти, угоди та процедури можуть бути також створені усередині організації або навіть проектної команди. Ці стандарти підтримують координацію між певними видами діяльності, групами операцій, мінімізують складність (у тому числі при взаємодії членів проектної групи та за її межами), можуть бути пов'язані з питаннями очікування та обробки змін, ризиків і питаннями конструювання для перевірки та подальшого тестування. У поєднанні з зовнішніми стандартами, внутрішні стандарти покликані визначити загальні правила гри для всіх членів проектної команди, домовившись про терміни, процедури та інших значущих угодах, незалежно від ступеня формалізації процесів конструювання, зокрема, і процесів життєвого циклу, в загальному випадку.
2. Управління конструюванням (Managing Construction)
2.1 Моделі конструювання (Construction Models)
Моделі конструювання визначають комплекс операцій, які включають послідовність, результати (наприклад, вихідний код і відповідні unit-тести) та інші аспекти, пов'язані із загальним життєвим циклом розробки. У більшості випадків, моделі конструювання визначаються використовуваним стандартом життєвого циклу, застосовуваними методологіями і практиками. Деякі стандарти життєвого циклу, за своєю природою, є орієнтованими на конструювання - наприклад, екстремальне програмування (XP-eXtreme Programming). Деякі розглядають конструювання в нерозривному зв'язку з проектуванням (в частині моделювання), наприклад, RUP (Rational Unified Process).
Створено безліч моделей розробки програмного забезпечення. Ряд із них більшою мірою сфокусований на конструюванні програмного забезпечення, як такому.
Деякі моделі є більш лінійними з точки зору конструювання ПЗ. До них належать, наприклад, Водоспадна (waterfall) і поетапна (staged-delivery) моделі життєвого циклу (моделям життєвого циклу присвячена спеціальна глава, написана Сергієм Орликом і доступна як частина представлених тут "Основ програмної інженерії"). Ці моделі розглядають конструювання як діяльність, яка починає проводитися тільки після завершення певних обов'язкових до виконання (prerequisite) робіт, що включають детальне визначення вимог, детальний дизайн і детальне планування. Більш лінійні підходи намагаються підкреслити дії, що передують конструювання (тобто вимоги та дизайн) і створити більш чіткий поділ між такими різними типами діяльності. У таких моделях основним змістом конструювання може бути кодування.
Інші моделі більш ітеративний, до них відносяться - еволюційний прототипування, екстремальне програмування та Scrum. Ці підходи сходяться до розгляду конструювання як діяльності, яка ведеться одночасно з іншими видами робіт зі створення програмного забезпечення та перетинаючись з ними (мабуть, тут мається на увазі взаємозалежність і вплив один на одного), включаючи визначення вимог, проектування і планування. Ці підходи змішують проектування, кодування і тестування, часто розглядаючи їх комбінацію як конструювання.
Відповідно, що саме мається на увазі під "конструюванням" залежить певною мірою від своєї моделі життєвого циклу.
Планування конструювання (Construction Planning)
Вибір методу (методології) конструювання є ключовим аспектом для планування конструкторської діяльності. Такий вибір значущий для всієї конструкторської діяльності, а також необхідних умов її здійснення, визначаючи порядок відповідних операцій та рівень виконання заданих умов перед тим як почнеться конструювання або складові його дії. Наприклад, модульне тестування в ряді методів є частиною робіт, після написання відповідного функціонального коду, в той час, як ряд гнучких (agile) практик, наприклад, XP (до речі, першими почали використовувати такі методи верифікації коду), вимагають написання Unit-тестів до того, як пишеться відповідний код, що вимагає тестування.
Використовуваний підхід до конструювання впливає на можливість зменшення (в ідеалі - мінімізації) складності, готовності до змін і конструюванні з можливістю перевірки.
Планування конструкторської діяльності визначає порядок, в якому створюються компоненти та інші активи цієї галузі знань (фази діяльності), проводяться роботи по забезпеченню якості одержуваного програмного забезпечення, розподіляються * завдання і відповідні ресурси, в тому числі, визначаються призначення / відображення робіт конкретним інженерам-програмістам, членам проектної групи. Все це, звичайно, відбувається, дотримуючись правил, що визначаються використовуваним методом (методологією, практиками і т.п.).
* Зауважте - не розподіляють, а розподіляються, маючи на увазі процес, що призводить до забезпечення явного зв'язку між завданням і ресурсами. У нечітко регламентованих (це ні в якому разі не лайка, це визначення - адже існує ж поняття нечітка логіка, неструктуровані бази даних, наприклад, щодо нереляційних систем тощо) та неформальних методах, таких, як XP, члени проектної групи самі приймають на себе відповідальність за вирішення певних завдань, а "володіння" кодом є спільним на основі співробітництва, як одного з ключових принципів роботи проектної команди.
2.3 Вимірювання в конструюванні (Construction Measurement)
Більша частина результатів, та й самої діяльності з конструювання програмного забезпечення, може бути виміряна, в тому числі - кількісно. Це і вихідний розроблений код, і модифікований обсяг коду, і ступінь повторного використання, і багато інших характеристик. Ці виміри, або як їх ще прийнято називати - результати аудиту коду і метрики коду, несуть велику користь як для оцінки ризиків і якості (призводять до відповідних операціях зі зниження ризиків та підвищення якості), а також, для керування конструюванням і програмними проектами, в цілому. Про який плануванні може йти мова, якщо ми не здатні передбачити (наприклад, на основі оцінки результатів попередніх проектів) ні тривалість робіт, ні вартість окремих завдань, ні ймовірність виникнення дефектів проти заданих параметрів прийнятної якості?
Код є одним з найбільш чітко детермінованих активів проекту (поступово такими стають і моделі, що будуються на основі структур метаданих, і тісно пов'язані з кодом - наприклад, UML). Код є і самим носіям необхідної функціональності. Відповідно, застосування вимірювань щодо коду стає тим інструментом, який впливає і на управління і на сам код.
Останнім часом, велику увагу багато професійних розробники, тобто інженери-конструктори програмного забезпечення, приділяють рефакторинг коду, як методи його реструктурування, покликані без зміни змісту (тобто функціональності та функціональної цілісності) забезпечити вирішення завдань мінімізації складності, готовності до змін (гнучкості), прозорості документування і багатьох інших актуальних аспектів конструювання. Але, на жаль, багато хто забуває про необхідність мотивованості змін, навіть на рівні рефакторинга. Застосування вимірювань, зокрема, метрик, дозволяє визначити необхідність внесення таких змін, проведення рефакторинга. І не тому що "так, напевно, буде все ж краще, красивіше ...", а тому, що в ієрархії спадкоємства з 10 поколінь класів - 9 є абстрактними (" з любові до мистецтва "), а на 10-м ( в силу перевищень термінів проекту, після того, як довго і "в кайф" створювали архітектурно-красивий код) "повішено" 20 (!) бізнес-методів. Ось це - дійсно обгрунтована причина для рефакторинга, який, навіть із застосуванням найдосконаліших інструментів, разом з обмірковуванням необхідності рефакторинга, а потім, іноді, і боротьбою з його наслідками через неузгодженості членів команди (а це вже життя, навіть в самому ідеальному колективі, де люди розуміють один одного з півслова) часто є просто тратою часу. Якщо застосовується рефакторинг, але не застосовуються метрики - у переважній більшості випадків, це негативно впливає на проект. І таких прикладів робіт, що вимагають застосування вимірювань, але, на жаль, ігнорують їх, можна наводити досить довго. Ви, напевно, самі можете розповісти на цю тему багато прикладів з життя.
Чому "авторизований переклад" цієї теми SWEBOK виявився настільки емоційний? Практика автора показує, що в гонитві за "красою", розробники дуже часто забувають про мету їх роботи і сприймають діяльність з управління проектами (не буду сперечатися, іноді лише формальну, для "прикриття" все, що тільки можна ...) з боку менеджерів і , тим більше, будь аудит - як однозначну перешкоду "польоту думки". Даремно. Якщо все саме так йде у вашому випадку - проект, з великою ймовірністю, а іноді й просто, "якщо не станеться чудо", можна вважати хай і не провальним ("фуух ... не закрили ...."), те, напевно, вийдущім за рамки тих чи інших обмежень, будь то терміни, гроші, якість або, нарешті, час, який розробник міг провести з родиною. І не сидіти вночі, дописуючи функціональність або відловлюючи чергову помилку за кілька днів до передачі проекту в експлуатацію. Всі ці питання переслідують одну єдину мету - передбачуваність робіт і результату. І виміру - важливий інструмент досягнення цієї мети.
Область знань "Software Engineering Process" приділяє спеціальну увагу питанням вимірювань при створенні програмного забезпечення.
3. Практичні міркування (Practical Considerations)
Конструювання - діяльність, в рамках якої програмне забезпечення наводиться до угоди з довільними (іноді - хаотичними) обмеженнями реального світу, які вимагають від програмного забезпечення точного дотримання їх. Наближаючись до обмежень реального світу, конструювання (більшою мірою, ніж будь-яка інша область знань) ведеться на основі практичних міркувань і технік.
3.1 Проектування в конструюванні (Construction Design)
Деякі проекти передбачають більший обсяг робіт з проектування саме на стадії конструювання; інші проекти явно виділяють проектну діяльність у формі фази дизайну. Незалежно від чіткості виділення діяльності з проектування, як такої, практично завжди на стадії конструювання доводиться займатися і питаннями детального дизайну системи. Такі проектні роботи мають прагнення до вашого стійким обмеженням, нав'язуються конкретними проблемами, вирішення яких має бути забезпечене використанням конструюється програмної системи.
Деталі діяльності з проектування на стадії конструювання в основному ті ж самі, що й описані в галузі знань "Проектування програмного забезпечення" (Software Design). Відмінність полягає в більшій увазі деталям.