Да отслабнете с 5 lbs за 5 секунди? лесно! Просто си отрежете ръката.

Повечето от нас са запознати с концепцията за SMART цели: конкретни, измерими, постижими, реалистични и навременни. Може да твърдите, че отрязването на ръката не е наистина реалистично, но според типичната SMART дефиниция със сигурност е така. В това се крие недостатъкът на SMART целите за инженерство; Бих казал, че Sustainable трябва да се добави към сместа. Има разлика между простото постигане на вашия резултат и постигането му по устойчив – или когато става въпрос за код, по поддържаем начин.

Някои от най-добрите ни уроци идват от вътрешни изказвания на Slack от нашите инженери; това е добър, който споделих, след като се потопих в стария код.

Ето старата версия на кода:

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

Първият проблем

Името всъщност не ми казва какво се случва. „getsWhatsRequired“ е име, което би се приложило към почти всяка функция, която получава и/или форматира данни. Не ми казва защо тази функция съществува сама, нито какво прави, което е особено полезно.

Вторият проблем

Има цял удар на повторение, което се случва вътре в URI. Този код се повтаря 6 пъти в тази функция. Повтарянето 6 пъти прави по-трудно разсъждението, защото или трябва да прочетете всяко повторение и да решите дали правят точно същото нещо, ИЛИ в крайна сметка го прескачате и приемате, че прави точно същото нещо всеки път. В този случай той е да прави едно и също нещо всеки от шестте пъти, но трябва да упражните много умствена енергия, за да разберете това.

Третият проблем

Вътре в повтарящия се код има намерение и цел, които се губят. Ние не нарязваме низове и добавяме наклонени черти и други неща само за дяволите, ние го правим с конкретна цел! Но защо? От този код изобщо не става ясно.

Четвъртият проблем

Тези двойни равни? Те са издръжливи! По време на малко почистване на кода един от колегите ми отиде и ги преобразува в === строг оператор за равенство, както предложи ESLint, защото нямаше причина да смятаме, че това трябва да е свободна проверка за равенство.

Оказа се, че получените стойности не са били 1, те всъщност са били „1“. Това е много различно и това предизвика инцидент, защото не изпращахме никакви файлове за определен период от време.

Има един от два начина, по които това може да се подобри:

  1. Ако стойността, която идва през винаги е низ, тогава използвайте представянето на низ вместо това с ===.
  2. Ако стойността идва или като низ, или като число и има наистина добра причина това да продължава да се случва, тогава използвайте двойното равно и документирайте това конкретно поведение, така че Future You / your peer знае, че зависиш от това много специфично поведение.

И петият (и далеч най-ниткият избор)

Ако възнамерявате да дефинирате променливата и след това веднага да я върнете, можете просто да върнете тази стойност веднага, без първо да я присвоите на променлива. Това е малък детайл, но прави функцията по-кратка.

Ето новия код:

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

Това са двата реда, които въведох на мястото на кода, който беше повторен шест пъти.

Можете лесно да твърдите, че тези два реда могат да бъдат един ред, който се чете така:

Това би било дори по-ефективно за пространството, нали? вярно! Това би било 100% правилно! И ето кога контекстът влиза в игра. Не бихте го познали, ако прочетете този код сам, но всички активи на поръчката? Те се качват в услугата за активи на поръчката, като папката е идентификаторът на поръчката без префикса.

Знаейки, че идентификаторът на поръчката без префикс има специфично значение извън този контекст, мисля, че е по-добре да отделите разделянето на префикса на идентификатора от състава на пътя.

И така, след като критикувах този код надълго и нашироко, искам да бъда наистина ясен относно няколко неща:

Нене е грешката на инженера, че този код, който беше обединен, беше неполиран. Говорейки от името на EMs и Staff Engineers, наша отговорност е да зададем стандартите и да подкрепим колегите си в писането на код, който е добре полиран и поддържаем – и не успяхме да го направим тук. Научен ценен урок.

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

В отговор на моето изказване получих следния ценен съвет от мои колеги и съм напълно съгласен:

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

И ще ви оставя с перфектно резюме на горното от Рос Мартин, инженерен мениджър:

‍„Накарайте го да работи, направете го правилно, направете го бързо в този ред.“

Първоначално публикувано на https://www.lob.com от щатен инженер Rich Seviora.