Очистка моего беспорядка JavaScript

В колледже я хотел стать писателем. Но даже когда я получил степень, я никогда не мечтал, что стану писателем кода.

Два года спустя я оказался в большой группе людей, которые хотели сменить профессию и попробовать себя в программировании. Я сел на свой первый урок по веб-разработке, не имея никакого опыта, за исключением единственного учебника по Python, который я попробовал в колледже. Несколько месяцев спустя я начал создавать веб-приложения.

Когда я вспоминаю об этом сейчас, я очень ясно помню трепет, когда код работал, и соответствующее разочарование, когда он не работал. Этот цикл между «работает» и «не работает» был процессом, которому меня учили следовать. Будучи студентами, наша цель состояла в том, чтобы представить ТА работающее приложение и его кодовую базу. Они могли придираться к нашим именам переменных или указывать места, где массивы могли бы работать лучше, но в основном нас оценивали по тому, насколько функциональным было приложение. Чем больше ошибок, тем ниже оценки. Тестирование в этих проектах не имело значения; результат говорил сам за себя.

Оглядываясь назад, я несколько рад своей первоначальной фиксации на том, чтобы все работало. За свою карьеру я видел много поставляемого кода, который просто не делает того, для чего предназначен — черт возьми, я сам отправил часть кода. Но мне потребовалось слишком много времени, чтобы понять простую истину о программировании: доставка работающего кода является минимальным профессиональным требованием. Все то, чему меня никогда не учили — чистое кодирование, хорошая архитектура, тестирование — вот где происходит работа по программированию.

Ранее на этой неделе я сел, чтобы ответить на вопрос: если я просматриваю приложения JavaScript, которые написал во время учебы, могу ли я сказать, в чем ценность моего образования в области программирования? Как я мог «оценить» кодовые базы, которые написал?

Почти сразу же после того, как я изучил свое первое приложение, зависящее от JavaScript, я откинулся на спинку стула и вслух задал вопрос, о чем, во имя Бога, я, должно быть, думал. Приложение представляет собой вариацию игры в палача. Я применил к нему стиль римской истории — цель состоит в том, чтобы угадать имя конкретного римского императора, зная только, сколько букв в его имени. Приложение все еще работает спустя пять лет. Помимо jQuery и шрифта Google, в нем отсутствуют внешние зависимости. Это позор; значит, я не могу винить устаревшую библиотеку в глючности приложения. Это означает, что я отправил его с этими ошибками.

Есть 160 строк JS, управляющих поведением этого приложения. Он объявляет три глобальные переменные — wordList, wins и losses. wordList более точно называется списком имен; к счастью, я оставил своему преемнику комментарий, чтобы убедиться, что это поняли — //a list of names. Великолепно.

Почти весь оставшийся код находится в функции с именем hangmanGame. Игра содержит больше объявлений переменных, которые имеют уровень ниже, чем глобальные переменные, без какой-либо реальной причины. Он содержит (и здесь я действительно начинаю терять его из виду) объявления функций, которые находятся в пределах области действия hangmanGame и, несомненно, полагаются на переменные, доступные только в пределах области действия hangmanGame.

Больше беспокоит то, что эти функции делают все. Влияние на рендеринг приложения. Они определяют, какое имя из списка выбрать наугад. Они проверяют догадку. Они обновляют рендер при каждом предположении. Скажем, я хочу начать работу над этим кодом, исправив довольно вопиющую ошибку, заключающуюся в том, что изображение на странице не загружается правильно — где, черт возьми, я собираюсь это сделать? Функция настолько сильно загрязнена разными обязанностями, что любое изменение игровой механики может сломать рендеринг страницы, а любое изменение рендеринга — игру.

И ни одна из них — ни одна линия — не тестируется.

Излишне говорить, что этот код — беспорядок. Это беспорядочныйJavaScript — вид JavaScript, вызывающий поток статей на Medium, в которых JavaScript называется опасным, рискованным, глючным и глупым. Это также тот вид JavaScript, который принес мне хорошую оценку за проект, успех, который доказал моим инструкторам, что я умею писать код и знаю, как заставить его работать. И поскольку он проходит проверку в классе, этот вид JavaScript работает по всему Интернету.

Как эти две вещи — невероятно беспорядочные, одобренные преподавателем — могут сосуществовать? Если бы я оценивал этот код сейчас, даже если бы автор был таким же новичком, как и я, я бы не стал воздерживаться от критики. Код не проверен. Код хрупкий. Это также невероятно жестко, потому что ни одна функция не имеет единственной обязанности. Из-за своей жесткой хрупкости ее нелегко изменить. Любое изменение приведет к ошибкам, которые останутся непроверенными и непредвиденным образом сломают приложение. Да, это работает пока. Это означает, что оно соответствует первому критерию профессионально запрограммированного приложения. Теперь пора приступать к работе.

Я не верю, что наши воспитатели были ленивы — нет, я в огромном долгу перед ними. Без них я бы не был там, где я сейчас в своей карьере. Но я задаюсь вопросом, почему хотя бы тестирование не было включено в учебную программу.

Я намерен провести рефакторинг своих старых кодовых баз с учетом того, что код говорит о приоритетах моего образования. Но даже не делая этого, у меня есть гипотеза о том, что может быть виновато:

  1. Меня записали на курс, который должен был обучать полному стеку веб-разработки. За шесть месяцев я изучил HTML, CSS, базовый браузерный JavaScript, Node.js, SQL и NoSQL, интерфейсные и серверные фреймворки. Было достаточно времени, чтобы охватить основы всего, но не хватило времени, чтобы углубиться в какую-то одну тему. Проблема 1 связана с проблемой 2:
  2. Программы, подобные той, на которую я обратился, очень успешно выполняют свое обещание: они выпускают наемных разработчиков. Они, несомненно, просматривают объявления о вакансиях, чтобы увидеть, какие навыки наиболее востребованы рекрутерами и объявлениями о вакансиях, и строят свою учебную программу на основе этих навыков. В этих объявлениях о вакансиях почти всегда требуется опыт работы с множеством «горячих» фреймворков и языков. Они хотят, чтобы их разработчики понимали 3 языка, 20 нечетных фреймворков, бэкэнд и фронтэнд, конвейеры развертывания, agile-обязанности и все такое прочее. Каждый разработчик должен быть идеальным воплощением своей отрасли. Конечно, как и в случае с любой вакансией, компаниям обычно не требуются все эти навыки, и они часто нанимают людей, которые соответствуют лишь небольшой части требований — это тактика, забрасывать широкую сеть и смотреть, что вы поймаете.

Но если объявления о вакансиях влияют на педагогов, то педагоги будут стремиться втиснуть в учебные программы как можно больше востребованных навыков. В конце концов, им нужно, чтобы их учеников можно было нанять. Программы кодирования будут откачивать студентов, которые соответствуют объявлениям о вакансиях, и наниматели начнут видеть кандидатов, идеально подходящих для объявления о вакансии. Но чего не видят наниматели, так это того, что было принесено в жертву. Что было вырезано из учебного плана, чтобы освободить место для всех этих свежих фреймворков? Что, если эти студенты не понимают основ JavaScript? Что, если они не понимают, как правильно тестировать? Что, если они не могут спроектировать чистый код? Короче говоря, что, если они точно такие же, как я, когда я вышел на рынок труда?

Беспорядок растет, и репутация JavaScript ухудшается.