30
Симболички Код Процеса Програмирања Садржај 9.1 Резиме: Кораци о стварању класа и рутина 9.2 Симболички код за професионалца 9.3 Конструисање рутина коришћење м симболичког кода процеса програмирања 9.4 Алтернативе симболичког кода процеса програмирања Сродне теме Стварање високо-квалитетних класа: Поглавље 6 Карактеристике високо квалитетних рутина: Поглавље 7 Дизајн високог новоа: Поглавље 5 Коментаришући стил: Глава 32 Иако смо могли да сматрамо ову књигу продуженим описом процеса програмирања за креирање класа и рутина, ово поглавље ставља кораке у контекст. П оглавље се фокусира на програмирање у малом--на специфичне кораке за изградњу индивидуалних класе и рутине које су критичне на пројектима свих величина. Поглавље такође описује симболички код процеса програмирања, чиме се смањује рад потребан приликом пројектовања и документације и побољшава квалитет оба. Ако сте искусан програмер, могли бисте само брзо прегледати ово поглавље. Посматрајмо преглед корака и размотримо савете за конструисање рутина коришћењем симболичког кода процеса програмирања у одељку 9.3. Неколицина програмера је успела да искористи пуну моћ просе с а, и оно нуди доста могућности. Симболички код процеса програмирања није једина процедура за креирање класа и рутина. На крају одељка 9.4 описују се најпопуларније алтернативе укључујући тест—прв о развој и дизајн по уговору. 1

Симболички код

  • Upload
    -

  • View
    232

  • Download
    0

Embed Size (px)

DESCRIPTION

Код

Citation preview

Page 1: Симболички код

Симболички Код Процеса Програмирања

Садржај91 Резиме Кораци о стварању класа и рутина92 Симболички код за професионалца93 Конструисање рутина коришћењем симболичког кода процеса програмирања94 Алтернативе симболичког кода процеса програмирања

Сродне темеСтварање високо-квалитетних класа Поглавље 6Карактеристике високо квалитетних рутина Поглавље 7Дизајн високог новоа Поглавље 5Коментаришући стил Глава 32

Иако смо могли да сматрамо ову књигу продуженим описом процеса програмирања за креирање класа и рутина ово поглавље ставља кораке у контекст Поглавље се фокусира на програмирање у малом--на специфичне кораке за изградњу индивидуалних класе и рутине које су критичне на пројектима свих величина Поглавље такође описује симболички код процеса програмирања чиме се смањује рад потребан приликом пројектовања и документације и побољшава квалитет оба

Ако сте искусан програмер могли бисте само брзо прегледати ово поглавље Посматрајмо преглед корака и размотримо савете за конструисање рутина коришћењем симболичког кода процеса програмирања у одељку 93 Неколицина програмера је успела да искористи пуну моћ просеса и оно нуди доста могућности

Симболички код процеса програмирања није једина процедура за креирање класа и рутина На крају одељка 94 описују се најпопуларније алтернативе укључујући тестmdashпрво развој и дизајн по уговору

91 Резиме Кораци о стварању класа и рутинаКонструкцијом класа може се приступити из многих праваца али обично то је итеративни процес стварања општег дизајна за класу набрајају одређене рутине у оквиру класе конструисање специфичних рутина и проверавање конструкције класе у целини Као што сугерише Слика 9-1 креирање класа може бити збркан поступак због свих разлога због којих је дизајн збркан поступак ( описано у одељку 51 )

1

Почетак

Крај Слика 9-1 Детаљи се разликују од конструкције класе али активности ће се углавном збити као што је приказано на слици

Кораци у креирању класе

Кључни кораци у конструкцији класе су

Креирање општег дизајна за класуДизајн класа обухвата бројна специфична питања Дефинисати специфичне одговорности класе Дефинишите које ldquoтајнеrdquo ће сакрити класа Дефинисати тачно коју апстракцију ће интерфејс класе заузети Утврдити да ли ће класа бити изведена из друге класе и да ли ће другим класама бити омогућено да се изведу из ње Идентификовати кључну класну општу методу Индетификовати и креирати све значајне податке о члановима које користи класа Поновите ове теме(одељке) онолико пута колико је потребно да формирате директан дизајн за рутине Овим разматрањима и многи други се разматрају детаљније у Поглављу 6

Конструисање рутина унутар класе Када сте идентификовали главна рутине у класи је први корак морате даизградити сваку одређену рутину Изградња сваке рутине обично открива

Прављење општег дизајна за

класу

Конструисање рутина унутар

класе

Преглед и тестирање класе

као целине

2

Дизајн рутине Провера дизајна

Преглед и тестирање кода

Кодирање рутине

потребу за додатним рутина мањим и већим и ствара проблеме који произилазе изстварање додатних рутина често враћањем назад у укупном дизајну класа

Преглед и тестирање класа као целинеНормално свака рутина је тестирана када је креирана Након што класа као целинапостане оперативна класa као целинa треба да буде прегледанa и тестиранa за свапитања за која не могу бити тестирана на индивидуалним-рутинском нивоу

Кораци у изградњи рутинаМноге класне рутине биће једноставно и директно инплементирати-pristupne рутине пролазимо-од почетка до краја до других објектних рутина и слично Имплементација других рутина биће компликованије и стварање тихрутине има веће користи од системског приступа Главне активности укључене укреирање рутина--пројектовање рутина проверу дизајна кодирањерутине и провера кода-се обично изводи у редоследу приказаном на слици 9-2 Почетак

Поновити ако је потребно

КрајСлика 9-2Ово су главне активности које иду у изградњи рутину Обично се изводе у приказаном редоследу

3

Стручњаци су развили бројне приступе за стварање рутина и мојомиљени приступ је симболички код процеса програмирања То је описано у следећем одељку

92 Симболички код за професионалце

Термин симболички код односи се на неформалан на енглеском--као нотација који описује како ће алгоритам рутина класа односно програм радитиСимболички код процеса програмирања (СКПП) дефинише специфични приступ како користити симболички код за унапређења стварања кода у оквиру рутине

Због тога што симбилички код личи на енглеском природно је претпоставити да ће било који енглески као и опис који прикупља ваше мисли имати приближно исти ефекат као и сваки други У пракси наћи ћете да су неки стилови симболичког кода кориснији од других Ево упутства за коришћење симболичког кода ефикасно

bull Користите енглески као што су изјаве којима се прецизно описују одређене операције

bull Избегавајте синтаксне елементи из циљних језика програмаСимболички код вам омогућава да дизајнирате на нешто вишем нивоу него сам код Када користите програмски-језик конструкције можете потонути у доњем нивоу и тиме елиминисати главну предност дизајна на вишем нивоу и тиме оптерећујете себе непотребним синтаксичким ограничењима

bull Напишите симболички код на нивоу намере Опишите значењеприступа него како ће приступ бити имплементиран у циљаномјезику

bull Напишите симболички код на довољно ниском нивоу да ће генерисање кода из њега бити скоро аутоматски Ако је симболички код на превисоком нивоу може назначити проблематичне детаље у коду Усавршите симболички код у све више и више детаља све док не изгледа да би било лакше да једноставно напишемо код

Када напишемо симболички код градимо код око тога и симболички код се претвара у програмски-језик коментара Ово елиминише већину коментаришућих напора Ако симболички код следи упутства коментари ће бити комплетнии имаће смисла

4

Ево примера дизајна у симболичком коду који крши скоро све принципе управо описане

Пример лошег симболичког кода

increment resource number by 1allocate a dlg struct using mallocif malloc() returns NULL then return 1invoke OSrsrc_init to initialize a resource for the operating systemhRsrcPtr = resource numberreturn 0Шта је намера овог блока симболичког кода Зато што је лоше написан тешко је рећи Овај тзв симболички код је лош јер обухвата кодирање детаљапопут hRsrcPtr у специфичним Ц-језику показивача нотације и malloc() специјалну функцију у Ц-језику Овај блок симболичког кода се фокусира на то како ће код бити написан него на смисао дизајна Добија у кодирањудетаља-било да се рутина враћа на 1 или 0 Ако мислите о овомсимболичком коду са становишта да ли ће се претворити у добре коментарепочеће те да схватате да то није много помогло

Ево дизајна за исту операцију у много-побољшаном симболичком коду

Пример доброг Симболичког Кода

Keep track of current number of resources in useIf another resource is available Allocate a dialog box structure If a dialog box structure could be allocated Note that one more resource is in use Initialize the resource Store the resource number at the location provided by the caller EndifEndifReturn TRUE if a new resource was created else return FALSEОвај симболички код је много бољи него први зато што је у потпуности написан на енглеском језику не користи ниједне синтактичке елементе циљаног језикаУ првом примеру симболички код могао је бити имплементиран само у Ц језикуУ другом примеру симболички код се не ограничава на избор језика Други блоксимболичког кода такође је написан на нивоу намере Шта други блоксимболичког кода значи Вероватно је лакше разумети други него први блокЧак и ако је написан јасно на енглеском језику други блок симболичког кода јепрецизно и детаљно довољан да може лако да се користи као основа запрограмски-језик кода Када се изјаве у симболичком коду преведу у коментаре они ће бити добро објашњење о намени кода

5

Oво су погодности које можете да очекујете користећи овај стил симболичког кода

bull Симболички код чини прегледање лакшим Можете да прегледате детаље дизајна без испитивање изворног кода Симболички код чини дизајне нижих-нивоа лакшим за прегледањ смањује потребу за прегледање самог кода

bull Симболички код подржава идеју учесталих побољшања Почнете са дизајном високог-новоа побољшате дизајна до симболичког кода а затим усавршитесимболички код у изворном коду Ова узастопна побољшања у малим корацима омогућава да проверите ваш дизајн како се приближавате нижим нивоима детаља Као резултат треба да уочите грешке на високом-нивоу на највишем нивоу грешке средњег-нивоа у средњем нивоу као и грешке нижег-нивоа на најнижем нивоу пре него што било која од њих постане проблем или поквари рад на детаљнијим нивоима

bull Симболички код омогућава лакше измене Неколико редова симболичког кода лакше се мењају од страна кода Да ли би радије променили линију на шематском плану или срушити зид и углавити два до четири негде другде Ефекти нису тако физички драматични у програму већ принцип промене производа када је већина савитљива Један од кључева успеха пројекта је да се увиде грешке у најмањој фази вредност фаза у којој је најмање уложено Много мање је уложено у фази симболичког кода него после потпуног кодирање тестирање и отклањање грешака економичније је увидети грешке раније

bull Симболички код минимизира коментаришујући напор У типичном сценарију кодирања пишете код и додајете коментаре касније У СКПП-а изјаве симболичког кода постају коментари тако да је заправо потребно много више посла да се уклоне коментари него да их оставимо унутра

bull Симболички код је лакши за одржавање од других облика пројектне документације Са другим приступима дизајн је одвојен од кода и када се један промени долази до раскида уговора Са СКПП-а изјаве симболичког кода постају коментари у коду Докле год се угњеждени коментари одржавају документација симболичког кода у дизајну ће бити тачна

Као средство за детаљан дизајн симболички код је тешко надмашити Једно истраживање је утврдило да програмери воле симболички код због начина на који олакшава изградњу у програмском језику због способности да им помогне да открију недовољно детаља дизајна и због једноставности документације и лакоћу модификације коју обезбеђује (Ремзи Атвуд и Ван Дорен 1983) Симболички код није само средство за детаљни дизајн али симболички код и СКПП су корисни алати које треба имати у својој програмској картици алата Користите их Следећи одељак показаће вам како

6

93 Конструисање Рутина Коришћењем СКПП

Овај одељак описује активности у изградњи рутину односно

Дизајнирање рутина Кодирање рутина Проверавање кода Поспремање остатака Понављање ако је потребно

Дизајнирање Рутина

Када сте идентификовали рутине класе први корак у изградњи било које одкласа више компликованих рутина је дизајнирати их Претпоставимо да желите да пишете рутине за излаз порука о грешкама у зависности од кода грешке и претпоставимо да позовете рутину ReportErrorMessage() Ево неформалне спецификације за ReportErrorMessage()

ReportErrorMessage() поставља код грешке као улазни аргуменат и поставља излазну текстуалну грешку која одговара коду Одговорна је за руковање неважећим кодовима Ако програм интерактивно функционише ReportErrorMessage() приказује поруку кориснику Ако је оперативни у режиму командне линије ReportErrorMessage() учитава поруку у датотеци порука Након штампања поруке ReportErrorMessage() враћа статус вредност указијући да ли је успела или није

Остатак овог поглавља користи ову рутину приказујући је кроз примере Остатак овог одељак описује како да дизајнирате рутину

Погледајте предусловиПре него што почнете са радом на самој рутини проверите да ли посао који рутина треба да обави добро дефинисан и чисто уклапа у укупни дизајн Проверите да би били сигурни да је рутина у ствари позвана у најмању руку посредно од стране захтева пројекта

Дефинишите проблем који ће рутина решити Стање проблема који ће рутина решити је довољан детаљ да омогући стварањерутине Ако је висок ниво дизајна довољно детаљан посао би могао већ бити завршен Висок ниво дизајна требао би барем да показује следеће

Информације које ће рутина сакрити Улази у рутину Излази из рутине

7

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 2: Симболички код

Почетак

Крај Слика 9-1 Детаљи се разликују од конструкције класе али активности ће се углавном збити као што је приказано на слици

Кораци у креирању класе

Кључни кораци у конструкцији класе су

Креирање општег дизајна за класуДизајн класа обухвата бројна специфична питања Дефинисати специфичне одговорности класе Дефинишите које ldquoтајнеrdquo ће сакрити класа Дефинисати тачно коју апстракцију ће интерфејс класе заузети Утврдити да ли ће класа бити изведена из друге класе и да ли ће другим класама бити омогућено да се изведу из ње Идентификовати кључну класну општу методу Индетификовати и креирати све значајне податке о члановима које користи класа Поновите ове теме(одељке) онолико пута колико је потребно да формирате директан дизајн за рутине Овим разматрањима и многи други се разматрају детаљније у Поглављу 6

Конструисање рутина унутар класе Када сте идентификовали главна рутине у класи је први корак морате даизградити сваку одређену рутину Изградња сваке рутине обично открива

Прављење општег дизајна за

класу

Конструисање рутина унутар

класе

Преглед и тестирање класе

као целине

2

Дизајн рутине Провера дизајна

Преглед и тестирање кода

Кодирање рутине

потребу за додатним рутина мањим и већим и ствара проблеме који произилазе изстварање додатних рутина често враћањем назад у укупном дизајну класа

Преглед и тестирање класа као целинеНормално свака рутина је тестирана када је креирана Након што класа као целинапостане оперативна класa као целинa треба да буде прегледанa и тестиранa за свапитања за која не могу бити тестирана на индивидуалним-рутинском нивоу

Кораци у изградњи рутинаМноге класне рутине биће једноставно и директно инплементирати-pristupne рутине пролазимо-од почетка до краја до других објектних рутина и слично Имплементација других рутина биће компликованије и стварање тихрутине има веће користи од системског приступа Главне активности укључене укреирање рутина--пројектовање рутина проверу дизајна кодирањерутине и провера кода-се обично изводи у редоследу приказаном на слици 9-2 Почетак

Поновити ако је потребно

КрајСлика 9-2Ово су главне активности које иду у изградњи рутину Обично се изводе у приказаном редоследу

3

Стручњаци су развили бројне приступе за стварање рутина и мојомиљени приступ је симболички код процеса програмирања То је описано у следећем одељку

92 Симболички код за професионалце

Термин симболички код односи се на неформалан на енглеском--као нотација који описује како ће алгоритам рутина класа односно програм радитиСимболички код процеса програмирања (СКПП) дефинише специфични приступ како користити симболички код за унапређења стварања кода у оквиру рутине

Због тога што симбилички код личи на енглеском природно је претпоставити да ће било који енглески као и опис који прикупља ваше мисли имати приближно исти ефекат као и сваки други У пракси наћи ћете да су неки стилови симболичког кода кориснији од других Ево упутства за коришћење симболичког кода ефикасно

bull Користите енглески као што су изјаве којима се прецизно описују одређене операције

bull Избегавајте синтаксне елементи из циљних језика програмаСимболички код вам омогућава да дизајнирате на нешто вишем нивоу него сам код Када користите програмски-језик конструкције можете потонути у доњем нивоу и тиме елиминисати главну предност дизајна на вишем нивоу и тиме оптерећујете себе непотребним синтаксичким ограничењима

bull Напишите симболички код на нивоу намере Опишите значењеприступа него како ће приступ бити имплементиран у циљаномјезику

bull Напишите симболички код на довољно ниском нивоу да ће генерисање кода из њега бити скоро аутоматски Ако је симболички код на превисоком нивоу може назначити проблематичне детаље у коду Усавршите симболички код у све више и више детаља све док не изгледа да би било лакше да једноставно напишемо код

Када напишемо симболички код градимо код око тога и симболички код се претвара у програмски-језик коментара Ово елиминише већину коментаришућих напора Ако симболички код следи упутства коментари ће бити комплетнии имаће смисла

4

Ево примера дизајна у симболичком коду који крши скоро све принципе управо описане

Пример лошег симболичког кода

increment resource number by 1allocate a dlg struct using mallocif malloc() returns NULL then return 1invoke OSrsrc_init to initialize a resource for the operating systemhRsrcPtr = resource numberreturn 0Шта је намера овог блока симболичког кода Зато што је лоше написан тешко је рећи Овај тзв симболички код је лош јер обухвата кодирање детаљапопут hRsrcPtr у специфичним Ц-језику показивача нотације и malloc() специјалну функцију у Ц-језику Овај блок симболичког кода се фокусира на то како ће код бити написан него на смисао дизајна Добија у кодирањудетаља-било да се рутина враћа на 1 или 0 Ако мислите о овомсимболичком коду са становишта да ли ће се претворити у добре коментарепочеће те да схватате да то није много помогло

Ево дизајна за исту операцију у много-побољшаном симболичком коду

Пример доброг Симболичког Кода

Keep track of current number of resources in useIf another resource is available Allocate a dialog box structure If a dialog box structure could be allocated Note that one more resource is in use Initialize the resource Store the resource number at the location provided by the caller EndifEndifReturn TRUE if a new resource was created else return FALSEОвај симболички код је много бољи него први зато што је у потпуности написан на енглеском језику не користи ниједне синтактичке елементе циљаног језикаУ првом примеру симболички код могао је бити имплементиран само у Ц језикуУ другом примеру симболички код се не ограничава на избор језика Други блоксимболичког кода такође је написан на нивоу намере Шта други блоксимболичког кода значи Вероватно је лакше разумети други него први блокЧак и ако је написан јасно на енглеском језику други блок симболичког кода јепрецизно и детаљно довољан да може лако да се користи као основа запрограмски-језик кода Када се изјаве у симболичком коду преведу у коментаре они ће бити добро објашњење о намени кода

5

Oво су погодности које можете да очекујете користећи овај стил симболичког кода

bull Симболички код чини прегледање лакшим Можете да прегледате детаље дизајна без испитивање изворног кода Симболички код чини дизајне нижих-нивоа лакшим за прегледањ смањује потребу за прегледање самог кода

bull Симболички код подржава идеју учесталих побољшања Почнете са дизајном високог-новоа побољшате дизајна до симболичког кода а затим усавршитесимболички код у изворном коду Ова узастопна побољшања у малим корацима омогућава да проверите ваш дизајн како се приближавате нижим нивоима детаља Као резултат треба да уочите грешке на високом-нивоу на највишем нивоу грешке средњег-нивоа у средњем нивоу као и грешке нижег-нивоа на најнижем нивоу пре него што било која од њих постане проблем или поквари рад на детаљнијим нивоима

bull Симболички код омогућава лакше измене Неколико редова симболичког кода лакше се мењају од страна кода Да ли би радије променили линију на шематском плану или срушити зид и углавити два до четири негде другде Ефекти нису тако физички драматични у програму већ принцип промене производа када је већина савитљива Један од кључева успеха пројекта је да се увиде грешке у најмањој фази вредност фаза у којој је најмање уложено Много мање је уложено у фази симболичког кода него после потпуног кодирање тестирање и отклањање грешака економичније је увидети грешке раније

bull Симболички код минимизира коментаришујући напор У типичном сценарију кодирања пишете код и додајете коментаре касније У СКПП-а изјаве симболичког кода постају коментари тако да је заправо потребно много више посла да се уклоне коментари него да их оставимо унутра

bull Симболички код је лакши за одржавање од других облика пројектне документације Са другим приступима дизајн је одвојен од кода и када се један промени долази до раскида уговора Са СКПП-а изјаве симболичког кода постају коментари у коду Докле год се угњеждени коментари одржавају документација симболичког кода у дизајну ће бити тачна

Као средство за детаљан дизајн симболички код је тешко надмашити Једно истраживање је утврдило да програмери воле симболички код због начина на који олакшава изградњу у програмском језику због способности да им помогне да открију недовољно детаља дизајна и због једноставности документације и лакоћу модификације коју обезбеђује (Ремзи Атвуд и Ван Дорен 1983) Симболички код није само средство за детаљни дизајн али симболички код и СКПП су корисни алати које треба имати у својој програмској картици алата Користите их Следећи одељак показаће вам како

6

93 Конструисање Рутина Коришћењем СКПП

Овај одељак описује активности у изградњи рутину односно

Дизајнирање рутина Кодирање рутина Проверавање кода Поспремање остатака Понављање ако је потребно

Дизајнирање Рутина

Када сте идентификовали рутине класе први корак у изградњи било које одкласа више компликованих рутина је дизајнирати их Претпоставимо да желите да пишете рутине за излаз порука о грешкама у зависности од кода грешке и претпоставимо да позовете рутину ReportErrorMessage() Ево неформалне спецификације за ReportErrorMessage()

ReportErrorMessage() поставља код грешке као улазни аргуменат и поставља излазну текстуалну грешку која одговара коду Одговорна је за руковање неважећим кодовима Ако програм интерактивно функционише ReportErrorMessage() приказује поруку кориснику Ако је оперативни у режиму командне линије ReportErrorMessage() учитава поруку у датотеци порука Након штампања поруке ReportErrorMessage() враћа статус вредност указијући да ли је успела или није

Остатак овог поглавља користи ову рутину приказујући је кроз примере Остатак овог одељак описује како да дизајнирате рутину

Погледајте предусловиПре него што почнете са радом на самој рутини проверите да ли посао који рутина треба да обави добро дефинисан и чисто уклапа у укупни дизајн Проверите да би били сигурни да је рутина у ствари позвана у најмању руку посредно од стране захтева пројекта

Дефинишите проблем који ће рутина решити Стање проблема који ће рутина решити је довољан детаљ да омогући стварањерутине Ако је висок ниво дизајна довољно детаљан посао би могао већ бити завршен Висок ниво дизајна требао би барем да показује следеће

Информације које ће рутина сакрити Улази у рутину Излази из рутине

7

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 3: Симболички код

Дизајн рутине Провера дизајна

Преглед и тестирање кода

Кодирање рутине

потребу за додатним рутина мањим и већим и ствара проблеме који произилазе изстварање додатних рутина често враћањем назад у укупном дизајну класа

Преглед и тестирање класа као целинеНормално свака рутина је тестирана када је креирана Након што класа као целинапостане оперативна класa као целинa треба да буде прегледанa и тестиранa за свапитања за која не могу бити тестирана на индивидуалним-рутинском нивоу

Кораци у изградњи рутинаМноге класне рутине биће једноставно и директно инплементирати-pristupne рутине пролазимо-од почетка до краја до других објектних рутина и слично Имплементација других рутина биће компликованије и стварање тихрутине има веће користи од системског приступа Главне активности укључене укреирање рутина--пројектовање рутина проверу дизајна кодирањерутине и провера кода-се обично изводи у редоследу приказаном на слици 9-2 Почетак

Поновити ако је потребно

КрајСлика 9-2Ово су главне активности које иду у изградњи рутину Обично се изводе у приказаном редоследу

3

Стручњаци су развили бројне приступе за стварање рутина и мојомиљени приступ је симболички код процеса програмирања То је описано у следећем одељку

92 Симболички код за професионалце

Термин симболички код односи се на неформалан на енглеском--као нотација који описује како ће алгоритам рутина класа односно програм радитиСимболички код процеса програмирања (СКПП) дефинише специфични приступ како користити симболички код за унапређења стварања кода у оквиру рутине

Због тога што симбилички код личи на енглеском природно је претпоставити да ће било који енглески као и опис који прикупља ваше мисли имати приближно исти ефекат као и сваки други У пракси наћи ћете да су неки стилови симболичког кода кориснији од других Ево упутства за коришћење симболичког кода ефикасно

bull Користите енглески као што су изјаве којима се прецизно описују одређене операције

bull Избегавајте синтаксне елементи из циљних језика програмаСимболички код вам омогућава да дизајнирате на нешто вишем нивоу него сам код Када користите програмски-језик конструкције можете потонути у доњем нивоу и тиме елиминисати главну предност дизајна на вишем нивоу и тиме оптерећујете себе непотребним синтаксичким ограничењима

bull Напишите симболички код на нивоу намере Опишите значењеприступа него како ће приступ бити имплементиран у циљаномјезику

bull Напишите симболички код на довољно ниском нивоу да ће генерисање кода из њега бити скоро аутоматски Ако је симболички код на превисоком нивоу може назначити проблематичне детаље у коду Усавршите симболички код у све више и више детаља све док не изгледа да би било лакше да једноставно напишемо код

Када напишемо симболички код градимо код око тога и симболички код се претвара у програмски-језик коментара Ово елиминише већину коментаришућих напора Ако симболички код следи упутства коментари ће бити комплетнии имаће смисла

4

Ево примера дизајна у симболичком коду који крши скоро све принципе управо описане

Пример лошег симболичког кода

increment resource number by 1allocate a dlg struct using mallocif malloc() returns NULL then return 1invoke OSrsrc_init to initialize a resource for the operating systemhRsrcPtr = resource numberreturn 0Шта је намера овог блока симболичког кода Зато што је лоше написан тешко је рећи Овај тзв симболички код је лош јер обухвата кодирање детаљапопут hRsrcPtr у специфичним Ц-језику показивача нотације и malloc() специјалну функцију у Ц-језику Овај блок симболичког кода се фокусира на то како ће код бити написан него на смисао дизајна Добија у кодирањудетаља-било да се рутина враћа на 1 или 0 Ако мислите о овомсимболичком коду са становишта да ли ће се претворити у добре коментарепочеће те да схватате да то није много помогло

Ево дизајна за исту операцију у много-побољшаном симболичком коду

Пример доброг Симболичког Кода

Keep track of current number of resources in useIf another resource is available Allocate a dialog box structure If a dialog box structure could be allocated Note that one more resource is in use Initialize the resource Store the resource number at the location provided by the caller EndifEndifReturn TRUE if a new resource was created else return FALSEОвај симболички код је много бољи него први зато што је у потпуности написан на енглеском језику не користи ниједне синтактичке елементе циљаног језикаУ првом примеру симболички код могао је бити имплементиран само у Ц језикуУ другом примеру симболички код се не ограничава на избор језика Други блоксимболичког кода такође је написан на нивоу намере Шта други блоксимболичког кода значи Вероватно је лакше разумети други него први блокЧак и ако је написан јасно на енглеском језику други блок симболичког кода јепрецизно и детаљно довољан да може лако да се користи као основа запрограмски-језик кода Када се изјаве у симболичком коду преведу у коментаре они ће бити добро објашњење о намени кода

5

Oво су погодности које можете да очекујете користећи овај стил симболичког кода

bull Симболички код чини прегледање лакшим Можете да прегледате детаље дизајна без испитивање изворног кода Симболички код чини дизајне нижих-нивоа лакшим за прегледањ смањује потребу за прегледање самог кода

bull Симболички код подржава идеју учесталих побољшања Почнете са дизајном високог-новоа побољшате дизајна до симболичког кода а затим усавршитесимболички код у изворном коду Ова узастопна побољшања у малим корацима омогућава да проверите ваш дизајн како се приближавате нижим нивоима детаља Као резултат треба да уочите грешке на високом-нивоу на највишем нивоу грешке средњег-нивоа у средњем нивоу као и грешке нижег-нивоа на најнижем нивоу пре него што било која од њих постане проблем или поквари рад на детаљнијим нивоима

bull Симболички код омогућава лакше измене Неколико редова симболичког кода лакше се мењају од страна кода Да ли би радије променили линију на шематском плану или срушити зид и углавити два до четири негде другде Ефекти нису тако физички драматични у програму већ принцип промене производа када је већина савитљива Један од кључева успеха пројекта је да се увиде грешке у најмањој фази вредност фаза у којој је најмање уложено Много мање је уложено у фази симболичког кода него после потпуног кодирање тестирање и отклањање грешака економичније је увидети грешке раније

bull Симболички код минимизира коментаришујући напор У типичном сценарију кодирања пишете код и додајете коментаре касније У СКПП-а изјаве симболичког кода постају коментари тако да је заправо потребно много више посла да се уклоне коментари него да их оставимо унутра

bull Симболички код је лакши за одржавање од других облика пројектне документације Са другим приступима дизајн је одвојен од кода и када се један промени долази до раскида уговора Са СКПП-а изјаве симболичког кода постају коментари у коду Докле год се угњеждени коментари одржавају документација симболичког кода у дизајну ће бити тачна

Као средство за детаљан дизајн симболички код је тешко надмашити Једно истраживање је утврдило да програмери воле симболички код због начина на који олакшава изградњу у програмском језику због способности да им помогне да открију недовољно детаља дизајна и због једноставности документације и лакоћу модификације коју обезбеђује (Ремзи Атвуд и Ван Дорен 1983) Симболички код није само средство за детаљни дизајн али симболички код и СКПП су корисни алати које треба имати у својој програмској картици алата Користите их Следећи одељак показаће вам како

6

93 Конструисање Рутина Коришћењем СКПП

Овај одељак описује активности у изградњи рутину односно

Дизајнирање рутина Кодирање рутина Проверавање кода Поспремање остатака Понављање ако је потребно

Дизајнирање Рутина

Када сте идентификовали рутине класе први корак у изградњи било које одкласа више компликованих рутина је дизајнирати их Претпоставимо да желите да пишете рутине за излаз порука о грешкама у зависности од кода грешке и претпоставимо да позовете рутину ReportErrorMessage() Ево неформалне спецификације за ReportErrorMessage()

ReportErrorMessage() поставља код грешке као улазни аргуменат и поставља излазну текстуалну грешку која одговара коду Одговорна је за руковање неважећим кодовима Ако програм интерактивно функционише ReportErrorMessage() приказује поруку кориснику Ако је оперативни у режиму командне линије ReportErrorMessage() учитава поруку у датотеци порука Након штампања поруке ReportErrorMessage() враћа статус вредност указијући да ли је успела или није

Остатак овог поглавља користи ову рутину приказујући је кроз примере Остатак овог одељак описује како да дизајнирате рутину

Погледајте предусловиПре него што почнете са радом на самој рутини проверите да ли посао који рутина треба да обави добро дефинисан и чисто уклапа у укупни дизајн Проверите да би били сигурни да је рутина у ствари позвана у најмању руку посредно од стране захтева пројекта

Дефинишите проблем који ће рутина решити Стање проблема који ће рутина решити је довољан детаљ да омогући стварањерутине Ако је висок ниво дизајна довољно детаљан посао би могао већ бити завршен Висок ниво дизајна требао би барем да показује следеће

Информације које ће рутина сакрити Улази у рутину Излази из рутине

7

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 4: Симболички код

Стручњаци су развили бројне приступе за стварање рутина и мојомиљени приступ је симболички код процеса програмирања То је описано у следећем одељку

92 Симболички код за професионалце

Термин симболички код односи се на неформалан на енглеском--као нотација који описује како ће алгоритам рутина класа односно програм радитиСимболички код процеса програмирања (СКПП) дефинише специфични приступ како користити симболички код за унапређења стварања кода у оквиру рутине

Због тога што симбилички код личи на енглеском природно је претпоставити да ће било који енглески као и опис који прикупља ваше мисли имати приближно исти ефекат као и сваки други У пракси наћи ћете да су неки стилови симболичког кода кориснији од других Ево упутства за коришћење симболичког кода ефикасно

bull Користите енглески као што су изјаве којима се прецизно описују одређене операције

bull Избегавајте синтаксне елементи из циљних језика програмаСимболички код вам омогућава да дизајнирате на нешто вишем нивоу него сам код Када користите програмски-језик конструкције можете потонути у доњем нивоу и тиме елиминисати главну предност дизајна на вишем нивоу и тиме оптерећујете себе непотребним синтаксичким ограничењима

bull Напишите симболички код на нивоу намере Опишите значењеприступа него како ће приступ бити имплементиран у циљаномјезику

bull Напишите симболички код на довољно ниском нивоу да ће генерисање кода из њега бити скоро аутоматски Ако је симболички код на превисоком нивоу може назначити проблематичне детаље у коду Усавршите симболички код у све више и више детаља све док не изгледа да би било лакше да једноставно напишемо код

Када напишемо симболички код градимо код око тога и симболички код се претвара у програмски-језик коментара Ово елиминише већину коментаришућих напора Ако симболички код следи упутства коментари ће бити комплетнии имаће смисла

4

Ево примера дизајна у симболичком коду који крши скоро све принципе управо описане

Пример лошег симболичког кода

increment resource number by 1allocate a dlg struct using mallocif malloc() returns NULL then return 1invoke OSrsrc_init to initialize a resource for the operating systemhRsrcPtr = resource numberreturn 0Шта је намера овог блока симболичког кода Зато што је лоше написан тешко је рећи Овај тзв симболички код је лош јер обухвата кодирање детаљапопут hRsrcPtr у специфичним Ц-језику показивача нотације и malloc() специјалну функцију у Ц-језику Овај блок симболичког кода се фокусира на то како ће код бити написан него на смисао дизајна Добија у кодирањудетаља-било да се рутина враћа на 1 или 0 Ако мислите о овомсимболичком коду са становишта да ли ће се претворити у добре коментарепочеће те да схватате да то није много помогло

Ево дизајна за исту операцију у много-побољшаном симболичком коду

Пример доброг Симболичког Кода

Keep track of current number of resources in useIf another resource is available Allocate a dialog box structure If a dialog box structure could be allocated Note that one more resource is in use Initialize the resource Store the resource number at the location provided by the caller EndifEndifReturn TRUE if a new resource was created else return FALSEОвај симболички код је много бољи него први зато што је у потпуности написан на енглеском језику не користи ниједне синтактичке елементе циљаног језикаУ првом примеру симболички код могао је бити имплементиран само у Ц језикуУ другом примеру симболички код се не ограничава на избор језика Други блоксимболичког кода такође је написан на нивоу намере Шта други блоксимболичког кода значи Вероватно је лакше разумети други него први блокЧак и ако је написан јасно на енглеском језику други блок симболичког кода јепрецизно и детаљно довољан да може лако да се користи као основа запрограмски-језик кода Када се изјаве у симболичком коду преведу у коментаре они ће бити добро објашњење о намени кода

5

Oво су погодности које можете да очекујете користећи овај стил симболичког кода

bull Симболички код чини прегледање лакшим Можете да прегледате детаље дизајна без испитивање изворног кода Симболички код чини дизајне нижих-нивоа лакшим за прегледањ смањује потребу за прегледање самог кода

bull Симболички код подржава идеју учесталих побољшања Почнете са дизајном високог-новоа побољшате дизајна до симболичког кода а затим усавршитесимболички код у изворном коду Ова узастопна побољшања у малим корацима омогућава да проверите ваш дизајн како се приближавате нижим нивоима детаља Као резултат треба да уочите грешке на високом-нивоу на највишем нивоу грешке средњег-нивоа у средњем нивоу као и грешке нижег-нивоа на најнижем нивоу пре него што било која од њих постане проблем или поквари рад на детаљнијим нивоима

bull Симболички код омогућава лакше измене Неколико редова симболичког кода лакше се мењају од страна кода Да ли би радије променили линију на шематском плану или срушити зид и углавити два до четири негде другде Ефекти нису тако физички драматични у програму већ принцип промене производа када је већина савитљива Један од кључева успеха пројекта је да се увиде грешке у најмањој фази вредност фаза у којој је најмање уложено Много мање је уложено у фази симболичког кода него после потпуног кодирање тестирање и отклањање грешака економичније је увидети грешке раније

bull Симболички код минимизира коментаришујући напор У типичном сценарију кодирања пишете код и додајете коментаре касније У СКПП-а изјаве симболичког кода постају коментари тако да је заправо потребно много више посла да се уклоне коментари него да их оставимо унутра

bull Симболички код је лакши за одржавање од других облика пројектне документације Са другим приступима дизајн је одвојен од кода и када се један промени долази до раскида уговора Са СКПП-а изјаве симболичког кода постају коментари у коду Докле год се угњеждени коментари одржавају документација симболичког кода у дизајну ће бити тачна

Као средство за детаљан дизајн симболички код је тешко надмашити Једно истраживање је утврдило да програмери воле симболички код због начина на који олакшава изградњу у програмском језику због способности да им помогне да открију недовољно детаља дизајна и због једноставности документације и лакоћу модификације коју обезбеђује (Ремзи Атвуд и Ван Дорен 1983) Симболички код није само средство за детаљни дизајн али симболички код и СКПП су корисни алати које треба имати у својој програмској картици алата Користите их Следећи одељак показаће вам како

6

93 Конструисање Рутина Коришћењем СКПП

Овај одељак описује активности у изградњи рутину односно

Дизајнирање рутина Кодирање рутина Проверавање кода Поспремање остатака Понављање ако је потребно

Дизајнирање Рутина

Када сте идентификовали рутине класе први корак у изградњи било које одкласа више компликованих рутина је дизајнирати их Претпоставимо да желите да пишете рутине за излаз порука о грешкама у зависности од кода грешке и претпоставимо да позовете рутину ReportErrorMessage() Ево неформалне спецификације за ReportErrorMessage()

ReportErrorMessage() поставља код грешке као улазни аргуменат и поставља излазну текстуалну грешку која одговара коду Одговорна је за руковање неважећим кодовима Ако програм интерактивно функционише ReportErrorMessage() приказује поруку кориснику Ако је оперативни у режиму командне линије ReportErrorMessage() учитава поруку у датотеци порука Након штампања поруке ReportErrorMessage() враћа статус вредност указијући да ли је успела или није

Остатак овог поглавља користи ову рутину приказујући је кроз примере Остатак овог одељак описује како да дизајнирате рутину

Погледајте предусловиПре него што почнете са радом на самој рутини проверите да ли посао који рутина треба да обави добро дефинисан и чисто уклапа у укупни дизајн Проверите да би били сигурни да је рутина у ствари позвана у најмању руку посредно од стране захтева пројекта

Дефинишите проблем који ће рутина решити Стање проблема који ће рутина решити је довољан детаљ да омогући стварањерутине Ако је висок ниво дизајна довољно детаљан посао би могао већ бити завршен Висок ниво дизајна требао би барем да показује следеће

Информације које ће рутина сакрити Улази у рутину Излази из рутине

7

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 5: Симболички код

Ево примера дизајна у симболичком коду који крши скоро све принципе управо описане

Пример лошег симболичког кода

increment resource number by 1allocate a dlg struct using mallocif malloc() returns NULL then return 1invoke OSrsrc_init to initialize a resource for the operating systemhRsrcPtr = resource numberreturn 0Шта је намера овог блока симболичког кода Зато што је лоше написан тешко је рећи Овај тзв симболички код је лош јер обухвата кодирање детаљапопут hRsrcPtr у специфичним Ц-језику показивача нотације и malloc() специјалну функцију у Ц-језику Овај блок симболичког кода се фокусира на то како ће код бити написан него на смисао дизајна Добија у кодирањудетаља-било да се рутина враћа на 1 или 0 Ако мислите о овомсимболичком коду са становишта да ли ће се претворити у добре коментарепочеће те да схватате да то није много помогло

Ево дизајна за исту операцију у много-побољшаном симболичком коду

Пример доброг Симболичког Кода

Keep track of current number of resources in useIf another resource is available Allocate a dialog box structure If a dialog box structure could be allocated Note that one more resource is in use Initialize the resource Store the resource number at the location provided by the caller EndifEndifReturn TRUE if a new resource was created else return FALSEОвај симболички код је много бољи него први зато што је у потпуности написан на енглеском језику не користи ниједне синтактичке елементе циљаног језикаУ првом примеру симболички код могао је бити имплементиран само у Ц језикуУ другом примеру симболички код се не ограничава на избор језика Други блоксимболичког кода такође је написан на нивоу намере Шта други блоксимболичког кода значи Вероватно је лакше разумети други него први блокЧак и ако је написан јасно на енглеском језику други блок симболичког кода јепрецизно и детаљно довољан да може лако да се користи као основа запрограмски-језик кода Када се изјаве у симболичком коду преведу у коментаре они ће бити добро објашњење о намени кода

5

Oво су погодности које можете да очекујете користећи овај стил симболичког кода

bull Симболички код чини прегледање лакшим Можете да прегледате детаље дизајна без испитивање изворног кода Симболички код чини дизајне нижих-нивоа лакшим за прегледањ смањује потребу за прегледање самог кода

bull Симболички код подржава идеју учесталих побољшања Почнете са дизајном високог-новоа побољшате дизајна до симболичког кода а затим усавршитесимболички код у изворном коду Ова узастопна побољшања у малим корацима омогућава да проверите ваш дизајн како се приближавате нижим нивоима детаља Као резултат треба да уочите грешке на високом-нивоу на највишем нивоу грешке средњег-нивоа у средњем нивоу као и грешке нижег-нивоа на најнижем нивоу пре него што било која од њих постане проблем или поквари рад на детаљнијим нивоима

bull Симболички код омогућава лакше измене Неколико редова симболичког кода лакше се мењају од страна кода Да ли би радије променили линију на шематском плану или срушити зид и углавити два до четири негде другде Ефекти нису тако физички драматични у програму већ принцип промене производа када је већина савитљива Један од кључева успеха пројекта је да се увиде грешке у најмањој фази вредност фаза у којој је најмање уложено Много мање је уложено у фази симболичког кода него после потпуног кодирање тестирање и отклањање грешака економичније је увидети грешке раније

bull Симболички код минимизира коментаришујући напор У типичном сценарију кодирања пишете код и додајете коментаре касније У СКПП-а изјаве симболичког кода постају коментари тако да је заправо потребно много више посла да се уклоне коментари него да их оставимо унутра

bull Симболички код је лакши за одржавање од других облика пројектне документације Са другим приступима дизајн је одвојен од кода и када се један промени долази до раскида уговора Са СКПП-а изјаве симболичког кода постају коментари у коду Докле год се угњеждени коментари одржавају документација симболичког кода у дизајну ће бити тачна

Као средство за детаљан дизајн симболички код је тешко надмашити Једно истраживање је утврдило да програмери воле симболички код због начина на који олакшава изградњу у програмском језику због способности да им помогне да открију недовољно детаља дизајна и због једноставности документације и лакоћу модификације коју обезбеђује (Ремзи Атвуд и Ван Дорен 1983) Симболички код није само средство за детаљни дизајн али симболички код и СКПП су корисни алати које треба имати у својој програмској картици алата Користите их Следећи одељак показаће вам како

6

93 Конструисање Рутина Коришћењем СКПП

Овај одељак описује активности у изградњи рутину односно

Дизајнирање рутина Кодирање рутина Проверавање кода Поспремање остатака Понављање ако је потребно

Дизајнирање Рутина

Када сте идентификовали рутине класе први корак у изградњи било које одкласа више компликованих рутина је дизајнирати их Претпоставимо да желите да пишете рутине за излаз порука о грешкама у зависности од кода грешке и претпоставимо да позовете рутину ReportErrorMessage() Ево неформалне спецификације за ReportErrorMessage()

ReportErrorMessage() поставља код грешке као улазни аргуменат и поставља излазну текстуалну грешку која одговара коду Одговорна је за руковање неважећим кодовима Ако програм интерактивно функционише ReportErrorMessage() приказује поруку кориснику Ако је оперативни у режиму командне линије ReportErrorMessage() учитава поруку у датотеци порука Након штампања поруке ReportErrorMessage() враћа статус вредност указијући да ли је успела или није

Остатак овог поглавља користи ову рутину приказујући је кроз примере Остатак овог одељак описује како да дизајнирате рутину

Погледајте предусловиПре него што почнете са радом на самој рутини проверите да ли посао који рутина треба да обави добро дефинисан и чисто уклапа у укупни дизајн Проверите да би били сигурни да је рутина у ствари позвана у најмању руку посредно од стране захтева пројекта

Дефинишите проблем који ће рутина решити Стање проблема који ће рутина решити је довољан детаљ да омогући стварањерутине Ако је висок ниво дизајна довољно детаљан посао би могао већ бити завршен Висок ниво дизајна требао би барем да показује следеће

Информације које ће рутина сакрити Улази у рутину Излази из рутине

7

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 6: Симболички код

Oво су погодности које можете да очекујете користећи овај стил симболичког кода

bull Симболички код чини прегледање лакшим Можете да прегледате детаље дизајна без испитивање изворног кода Симболички код чини дизајне нижих-нивоа лакшим за прегледањ смањује потребу за прегледање самог кода

bull Симболички код подржава идеју учесталих побољшања Почнете са дизајном високог-новоа побољшате дизајна до симболичког кода а затим усавршитесимболички код у изворном коду Ова узастопна побољшања у малим корацима омогућава да проверите ваш дизајн како се приближавате нижим нивоима детаља Као резултат треба да уочите грешке на високом-нивоу на највишем нивоу грешке средњег-нивоа у средњем нивоу као и грешке нижег-нивоа на најнижем нивоу пре него што било која од њих постане проблем или поквари рад на детаљнијим нивоима

bull Симболички код омогућава лакше измене Неколико редова симболичког кода лакше се мењају од страна кода Да ли би радије променили линију на шематском плану или срушити зид и углавити два до четири негде другде Ефекти нису тако физички драматични у програму већ принцип промене производа када је већина савитљива Један од кључева успеха пројекта је да се увиде грешке у најмањој фази вредност фаза у којој је најмање уложено Много мање је уложено у фази симболичког кода него после потпуног кодирање тестирање и отклањање грешака економичније је увидети грешке раније

bull Симболички код минимизира коментаришујући напор У типичном сценарију кодирања пишете код и додајете коментаре касније У СКПП-а изјаве симболичког кода постају коментари тако да је заправо потребно много више посла да се уклоне коментари него да их оставимо унутра

bull Симболички код је лакши за одржавање од других облика пројектне документације Са другим приступима дизајн је одвојен од кода и када се један промени долази до раскида уговора Са СКПП-а изјаве симболичког кода постају коментари у коду Докле год се угњеждени коментари одржавају документација симболичког кода у дизајну ће бити тачна

Као средство за детаљан дизајн симболички код је тешко надмашити Једно истраживање је утврдило да програмери воле симболички код због начина на који олакшава изградњу у програмском језику због способности да им помогне да открију недовољно детаља дизајна и због једноставности документације и лакоћу модификације коју обезбеђује (Ремзи Атвуд и Ван Дорен 1983) Симболички код није само средство за детаљни дизајн али симболички код и СКПП су корисни алати које треба имати у својој програмској картици алата Користите их Следећи одељак показаће вам како

6

93 Конструисање Рутина Коришћењем СКПП

Овај одељак описује активности у изградњи рутину односно

Дизајнирање рутина Кодирање рутина Проверавање кода Поспремање остатака Понављање ако је потребно

Дизајнирање Рутина

Када сте идентификовали рутине класе први корак у изградњи било које одкласа више компликованих рутина је дизајнирати их Претпоставимо да желите да пишете рутине за излаз порука о грешкама у зависности од кода грешке и претпоставимо да позовете рутину ReportErrorMessage() Ево неформалне спецификације за ReportErrorMessage()

ReportErrorMessage() поставља код грешке као улазни аргуменат и поставља излазну текстуалну грешку која одговара коду Одговорна је за руковање неважећим кодовима Ако програм интерактивно функционише ReportErrorMessage() приказује поруку кориснику Ако је оперативни у режиму командне линије ReportErrorMessage() учитава поруку у датотеци порука Након штампања поруке ReportErrorMessage() враћа статус вредност указијући да ли је успела или није

Остатак овог поглавља користи ову рутину приказујући је кроз примере Остатак овог одељак описује како да дизајнирате рутину

Погледајте предусловиПре него што почнете са радом на самој рутини проверите да ли посао који рутина треба да обави добро дефинисан и чисто уклапа у укупни дизајн Проверите да би били сигурни да је рутина у ствари позвана у најмању руку посредно од стране захтева пројекта

Дефинишите проблем који ће рутина решити Стање проблема који ће рутина решити је довољан детаљ да омогући стварањерутине Ако је висок ниво дизајна довољно детаљан посао би могао већ бити завршен Висок ниво дизајна требао би барем да показује следеће

Информације које ће рутина сакрити Улази у рутину Излази из рутине

7

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 7: Симболички код

93 Конструисање Рутина Коришћењем СКПП

Овај одељак описује активности у изградњи рутину односно

Дизајнирање рутина Кодирање рутина Проверавање кода Поспремање остатака Понављање ако је потребно

Дизајнирање Рутина

Када сте идентификовали рутине класе први корак у изградњи било које одкласа више компликованих рутина је дизајнирати их Претпоставимо да желите да пишете рутине за излаз порука о грешкама у зависности од кода грешке и претпоставимо да позовете рутину ReportErrorMessage() Ево неформалне спецификације за ReportErrorMessage()

ReportErrorMessage() поставља код грешке као улазни аргуменат и поставља излазну текстуалну грешку која одговара коду Одговорна је за руковање неважећим кодовима Ако програм интерактивно функционише ReportErrorMessage() приказује поруку кориснику Ако је оперативни у режиму командне линије ReportErrorMessage() учитава поруку у датотеци порука Након штампања поруке ReportErrorMessage() враћа статус вредност указијући да ли је успела или није

Остатак овог поглавља користи ову рутину приказујући је кроз примере Остатак овог одељак описује како да дизајнирате рутину

Погледајте предусловиПре него што почнете са радом на самој рутини проверите да ли посао који рутина треба да обави добро дефинисан и чисто уклапа у укупни дизајн Проверите да би били сигурни да је рутина у ствари позвана у најмању руку посредно од стране захтева пројекта

Дефинишите проблем који ће рутина решити Стање проблема који ће рутина решити је довољан детаљ да омогући стварањерутине Ако је висок ниво дизајна довољно детаљан посао би могао већ бити завршен Висок ниво дизајна требао би барем да показује следеће

Информације које ће рутина сакрити Улази у рутину Излази из рутине

7

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 8: Симболички код

Предуслови да се гарантује да ће бити тачно пре него што се рутина позове(улазне вредности у оквиру одређених опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

После услова које рутина гарантује бити истинити пре него што прође контролни блок до позиваоца (излазне вредности унутар одређеног опсега токови иницијализације датотеке отворене или затворене бафери попуњени или препуни итд)

Ево како су ови проблеми решени у ReportErrorMessage() примеру

Рутина крије две чињенице грешке у виду текстуалних порука и тренутни метод обраде (интерактивно или командне линије)

Не постоје предуслови гарантовани у рутини

Унос према рутина је код грешке

Две врсте излаза се позивају Први је текстуална грешка други је стање које ReportErrorMessage() враћа на позивање рутине

Рутина гарантује да ће стањ вредности имати вредност или успеха илинеуспеха

Дајте рутини називДавати рутини назив може изгледати тривијално али је добра рутинска имена су један знак супериорног програма а није их лако смислити У принципу рутина треба да има јасан недвосмислен назив Ако имате проблема да осмислите добар назив који се обично означава да сврха рутине није јасна Нејасаннеодређен назив је као политичар који заостаје у кампањи То звучи као да говори нешто али када боље поглеате не можете да схватите шта то значи Ако можете да осмислите јаснији назив учините то Ако неодређен назив резултира из неодређеног дизајна обратите пажњу на знаке упозорења Направите резервну копију и побољшајте дизајн

На пример ReportErrorMessage() је недвосмислен назив То је добро име

Одлучите како да тестирате рутинскиКао што пишете рутину мислити о томе како можете да је тестирате Ово је корисно када радите појединачно тестирање и за испитивача који тестира вашу рутину независно

На пример улаз је једноставан тако да можете да планирате да тестиратеReportErrorMessage() са свим важећим кодовима грешке и различитих неважећих кодова

8

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 9: Симболички код

Размислите о грешкама руковањаРазмислите о свим стварима које би могле евентуално да крену наопако у рутини Мислите о лошим улазним вредностима неважећим вредностима враћеним из других рутина и тако даље

Рутине могу да прихвате грешке на бројне начине и требало би да одаберете пажљиво како да рукујете грешкама Уколико програмска архитектура дефинише програмску грешку руководилачке стратегије онда једноставно можете да испланирате да пратите ту стратегију У другим случајевима морате да одлучите који приступ ће најбоље радири за специјалне рутине

Размислите о ефикасностиУ зависности од ваше ситуације можете адресирати ефикасност у један од два начина У првој ситуацији у већини система ефикасност није критична У таквимслучају видите да интерфејс рутине буде добро замишљен и код буде читљивтако да можете касније то да поправите ако треба Ако имате добру енкапсулацијуможете да замените спор ресурс језика високог нивоа имплементацијеса бољим алгоритмом или брзи погоднији са језиком ниског-нивоа имплементације и нећете утицати на било коју другу рутину

У другој ситуацији - у мањини система - извршавање је критичноПроблем извршавања може бити проблем у вези са ретким везама базе података ограничена меморије са свега неколико ручица амбициозним временом ограничења или неким другим ретких ресурса Архитектура треба да укаже колико ресурса је свакој рутини (или класи) дозвољено да користи и колико брзо треба да обављају те операције

Дизајнирајте своју рутину тако да задовољава своје ресурсе циљеве брзине Ако било ресурс или брзина изгледа више критичо дизајнирајте тако да ресурсе замените за брзину и обрнуто То је прихватљиво приликом почетног изградње рутински док се не подеси довољно да садовољи своје ресурса и брзину трошења буџета

Поред предузимања ових приступа предложених за ове две опште ситуације то јеобично губљење напора да се ради на ефикасности на нивоу појединих рутинаВелика побољшања долазе од прераде на дизајну високог нивоа а неиндивидуалних рутина Обично користите микро оптимизације само када високниво дизајна изгледа да не подржава циљеве перформанси система инећете знати то све док се цео програм не заврши Не губите време за стругањеинкрементални побољшања све док не знаш да су потребна

Истраживање функционалности доступне у стандардним библиотекамаНајбољи начин како да се побољша оба и квалитет свог кода и вашупродуктивност је да поново употребите добар код Ако се нађете у ситуацији да се борите да дизајнирате рутину која изгледа претерано компликовано запитајте се да ли су неке или све функционалности рутина можда већ доступне у библиотеци кодова околине или алатке коју користите Многи алгоритми су већ измишљени

9

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 10: Симболички код

тестирани објашњени у разној литератури прегледни и побољшани Уместо трошења време да измислиш нешто кад је неко већ написао докторску дисертацију на ту тему потребно вам је неколико минута да погледате код који је већнаписан и уверите се да не радите више посла него што је потребно

Истраживања алготитама и типова податакаАко функционалност није доступна у доступним библиотекама она ипак може бити описана у књизи алгоритама Пре него што кренете у писање компликованог кода из почетка проверите књигу алгоритама да видите шта је већ на располагању Ако користите претходно дефинисани алгоритам будите сигурни да га правилно прилагоде свом програмском језику

Напишите симболички кодМожда нема толико да се пише након што завршите претходне коракеОсновни циљ корака је да се успостави ментална оријентација која је корисна кадави у ствари пишете рутину

Са завршеним прелиминарним корацима можете почети да пишете рутину као симболички код на високом нивоу Само напред и користите свој програмски едитор или интегрисано окружење за писање симболичког кода ndash симболички код биће употребљен као основа за програмски језик кода

Почните са општим и радите у правцу нечег специфичнијег Већина општег дела рутине је заглавље коментара које описује шта рутина требало да ради тако да прво напишите сажет концепт о циљу рутине Концепт ће вам помоћи да разјасните своје схватање о рутини Проблем у писању генералног коментара је упозорење да морате да разумете улогу рутине у програму боље Генерално ако је тешко да сумирате улогу рутине вероватно би требало претпоставити да нешто није у реду Ево примера заглавља коментара који описује рутину

Пример заглавља коментар за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

Након што сте написали општи коментар попуните симболички код на високом нивоу за рутину Пример симболичког кода

Пример симболичког кода за рутинуОва рутина приказује текстуалну грешку на основу грешке кода добијене од позивне рутине Начин на који приказује поруку зависи од тренутног стања обраде које преузима самостално Враћа вредност указујући на успех или неуспех

поставите подразумевани статус на неуспех погледајте поруку засновану на коду грешке

ако код грешке важећи

10

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 11: Симболички код

ако ради интерактивну обраду приказаће текстуалну грешку интерактивно и објавиће успех

ако радите у командној линији пријавите текстуалну грешку командној линији и објавите успех

ако је код грешке неважећи обавести корисника да је откривена унутрашња грешка

повратак информација о статусу

Имајте на уму да је симболички код написан на прилично високом нивоу Свакако није написан у програмском језику Прецизно на енглеском каже шта тачно треба рутина да ради

Размислите о подацимаМожете да дизајнирате податке рутина на неколико различитих места у процесу На пример податак је једноставан и манипулација подацима тренутно није истакнути део рутине Ако је управљање подацима истакнути део рутине вреди размислити о великим деловима података пре него што мислите о рутинској логици Дефиниције кључних типова података су корисне када дизајнирате логику рутине

Проверите симболички кодЈедном када напишете симболички код и дизајнирате податаке одвојите минут да прегледате симболички код који сте написали Удаљите се од њега и размислите о томе како бисте ви то објаснили неком другом

Замолите неког другог да то погледа и саслуша ваше објашњење Можда мислите да то је глупо да неко погледа у 11 линија симболичког кода али ћете се изненадити Симболички код може ваше претпоставке и грешке на високом нивоу учинити очигледнијим него што програмски језик кода ради Људи су више спремни да прегледају неколико редова симболичког кода него што су за разматрање 35 линија Ц + + језика или Јаве

Уверите се да имате лако и лежерно разумевање онога што рутина ради и како то ради Ако не разумете концептуално на нивоу симболичког кода које шансе ћеш имати да разумеш то на нивоу програмског језика А ако га ти не разумеш ко ће други

Пробајте неколико идеја у симболичком коду и задржите најбоље (поновите)Покушајте што више идеја у симболичком коду пре него што почнете кодирање Када почнете кодирање постајете емоционално укључени у свој код и постаје све теже да одбаците лош дизајн и почнете испочетка

11

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 12: Симболички код

Општа идеја је да поновите рутине у симболичком коду све док изјаве симболичког кода не постану једноставне довољно да можете да попуните код испод сваке изјаве и оставите оригинални симболички код као документацију Неки део симболичког кода може да буде на високом нивоу тако да из вашег првог покушаја морате да га анализирате даље Обавезно га анализирајте даље Ако нисте сигурни како да кодирате нешто наставити да радите са симболичким кодом док не будете сигурни Наставите да прерађујете и анализирате симболички код док се не изгледа као губљење времена да га напишете уместо стварног кода

Кодирајте рутину Када дизајнирате рутину изградите је Можете изводити кораке у стандардном редоследу али слободно их мењајте ако имате потребу за тим Слика 9-3 показује кораке у изградњи рутине

Почните са симболичким кодом

Напишите декларацију рутине

Напишите прву и последњу изјаву и претворите симболички код у

коментаре високог нивоа

Испод сваког коментара поставите код

Погледајте неформално код

Поспремите остатке

Почните са формалном провером кодаСлика 93Изводићете све ове кораке као што дизајнирате рутину али не нужно у неком одређеном редоследу

Напишите декларацију рутине Напишите изјаву интерфејса рутине - декларацију функције у Ц + + метода декларације у Јави функцију или под процедуру декларације у Визуал Беизику или како код зе зове програм у коме радите Окрените оригинални

12

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 13: Симболички код

коментар у заглављу у програмски језик коментара Оставите га изнад симболичког кода који сте већ написали Ево примера изјаве интерфејса рутине и заглавља у Ц + +

Ц + +-Пример рутинског интерфејса и заглавља додатог симболичком коду| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех | Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном коду

ако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуОво је добар тренутак да направимо белешке о свим унутрашњим претпоставкама У овом случају унутрашња променљива error је једноставна и уписана због своје посебне сврхе тако да не треба да буде документована

Поставите симболички код на коментаре високог нивоа Будите у току тако што ћете написати прву и последнју изјаву-(и) у Ц + + Затим поставите симболички код у коментаре Ево како ће то изгледати у примеру

Ц + +-Пример писања прве и последње изјаве око симболичког кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку) поставите стстус на ldquoнеуспехrdquoпотражите поруку засновану на погрешном кодуако је погрешан код исправан ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

13

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 14: Симболички код

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

вратите информације о стањуOд овог тренутка карактер рутине је евидентан Дизајн је комплетиран и можете да осетите како рутина ради иако не видите ни један код Требало би да видите да конвертовањем симболичког кода у програмски-језик код ће бити механички природан и лак Ако не наставите да пројектујете у симболичком коду све док дизајн не делује солидно

Испод сваког коментара поставите кодИспод сваког коментара симболичког кода поставите код Процес је сличан писању појмова на папира Први напишете обрис а затим пишете параграф за сваку тачку у приказу структуре Сваки коментар симболичког кода описује блок или параграф кода Као дужине књижевних параграфа дужине параграфа кода варирају у зависности од тога како се изражавамо и квалитет параграфа зависи од јасности и фокуса мисли у њима

На пример прва два коментара симболичког кода стварају две линије кода

Ц + +-Пример показивања симболичког кода коментара као кода| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако ради интерактивно обраду прикажите грешку интерактивно и објавите успех

ако радите из командне линије обраду унесите грешку у командну линију и објавите успех

ако је код грешке неисправан обавестите корисника да је детектована унутрашња грешка

14

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 15: Симболички код

вратите информације о стањуОво је почетак кода Променљива Грешка(errorMessage) је коришћена тако да мора бити проглашена Ако будете коментарисали после сваке чињенице две линије коментара за две линије кода биле би равне уништењу на много начина У овом приступу међутим најважнији је семантичко значење коментара а не колико линија кода оне коментаришу Коментари су већ тамо и они објашњавају намеру кода зато их оставите (за сада најмање)

Испод кодова сваки од преосталих коментара мора да буде попуњен Ево комплетне рутине

Ц++ Пример комплетне рутине написане са симболичким кодом процеса програмирања| Ова рутина приказује грешку засновану на погрешном коду достављеног од рутине која се позива Начин на који приказује грешку зависи од тренутног стања процеса коју сам приказује Враћа вредност указујући на успех или неуспех Статус Пријавитегрешку ( ПогрешанКод ПријављујеГрешку)

поставите стстус на ldquoнеуспехrdquoСтатус СтатусГрешке = Статус_Неуспех

погледај грешку засновану на коду грешкеПорука Грешка = ПогледајтеГрешку(ПријављујеГрешку)

ако је код грешке важећиАко (ГрешкаИсправанКод() ) утврдите метод за обраду МетодОбраде ГрешкаМетодаОбраде = ТренутниМметодОбраде()

ако ради интерактивну обраду прикажите грешку интерактивно и обајавите успех ако (ГрешкаМетодаОбраде)==МетодОбраде_Интерактивни) ПрикажитеИнтерактивнуПоруку (ГрешкаТекст() ) СтатусГрешке = Статус_Успех ако радите из командне линије обраду унесите грешку у командну линију и објавите успехдруго ако ( ГрешкаМетодаОбраде == МетодОбраде_КоманднаЛинија ) КоманднаЛинија УчитавањеПорукеако ( УчитавањеПорукеСтатус( ) == СтатусКоманднеЛиније_Ок ) УчитавањеПорукеДодајтеУРедПорука ( ГрешкаТекст () ) УчитавањеПорукеОсвежитеРедПорука () друго

15

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 16: Симболички код

ништа не може да се уради зато што рутина већ обрађује грешку друго ништа не може да се уради зато што рутина већ обрађује грешку

ако код грешке није исправан обавестити корисника да је детектована унутрашња грешкадруго ПрикажитеИнтерактивнуПоруку ( ldquoУнутрашња Грешка Неважећо код грешке у извештају грешке ()rdquo )

вратити информације о статусувратити извештај о грешциСваки коментар је дао повода за један или више линија кода Сваки блок кода образује потпуну мисао засновану на коментарима Коментари су задржани да би се обезбедио виши ниво објашњења кода Све променљиве су проглашене и дефинисане до сврхе где су прво коришћене Сваки коментар би требало да се прошири обично између 2 и 10 линија кода (Будући да је овај пример само у циљу илустрације експанзија кода је слаба од онога што обично треба искусити у пракси)

Поново погледајте спецификацију на страници 000 и почетни симболички код на страници 000 Оригинална спецификација у 5-реченица проширила се на 15-реченица симболичког кода ( у зависности од тога како рачунате линије ) што је заузврат проширило рутину на целу страну Иако је спецификација детаљна за креирање рутина неопходан је рад на дизајну у симболичком коду и самом коду Низак ниво дизајн је један од разлога зашто је кодирање нетривијалан задатак и зашто је тема ове књиге веома важна Проверите да ли код даље треба да буде факторисанУ неким случајевима видећете како код пуца испод неке од почетних линија симболичког кода У том случају требало би да размислите о предузимању једну од две акције

Факторишите код испод коментара у нову рутину Ако нађете једну линију симболичког кода која се шири у више кодова него што сте очекивали факторишите код у сопствену рутину Напишите код да бисте позвали рутину укључујући назив рутине Ако сте користили СКПП добро име нове рутине требало би да испадне лако из симболичког кода Једном када завршите рутину коју сте првобитно стварили можете врло брзо отпочети нову рутину и применити СКПП на ту рутину

16

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 17: Симболички код

Примените СКПП рекурзивно Уместо да пишете пар десетина линија кода испод једне линије симболичког кода не журите да разложите оргиналну линију симболичког кода у неколико линија симболичког кода Онда наставите да исписујете код испод сваке нове линије симболичког кода

Проверите кодНакон дизајнирања и имплементирања рутине трећи велики корак у изградњи је проверава да је оно што сте конструисали исправно Све грешке које пропустити у овој фази неће бити пронађена све до каснијег тестирања Тада је много скупље да их пронађемо и тестирамо тако да треба пронаћи све што можете у овој фази

Може се десити да се проблем не појави све док рутина не буде потпуно кодирана а све то из неколико разлога Грешка у симболичком коду може постати очигледнија у детаљбој примени логике Дизајн који изгледа елеганто у симболичком коду би могао постати гломазан у инплементационом језику Рад са детаљном имплементацијом може открити грешке у архитектури у дизајну високог нивоа или у захтевима Коначно код може садржати застареле половичне грешке--нико није савршен Из свих ових разлога обавезно проверите код пре него што наставите

Подсвесно проверите рутину због грешакаПрва формална провера рутина је подсвесна Сређивање и неформална провера су кораци које смо споменули раније као две врсте посдвесних провера Други је извршење сваке путање подсвесно Подсвесно извршавања рутина је тешко и због тога што је тешко требало би да ваше рутине буду мале Будите сигурни да сте проверили номиналне путање и крајње тачке и све изузете услове Оба урадите сами а то се назива потпуна провера и са једним или више провера који је назван потпуна провера подпровера или инспекција у зависности од тога како ви то урадите

Једна од огромних разлика између хобиста и професионалних програмера је разлика која произилази из сујеверја у разумевање Реч сујеверје у овом контексту не односи се на програм од којег вам подилази језа или ствара додатне грешке при пуном месецу То значи размењивање осећања о коду да бисте га разумели Ако често посумљате да компајлер или опрема праве грешку ви сте још увек у домену сујеверја Само 5 одсто свих грешке су хардверске компајлерске или - грешке оперативног система ( Остранд и Вејкер 1984)

Програмери који који су већ у домену разумевања увек прво сумњају у свој рад јер знају да су узрок 95 процената грешака Разумите улогу сваке линије кода и зашто је то потребно Ништа није исправно само зато што се чини да функционише Ако не знате зашто то ради вероватно не-али једноставно то не схватате

Задња линија Радна рутина није довољна Ако не знате зашто то ради проучите то разговарајте о томе и експериментишите са алтернативним дизајном све док не урадите то

17

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 18: Симболички код

Компајлирајте рутинуНакон што проверите рутину компајлирајте је Можда делује неефикасно што оволико дуго чекамо да компајлирамо пошто је код већ завршен неколико страница пре истина можда сте сачували рад компајлирајући рутину раније и пуштајући компијутер да провери непријављене променљиве дајући називе конфликтима и тако даље

Имаћете користи на неколико начина међутим што не компајлирате до пред крај процеса Главни разлог је да када саставити нови код унутрашња штоперица почиње да откуцава Након првог компајлирања подносите притисак добили сте право за ldquoЈош Једно За Компајлирањеrdquo Синдром ldquoЈош Једно За Компајлирањеrdquo води ка исхитреном грешкама подложним променама за које је потребно више времена на дуге стазе Избегните журбу да завршите све док не убедите себе да је рутина исправна

Суштина ове књиге је да покаже како да се подигнете изнад циклуса хакерисања нечега заједнои покренути га да видите да ли ради Компајлирање пре него што сте сигурни да ваш програм ради је често симптом хакерске контроле ума Ако се нисте запетљали у хакерско компајлирућем кругу компајлирајте када мислите да је то најприкладније Али будите свесни мишљења већине људи према хакерисању компајлирању и поправкама вашим начином да учините да програм ради

Овде су нека упутства да извучете највише за компајлирање ваше рутине Подесите ниво упозорења компајлера на највећи могући ниво Можете ухватити невероватно велики број суптилних грешака дозвољавајући компајлеру да их открије

Уклоните узорке свих компајлерских грешака и упозорења Обратите пажњу на шта вам компајлер говори о вашем коду Велики број упозорења често указује код слабог квалитета и требало би да покушате да разумете свако упозорење које сте добили У пракси упозорења која виђате изнова и изнова једну од две могуће последице Ви их игноришете и оне скривају друга важнија упозорења или постану досадне као кинеско мучење водом Обично је сигурније и мање болно ако поново прерадити код да реши проблем и елиминише упозорења

Проверите код у програму за отклањање грешака Једном када се рутина компајлира проверите је у програму за отклањање грешака и прођите кроз сваку лионију кода Уверите се да се сваки ред извршава како очекујете ви Можете наћи многе грешке пратећи ову једноставну процедуру

Тестирајте кодТестирајте код користећи проверене случајеве ако сте планирали или направили док сте развијали рутину Можда ћете морати да развијете ldquoскелеrdquo за подршку за ваше случајеве за проверу -- кода који је коришћен као подршка рутинама док су оне тестиране и док нису укључене у коначни производ ldquoСкелеrdquo могу бити добра

18

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 19: Симболички код

провера рутине која позива вашу рутину са провереним подацима или се може ldquoвезатиrdquo позивом ваше рутине

Уклони грешке из рутинеКада је грешка откривена мора да буде уклоњена Ако је рутина коју сте развијали багована до овог тренутка добре су шансе да остати багована Ако сазнате да је рутина пуна грешака (багована) почните испочетка Не исправљајте је Напишите је поново Исправке обично показују непотпуно разумевање и гарантује грешке и сада и касније Стварање потпуно новиог дизајна за баговану рутину исплати се Постоје неколико ствари које су више него задовољавајуће од писања нове рутине а то је да у новој нећете пронаћи грешке

Средите оно што је остало Када сте завршили проверу кода због могућих проблема проверите га за опште карактеристике описане у целој овој књизи Можете да предузмете неколико корака за сређивање представљених у овој књизи Можете да предузмете неколико корака за сређивање да бисте се уверили да је рутина по вашим стандардима

Проверите интерфејс рутине Уверите се да су сви улазни и излазни подаци објашњени и да су употребљени сви параметри За више детаља видите Одељак 75 ldquoКако да користите параметре рутинеrdquo

Проверите општи квалитет дизајна Будите сигурни да рутина ради једну ствар и да је ради добро да се слободно везује за друге рутине и да је дизајнирана дефанзивно За детаље погледајте Поглавље 7 ldquoВисоко-Квалитетне рутинеrdquo

Проверите податке у рутини Проверите нетачне називе променљивих некоришћене података необјављене податке и тако даље За детаље погледајте поглавља о коришћењу података Поглавља 10 до 13

Проверите рутински извештај и логику Проверите све-до-једне грешке бесконачне петље и неправилног гнежђења За детаље видите поглавља о изјавама Поглавља 14 до 19

Проверите распоред рутина Уверите се да сте користили размак да разјасните логичке структуре рутине изразе и параметре листе За детаље погледајте Поглавље 31 Распоред и Обликовање

Проверите документацију рутине Будите сигурни да је симболички код који је преведен у коментаре и даље тачан Погледајте опис за алгоритам за документовање спољних претпоставки и неочигледне зависности за оправданост нејасне праксе кодирања и тако даље За детаље погледајте Поглавље 32 Суштина-Документованог кода

Уклоните сувишне коментаре Понекад коментар симболичког кода зна да буде сувишан заједно са кодом који коментар описује посебно када се СКПП примењује рекурзивно и коментар само претходи позиву добре по имену рутине

19

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 20: Симболички код

Поновите кораке ако је потребно Ако је квалитет рутине слаб све до симболичког кода Високо-квалитетно програмирање је итеративни процес неустручавајте се да погледате кроз активности изградње поново

94 Алтернативе СКПП

За свој новац СКПП је најбоља метода за креирање класа и рутина Овде су неки од алтернативних приступа препоручени од стране неких експерата

Прва-провера развојаПрво-провера популарни развојни стил у којима су тестирани случајеви написани пре писања неког кода Овај приступ је детаљније описан у Прво Тест или Тест Kaсније у одељку 222 Добра књига о прво-провера је књига Кента Бека Развој Кроз Тестирање (Бек 2003)

Дизајн по уговоруДизајн по уговору је развоји приступ у којем се за сваку рутину сматра да има предуслове и подуслове Овај приступ је описан у Користи тврдње да документујеш предуслове и подуслове у Одељку 82 Најбољи извор информација о дизајну по уговору је Бертран Мајерссов Објектно-оријентисани софтвер у грађевинарству (Мајер 1997)

Хакерисање Неки програмери покушавају да скрате пут према исправном коду радије него да користе системски приступ као СКПП Ако икада откријете да сте себе сатерали у чошак у рутини и зато морате да почнете испочетка то је назнака да СКПП може да ради боље Ако се нађете у ситуацији да изгубите тренутну мисао у току кодирање рутине то је још један показатељ да ће СКПП бити од користи Да ли сте икада једноставно заборавили да напише део класе или део рутине То се ретко дешава ако користите СКПП Ако се нађете у ситуацији да безидејно гледате у монитор не знајући одакле да почнете то је поуздан знак да ће СКПП направити ваш програмерски живот лакшим

КОНТРОЛНА ЛИСТА Симболички код процеса програмирања1048713 Да ли сте проверили да ли су предуслови задовољени 1048713 Да ли сте дефинисали проблем класа ће се решити 1048713 Да ли је дизајн високог нивоа довољно јасан да да класи и свакој њеној рутина добар назив1048713 Да ли сте размишљали о томе како да тестирате класу и сваку њену рутину1048713 Да ли сте размишљали о ефикасности углавном у смислу стабилног интерфејса и читљиве имплементације или у смислу преосталих ресурса и брзина трошења буџета1048713 Јесте ли проверили стандардне библиотеке и остале библиотеке кода за важећим рутинама или компонентама1048713 Да ли сте проверили приручнике због корисних алгоритама

20

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21

Page 21: Симболички код

1048713 Да ли сте дизајнирали сваку рутину користећи детаљан симболички код 1048713 Јесте ли проверили подсвесно симболички код Да ли га је лако разумети 1048713 Да ли си обратио пажњу на упозорења која би вас послала назад на дизајн (употреба глобалних података операције које се чине боље одговарајућим за друге класе или друге рутине и тако даље)1048713 Да ли сте превели симболички код у код тачно 1048713 Да ли сте применити рекурзивно СКПП разбијањем рутина у мање рутине када је то потребно 1048713 Да ли сте документовали претпоставке када сте их начинили 1048713 Да ли сте уклонили коментаре за који се испоставило да је сувишан1048713 Да ли сте изабрали најбољу од неколико итерација радије него да застанете након ваше прве итерације 1048713 Да ли заиста разумете код Да ли је лако разумети

Кључне тачке Конструисање класа и изградња рутина има тенденцију да буде итеративан процес Стичемо увид док изграђујемо специфичне рутине које имају тенденцију да нас одвуку назад у дизајн класе

За писање доброг симболичког кода тражи потребу познавања разумљивог енглеског избегавајући будуће специфичности иједног програмског језика и писања на нивоу намереmdashрадије описујући шта дизајн ради него како ће то урадити

Симболички код процеса програмирања је корисно средство за детаљно пројектовање и чини кодирање једноставним Симболички код преводи директно у коментаре обезбеђујући се да су коментари тачни и корисни

Не задовољавајте се првим дизајном који вам падне на памет Итерирајте кроз више приступа у симболичком коду и изаберите најбољи приступ пре него што кренете да пишете код

Проверавајте свој рад у сваком кораку и подстичите друге да то раде На тај начин увидећете грешке на последњем најскупљем нивоу када сте већ потрошили и последњи атом снаге

21