Критерии за лош дизайн
Животът работи съвсем просто: често, за да бъдеш умен, просто не трябва да правиш глупави неща. Това важи и за разработката на софтуер: в повечето случаи, за да направите нещо добре, просто трябва да не го правите зле.
Повечето програмисти са имали опит с части от системата, които са бor лошо проектирани. Но още по-тъжно е, че повечето от вас ще имат тъжния опит да осъзнаят, че сте бor авторите на такава система. Искахме най-доброто, но се получи Howто винаги.
Повечето разработчици не се стремят към лоша архитектура и за много системи идва момент, в който започват да казват, че архитектурата им е ужасна. Защо се случва това? Архитектурният дизайн беше ли лош от самото начало or с времето стана лош?
Коренът на този проблем е липсата на определение за „лош“ дизайн.
Струва ми се, че най-важните качества за всеки програмист са разбирането за качеството на дизайна и причините за неговото „упадък“. Както в повечето други случаи, основното е да се идентифицира проблемът и решаването му ще бъде въпрос на технология.
Определение за „лош дизайн“
Ако решите да се похвалите с codeа си пред колега програмист, най-вероятно ще получите подигравки в отговор: „Кой го прави?“, „Защо е така?“ и „Бих направил нещата по различен начин.“ Това се случва много често.
Всички хора са различни, но вие все още пишете codeа за вашите колеги програмисти, така че в процеса на разработване на всяка функция винаги се нуждаете от фаза на преглед, когато други хора гледат вашия code.
Но дори ако много неща могат да бъдат напequalsи по различни начини, има набор от критерии, с които всички разработчици биха се съгласor. Всяка част от codeа, която удовлетворява изискванията си, но все още показва една (or повече) характеристики, е лош дизайн.
Лош дизайн:
- Трудно се променя, защото всяка промяна засяга твърде много други части на системата. ( Ригидност , Ригидност).
- Когато се правят промени, други части на системата се повреждат неочаквано. ( Чупливост , Чупливост).
- Кодът е трудно да се използва повторно в друго приложение, защото е твърде трудно да бъде изваден от текущото приложение. ( Неподвижност , Неподвижност).
И най-смешното е, че е почти невъзможно да се намери част от системата , която да не съдържа нито една от тези характеристики (т.е. да е гъвкава, надеждна и многократно използваема), да отговаря на изискването и в същото време дизайнът й да е лош .
По този начин можем да използваме тези три характеристики, за да определим недвусмислено дали даден дизайн е „лош“ or „добър“.
Причини за "лош дизайн"
Какво прави дизайна твърд, крехък и неподвижен? Твърда взаимозависимост на модулите.
Един дизайн е твърд , ако не може лесно да се промени. Тази твърдост се дължи на факта, че една единствена промяна на част от codeа в изтъкана система води до каскадни промени в зависимите модули. Това винаги се случва, когато един човек работи върху codeа.
Това веднага усложнява целия процес на търговско развитие: когато броят на каскадните промени не може да бъде предвиден от дизайнера or разработчика, невъзможно е да се оцени въздействието на такава промяна. Затова те се опитват да отложат подобни промени за неопределено време.
А това от своя страна прави цената на промяната непредсказуема. Изпequalsи пред такава несигурност, мениджърите не са склонни да правят промени, така че дизайнът официално става твърд.
В един момент вашият проект преминава „хоризонта на събитията“ и е обречен да попадне в „черната дупка“ на твърдата архитектура.
Нестабилността е склонността на една система да се повреди на множество места след една единствена промяна. Обикновено нови проблеми възникват на места, които концептуално не са свързани с мястото на промяната. Такава крехкост сериозно подкопава доверието в дизайна и поддръжката на системата.
Това обикновено се случваше, когато нямаше частни методи. Достатъчно е да направите всички методи публични и ще бъдете обречени на появата на крехка архитектура. Капсулирането помага да се справим с това на микро ниво. Но на макро ниво се нуждаете от модулна архитектура.
Когато даден проект има крехка архитектура, разработчиците не могат да гарантират качеството на продукта.
Прости промени в една част на приложението водят до грешки в други несвързани части. Коригирането на тези грешки води до още повече проблеми и процесът на ескорт се превръща в известно куче, което гони собствената си опашка.
Дизайнът е неподвижен , когато необходимите части на системата са силно обвързани с други нежелани детайли. Твърде много собствен code, собствени уникални подходи и решения.
Помните ли регистратора JUL, чиито разработчици измислиха свои собствени нива на регистриране без основателна причина? Това е точно така.
За да дадете на дизайнера представа колко лесно е повторното използване на съществуващ дизайн, достатъчно е да помислите колко лесно ще бъде използването му в ново приложение.
Ако дизайнът е тясно свързан, тогава този дизайнер ще бъде ужасен от количеството работа, необходимо за отделяне на необходимите части на системата от ненужните детайли. В повечето случаи такъв дизайн не може да се използва повторно, тъй като разходите за отделянето му надвишават разработването му от нулата.
Уместност
Всичко се променя, но всичко си остава същото. (китайска поговорка)
По-горе бяха повдигнати много добри въпроси. Какви са опасностите от крехките и твърди системи? Да, защото процесът на управление на такъв проект става непредвидим и неконтролируем. И цената е непосилна.
Как може един мениджър да даде or да не даде зелена светлина за добавяне на няHowва функция, ако не знае колко време всъщност ще отнеме? Как да приоритизирате задачите, ако не можете да оцените адекватно времето и сложността на тяхното изпълнение?
И How могат разработчиците да изплатят същия технически дълг, когато ние ще рейкнем в плащането му и не можем да разберем колко ще рейкнем, докато не рейкнем?
Проблемите с повторното използване на codeа or тестването също са много важни. Единичните тестове служат не само за тестване на някои предположения относно тестваната единица, но и за определяне на степента на нейната кохезия и могат да служат като индикатор за повторно използване.
Ето цитат от Боб Мартин за този случай: „За да използвате повторно codeа си, трябва да положите усorята за повторното му използване по-малко от разходите за разработване от нулата . “ В противен случай никой дори няма да се занимава с този въпрос.
Използването на принципи и модели на дизайн служи на една цел - да направи дизайна добър. Ако използването им не ви носи ниHowва полза (or обратното, нарушава принципите на „добрия дизайн“), тогава нещо във вашата зимна градина не е наред и може би инструментът е започнал да се използва за други цели.