Како што велат, ако не се срамите од вашиот стар код, тогаш не растете како програмер - и јас се согласувам со ова мислење. Почнав да програмирам за забава пред повеќе од 40 години, а професионално пред 30 години, така што имам многу грешки. многу. Како професор по компјутерски науки, ги учам моите студенти да учат од грешките - нивни, мои и други. Мислам дека е време да зборувам за моите грешки за да не ја изгубам скромноста. Се надевам дека некому ќе му бидат корисни.
Трето место - Microsoft C компајлер
Мојот училишен учител веруваше дека Ромео и Јулија не може да се сметаат за трагедија бидејќи ликовите немаа трагична вина - тие едноставно се однесуваа глупаво, како што требаше тинејџерите. Тогаш не се согласував со него, но сега гледам зрнце рационалност во неговото мислење, особено во врска со програмирањето.
Кога ја завршив втората година на МИТ, бев млад и неискусен, и во животот и во програмирањето. Летото, интернирав во Мајкрософт, во тимот на компајлерот C. Отпрвин правев рутински работи како поддршка за профилирање, а потоа ми беше доверено да работам на најзабавниот дел од компајлерот (како што мислев) - оптимизација на задниот дел. Конкретно, морав да го подобрам кодот x86 за изјавите на гранките.
Решен да го напишам оптималниот машински код за секој можен случај, безглаво се фрлив во базенот. Ако густината на дистрибуцијата на вредностите беше висока, ги внесов . Ако имаа заеднички делител, јас го користев за да ја затегнам табелата (но само ако поделбата може да се направи користејќи ). Кога сите вредности беа сили од два, направив уште една оптимизација. Ако збир на вредности не ги задоволуваше моите услови, го поделив на неколку оптимизирани случаи и го користев веќе оптимизираниот код.
Тоа беше кошмар. Многу години подоцна ми беше кажано дека програмерот кој го наследи мојот код ме мрази.
Научена лекција
Како што пишуваат Дејвид Патерсон и Џон Хенеси во Computer Architecture and Computer Systems Design, еден од главните принципи на архитектурата и дизајнот е генерално да се направат работите да функционираат што е можно побрзо.
Забрзувањето на вообичаените случаи ќе ги подобри перформансите поефикасно отколку оптимизирањето на ретките случаи. Иронично, вообичаените случаи се често поедноставни од ретките. Овој логичен совет претпоставува дека знаете кој случај се смета за вообичаен - а тоа е можно само преку процес на внимателно тестирање и мерење.
Во моја одбрана, се обидов да сфатам како изгледаат изјавите на гранките во пракса (како на пример колку гранки има и како се распределени константите), но во 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 ја загуби понудата. Следниот ден, овој вработен влезе во канцеларијата на г-дин Вотсон и стави плик на неговото биро. Г-дин Вотсон не се ни потруди да го погледне - чекаше вработен и знаеше дека тоа е писмо со отказ.
Вотсон праша што тргна наопаку.
Продажниот претставник детално зборуваше за напредокот на тендерот. Тој ги наведе грешките направени што можеше да се избегнат. Конечно, тој рече: „Господине Вотсон, ви благодарам што ми дозволивте да објаснам. Знам колку ни требаше оваа нарачка. Знам колку беше важен“, и се подготвив да замине.
Вотсон му пријде на вратата, го погледна во очи и му го врати пликото со зборовите: „Како да те пуштам? Само што вложив милион долари во вашето образование.
Имам маица на која пишува: „Ако навистина учиш од грешките, тогаш јас сум веќе мајстор“. Всушност, кога се работи за грешки, јас сум доктор на науки.
Прво место: App Inventor API
Навистина ужасните грешки влијаат на огромен број корисници, стануваат јавно познати, им треба долго време за да се поправат и ги прават оние кои не можеле да ги направат. Мојата најголема грешка одговара на сите овие критериуми.
Колку полошо толку подобро
Читам за овој пристап во деведесеттите како дипломиран студент, и толку многу ми се допаѓа што им го прашувам на моите студенти. Ако не се сеќавате добро, освежете ја меморијата, мала е. Овој есеј ја спротивставува желбата да се „добие правилно“ и пристапот „полошо е подобро“ на многу начини, вклучувајќи ја и едноставноста.
Како треба да биде: дизајнот треба да биде едноставен во имплементацијата и интерфејсот. Едноставноста на интерфејсот е поважна од едноставноста на имплементацијата.
Колку е полошо, толку подобро: дизајнот треба да биде едноставен во имплементацијата и интерфејсот. Едноставноста на имплементацијата е поважна од едноставноста на интерфејсот.
Ајде да заборавиме на тоа за една минута. За жал, заборавив на тоа многу години.
Пронаоѓач на апликации
Додека работев во Google, бев дел од тимот , влечење и спушти онлајн развојна околина за аспиранти за развивачи на Android. Беше 2009 година и брзавме да ја објавиме алфа верзијата навреме за да можеме во лето да одржуваме мастер-класови за наставниците кои би можеле да ја користат околината при наставата наесен. Волонтирав да имплементирам sprites, носталгичен за тоа како пишував игри на TI-99/4. За оние кои не знаат, sprite е дводимензионален графички објект кој може да се движи и да комуницира со други софтверски елементи. Примери за спрајт вклучуваат вселенски бродови, астероиди, џамлии и рекети.
Имплементиравме објектно-ориентиран App Inventor во Java, така што има само еден куп објекти таму. Бидејќи топките и спрајтите се однесуваат многу слично, создадов апстрактна класа на спрајт со својства (полиња) X, Y, Speed (брзина) и Heading (насока). Ги имаа истите методи за откривање судири, отскокнување од работ на екранот итн.
Главната разлика помеѓу топка и спрајт е што точно е нацртано - исполнет круг или растер. Бидејќи прво ги имплементирав sprites, логично беше да ги наведам x- и y-координатите на горниот лев агол на местото каде што се наоѓа сликата.
Откако работеа sprites, решив дека можам да имплементирам топчести објекти со многу малку код. Единствениот проблем беше што отидов на наједноставниот пат (од гледна точка на имплементатор), означувајќи ги x- и y-координатите на горниот лев агол на контурата што ја врамува топката.
Всушност, неопходно беше да се наведат x- и y-координатите на центарот на кругот, како што е наведено во секој учебник по математика и во кој било друг извор што споменува кругови.
За разлика од моите грешки од минатото, оваа не влијаеше само на моите колеги, туку и на милиони корисници на App Inventor. Многу од нив беа деца или сосема нови во програмирањето. Мораа да направат многу непотребни чекори при работа на секоја апликација во која беше присутна топката. Ако се сеќавам на другите мои грешки со смеење, тогаш оваа и денес ме тера да се потам.
Конечно ја закрпив оваа грешка дури неодамна, десет години подоцна. „Крпен“, а не „поправен“, бидејќи како што вели Џошуа Блох, API-ите се вечни. Не можејќи да направиме промени што би влијаеле на постоечките програми, го додадовме својството OriginAtCenter со вредност неточно во старите програми и точно во сите идни. Корисниците може да постават логично прашање: кој воопшто помислил да ја постави почетната точка на друго место освен во центарот. На кого? На еден програмер кој беше премногу мрзлив да создаде нормален API пред десет години.
Научени лекции
Кога работите на API (што скоро секој програмер мора да го прави понекогаш), треба да ги следите најдобрите совети наведени во видеото на Џошуа Блох.„или :
- API може да ви донесе и голема корист и голема штета.. Доброто API создава повторливи клиенти. Лошиот ти станува вечен кошмар.
- Јавните API, како дијамантите, траат вечно. Дајте сè од себе: никогаш нема да има друга шанса да направите сè како што треба.
- Контурите на API треба да бидат кратки — една страница со потписи и описи на класите и методите, кои зафаќаат не повеќе од една линија. Ова ќе ви овозможи лесно да го реструктуирате API ако првиот пат не излезе совршен.
- Опишете ги случаите на употребапред да го имплементирате API или дури и да работите на неговата спецификација. На овој начин ќе избегнете спроведување и специфицирање на целосно нефункционално API.
Да напишев макар и краток синопсис со вештачко сценарио, најверојатно ќе ја идентификував грешката и ќе ја исправев. Ако не, тогаш еден од моите колеги дефинитивно би го направил тоа. Секоја одлука што има далекусежни последици треба да се размислува барем еден ден (ова се однесува не само на програмирањето).
Насловот на есејот на Ричард Габриел, „Полошо е подобро“, се однесува на предноста што ја носи да се биде прв на пазарот - дури и со несовршен производ - додека некој друг поминува цела вечност бркајќи го совршениот. Размислувајќи за sprite кодот, сфаќам дека дури и не морав да напишам повеќе код за да го сфатам правилно. Што и да каже некој, бев во голема грешка.
Заклучок
Програмерите прават грешки секој ден, без разлика дали тоа е пишување баг-код или несакање да пробаат нешто што ќе ја подобри нивната вештина и продуктивност. Се разбира, можеш да бидеш програмер без да правиш толку сериозни грешки како јас. Но, невозможно е да станете добар програмер без да ги препознаете своите грешки и да научите од нив.
Постојано се среќавам со студенти кои се чувствуваат како да прават премногу грешки и затоа не се отсечени за програмирање. Знам колку е чест синдромот на измамник во ИТ. Се надевам дека ќе ги научите лекциите што ги наведов - но запомнете ја главната: секој од нас прави грешки - срамни, смешни, страшни. Ќе бидам изненаден и вознемирен ако во иднина немам доволно материјал за да ја продолжам статијата.
Извор: www.habr.com