Ево шта сам научио девет месеци у свом софтверском инжењерингу

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

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

Циљ је написати тачну количину доброг кода и добро комуницирати. Нисте плаћени за програмирање, плаћени сте за размишљање и откривање проблема. Нуспроизвод је искристалисана мисао и упутство за машину у облику кода. Радије бих проблем решио у једном реду јасно читљивог кода него у 10 редова кода који је тешко разумети. Радије бих проблем решио у 5 редова читљивог коментарисаног кода, него у једном ретку веома сложеног, више угнежђеног кода са вишеструким тернарним операторима. Схватили сте идеју.

Постављајте пуно питања и документујте одговоре

Шеф ми је послао ову везу која је садржала пуно стреса и анксиозности које осећам као нови инжењер. Потцењено је рећи да сам врло самосвестан у постављању питања.

Користим ову контролну листу пре него што затражим помоћ од других:

  • Да ли је ово питање које сам раније постављао, и ако је тако, где сам документовао одговор?
  • Да ли је ово нешто што бих могао да гуглам?
  • Да ли је то негде неко други интерно документовао?
  • Шта се дешава овде? Који је основни узрок грешке или неочекиваног понашања које имам?
  • Да ли заиста разумем питање на које покушавам да одговорим? У реду је да одвојите мало времена и поново прочитате проблем, уместо да дајете пола гузице или брзоплет одговор.

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

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

Паметни људи воле добра питања - зато их поставите.

Избегавајте да понављате исте грешке и постављате иста питања изнова и изнова

Ово је лакше рећи него учинити и могло би бити тачно за било који посао, не само за програмирање. Много нових концепата и информација вам се баца на пут, а прављење грешака је неизбежно. Будите свесни тога. Размислите пре него што питате. Гоогле ствари. Погледајте документе. Они су ти пријатељи. Ако видите тренд, покушајте да га идентификујете. Потрудите се активно како бисте ухватили себе како постављате исту врсту питања. Запишите то и поставите себи циљ да то поправите.

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

Увек прегледајте свој рад

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

Заиста погледајте свој код и поставите себи следећа питања:

  • Написао сам сложену логику. Да ли постоји слична функционалност у апликацији која то можда чини на читљивији, флексибилнији или генерички начин?
  • Ако не, да ли бих се сетио зашто сам написао овај код за недељу дана? Ако је одговор не, вероватно желим да променим код или да га коментаришем. Особа која прегледава ПР требало би да има неки контекст због чега сам донела такву одлуку.
  • Уверите се да ваш код пролази повезивање и тестове пре него што га дате било коме другом.
  • Да ли се понављам? Могу ли логику коју понављам уврстити у функцију?
  • Да је ово туђи код који сам прегледао, које коментаре бих дао? Шта бих желео да променим да би било директније?

Погледајте свој код са новим очима (можда следећег дана). Да ли постоји специфична логичка крварења у компоненте које не би смеле бити? Да ли ваша пословна логика која управља компонентама треба да уђе у контејнер?

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

Последња ствар око прегледа вашег кода. Додирните и кликните СВЕ на чему сте радили. Желим да код који пошаљем било коме буде изузетно тежак за разбијање. Ако кликну нову страницу и приме велику грешку или бели екран смрти, то показује да нисам заиста прегледао свој рад. Греп за код који сте уредили и заиста се побрините да нисте провалили нешто друго додавањем дељене компоненте.

Можда се чини глупо, али велике базе кода су сложене и можда нећете схватити да нешто сломите док то не учините.

Озбиљно, не желите да видите први нацрт овог блога :)

Ништа није магија

Обично постоји добар разлог зашто је код добио ЛГТМ (одобрен и у основи кода). Ако не разумете како то функционише, проведите неко време да то смислите. Записујте ствари, разбијајте ствари, погледајте неку документацију о функцијама и обрасцима који су коришћени.

Можете ли рећи својој гуменој патки како је то функционисало? Ако и даље нисте сигурни, поставите неколико питања о одређеним празнинама у вашем разумевању.

Обавите удобно отклањање грешака, јер то радите много

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

Неки корисни ресурс који сам пронашао:

  • ЦСС трикови о отклањању грешака
  • Отклањање грешака у Фронт-Енд Мастерсу (плаћа се, али прилично добро)

Про-тип: излаз цонсоле.лог може се стилизовати помоћу ЦСС-а. Ово олакшава препознавање дневника који желите да видите.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

Пратите податке

То се понављало изнова и изнова, јер додуше то је била грешка коју сам непрестано радио. То је нешто у чему сам се поправио, али и даље треба радити.

Велики део развоја софтвера укључује манипулацију подацима у формату, тако да корисник од њега може добити увид у деловање или га самостално ажурирати.

Апликације са једносмерним протоком података и глобалним стањем имају директну линију података коју треба следити. Сви ти подаци долазе однекуд. Једном када сазнате одакле долази, лакше је отклонити грешке.

Изолујте своје проблеме, а затим их интегришите у оно на чему радите

Цодепен.ио ми је близак пријатељ, а требао би бити и ваш. Када не могу да схватим шта је узрок проблема, направим једноставну верзију онога што градим. Уверите се да то функционише, а затим га интегришем у своје развојно окружење. Лакше је схватити шта можда руши ваш кориснички интерфејс у ​​огољеном окружењу.

Размислите о томе како би функционалност требало да ради

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

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

Прихватите борбу

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

Прихватите конструктивну критику и непрестано је понављајте

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

Не журите

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

Наставите са учењем ван посла

Колико год учим на послу, и даље желим да учим нове ствари, а не само да радим на нашој бази кода. То би могло бити подизање Питхона, израда бота, рад кроз видео серију или рад на личном пројекту. Направио сам таблу са Зенхуб + Гитхуб-ом како бих пратио где сам и на шта сам се обавезао за месец дана. Одржавање општег циља за месец дана приморало ме је да наставим да учим, да градим и да, блогам у своје време.