Уроци от бивш технически ръководител на Google
Тази статия ще очертае основните признаци на неопитен програмист и какво можете да направите, за да ги преодолеете. Това е резюме на моите бележки от „видео в YouTube“ от „Patrick Shyu“, бивш технически ръководител на Google.
Всички нови инженери показват определени черти. Като обръщате внимание на моделите, показани в техните действия, тяхната ежедневна рутина и кода, който извеждат, можете лесно да направите разлика между опитен инженер и някой нов.
Като софтуерни инженери всички преминаваме през подобни преживявания, когато започваме. Отнема ни месеци, понякога години, за да надраснем нашето „начинаещо“ поведение и да станем „професионалисти“, така да се каже. Младшите инженери във всяка компания преминават през този процес.
Когато започнете работа в голяма компания като Google, е доста обичайно други инженери да ви дразнят при първите прегледи на кода. Те ще оставят стотици, ако не и МИЛИОНИ, коментари в първия diff изход, който се опитвате да ангажирате. Много хора намират това изживяване за толкова поразително, че в крайна сметка се отказват на следващия ден.
Разлика (или „разлика“) се отнася до „заявка за изтегляне“, когато изпращате код за преглед. Това е чудесен инструмент, който позволява на разработчиците да видят какво се е променило между различните версии на файла.
От хората, които влизат в компании като Google като инженери, около половината напускат, преди дори да изпратят първия си ред код. Така че, ако това не ви е отблъснало кариерата в областта на софтуерното инженерство, ето няколко съвета, които можете да използвате, за да изпреварите кривата и да сте на път към новата си работа.
1. Изпращане на големи части от код
Решение: Дръжте ангажиментите си малки
Звучи очевидно, но това е най-често срещаният капан, в който попадат неопитни програмисти. Вероятно е, когато за първи път започнете работа в компания, да ви бъде възложен стартов проект, който изисква значителна част от кода, за да завършите някаква функция. Ключът, който трябва да се отбележи, е, че не става въпрос непременно за завършване на функцията с едно изпращане на код.
Това, което хората искат да видят, че правите, е да започнете да изучавате практиките за кодиране и процесите на разработка, с които получавате подаден код. Това включва разбиване на проекта на малки парчета и изпращане на малки целеви части от код, един по един.
Когато изпратите един код, който е дълъг хиляди редове, за преглед на кода, хората просто ще го погледнат и ще започнат да избират дупки във вашия код и да маркират цели части от кода, които трябва да бъдат пренаписани.
Когато започнете за първи път, има голяма вероятност да объркате фундаментално някакъв модел, дизайн или архитектура на вашата програма. Което ще промени целия начин, по който вашата програма ще бъде написана. Това е нещо, което може да се очаква. Ако изпращате малки разлики постепенно, хората могат да ви помогнат да се уверите, че сте на прав път. Поддържането на малки ангажименти също улеснява получаването на вашите разлики.
Много по-лесно е да получите одобрение за множество различия, които са малки и целеви.
Използването на редактор като VS Code или Atom, който показва разликите ред по ред относно направените промени, може да ви помогне да сте сигурни, че не редактирате редове от текст, които не е необходимо да се променят.
Този урок за малки разлики непрекъснато се преподава на нови инженери в почти всяка организация. Ако влезете в компанията, като вече сте развили това умение, ще бъдете готови.
2. Имате сложен, заплетен код
Решение: Напишете документ за дизайн
Друг признак на неопитен програмист е прекалено проектираният код, който е пълен с огромни функции, оператори if, произволни помощни методи и преждевременна оптимизация. Лошият код не просто има много грешки и не успява да се компилира или стартира. Един неопитен инженер пак ще може да накара кода си да работи и да функционира прилично.
Въпреки това начинът, по който е настроена логиката и е написан кодът, ще изглежда ужасно. Ще бъде заплетено, объркано, пълно със сложна логика и ще бъде пълна болка за четене. Всеки старши инженер би получил главоболие, след като прочете кода за начинаещи и ще трябва да отиде на почивка за кафе.
Решението всъщност е доста просто. Напишете документ за дизайн, преди да започнете.
Документът трябва да описва:
- Какво ще строите
- Какви са изискванията за характеристиките
- Как ще настроите нещата
- Какви функции ще ви трябват
- Кои класове и структури от данни може да имате нужда
Тази проста стъпка ще помогне за предотвратяване на дублиран код и прекалено сложна логика. Това ще ви даде шанс да организирате правилно мислите си, преди да започнете да кодирате. Кодът все още ще работи без проектен документ, но ще ви бъде трудно да го поддържате, когато добавяте функции към него. Нови грешки ще се въвеждат всеки път, когато се опитате да промените кода. В крайна сметка ще трябва да направите промени в множество области и логиката ще пострада поради това.
Напишете документ за дизайн, спестете си малко време и това също ще ви накара да изглеждате малко по-добре.
3. Ниска ефективността
Решение: Проследявайте действията си в минута
Неопитните разработчици искат да се докажат и работят усилено, за да научат колкото могат повече. Въпреки това, те често се оказват неефективни и се чувстват така, сякаш губят много време.
Когато му бъде предоставен прекалено сложен потребителски интерфейс от дизайнер, нов инженер може да реши да разработи решението, дори ако е почти невъзможно да се приложи. Той няма да хвърли око на целта и просто ще се опита да направи някаква основа, за да се докаже. Този проект най-вероятно никога няма да стартира. По-опитен програмист обаче би идентифицирал целта на проекта и би отблъснал дизайнерите на потребителския интерфейс, като предостави алтернативни решения, които биха били много по-лесни за изпълнение, като същевременно постигат желаната цел.
Не кодирайте заради самото кодиране. Гледайте гората, а не дърветата.
Дръжте под око визията, която се опитвате да осъществите, и се уверете, че вашият код се изпраща. Ако не виждате изпращането на кода си, опитайте се да изчистите всички пречки, за да можете да окажете влияние там, където можете.
Опитайте се да следите действията си в минута (APM). Много младши инженери лесно се разсейват от гъвкавото работно време и в крайна сметка губят време в Reddit, социални медии и онлайн пазаруване. Вашето време е ваше лично, но ако се опитате да оптимизирате времето, което имате на работа, представете си колко по-продуктивен ще бъдете. Бихте могли да изпратите много повече код, да прочетете повече код, да научите за кодовата база и да измислите повече идеи... Ще бъдете неудържими!
Не бъдете човекът, който изпраща едно или две парчета код за цяла седмица. Опитайте се да изпращате поне едно парче код на ден, което ще ви държи на път. Превърнете го в лична цел за себе си и ще се изненадате колко по-ефективни ще бъдете.
4. Гордост, его и арогантност
Решение: Поискайте помощ, когато имате нужда от нея
Това е нещо, което виждате от няколко студенти по CS, излизащи от колежа. Въпреки че не е задължително да идва от негативно място. Младшите инженери обикновено искат да се докажат в началото на кариерата си, което е разбираемо. Това обаче може да доведе до тенденция към прекомерно проектиране на техния код, като се опитват да го направят да изглежда прекалено умен и умен. Не го усложнявай!
Опитайте се да оставите гордостта си настрана и да поискате помощ, когато имате нужда от нея. Не се очаква да знаете всичко като младши инженер. От вас се очаква да искате да учите. Така че задавайте въпроси! Това може да ви спести много време, което ще ви направи по-ефективни, както споменах по-рано. Не бъдете инженерът, който иска да се справи сам с много проблеми и се появява отново седмици по-късно с код, който трябва да бъде преработен.
Само за забавление, нека изиграем общ сценарий, включващ горд възпитаник и Техническия ръководител — Техническият ръководител, преглежда кода на инженера и оставя няколко коментара за подобрение. Инженерът не може да повярва на това и решава да се втурне към бюрото на техническия ръководител и лично да го разпитва за всеки коментар, докато се опитва да обоснове своя код на всеки ред. Арогантността му е просто невероятна! Техническият ръководител няма нищо от това. Докато младият инженер се опитва да се защити, той се подиграва на хората, които смята за по-малко квалифицирани от него. Техническият ръководител вижда, че инженерството се опитва да направи нещо глупаво или нещо „готино“. Проблемът е, че … техническият ръководител не се интересува дали мислите, че сте готин или искате той да мисли, че сте готин и завършва спора с това:
Глоба. Ти си готин, аз съм готин. Всички са готини, просто аз съм по-готин от теб. Добре!
Моралът на историята е, винаги се опитвайте да се учите от хората около вас, не бъдете арогантни и НЕ ставайте от лошата страна на техническия ръководител.
Като нов софтуерен инженер намирам „това видео“ от техническия ръководител за изключително проницателно. Ако сте опитен инженер, моля, добавете към този съвет по-долу. Ако сте нов в софтуерното инженерство, уведомете ме кой съвет ви хареса най-много!
