Наскоро имахме среща за разработчици в моята компания и обсъдихме качеството на нашия код. Изглежда, че с бързането ни винаги да избутваме кода през вратата, качеството ни се подхлъзваше. Говорихме за поемане на собственост върху нашия код (винаги важно), по-строги прегледи на кода и по-задълбочено тестване. Излязох от това, чувствайки се добре, в крайна сметка моят код е безупречен. Продължих да се чувствам добре до около 5:30, когато установих, че страницата на нашия мобилен сайт е повредена. Тъй като бях в екипа, който пусна най-новата мобилна версия, не бях много развълнуван.
Ето и ето, грешката беше от задния екип. ВСЕ ОЩЕ СЪМ БЕЗПОГРЕШЕН! Всичко, което трябваше да направим, е да върнем назад промените в задния край и щяхме да се върнем на работа! Това е, докато не разбрах, че връщане назад може да повреди моите промени. Време е за разследване!
Част от промените в разгръщането бяха добавянето на цветни „мостри“ под продуктите, които продаваме. Сървърът изпрати данни до предния край на React, които след това бяха анализирани и показани. Съответният код:
Красиво, нали? Взимаме братята и сестрите, предадени от сървъра, и използваме map(), за да преминем. Ако вече имаме четири, не правим нищо и за първите четири връщаме JSX със съответните класове. Просто нали? Тествано. премина. Дори QA сметна, че е шикозен. Но какво се случва, когато задната част върне промените си и братята и сестрите вече не съществуват?
Поглеждайки назад, осъзнавам своята фатална грешка. Понякога пренебрегвам значението на проверката за грешки. Моят код може да работи в перфектен свят, но светът не винаги е перфектен. Частичното връщане назад не е опция сега, защото извършването на map() върху недефинирана променлива хвърля грешка и срива приложението. Нещастен.
По-добрият подход би бил да пуснете някои проверки за разумност там, така че грешка другаде да не срине цялата къща:
Този оператор if в горната част? Това точно там ще спаси приложението от срив. Можем дори да направим крачка напред и да проверим дали е масив. Ако бях отделил време да проверя постъпващите данни, можехме да отменим промените на сървъра и да продължим весело. Както е? Е, честно казано, не беше толкова лошо. Те избутаха гореща корекция, за да коригират пагинацията, така че така или иначе не беше необходимо връщане назад. Но все пак ми показа крехко място в кода. Един, който лесно можеше да бъде избегнат, ако бях отделил време да добавя проста проверка на грешки. Така че за днешния урок научих: не просто пишете код, който не е разбит, пишете код, който не може да бъде разбит. Приятно кодиране!
