Животът на разработчика не е лесен. Живеем двоен живот, разкъсвани между идеалистични идеи (якети-яка?) за първокласно качество на софтуера и, добре, живота; срокове, рязане на ъгли и писане на софтуер без нито един тест. Знам, знам, но разкрийте кървящите си уши, това е истината - вашият код никога няма да бъде перфектен, защото обстоятелствата никога няма да бъдат идеални. Но ето какво можете и определено трябва да направите, за да направите живота си като разработчик по-добър и по-лесен за тези (вашето бъдеще също се брои), които ще работят върху вашия код след вас.

Случвало ли ви се е да работите върху част от кода, който не можете да разберете и след един час опити да разберете какво, по дяволите, става, да влезете във вашия VSC и да натиснете Git Blame и да сте като аз кълна се, който и да е написал този код...

да Звучи ми познато?

  1. Документирайте своя код

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

Прегледайте вашия файл README. Когато се появи нов човек, вие искате да го направите гладко за него. Не искате тя да губи ценно време в първия си ден да се бори с нещо толкова лесно като създаването на проекта. Вие сте този новодошъл и някои неща не са актуални в README? Пий малко билки, преглътни разочарованието си и ГО ОПРАВИ. Не забравяйте, че най-добрият начин да научите другите на добри практики е като самите вие ​​давате пример.

2. Не се доверявайте на сървъра

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

3. Съобщавайте решения

Или по-добре. Включете вашия екип, за да ги направите заедно. Вие просто започвате нов проект и мислите какво решение за маршрутизиране да използвате. Или мислите за перфектен git поток за вашия случай на употреба. Комуникирайте ясно вашите мисли и предположения, но бъдете отворени към предложенията на други хора. Не го оставяйте извън дискусията и замълчете; ще оставите вашите младши разработчици объркани, докато това е перфектна възможност за тях да научат как се справяте с вземането на решения. И никога не се знае, други може да ви изненадат с по-добро решение на проблема. След като всички сте съгласни, преминете към стъпка 1 и документирайте това за бъдещите разработчици.

4.Преценете честно

Хей. Бил съм там. Крайният срок наближава и искате да приключите с него. Но вие точно там лъжете себе си. Оценките са трудни, така че не ги правете още по-трудни, като приемете най-добрия сценарий. Може би си мислите, че това падащо меню изглежда доста лесно; използвали сте го хиляди пъти преди и сте го приложили, добре, малко по-малко пъти. Но обмислили ли сте анализирането на данни, което е включено в тази задача? Между другото, знаете, че бекендът все още не е готов, нали? И помните, че бекенд инженерите са зли и няма да ви обслужват формата, който бихте искали да имате, нали? Ако сте решили, че ще използвате библиотека, за да напишете този падащ компонент, проверили ли сте как да промените CSS стиловете по подразбиране? Как можете да добавите функционалност, която липсва? Струва ли си дори да използвате тази външна библиотека или по-добре да напишете своя? Помислете за всички тези случаи, когато оценявате задачи. Убедих ли те да надраскаш тези 4 часа, за които си мислеше първоначално?

5.Опишете изчерпателно вашите PR

Може би, ако сте четец на мисли, може би знаете какво ще прегледате. Съмнявам се обаче, мисля, че този човек ще трябва да седи с вас в една и съща стая и ще трябва да сте вещица от 17-ти век. Колкото повече информация и контекст давате за вашия PR, толкова по-добре; пишете за бизнес логиката, която сте въвели, и този CSS !important, който трябваше да използвате, защото използвате библиотека на трета страна — ще спестите вашето време и времето на рецензента ви да ви укоряват за това !important и вас обяснете защо трябва да го използвате. Преди да отворите заявка за изтегляне; дайте допълнително превъртане през промените, които сте направили. Може би сте забравили да премахнете този console.logили сте оставили магическо число.

6. Повдигнете, докато се изкачвате

Ако вече имате няколко години опит, може да не си спомняте колко трудно е било, когато сте били младши програмист (zapomniał wół jak cielęciem był). Имайте предвид, че вие ​​също можете да бъдете младши в неща, които все още не сте срещали. Всички ние имаме тези моменти поне няколко пъти на ден. Ментор други; обяснете защо сте направили нещата така, както сте направили. Измислете нови метафори за тази функция намаляване. Направете сесия за програмиране по двойки. Подавай ръка от време на време. Предложете някой друг да води тази среща. Бъдете мили в процеса и бъдете смирени, никой не обича снизходителни хора.

Обещах 20 неща, но тук имате 6. Вероятно вече сте кодирали твърдо 20 елемента и сега имате 14 недефинирани. О, добре, не се доверявайте на сървъраи следете за още 📻 🙌