Предговор на преводача: След като прочетете тази статия, може да се изненадате или дори да се ядосате. Да, и ние бяхме изненадани: авторът уж никога не е чувал за йерархията в екипа, за поставянето на задачи със статус „направи го бързо и без аргументи“. Да, точно така, това е малко странен текст. Наистина, авторът предлага програмистът да поеме ролята на системен архитект - защо тогава имате нужда от архитект? Но всички тези възражения не бива да ви заслепяват за основното - защо все пак взехме и преведохме този текст. Той не говори за роли. Този текст е за професионален подход и информираност. Истината е, че докато просто „правите каквото ви се каже“, без да мислите за смисъла на действията си, никога няма да станете велик програмист.
Кажете не на ненужния код. Всичко, което трябва да направите, е да съберете три букви и да кажете думата. Нека се опитаме да направим това заедно: "Нееее!"
Но почакай. Защо правим това? В крайна сметка основната задача на програмиста е да пише код. Но трябва ли да напишете код, който се иска от вас? Не! „Разбирането кога да не се пише код е може би най-важното умение за един програмист.“ .
Напомняме ви: за всички читатели на "Habr" - отстъпка от 10 000 рубли при записване във всеки курс Skillbox, използвайки промоционалния код на "Habr".
Skillbox препоръчва: Практически курс .
Програмирането е изкуството за решаване на проблеми. А вие сте майстори на това изкуство.
Понякога, в стремежа си да започнем работа възможно най-бързо, не мислим за нищо друго, освен за изпълнение на поставената задача. А това може да доведе до още по-сериозни проблеми.
За какво програмистите си затварят очите?
Целият код, който пишете, трябва да бъде разбираем за други разработчици и трябва да бъде тестван и отстранен.
Но има проблем: каквото и да напишете, ще усложни вашия софтуер и вероятно ще въведе грешки в бъдеще.
Според Рич Скрент, . Ето какво пише той:
„Кодът е лош, защото започва да гние и изисква постоянна поддръжка. Добавянето на нови функции често изисква модифициране на стар код. Колкото по-голям е, толкова по-голяма е вероятността от възникване на грешка и толкова повече време отнема компилирането. Отнема повече време на друг разработчик, за да го разбере. И ако е необходим рефакторинг, тогава определено ще има фрагменти, които си струва да се променят. Големият код често означава намалена гъвкавост и функционалност на проекта. Простото и елегантно решение е по-бързо от сложния код.“
Как да разберете кога да не пишете код?
Проблемът е, че програмистите често преувеличават броя на функциите, от които се нуждаят техните приложения. В резултат на това много части от кода остават недовършени или никой не ги използва, но те усложняват приложението.
Трябва ясно да разберете от какво се нуждае вашият проект и от какво не.
Пример е приложение, което решава само една задача - управление на имейл. За целта са въведени две функции - изпращане и получаване на писма. Не трябва да очаквате мениджърът на пощата да стане едновременно мениджър на задачи.
Трябва твърдо да кажете „не“ на предложенията за добавяне на функции, които не са свързани с основната задача на приложението. Точно в този момент става ясно, че допълнителен код не е необходим.
Никога не губете фокуса на вашето приложение.
Винаги се питайте:
— Каква функция трябва да се приложи сега?
— Какъв код да напиша?
Подлагайте на съмнение идеите, които ви хрумват, и оценявайте предложенията, идващи отвън. В противен случай допълнителният код може просто да убие проекта.
Знаейки кога да не добавяте ненужни неща, ще ви помогне да поддържате кодовата си база под строг контрол.
В самото начало на пътя програмистът има само два или три изходни файла. Просто е. Компилирането и стартирането на приложението изисква минимум време; Винаги е ясно къде и какво да търсите.
С разширяването на приложението се появяват все повече кодови файлове. Те изпълват каталога, всеки със стотици редове. За да организирате всичко това правилно, ще трябва да създадете допълнителни директории. В същото време запомнянето кои функции за какво са отговорни и кои действия ги причиняват става все по-трудно; хващането на грешки също отнема повече време. Управлението на проекти също става все по-сложно; не един, а няколко разработчици са длъжни да следят всичко. Съответно разходите, както парични, така и времеви, се увеличават и процесът на развитие се забавя.
Проектът в крайна сметка става огромен и добавянето на всяка нова функция отнема все повече усилия. Дори за нещо много незначително трябва да отделите няколко часа. Коригирането на съществуващи грешки води до появата на нови и се пропускат сроковете за пускане на приложението.
Сега трябва да се борим за живота на проекта. Защо?
Факт е, че просто не сте разбрали кога не трябва да добавяте допълнителен код и сте отговорили с „да“ на всяко предложение и идея. Ти беше сляп, желанието да създаваш нови неща те накара да пренебрегнеш важни факти.
Звучи като сценарий за филм на ужасите, нали?
Точно това ще се случи, ако продължавате да казвате „да“. Опитайте се да разберете кога не трябва да се добавя код. Премахнете ненужните неща от проекта - това ще улесни много живота ви и ще удължи живота на приложението.
„Един от най-продуктивните ми дни беше, когато изтрих 1000 реда код.“
— Кен Томпсън.
Трудно е да научите кога да не пишете код. Но е необходимо.
Да, знам, че току-що сте поели по пътя на разработчика и искате да пишете код. Добре е, не губете това първо впечатление, но не изпускайте от поглед важните фактори заради ентусиазма. Разбрахме всичко чрез проба-грешка. Вие също ще правите грешки и ще се учите от тях. Но ако можете да се поучите от горното, работата ви ще стане по-съзнателна.
Продължавайте да създавате, но знайте кога да кажете „не“.
Skillbox препоръчва:
- Приложен онлайн курс .
- Онлайн курс .
- Практически годишен курс .
Източник: www.habr.com