Както се казва, ако не се срамувате от стария си код, значи не растете като програмист - и аз съм съгласен с това мнение. Започнах да кодирам за забавление преди повече от 40 години и професионално преди 30 години, така че направих много грешки. много. Като преподавател по информатика уча студентите си да се учат от грешките – свои, мои, чужди. Мисля, че е време да говоря за грешките си, за да не губя скромност. Надявам се да са полезни на някого.

Трето място - C компилатор от Microsoft

Моят гимназиален учител смяташе, че „Ромео и Жулиета“ не е трагедия, защото героите нямаха трагична вина — те просто се държаха глупаво, както би трябвало на тийнейджърите. Тогава не бях съгласен с него, но сега виждам рационално зърно в мнението му - особено във връзка с програмирането.

По времето, когато завърших втората си година в MIT, бях млад и неопитен, както в живота, така и в програмирането. През лятото бях на стаж в Microsoft, в екипа на компилатора на C. Отначало направих рутинна работа като поддръжка на профили, а след това ми беше поверена работата по най-забавната (по мое мнение) част от компилатора - backend оптимизация. По-конкретно, трябваше да подобря 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-инженерите за кратко спряха да играят билярд и направиха малко връщане назад. На следващата сутрин получих имейл с дъмп за срив, коригирах кода и добавих модулни тестове, които биха разкрили грешката. Тъй като следвах протокола - в противен случай кодът ми просто нямаше да се изпълни - нямаше други проблеми.

Научен урок

Много хора вярват, че такава голяма грешка със сигурност ще струва уволнението на лицето, отговорно за това, но това не е така: първо, всички програмисти правят грешки и второ, те рядко правят една и съща грешка два пъти.

Всъщност имам приятел програмист, който е брилянтен инженер, който беше уволнен само за една грешка. След това е нает от Google (и скоро повишен) - той честно говори за грешката, която е направил в интервюто, и това не се смята за фатално.

Ето какво казвам за Томас Уотсън, легендарният ръководител на IBM:

Обявена е държавна поръчка на стойност около милион долара. IBM Corporation - или по-скоро Томас Уотсън старши лично - наистина искаше да го получи. За съжаление, търговският представител не успя да го направи и IBM загуби офертата. На следващия ден този служител дойде в офиса на г-н Уотсън и постави плик на бюрото му. Г-н Уотсън дори не го погледна - той чакаше служител и знаеше, че това е писмо за напускане.

Уотсън попита какво се е объркало.

Търговският представител разказа подробно за хода на търга. Той назова грешките, които е можело да бъдат избегнати. Накрая той каза: „Г-н Уотсън, благодаря ви, че ми позволихте да се обясня. Знам колко много ни трябваше тази поръчка. Знам колко важен беше той” и се приготви да си тръгне.

Уотсън се приближи до него на вратата, погледна го в очите и върна плика с думите: „Как да те пусна? Току-що инвестирах милион долара във вашето образование.

Имам тениска, на която пише: „Ако наистина се учиш от грешките, значи вече съм майстор“. Всъщност аз съм доктор по отношение на грешките.

Първо място: API на App Inventor

Наистина ужасните грешки засягат огромен брой потребители, стават обществено достояние, коригират се дълго време и се правят от тези, които не са могли да ги направят. Най-голямата ми грешка отговаря на всички тези критерии.

Колкото по-зле, толкова по-добре

Аз чета есе от Ричард Габриел за този подход през XNUMX-те, като завършил студент, и ми харесва толкова много, че питам студентите си за него. Ако не го помните добре, опреснете паметта си, малко е. В това есе желанието „да го направиш както трябва“ и подходът „колкото по-лошо е по-добре“ са противопоставени по много начини, включително простотата.

Направете го правилно: Дизайнът трябва да е прост като изпълнение и интерфейс. Простотата на интерфейса е по-важна от простотата на изпълнението.

Колкото по-лошо, толкова по-добре: дизайнът трябва да е прост като изпълнение и интерфейс. Лесното изпълнение е по-важно от простотата на интерфейса.

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

Изобретател на приложения

Докато работех в Google, бях част от екипа Изобретател на приложения, онлайн среда за разработка с плъзгане и пускане за начинаещи разработчици на Android. Беше 2009 г. и ние бързахме да пуснем алфа версията навреме, за да проведем майсторски класове за учители през лятото, които биха могли да използват средата, за да преподават през есента. Доброволно предложих да внедря спрайтовете, носталгичен по начина, по който писах игри на TI-99/4. За тези, които не знаят, спрайтът е XNUMXD графичен обект, който може да се движи и да взаимодейства с други софтуерни елементи. Примери за спрайтове са космически кораби, астероиди, балони и ракети.

Ние внедрихме обектно-ориентиран App Inventor в Java, така че това е просто куп обекти. Тъй като топките и спрайтовете се държат много подобно, създадох абстрактен клас спрайтове със свойства (полета) 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.

Ако бях написал поне малко резюме с изкуствен скрипт, най-вероятно щях да идентифицирам грешката и щях да я коригирам. Ако не, тогава някой от моите колеги със сигурност би го направил. Всяко решение, което има далечни последици, трябва да бъде обмислено поне за един ден (това се отнася не само за програмирането).

Заглавието на есето на Ричард Габриел „Колкото по-лошо, толкова по-добро“ се отнася до предимството, което получава този, който пръв е влязъл на пазара – дори и с несъвършен продукт – докато някой друг преследва идеала от векове. Мислейки за кода на спрайта, осъзнавам, че дори не е трябвало да пиша повече код, за да го направя правилно. Каквото и да се каже, жестоко се обърках.

Заключение

Програмистите правят грешки всеки ден, независимо дали пишат код с грешки или не искат да опитат нещо, което ще подобри техните умения и продуктивност. Разбира се, можете да бъдете програмист, без да правите толкова сериозни грешки, каквито направих аз. Но е невъзможно да станеш добър програмист, без да осъзнаваш грешките си и без да се учиш от тях.

Постоянно се натъквам на студенти, които смятат, че правят твърде много грешки и затова не са създадени за програмиране. Знам колко често срещан е синдромът на самозванеца в ИТ. Надявам се да научите уроците, които изброих – но запомнете основното: всеки от нас прави грешки – срамни, смешни, ужасни. Ще бъда изненадан и разстроен, ако в бъдеще нямам достатъчно материал, за да продължа статията.

Източник: www.habr.com