Як гаворыцца, калі табе не сорамна за свой стары код, значыць, ты не расцеш як праграміст - і я згодна з такой думкай. Я пачала праграмаваць для забаўкі больш за 40 гадоў таму, а 30 гадоў таму і прафесійна, так што памылак у мяне набралася вельмі шмат. Будучы прафесарам інфарматыкі, я вучу сваіх студэнтаў здабываць урокі з памылак - сваіх, маіх, чужых. Думаю, прыйшоў час расказаць пра мае памылкі, каб не разгубіць сціпласць. Спадзяюся, камусьці яны будуць карыснымі.

Трэцяе месца - кампілятар C ад Microsoft

Мой школьны настаўнік лічыў, што «Рамэа і Джульету» нельга лічыць трагедыяй, таму што ў герояў не было трагічнай віны - проста яны паводзілі сябе бязглузда, як і належыць падлеткам. Тады я з ім не пагадзілася, але зараз бачу ў яго думцы рацыянальнае збожжа - асабліва ў сувязі з праграмаваннем.

Да моманту заканчэння другога курса MIT я была маладая і нявопытная, як у жыцці, так і ў праграмаванні. Улетку я праходзіла практыку ў Microsoft, у камандзе кампілятара C. Спачатку я займалася руцінай накшталт падтрымкі прафілявання, а потым мне даверылі працу над самай вясёлай (як я лічыла) часткай кампілятара – аптымізацыяй бэкенда. У прыватнасці, я павінна была палепшыць код x86 для аператараў галінавання.

Настроеная напісаць аптымальны машынны код для кожнага магчымага выпадку, я кінулася ў вір з галавой. Калі шчыльнасць размеркавання значэнняў была высокая, я ўносіла іх у табліцу пераходаў. Калі ў іх меўся агульны дзельнік, я выкарыстоўвала яго, каб зрабіць табліцу шчыльней (але толькі калі дзяленне можна было выканаць пры дапамозе бітавага зруху). Калі ўсе значэнні ўяўлялі сабой ступені двойкі, я праводзіла яшчэ адну аптымізацыю. Калі мноства значэнняў не задавальняла маім умовам, я разбівала яго на некалькі якія аптымізуюцца выпадкаў і выкарыстоўвала ўжо аптымізаваны код.

Гэта быў кашмар. Праз шмат гадоў мне распавядалі, што які ўспадкаваў мой код праграміст мяне ненавідзеў.

Вынесены ўрок

Як пішуць Дэвід Патэрсан і Джон Хэнэсі ў кнізе «Архітэктура кампутара і праектаванне кампутарных сістэм», адзін з галоўных прынцыпаў архітэктуры і распрацоўкі ў тым, каб у агульных выпадках усё працавала як мага хутчэй.

Паскарэнне агульных выпадкаў павысіць прадукцыйнасць больш эфектыўна, чым аптымізацыя рэдкіх выпадкаў. Як ні іранічна, агульныя выпадкі часта прасцей рэдкіх. Гэтая лагічная рада мае на ўвазе, што вы ведаеце, які выпадак лічыць агульным — а гэта магчыма толькі падчас асцярожнага тэставання і вымярэнні.

У сваю абарону магу сказаць, што я спрабавала разабрацца, як выглядалі аператары галінавання на практыцы (напрыклад, колькі існавала галінак і як былі размеркаваны канстанты), але ў 1988 годзе гэтая інфармацыя была недаступная. Тым не менш, мне не каштавала дадаваць адмысловыя выпадкі кожны раз, калі дзейсны кампілятар не мог згенераваць аптымальны код для прыдуманага мной штучнага прыкладу.

Мне трэба было паклікаць вопытнага распрацоўшчыка і разам з ім падумаць, якія былі агульныя выпадкі, і разабрацца канкрэтна з імі. Я напісала б менш за код, але гэта нават добра. Як пісаў заснавальнік Stack Overflow Джэф Этвуд, злейшы вораг праграміста – сам праграміст:

Я ведаю, што ў вас самыя добрыя намеры, як і ва ўсіх нас. Мы ствараем праграмы і любім пісаць код. Так ужо мы ўладкованыя. Мы думаем, што любую праблему можна вырашыць пры дапамозе ізаленты, самаробнага мыліцы і дробкі кода. Як бы ні было балюча кодэрам прызнаваць гэта, але лепшы код - той код, якога няма. Кожны новы радок мае патрэбу ў адладцы і падтрымцы, яе трэба разумець. Дадаючы новы код, вы павінны рабіць гэта з неахвотай і агідай, таму што ўсе іншыя варыянты аказаліся вычарпаныя. Многія праграмісты пішуць занадта шмат кода, робячы яго нашым ворагам.

Калі б я напісала прасцейшы код, які пакрываў агульныя выпадкі, то пры неабходнасці яго было б куды прасцей абнавіць. Я ж пакінула бязладзіцу, з якім ніхто не хацеў звязвацца.

Другое месца: рэклама ў сацсетках

Калі я працавала ў Google над рэкламай для сацсетак (падушыце Myspace?), я напісала на C++ нешта накшталт гэтага:

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)) {
  }
}

Праграмісты, магчыма, адразу ўбачаць памылку: апошнім аргументам павінен быць j, а не i. Модульнае тэсціраванне не выявіла памылку, не заўважыў яе і мой правяраючы. Быў праведзены запуск, і неяк уначы мой код адправіўся на сервер і абваліў усе кампутары ў дата-цэнтры.

Нічога страшнага не здарылася. Ні ў кога нічога не зламалася, таму што перад глабальным запускам код тэсціраваўся ў межах аднаго дата-цэнтра. Няўжо што SRE-інжынеры ненадоўга кінулі гуляць у більярд і зрабілі невялікі адкат. Раніцай я атрымала email з аварыйным дампам, выправіла код і дадала модульных тэстаў, якія выявілі б памылку. Паколькі я прытрымлівалася пратаколу - інакш мой код бы проста не прайшоў запуск - іншых праблем не ўзнікла.

Вынесены ўрок

Шмат хто ўпэўнены, што падобная буйная памылка абавязкова варта віноўніку звальнення, але гэта не так: па-першае, усе праграмісты памыляюцца, па-другое, яны рэдка здзяйсняюць адну памылку двойчы.

Насамрэч, у мяне ёсць знаёмы праграміст - бліскучы інжынер, якога звольнілі за адну-адзіную памылку. Пасля гэтага яго ўзялі на працу ў Google (і неўзабаве падвысілі) - ён сапраўды распавёў аб дапушчанай памылцы на інтэрв'ю, і яе не палічылі фатальнай.

вось што распавядаюць пра Томаса Уотсана, легендарным кіраўніку IBM:

Быў аб'яўлены дзяржзаказ на суму каля мільёна долараў. Карпарацыя IBM – а дакладней, асабіста Томас Уотсан-старэйшы – вельмі хацеў яго атрымаць. Нажаль, гандлёвы прадстаўнік не змог гэтага зрабіць, і IBM прайграла тэндэр. На наступны дзень гэты супрацоўнік прыйшоў у кабінет да містэра Уотсана і паклаў яму на стол канверт. Містэр Уотсан нават не стаў у яго зазіраць - ён чакаў супрацоўніка і ведаў, што гэта заява аб сыходзе.

Уотсан спытаў, што пайшло не так.

Гандлёвы прадстаўнік падрабязна расказаў аб ходзе тэндэру. Ён назваў дапушчаныя памылкі, якіх можна было пазьбегнуць. Нарэшце, ён сказаў: «Містэр Уотсан, дзякуй вам за тое, што далі мне растлумачыць. Я ведаю, наколькі мы мелі патрэбу ў гэтай замове. Я ведаю, як ён быў важны», - і сабраўся сыходзіць.

Уотсан падышоў да яго каля дзвярэй, паглядзеў яму ў вочы і вярнуў канверт са словамі: «Як я магу даць табе сысці? Я ж толькі што ўклаў мільён долараў у тваю адукацыю.

У мяне ёсць футболка, на якой напісана: "Калі на памылках і праўда вучацца, то я ўжо магістр". Насамрэч па частцы памылак я доктар навук.

Першае месца: App Inventor API

Па-сапраўднаму страшныя памылкі закранаюць велізарную колькасць карыстачоў, становяцца здабыткам грамадскасці, доўга выпраўляюцца і дапушчаюцца тымі, хто мог бы іх не дапушчаць. Мая найбуйная памылка задавальняе ўсім гэтым крытэрам.

Чым горш, тым лепей

я чытала эсэ Рычарда Гэбрыэла пра гэты падыход у дзевяностыя, будучы аспірантам, і яно мне так падабаецца, што я задаю яго сваім студэнтам. Калі вы дрэнна яго падушыце, асвяжыце памяць, яно невялікае. У гэтым эсэ жаданне "зрабіць як трэба" і падыход "чым горш, тым лепш" супрацьпастаўляюцца па многіх параметрах, у тым ліку прастату.

Як трэба: дызайн павінен быць простым у рэалізацыі і інтэрфейсе. Прастата інтэрфейсу важней прастаты рэалізацыі.

Чым горш, тым лепш: дызайн павінен быць простым у рэалізацыі і інтэрфейсе. Прастата рэалізацыі важней прастаты інтэрфейсу.

Забудземся пра гэта на хвілінку. Нажаль, я забылася аб гэтым на доўгія гады.

Прыкладанне вынаходнік

Працуючы ў Google, я ўваходзіла ў каманду Прыкладанне вынаходнік, анлайнавай асяроддзя распрацоўкі з падтрымкай перацягвання аб'ектаў для пачаткоўцаў Android-распрацоўшчыкаў. Ішоў 2009 год, і мы спяшаліся своечасова выпусціць альфа-версію, каб улетку правесці майстар-класы для настаўнікаў, якія маглі б карыстацца асяроддзем пры навучанні ўжо ўвосень. Я падахвоцілася рэалізаваць спрайты, настальгуючы па тым, як у свой час я пісала гульні на TI-99/4. Для тых, хто не ў курсе: спрайт - гэта двухмерны графічны аб'ект, які можа перамяшчацца і ўзаемадзейнічаць з іншымі праграмнымі элементамі. Прыклады спрайт - касмічныя караблі, астэроіды, шарыкі і ракеткі.

Мы рэалізавалі аб'ектна-арыентаваны App Inventor у Java, так што там проста куча аб'ектаў. Паколькі шарыкі і спрайты паводзяць сябе вельмі падобна, я стварыла абстрактны sprite-клас са ўласцівасцямі (палямі) X, Y, Speed ​​(хуткасць) і Heading (кірунак). Яны валодалі аднымі і тымі ж метадамі выяўлення сутыкненняў, адскоку ад мяжы экрана і т.д.

Галоўнае адрозненне паміж шарыкам і спрайтам у тым, што менавіта намалявана - запоўнены круг або растр. Паколькі спачатку я рэалізавала спрайты, лагічна было паказаць x-і y-каардынаты верхняга левага кута месца, дзе размяшчалася выява.

Калі спрайты зарабілі, я вырашыла, што можна рэалізаваць аб'екты-шарыкі вельмі невялікай колькасцю кода. Праблема была толькі ў тым, што я пайшла самым простым шляхам (з пункту гледжання рэалізатара), паказаўшы x-і y-каардынаты верхняга левага кута контуру, які атачае шар.

Насамрэч трэба было пазначыць x- і y-каардынаты цэнтра круга, як гэтаму вучыць любы падручнік матэматыкі і любая іншая крыніца, якая згадвае колы.

У адрозненне ад маіх мінулых памылак, ад гэтай пацярпелі не толькі мае калегі, але і мільёны карыстальнікаў App Inventor. Многія з іх былі дзецьмі ці зусім навічкамі ў праграмаванні. Ім даводзілася выконваць шмат лішніх дзеянняў пры працы над кожным дадаткам, у якім прысутнічаў шар. Калі астатнія свае памылкі я ўспамінаю са смехам, то гэтая кідае мяне ў пот і сёння.

Я нарэшце запатчыла гэтую памылку толькі нядаўна, дзесяць гадоў праз. "Запатчыла", а не "выправіла", бо як кажа Джошуа Блох, API вечныя. Не маючы магчымасці ўнесці змены, якія паўплывалі б на існуючыя праграмы, мы дадалі ўласцівасць OriginAtCenter са значэннем false у старых праграмах і true ва ўсіх будучых. Карыстальнікі могуць задаць заканамернае пытанне, каму наогул прыйшло ў галаву размясціць кропку адліку недзе, акрамя цэнтра. Каму? Аднаму праграмісту, які дзесяць гадоў таму заленаваўся стварыць нармальны API.

Вынесеныя ўрокі

Працуючы над API (што часам даводзіцца рабіць амаль кожнаму праграмісту), вам варта прытрымлівацца лепшых парад, выкладзеным у відэа Джошуа Блыха.Як стварыць добры API і чаму ён так важны»або у гэтым кароткім спісе:

• API можа прынесці вам як вялікую карысць, так і вялікую шкоду. Добры API стварае пастаянных кліентаў. Дрэнны становіцца вашым вечным кашмарам.
• Агульнадаступныя API, як і дыяменты, вечныя. Выкладзецеся на ўсе сто: іншага шанцу зрабіць усё, як трэба, больш не прадставіцца.
• Пазнакі для API павінны быць кароткімі - Адна старонка з сігнатурамі класаў і метадаў і апісаннямі, якія займаюць не больш радкі. Гэта дазволіць вам лёгка рэструктурызаваць API, калі з першага разу ён выйдзе не ідэальным.
• Распішыце сцэнары выкарыстання, перш чым рэалізоўваць API і нават працаваць над яго спецыфікацыяй. Такім чынам вы пазбегнеце рэалізацыі і спецыфікацыі цалкам нефункцыянальнага API.

Калі б я напісала хаця б невялікі канспект са штучным сцэнарам, хутчэй за ўсё, я б выявіла памылку і выправіла б яе. Калі і не, то гэта сапраўды б зрабіў хтосьці з маіх калег. Любое рашэнне, якое мае далёкасяжныя наступствы, неабходна абдумваць хаця б дзень (гэта тычыцца не толькі праграмавання).

Назва эсэ Рычарда Гэбрыэла «Чым горш, тым лепш» паказвае на перавагу, якую атрымлівае той, хто першым выйшаў на рынак - хай нават з недасканалым прадуктам - пакуль хтосьці іншы цэлую вечнасць гоніцца за ідэалам. Разважаючы над кодам спрайтаў, я разумею, што мне нават неабавязкова было пісаць больш кода, каб зрабіць усё, як трэба. Як ні круці, я груба памылілася.

Заключэнне

Праграмісты здзяйсняюць памылкі кожны дзень - няхай гэта будзе напісанне кода з багамі або нежаданне паспрабаваць нешта, што павысіць іх майстэрства і прадуктыўнасць. Вядома, можна быць праграмістам і не дапушчаючы гэтак сур'ёзных промахаў, якія рабіла я. Але стаць добрым праграмістам, не ўсведамляючы сваіх памылак і не здабываючы з іх урокаў, немагчыма.

Мне ўвесь час сустракаюцца студэнты, якім здаецца, што яны дапускаюць занадта шмат памылак і таму не створаны для праграмавання. Я ведаю, наколькі распаўсюджаны ў IT сіндром самазванца. Спадзяюся, вы засвоіце пералічаныя мной урокі - але памятаеце галоўны з іх: кожны з нас дапускае памылкі - сорамныя, смешныя, страшныя. Я буду здзіўленая і засмучаная, калі ў будучыні ў мяне не набярэцца матэрыялу на працяг артыкула.

Крыніца: habr.com