Книга е още в много ранна фаза на написване
Изтегляне 13.53 Mb.
|
- Навигация на страницата:
- Стоим на курса
- Фаза 0: Да направим план
- Фаза 1: Какво ще произвеждаме
- Фаза 2: Как ще го направим
- Фаза 3: Да строим!
- Фаза 4: Итерация
- Планирането се изплаща
Анализ и проектиранеПарадигмата на обектно-ориентираното програмиране е нов начин на мислене за програмирането и много хора отначало се затрудняват как да подходят към проектите си. Сега като знаете че всичко се предполага да бъде обекти вие можете да създадете “добър” дизайн, такъв който ще донесе всички предимства които се предполага да дава ООП. Повечето от книгите посветени на ООП са пълни с дълги думи, тромава проза и важно звучащи декларации.9 Аз не споделям този начин мислейки че книгата би била по-добра като глава или най-много като много кратка книга и дразнейки се от схващането че този процес не може да се опише стегнато и директно. (Смущава ме, че хората, които претендират да управляват сложността се затрудняват да напишат проста книга.) Най-после, цялата работа с ООП е да се направи процесът на софтуерна разработка по-лесен и макар това да заплашва може би поминъка на хората, които консултират по въпросите на сложността, защо все пак нещата да не се направят по-прости? Така, надявайки се да съм възбудил здравословен скептицизъм у вас аз ще се стремя да ви предам моето виждане относно анализа и проектирането в колкото е възможно по-малко параграфи. Стоим на курсаПо време на процеса на разработка най-важното е: не се загубвай. Лесно е да се направи. Повечето от тези методологии са направени да решават най-големите проблеми. (Това има смисъл; тези са наистина много трудни проблеми които оправдават наемането на съответния автор като консултант и съответните му големи цени.) Запомнете че повечето проекти не попадат в тази категория, така че можете да имате успешен анализ и проектиране с малко подмножество от цялата методология в повечето случаи. Но винаги някакъв анализ и проектиране биха ви довели по-бързо до искания резултат, отколкото просто да седнете и да започнете да програмирате. Ще рече, че ако вземете методология, която има огромно количество детайли и изисква съответното количество документация, трудно е все още да се каже къде да спрете. Помнете какво се опитвате да откриете:
Ако се окаже че имате само обекти и интерфейси, може да започвате писането на програмата. Поради много причини може да ви трябват повече документи от споменатите, но трудно може да минете с по-малко. Процесът може да се проведе на четири фази и фаза 0 е просто да се реши първоначално каква ще бъде общата структура. Фаза 0: Да направим планПървата стъпка е да решите какви стъпки ще има във вашия процес. Звучи просто (фактически всичко това звучи просто) и ето, често, хората даже не обикалят до фаза едно преди да започнат писането на програмите. Ако вашият план е “да скочим и да почнем кодирането,” чудесно. (Понякога така е добре - когато имате добре разбран проблем.) Най-малкото съгласен съм, че това е план. Бихте могли да решите също, че някаква допълнителна структурираност на проекта е необходима, но не прекалено велика. По достатъчно разбираеми причини някои програмисти предпочита да работят в режим на “ваканция” където не се предполага никаква структура на процеса на тяхната работа: “Ще стане когато стане.” Това може да бъде провлекателно за малка, но аз съм открил, че наличието на няколко километрични камъка по пътя помага да се фокусират и циментират усилията по посока на тях, отколкото единствено до целта “завършване на проекта.” В добавка това разбива процеса на по-смилаеми парчета и го прави по-малко заплашителен. Когато аз започнах да изучавам приказката структура (така че някой ден ще напиша новела) първоначално се съпротивлявах на идеята, чувствайки че когато пиша просто написаното се излива върху страниците от само себе си. Това, което открих бе, че когато пиша за компютри структурата е сравнително проста и не изисква специално внимание, но аз все пак структурирах моята работа все пак, само полусъзнателно в моята глава. Така че даже и да мисбите, че плана ви е веднага да започнете кодирането, все пак минавате следващите фази задавайки си някои въпроси и отговаряйки им.
Необходимо е фокусът да остане върху това, което искате да направите в тази фаза: да определите какво ще се иска от системата да прави. Най-ценното в тази посока е колекция от т.н. “случаи на използване.” Това са основно описателни отговори на въпроси които почват с “Какво прави системата ако …” Например “Какво прави автоматичния (програмен -б.пр.) отговарящ ако клиентът е направил депозит в рамките на 24 и няма достатъчно пари в сметката за да му се изплати подаден чек?” Случаят на използване описва подробно какво ще се прави по-нататък. Опитвате се да откриете пълната система на случаи на използване на програмата и когато веднъж го постигнете сте се сдобили със сърцевината на това, което системата (целевата -б.пр.) се предполага, че ще прави. Хубавото на събирането на случаите е, че те винаги ви връщат към основните неща и ви предпазват от отклонения към неща, които не са критично важни. Тоест ако имате пълната система случаи вие можете да опишити вашата система и да преминете към следващата фаза. Вероятно няма да я получите перфекто очертана в тази фаза, но това е нормално. Всичко ще се разбули от самосебе си с течение на процеса на разработка и ако вие искате перфектно описание още на този етап ще се си отворите излишна работа. Както крачния стартер на мотоциклет помага в тази фаза, ако изложите нещата в няколко параграфа и проследите за глаголи и съществителни . Съществителните стават обекти и глаголите - методи в интерфейсите на тези обекти. Ще бъдете изненадани колко полезен инструмент може да бъде това; понякога то ще свърши лъвската част от работата вместо вас. Въпреки че едва започваме, в тази точка някакво разпределение на времето вече е полезно. Вече имате поглед върху това, което се строи така че вероятно ще може да направите оценка колко дълго ще продължи. Много фактори важат тука: ако изчислите дълго време за реализация компанията може да не приеме проекта или управителят може вече да е решил колко време ще трае и да ви се намеси в разписанието. Но най-добре е да си направите честно разписанието и да вземете трудните решения рано. Много опити е имало да се излезе с акуратни разчети на времето (подобни на техниките на предвиждане на борсовия пазар), но може би е най-добре да се осланяте на опита и интуицията си. След като сте направили оценка, която смятате за добраудвоете я и добавете 10%. Вашето чувство вероятно е точно; вие можете да получите нещо работещо за това време. “Удвояването” ще го направи прилично и десетте процента ще са за доизкусуряване и детайли на края. Обаче вие искате да го обясните и независимо от стоновете и манипулациите които ще се чуват, всичко ще стане за това време.
Най-успешното консултиране което съм давал беше на тим, който никога преди това не беше правил ООП проект, като рисувах обекти на черната дъска. Обсъждахме как обектите ще взаимодействат помежду си, триехме някои и рисувахме нови. Тимът (те знаеха какво се очаква да прави проектът) фактически създаде дизайна; те “притежаваха” дизайна наместо той да им е спуснат отвън. Всичкото което аз правех беше да водя процеса чрез задаване на точните въпроси, правех предположения и имах обратната връзка с тима за корекцията им. Красотата на процеса беше в това, че тимът се научи да проектира ОО не с разглеждане на абстрактни примери, а чрез работа над проект, който беше най-интересният за тях към него момент: техния. Ще знаете че сте свършили фаза 2 когато имате описанието на обектите и техните интерфейси. Е, повечето от тях – има по няколко, които се промъкват и стават ясни във фаза 3. But that’s OK. Трябва да откриете всички ваши обекти в края на краищата - това само ви засяга. Добре е да ги откриете рано, но ООП дава достатъчна база да ги включите и по-късно, ако ги откриете тогава.
След като построите (компилирате и свържете - б.пр.) системата, важно е да се направи реалистичен тест и тук е мястото където системния анализ и спецификация влизат в работата пак. Минете по цялата програма и проверете дали всичко е наред и работи както се обаква по списъка на случаите. Сега сте готови. Дали сте готови? Фаза 4: ИтерацияТова е моментът в цикъла на програмното осигуряване, който традиционно се нарича “поддръжка,” термин с всевъзможни значения който може да значи от “да се накара да върви по начина, който отначало се искаше от него” до “добавяне на черти, които потребителят забравил да спомене по-рано” и до по-традиционното “оправяне на грешки, които забавят” и “добавяне на нови черти както изискват появяващи се нужди.” Толкова много смесени концепции са прилагани към термина “поддръжка” че той се взема малко за развалящ качеството, частично защото казва че сте направили завършена програма и че всичко, което трябва да правите е да сменяте части, да я смазвате и да я пазите от ръжда. Може би има по-добър термин за описание на това, което става. Терминът е итерация. Тоест: “Не можахте да го направите точно от първия път, затова се върнете и си дайте труда да го проучите и подобрите.” Може да се наложат много промени като навлизате по-дълбоко в проблема. Елегантността, която постигате при това ще се изплаща и в краткосрочен, и в дългосрочен план при това. Какво значи “да се оправи” е - точно каквото програмата не прави точно според изискванията. Значи също, че вътрешната структура на програмата да има смисъл за вас и да създава чувството че всичко се сработва добре, без тромав синтаксис, прекалено големи обекти и несръчно изложени на показ парченца код. В добавка трябва да чувствате, че структурата ще оцелее след всички промени, които несъмнено ще има през време на живота на програмата, а и че такива промени ще стават лесно и евтино. Това не е малко постижение. Трябва не само да разбирате построеното от вас, но също и как програмата ще се развива (което аз наричам вектор на промяната). За щастие ООП езици са специално пригодни за този тип непрекъснати промени – границите създадени от обектите са това, което има тенденция да пази системата от сриване. Те също позволяват да правите промени, които изглеждат драстични при процедурното програмиране без да предизвиквате земетресение. Фактически поддръжката на итерацията може би е на-печелившата част от ООП. С итерацията може най-малкото да постигнете някакво приближение на желаното, след това спирате, сравнявате го с изискванията и набелязвате нови промени. После се връщате обратно и оправяте нещата с използване на парчета код.10 Може да имате в действителност да решавате проблем, или аспект на проблема, няколко пъти преди да ударите правилното решение. (Изучаването на Design Patterns, описани в глава 16 обикновено е полезно в това отношение.) Също е итерация, когато построите система, видите че удовлетворява изискванията и после откриете, че те не са били подходящи. Когато видите системата забелязвате, че сте искали да решите друг проблем. Ако смятате, че този вид итерация е на път да се сбъдне, ще гледате да направите първата версия колкото може по-набързо за изясняване след това какво всъщност се иска. Итерацията е близка до инкрементното разработване. Инкрементно разработване е когато започнете с най-централната част на вашата система и после я използвате за среда за развитие, в която се разработва кодът парченце по парченце. После започвате да добавяте черти по цяла една наведнъж. Трикът е да се проектира среда, която лесно да получи всички черти, които ще искате после. (Вж. глава 16 за по-вътрешно разглеждане на това.) Предимството е, че когато веднъж подкарате началната система, всяка нова черта изглежда като малък проект, а не като част от голям проект. Също е и по-лесно да се провежда поддръжката. ООП поддържа инкременталното разработване, понеже ако програмата ви е разработена добре, промените ще са нови обекти или групи обекти. Планирането се изплащаНе може да се построи къща без множество грижливо начертани планове. Ако строите кучешка колибка вашите планове вероятно няма да са толкова подробни на сигурно ще започнете с нещо като скици, които да ви водят в работата. Софтуерната разработка е отишла към крайности. Дълго време хората нямаха структура на разработките си, но тогава големите проекти започнаха да се провалят. Като реакция се появиха методологии със сплашващо количество правила и данни. Те пък бяха тежки за използване - изглеждаше, че цялото време трябва да отиде за писане на документация, а не за програмиране. (Често такъв именно беше случаят.) Надявам се, че това което съм казал тука сочи средния път – една подвижна скала. Използвайте подход който отговаря на нуждите (и индивидуалността) ви. Без значение колко минимален, някакъв ще донесе голямо предимство пред липсата на всякакъв план. Помнете че според някой оценки повече от 50% от проектите се провалят. Каталог: Java Java -> Лекция Изключения. Уравнение на КортевегДеВриз Java -> Създаване на прозорци и аплети Java -> Лекция 2 Типове данни. Класове и обекти. Числено интегриране Java -> Национална академия по разработка на софтуер Java -> Java за цифрово подписване на документи в уеб Java -> Запознаване с JavaScript. Запознаване с Java Script Java -> Програма за изчисляване на средна стойност Изтегляне 13.53 Mb. Сподели с приятели:
|