Како кажу, ако се не стидите свог старог кода, онда не растете као програмер - и слажем се са овим мишљењем. Почео сам да програмирам из забаве пре више од 40 година, а професионално пре 30 година, тако да имам много грешака. пуно. Као професор информатике, учим своје ученике да уче из грешака – њихових, мојих и туђих. Мислим да је време да причам о својим грешкама како не бих изгубио скромност. Надам се да ће некоме бити од користи.

Треће место - Мицрософт Ц компајлер

Мој школски учитељ је веровао да се Ромео и Јулија не могу сматрати трагедијом јер ликови нису имали трагичну кривицу – једноставно су се понашали глупо, као што би тинејџери требало. Тада се нисам слагао са њим, али сада видим зрнце рационалности у његовом мишљењу, посебно у вези са програмирањем.

У време када сам завршио другу годину на МИТ-у, био сам млад и неискусан, како у животу тако и у програмирању. У лето сам стажирао у Мицрософт-у, у тиму компајлера Ц. Прво сам радио рутинске ствари као што је подршка за профилисање, а онда ми је поверен рад на најзабавнијем делу компајлера (како сам мислио) – оптимизацији позадине. Конкретно, морао сам да побољшам к86 код за изјаве о гранама.

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

То је била ноћна мора. Много година касније речено ми је да ме је програмер који је наследио мој код мрзео.

Лекција научена

Као што пишу Дејвид Патерсон и Џон Хенеси у „Архитектура рачунара и дизајн рачунарских система“, један од главних принципа архитектуре и дизајна је да, генерално, ствари треба да раде што је брже могуће.

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

У своју одбрану, покушао сам да схватим како изјаве о гранама изгледају у пракси (као на пример колико је грана било и како су константе распоређене), али 1988. ове информације нису биле доступне. Међутим, није требало да додајем посебне случајеве кад год тренутни компајлер није могао да генерише оптималан код за вештачки пример који сам смислио.

Морао сам да позовем искусног програмера и да заједно са њим размислим о томе који су уобичајени случајеви и конкретно се позабавим њима. Написао бих мање кода, али то је добра ствар. Као што је оснивач Стацк Оверфлов-а Џеф Атвуд написао, најгори непријатељ програмера је сам програмер:

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

Да сам написао једноставнији код који покрива уобичајене случајеве, било би много лакше ажурирати ако је потребно. За собом сам оставио неред са којим нико није хтео да се бави.

Друго место: оглашавање на друштвеним мрежама

Када сам радио у Гоогле-у на оглашавању на друштвеним мрежама (сећате ли се Миспаце-а?), написао сам нешто овако на Ц++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

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

Ништа се лоше није догодило. Никоме се ништа није покварило, јер је пре глобалног лансирања код тестиран у једном дата центру. Осим ако су инжењери СРЕ-а престали да играју билијар на неко време и направили мали повратак. Следећег јутра примио сам е-поруку са црасх думп-ом, исправио код и додао јединичне тестове који би ухватили грешку. Пошто сам следио протокол - иначе мој код једноставно не би могао да се покрене - није било других проблема.

Лекција научена

Многи су сигурни да ће тако велика грешка дефинитивно коштати отпуштања кривца, али то није тако: прво, сви програмери греше, а друго, ретко праве исту грешку два пута.

У ствари, имам пријатеља програмера који је био бриљантан инжењер и отпуштен је због једне грешке. После тога је примљен у Гугл (и убрзо унапређен) – искрено је говорио о грешци коју је направио у интервјуу, а није се сматрала фаталном.

Ето шта реци о Томасу Вотсону, легендарном шефу ИБМ-а:

Објављена је владина поруџбина вредна око милион долара. ИБМ Цорпоратион - или боље речено, Томас Вотсон старији лично - заиста је желео да је добије. Нажалост, представник продаје није био у могућности да то уради и ИБМ је изгубио понуду. Следећег дана, овај службеник је дошао у канцеларију господина Вотсона и ставио коверат на његов сто. Господин Вотсон се није ни потрудио да га погледа – чекао је запосленог и знао је да је то писмо о оставци.

Вотсон је питао шта је пошло по злу.

Представник продаје је детаљно говорио о току тендера. Он је навео учињене грешке које су се могле избећи. На крају је рекао: „Господине Вотсон, хвала вам што сте ми дозволили да објасним. Знам колико нам је ова наредба била потребна. Знам колико је био важан“, и спремио се да оде.

Вотсон му је пришао на вратима, погледао га у очи и вратио коверат са речима: „Како да те пустим? Управо сам уложио милион долара у твоје образовање.

Имам мајицу на којој пише: „Ако заиста учиш на грешкама, онда сам већ мајстор. У ствари, када су грешке у питању, ја сам доктор наука.

Прво место: Апп Инвентор АПИ

Заиста страшне грешке погађају огроман број корисника, постају општепознате, дуго се исправљају, а праве их они који нису могли да их направе. Моја највећа грешка одговара свим овим критеријумима.

Што горе то боље

Читам есеј Ричарда Габријела о оваквом приступу деведесетих година као постдипломцу, и толико ми се допада да га питам својим студентима. Ако се не сећате добро, освежите памћење, мало је. Овај есеј супротставља жељу да се „исправи“ и приступ „што је горе то боље“ на много начина, укључујући једноставност.

Како би требало да буде: дизајн треба да буде једноставан у имплементацији и интерфејсу. Једноставност интерфејса је важнија од једноставности имплементације.

Што горе, то боље: дизајн треба да буде једноставан у имплементацији и интерфејсу. Једноставност имплементације је важнија од једноставности интерфејса.

Заборавимо на то на тренутак. Нажалост, заборавио сам на то много година.

Апп Инвентор

Док сам радио у Гуглу, био сам део тима Апп Инвентор, превуци и испусти онлајн развојно окружење за амбициозне Андроид програмере. Била је 2009. година и журили смо да на време издамо алфа верзију како бисмо лети могли да држимо мајсторске курсеве за наставнике који би могли да користе окружење приликом предавања на јесен. Добровољно сам се пријавио за имплементацију сприте-ова, носталгичан за начином на који сам писао игре на ТИ-99/4. За оне који не знају, сприте је дводимензионални графички објекат који може да се креће и да комуницира са другим софтверским елементима. Примери духова укључују свемирске бродове, астероиде, кликере и рекете.

Имплементирали смо објектно оријентисани Апп Инвентор у Јави, тако да постоји само гомила објеката. Пошто се лопте и сприте понашају веома слично, направио сам апстрактну класу сприте-а са својствима (пољима) Кс, И, Спеед (брзина) и Хеадинг (смер). Имали су исте методе за откривање судара, одбијања од ивице екрана итд.

Главна разлика између лопте и сприте-а је шта је тачно нацртано - попуњен круг или растер. Пошто сам прво имплементирао спрајтове, било је логично да наведем к- и и-координате горњег левог угла где се налазила слика.

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

У ствари, било је неопходно назначити к- и и-координате центра круга, као што се учи у било ком уџбенику математике и било ком другом извору који помиње кругове.

За разлику од мојих претходних грешака, ова је утицала не само на моје колеге, већ и на милионе корисника Апп Инвентор-а. Многи од њих су били деца или потпуно нови у програмирању. Морали су да изврше много непотребних корака при раду на свакој апликацији у којој је била присутна лопта. Ако се са смехом сетим својих осталих грешака, онда се ова и данас озноји.

Коначно сам закрпио ову грешку тек недавно, десет година касније. „Закрпљено“, а не „поправљено“, јер како каже Џошуа Блох, АПИ-ји су вечни. Пошто нисмо у могућности да извршимо промене које би утицале на постојеће програме, додали смо својство ОригинАтЦентер са вредношћу „фалсе“ у старим програмима и „труе“ у свим будућим програмима. Корисници могу поставити логично питање: ко је уопште помислио да почетну тачку постави негде другде, а не у центар. Коме? Једном програмеру који је био превише лењ да направи нормалан АПИ пре десет година.

Научене лекције

Када радите на АПИ-јима (што скоро сваки програмер понекад мора да уради), требало би да следите најбоље савете наведене у видеу Џошуе Блоха "Како направити добар АПИ и зашто је то толико важно"или у овој краткој листи:

• АПИ вам може донети и велику корист и велику штету.. Добар АПИ ствара поновне купце. Лоша постаје твоја вечна ноћна мора.
• Јавни АПИ-ји, попут дијаманата, трају заувек. Дајте све од себе: никада више неће бити прилике да све урадите како треба.
• Нацрти АПИ-ја треба да буду кратки — једна страница са потписима и описима класа и метода, која не заузима више од једног реда. Ово ће вам омогућити да лако реструктурирате АПИ ако не испадне савршен први пут.
• Опишите случајеве употребепре имплементације АПИ-ја или чак рада на његовој спецификацији. На овај начин ћете избећи имплементацију и навођење потпуно нефункционалног АПИ-ја.

Да сам написао макар и кратак синопсис са вештачким скриптом, највероватније бих идентификовао грешку и исправио је. Ако не, онда би то сигурно урадио неко од мојих колега. О свакој одлуци која има далекосежне последице треба размишљати бар један дан (ово се не односи само на програмирање).

Наслов есеја Ричарда Габријела, „Што је горе је боље,“ односи се на предност која се односи на то да будете први на тржишту – чак и са несавршеним производом – док неко други проводи вечност јурећи за савршеним. Размишљајући о коду сприте-а, схватам да нисам чак ни морао да пишем више кода да бих био исправан. Шта год неко рекао, грдно сам се преварила.

Закључак

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

Стално се сусрећем са студентима који се осећају као да праве превише грешака и због тога нису створени за програмирање. Знам колико је синдром преваранта уобичајен у ИТ-у. Надам се да ћете научити лекције које сам навео – али запамтите главну: свако од нас прави грешке – срамотне, смешне, страшне. Бићу изненађен и узнемирен ако у будућности не будем имао довољно материјала за наставак чланка.

Извор: ввв.хабр.цом