випускати вчасно, і в цьому значною мірою допомагає хороший дизайн.
Метрики
Що ж все-таки таке В«хороший дизайнВ»? Формально кажучи, це такий дизайн, який з гарантією забезпечує досягнення гарного зовнішнього якості системи. Але є одна проблема: швидше за все, єдиного хорошого дизайну немає. p align="justify"> Ніхто досі не запропонував зводу правил, який би гарантував зовнішнє якість. Є лише деякі ідеї. Причому мова йде не тільки про дизайн, але і про архітектуру і про організацію розробки всього життєвого циклу ПЗ. p align="justify"> На практиці необхідно хоча б відрізняти поганий дизайн. Для цих цілей існують численні метрики: кількісні характеристики систем, нібито відображають їх внутрішню якість. Ось деякі приклади метрик:
В· Середня (або максимальна) довжина методу в рядках. Треба прагнути до зменшення цієї величини.
В· Кількість доступних клієнтам елементів класу. Теж варто зменшувати, оскільки з надто великим API важко працювати.
Запропоновано досить багато метрик. Деякі з них дійсно корисні як рядовим розробникам, так і людям, керуючим розробкою. p align="justify"> Існує ряд критеріїв внутрішнього якості, що не виражаються кількісно. Це скоріше принципи, ніж метрики. І від них, як правило, більше толку. br/>
Модульність
Для того щоб з великою системою можна було працювати, її доведеться розбити на частини. Це потрібно і тим, хто намагається зрозуміти, як вона працює (їм добре б зосередитися на одній такій частині, забувши про решту). І, звичайно, без цього не обійтися тим, хто створює систему: вони не зможуть ні придумати одне велике рішення для величезної проблеми, ні втілити його, якщо всі разом працюватимуть з усією системою разом. p align="justify"> Навіть середня програма не поміщається цілком в голові у однієї людини, тому необхідно розбивати програми на невеликі частини. Будемо називати такі частини модулями. p align="justify"> Розбиття великої завдання на більш дрібні називається декомпозицією задачі. Розумно ділити систему на модулі так, щоб кожен модуль вирішував деяку щодо ізольовану завдання, опис якої можна утримати в голові. p align="justify"> Насправді поняття модуля на різних рівнях абстракції потрібно трактувати по-різному. Справа в тому, що дуже велику задачу варто розбити на завдання поменше, ці в свою чергу - на ще дрібніші, і так далі, поки розмір задачі чи не стане підвладний одній людині. p align="justify"> Кожне розбиття відповідає зниженню рівня абстракції, оскільки при такому В«подрібненніВ» завдання все більш і більш конкретизуються (термін В«конкретнийВ» - антонім терміну В«абстрактнийВ»). На кожному рівні завданню зіставляється якийсь модуль. Спочатку це підсистеми, потім, можливо, пакети, підпакети, і нарешті, класи. У будь-...
