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