Когда популярность веб-разработки стала стремительно расти, многие люди из других областей начали переходить на JavaScript. Природа людей такова, что они довольно консервативны и очень редко меняют свое мышление. Особенно это касается программистов, у которых в целом высокая самооценка. Когда они узнали что-то, что было относительно сложно выучить, и потребовалось много усилий, чтобы получить эти знания, становится действительно трудно признать, что, возможно, это не единственный правильный способ решения проблем. Тенденция приносить из других «миров» другую перспективу и обогащать новую среду также имеет некоторые положительные последствия. Так Бьярн Страуструп изобрел C ++. Он был немного разочарован, когда начал писать код на простом C, без классов, которые он знал по SmallTalk, поэтому он представил эту концепцию в C, и именно так был создан C ++. То же самое произошло с Objective-C. Но иногда стоит сделать шаг назад и осознать: «Эй, я больше не использую серверную часть, и люди долгое время жили без всех этих инструментов». Может, это не то, без чего нельзя жить? Может быть, эти люди решали одну и ту же проблему, используя разные инструменты? При переходе на новую среду лучше уважать среду, в которой вы являетесь гостем, вместо того, чтобы заставлять хозяина уважать ваш подход и делать его «по-своему».

Я много лет был внутренним разработчиком C # и придерживался только этой точки зрения. За несколько лет до настоящего времени я перешел на интерфейсную часть и очень ценю этот переход. Я был вовлечен в проект с ребятами из Ruby on Rails. Это был действительно потрясающий опыт. Я обнаружил, что вы можете эффективно кодировать без сверхтяжелой IDE, такой как Visual Studio с Resharper. Вы можете просто использовать VIM. Вы можете довольно быстро сформировать некоторые общие вещи, такие как фоновый процесс, с помощью нескольких команд. Что-то, что потребовало бы от меня большого количества работы на C #, например, создание фоновой службы, которой я мог бы делегировать длительные задачи из ASP.MVC и сообщать о ходе выполнения через базу данных, с Ruby on Rails было легко. Тогда я перешел на CoffeeScript и сообщил, что не скучаю по статической типизации. Что я получаю от CoffeeScript - удобочитаемость была для меня намного полезнее, чем автоматическое переформатирование кода и т. Д. В повседневной работе вы чаще читаете свой код или чужой код, чем пишете свой собственный. Вот почему удобочитаемость кода для меня гораздо важнее, чем лучшая интеллигентность / автозаполнение или переформатирование кода.

Есть несколько вещей, которые пришли от back-end разработчиков и в сообществе считаются чем-то, что вы должны использовать, иначе вы хромаете. Более того, большинство шаблонов семян изначально настраиваются с помощью всех этих инструментов. А в реальном мире вам не нужно столько инструментов, серьезно :)

  1. TDD

Это одна из самых переоцененных техник. То, что я выпустил, немного похоже на аналогию больших данных с сексом подростков. Все об этом говорят. Все говорят, что тебе должно быть стыдно, когда ты этого не делаешь. Но на самом деле этим занимаются очень маленькие люди. Даже меньшая часть людей делает это правильно. Несколько мифов о TDD ниже:

  • «Это делает вас более безопасным во время рефакторинга»

Это один из самых распространенных мифов об этом подходе. На самом деле из-за этого рефакторинг становится намного сложнее и болезненнее. Если вы не проводите небольшие рефакторинги вроде изменения имени, тогда TDD действительно для вас;). Скорее всего, когда вы что-то разрабатываете, у вас нет полной картины того, что вам действительно нужно. Ваше видение часто меняется, и когда вы, наконец, создаете вещь из маленьких кусочков, вы действительно начинаете иметь лучшую картину, а затем вам следует перестроить свою модель, чтобы она лучше соответствовала реальности. Итак, давайте представим, вы разрабатываете какой-то инструмент для анализа файлов, почесываете в затылке и вдруг у вас появляются блестящие идеи. Ах да, это будет фабрика, которая производит парсеры файлов, затем эти парсеры будут внедряться в интерпретаторы файлов и так далее. Вы пишете небольшой тест, чтобы проверить, работает ли ваша фабрика. Затем вы пишете свою фабрику и тесты для парсеров и т. Д. И т. Д. Вы собираете все вместе и понимаете, что все работает так, как вы хотели. Но - это неправильная модель, и, возможно, схема цепочки ответственности лучше отразит ваши потребности. На этом этапе ваше решение покрыто бетоном модульных тестов. Вдобавок вы приложили столько усилий, чтобы ваш репортер показал вам, что вы хороший парень и у вас 100% тестовое покрытие. Ты юбиляр! А затем вы захотите провести рефакторинг своей модели, а это значит, что вам придется удалить все свои драгоценные тесты и снова написать их для цепочки ответственности ... Сделаете ли вы это? Ответ очевиден. Вы не желаете этого, хардкорные рефакторы, и ваша модель кода все больше и больше удаляется от реальности. Если у вас нет этих тестов, которые нужно поддерживать, вы двигаетесь быстрее, вы готовы больше экспериментировать, чтобы создавать прототипы, чтобы узнать, действительно ли ваша концепция верна. Для меня это правильный поток разработки. Создайте прототип, не заботясь о качестве кода, а затем создайте его снова с хорошим качеством.

  • «Это делает ваш код лучше, потому что вам нужно думать о тестируемости, которая обеспечивает соблюдение лучших практик, таких как SRP и IoC»

С этим тоже я бы поспорил. Модульные тесты находятся на низком уровне, что означает, что вы начинаете разбирать свою концепцию на мелкие кусочки. Затем вы тестируете такие маленькие кусочки по отдельности и собираете из них раствор. Это плохой подход ... Вы всегда должны переходить с более высокого уровня на более низкий, поэтому вы должны сначала определить свои потребности. Когда вы создаете компонент или сервис, прежде всего вам нужно определить, какой у вас воображаемый API для этого компонента. Как вы хотите вызвать этот компонент, какие параметры он должен получить и какой результат он должен дать. Тогда вам следует идти все глубже и глубже. Подобно требованию UX, необходимо определить UI, который должен определять разметку компонентов, который должен определять контроллер, который должен определять сервис, который должен определять API, который должен определять серверную часть и, наконец, базу данных. Когда вы начнете строить снизу вверх, вы получите небольшие кусочки, хорошо протестированные, но не совпадающие друг с другом.

  • «Это заставляет вас развиваться быстрее, потому что вам не нужно воспроизводить все шаги, такие как переход в браузер и щелкать то и это, чтобы узнать, правильно ли отображается ваш компонент»

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

2. ЛИНТЕРЫ и другие статические анализаторы кода.

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

3. Обзор кода

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

Когда вы находитесь в режиме быстрой разработки и строите новый проект с нуля, очень часто все меняется. Требования меняются довольно быстро и вы что-то пишете, чем удаляете, чем снова пишете. Если вы в то же время изучаете новый фреймворк, такой как angular 2, очень часто вы переписываете свой код снова и снова, потому что все еще учитесь. Нет смысла вдаваться в подробности и тратить много времени на обзоры кода и обсуждать, следует ли извлекать это из метода или нет.

4. Статическая типизация.

Я думаю, что со «статической типизацией» все или ничего. Когда у вас есть динамическая типизация, как в машинописном тексте, у нее есть все недостатки статической типизации с очень небольшими преимуществами. Место, где статическая типизация сияет, как в C #, - это рефакторинг. Но вам нужно, чтобы типы были обязательными везде, а не как в TS. Вы можете изменить имя метода или извлечь что-нибудь с помощью Resharper, и все в порядке. Вы знаете, что ничего не дует. С машинописным текстом я не вижу большой разницы с рефакторингом, если я делаю их в WebStorm в ES6 или TS. Мне всегда нужно просматривать список мест, где resharper обнаружил метод, который я хочу изменить, и мне нужно просмотреть этот довольно длинный список и тратить время на проверку.

Недостатком машинописного текста является нечитаемость. Как я сказал ранее, вы чаще читаете код, чем пишете его. Когда ваш код перегружен универсальными шаблонами и приведением к типам, это делает его гораздо менее читабельным. Ниже вы можете найти пример того же кода в TS в ES6. Для меня пример ES6 намного читабельнее.

Мне любопытно ваше мнение по этому поводу. Вы используете TDD для всего, и вам это нравится? Может, сделаю для этого подход №10 и наконец-то полюблю его;) А пока я без него живу счастливо.