Често, задатак на коме се ради је дефинисан-описан у неком систему за евиденцију буба (у време писања ових редова, ЈИРА је била популарна). Сваки задатак (буба, “тикет”) има неки идентификатор. Углавном, ради се о мнемонику после кога следи број, попут: МСП-5443. Симпатично је и корисно да се овај ознака упише “на погодно место”. Рецимо, у напомени у систему за контролу верзија (при стављању у СКВ), што омогућава да ЈИРА повеже бубу са одговарајућом изменом у СКВ. Али, у изворном коду, скреће пажњу, лако “забуђа” и, једном речју, представља мору за одржавање.

А коме то уопште паде на памет?

Па, искрено, идеја звучи добро на први поглед. Ако забележите ознаку “тикета”, можете да избегнете објашњавање проблема који се решава, што може да буде подоста текста и, утолико пре, слика и илустрација. Просто, читалац види ознаку и може да брзо оде у систем за евиденцију буба и види о чему се ради. Чак, неко напредно окужење би омогућило да се простим кликом на ознаку у коментару аутоматски скочи на (Њеб) корисничку спрегу система за евиденцију буба.

Па то је баш супер - што би то био проблем?

Има неколико разлога који су унеколико повезани, али, размотрићемо их одвојено.

То је скретање са теме

Када се пише изворни код, највећа услуга коју можете да учините ономе који ће тај код касније дачита (а што можете да будете управо ви) је да код и коментари буду што усредсређенији на оно чиме се баве.

Ознака бубе је управо обрнуто: скретање са теме. Сама ознака нема икакво значење само по себи. Стога, читалац ће да застане на тренутак да проба да пронађе значење. Очигледно, више неће бити усредсређен на код, па, чак иако неко напредно развојно окружење омогући да се ово скретање са теме одради “колико је брже могуће”.

Штавише, “тикети” система за евиденцију буба често имају много података који немају икакве везе са изворним кодом, попут ознаке “пројекта”, “групе пројеката”, “фазе”, “повезане бубе”, “озбиљност”, “ниво”, “процењено време за отклањање”, “рок” и многе друге. Стога често није тек тако лако доћи до онога што нас занима, а то је сам опис бубе, односно задатка.

Много је боље објаснити оно што има да се објасни у самом коментару.

Системи за евиденцију буба нису вечни

Пошто нису дијаманти, онда није не чудо.

Шалу на страну, ови системи су прилично “крти”. Често се мењају, односно са једног прелази на други, када се често стари не пребаце у нови, а стари врло брзо изгуби / нестане.

Такође, пошто су одвојени и сматрају се мање важним од самог кода, (са правом), чешће губе податке, чак и без замене или преласка на нову верзију.

Дакле, ако је ваш код “дугоживећи” (више од неколико година), ове ознаке постају бескорисне. Барем програмерима. Неким програмским археолозима могу да буду врло занимљиве.

Измене не морају да буду локализоване

Сећате ли се У2К? У то време, био је популаран штос да је неко то схватио као “променити слово У у слово К у свим извештајима”.

Заозбиљно, сличне ствари се дешавају. Рецимо, неко може да затражи да се у извештајима користи ИСО 8601 формат датума уместо локалног. Да би се то извело, највероватније ће бити много измена “свуда по коду” и стављање ознаке бубе код свих тих измена би било беспредметно.

Чак и у неком мање изузетном примеру, може да се деси да је потребно направи измену на више него једном место у изворном коду. Ако код свих измена стављамо коментар са ознаком бубе, то је напорно, а ако то радимо само негде, онда треба да смислимо разлог за то.

Готово је немогуће то одржавати

Ово је најбоље објаснити на примеру.

Замислимо да је наш добронамерни програмер написао нешто попут:

# МСП-5443: Пуца при додавању нових података у постојећи елемент
#           при вучењу мишем
if вуче then
    омогућено_додавање = false
end

Пример је мало “монтиран”, али, инспирисан стварним примером. Да, ово вероватно није баш најбољи начин да се ово “спуцавање” реши, али, то би само требало да потврди да је ово инспирисано стварним догађајима.

На прву лопту, ово је јасно. Али, касније се појави још једна буба или пак захтев за унапређење, рецимо, да подаци могу да се додају тастатуром. Једна од измена која је потребна би била у овом нашем парчету кода:

# МСП-5443: Пуца при додавању нових података у постојећи елемент
#           при вучењу мишем
if вуче and not додаје_тастатуром then
    омогућено_додавање = false
end

Очигледно, овај коментар је сада неажуран. У неком смислу, није погрешан, али, читајући га “тако како стоји”, читалац ће да помисли да је цео услов ту због МСП-5443. То није тачно, цео услов је ту и због МСП-6554. Дакле, да би се коментар одржао ажруним, треба нам нешто попут:

# МСП-5443: Пуца при додавању нових података у постојећи елемент
#           при вучењу мишем
# МСП-6554: Омогући додавње података тастатуром
if вуче and not додаје_тастатуром then
    омогућено_додавање = false
end

Е, сад. Шта ако се појави још један тикет који изискује измену у овом истом парчету кода? Мислим да је јасно где идемо са овом анализом… и то уопште није неко лепо место…

Са становишта изворног кода

Замислимо ознаке буба у коментарима као показиваче не меморију на којој нисмо власни, ни понајмање.

Неко ту “меморију” може да обрише а да ми и не приметимо и имаћемо нешто попут “употребе меморије након ослобађања”.

Или, ознаку нећемо да ажурирамо и она одједном показује на нешто потпуно погрешно.

Ово не важи само са системе за евиденцијз буба

Сличан проблем постоји и са бројевима уговора, ознакама измена у СКВ-овима (додато у измени 4455fa2) и сличним “референцама на спољашњи свет”.

Немојмо претеривати

Није увек све тако лоше. Рецимо, ако хоћемо да се позовемо на неки (међународни) стандард, попут: IETF RFC 3543 или ITU-T Q.703:1992 (за неке стандарде, потребно је навести и годину). То има смисла јер објашњава “зашто ово радимо” или “зашто нека константа има дату вредности” и слично.

Слично, давање ознаке књиге или чланка/рада који се “показује” где је неки алгоритам дефинисан, је сасвим у реду.

Очигледно, ствари су у реду када се показује на нешто што је стабилно. То личи на случај показивча на меморију за коју се зна да никад неће бити ослобођена или померена и наш код, чак и ако се сам мења, неће показивати на неку другу меморију.

Наравоученије

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

Things that look good and are done with the best of intentions, often are not really such and have bad, unintended consequences.