анні ООП саме по собі є кроком вперед на шляху до легкого розуміння устрою (дизайну та архітектури) системи. Як вже було сказано, осмислені імена класів і методів можуть сильно допомогти людині розібратися в коді, оскільки поняття, якими оперує система (її об'єкти і дії), присутні в коді. Таким чином, якщо людина знає, що робить програма, то йому буде відносно легко зрозуміти, як вона це робить, тому що він зможе орієнтуватися в коді за назвами, що збігається з поняттями, присутніми в інтерфейсі програми (і/або в предметній області).
Однак часто буває так, що використовувати в коді повні назви важко - вони бувають, наприклад, занадто довгими або взагалі не оформляються інакше, ніж в поширеному реченні.
Під час розробки (особливо на її початкових фазах) люди швидко втомлюються вживати в розмові довгі терміни і придумують їм замінники, можливо, з іншої предметної області. Для складно описуваних понять має сенс виробити метафори, тобто короткі назви, що виражають суть поняття (можливо, за допомогою аналогії). p align="justify"> Метафори корисні як при описі предметної області, так і при описі деталей реалізації. Наприклад, назва В«спливаючийВ» для елемента, переміщуваного до кінця набору при бульбашкової сортування, вдало описує сенс алгоритму. br/>
Зростаючі складні системи
Багато факторів внутрішнього якості пов'язані з тими труднощами, які виникають при розвитку програмної системи. Лише невелика кількість програм створюється одного разу, передається замовнику і ніколи паче не модифікується. Велика частина програмних систем розвивається на тлі змінюються вимог, умов експлуатації та кола завдань, що вирішуються системою. p align="justify"> З досить невеликої програми може розвинутися дуже великий проект.
Це створює багато проблем, оскільки спочатку не можна передбачити всіх мінливостей, які очікують систему на життєвому шляху, як і всіх помилок, що здійснюються при її створенні.
Більшу систему вельми важко розвивати і підтримувати хоча б тому, що одній людині не втримати в голові всіх її особливостей. Тому не обходимо слідувати певним правилам (як В«у великомуВ», так і В«в маломуВ»), щоб надалі система була досить гнучкою.
Такий зовнішній фактор якості ПЗ, як функціональність, важко визначити однозначно. Тут в силу вступає так званий закон 80/20: "80% користувачів використовують тільки 20% функцій системиВ». Чому б не залишити тільки 20% і не викинути інші 80%? Справа в тому, що для кожного користувача ці 20% можуть складатися з різної функціональності. p align="justify"> Ця проблема стосується в основному коробкових продуктів, створювалися не для конкретного замовника, а для широкого кола користувачів.
Так чи інакше, більшість програм являють собою неухильно зростаючі складні системи, які потрібно розширювати, розвивати і...
