Быть JavaScript-разработчиком круто, поскольку на рынке труда постоянно растет нужда в хороших JS-программистах. В наше время очень много фреймворков, библиотек и прочего, что можно использовать в работе, — и в значительной степени мы должны быть благодарны за это opensource-источникам. Но в какой-то момент разработчик начинает тратить на JS-проекты слишком много времени по сравнению со всеми остальными задачами.
Весьма вероятно, что в будущем это приведет к катастрофическим последствиям для вашей карьеры, но пока вы этого не осознаете. Я сам в прошлом допустил некоторые ошибки, описанные ниже, и теперь хочу уберечь от них вас. Вот восемь ошибок JS-разработчиков, которые могут сделать ваше будущее не слишком радужным.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Skillbox рекомендует: Образовательный онлайн-курс «Java-разработчик».
Использование jQuery
jQuery сыграл огромную роль в развитии всей экосистемы JavaScript. Изначально JS использовался для создания слайд-шоу и разного рода виджетов, галерей изображений для сайтов. jQuery позволил забыть о проблемах с совместимостью кода для разных браузеров, стандартизировав использование уровней абстракции и работу с DOM. В свою очередь, это помогло упростить AJAX и проблемы с кросс-браузерными различиями.
Однако сегодня эти проблемы не столь актуальны, как прежде. Большая их часть была решена путем стандартизации — например, это касается fetch и селекторов API.
Оставшиеся проблемы решаются другими библиотеками, такими как React. Библиотеки дают и много других возможностей, которые недоступны для jQuery.
Работая с jQuery, в какой-то момент вы начинаете делать странные вещи: например, использовать элементы DOM в качестве текущих состояний или данных, а также писать ужасно сложный код только для того, чтобы выяснить, что там с предыдущим, текущим и будущим состоянием DOM, в дополнение к обеспечению надлежащего перехода к предстоящим состояниям.
Никто не запрещает использовать jQuery, но уделите время, чтобы больше узнать о более современных альтернативах — React, Vue и Angular — и их преимуществах.
Отказ от unit-тестирования
Я часто вижу, как люди игнорируют юнит-тесты для своих веб-приложений. Все идет прекрасно — до того момента, пока приложение не падает с “unexpected error”. И в этот момент мы получаем огромную проблему, поскольку теряем время и деньги.
Да, если приложение нормально компилируется, не выдавая ошибок, а будучи скомпилированным, работает, — это не означает, что оно готово к использованию.
Отсутствие тестирования еще более-менее приемлемо для небольших приложений. Но когда программы большие и сложные, их тяжело обслуживать. Поэтому тесты становятся чрезвычайно важным элементом разработки. В этом случае изменение одного компонента приложения не приведет к повреждению другого.
Начните использовать тестирование незамедлительно.
Изучение фреймворков прежде JavaScript
Я прекрасно понимаю тех, кто, приступая к разработке веб-приложения, сразу же начинает использовать популярные библиотеки и фреймворки вроде React, Vue или Angular.
Раньше я говорил, что сначала нужно выучить JavaScript, а потом фреймворки, но теперь я убежден, что все это нужно выполнять одновременно. JS меняется крайне быстро, так что какой-то опыт использования React, Vue или Angular надо получить одновременно с изучением JavaScript.
Это начинает сказываться и на требованиях, выдвигаемых к кандидатам на должность разработчика. Вот, например, что я нашел, поискав в Indeed по ключу “JavaScript”.
В описании к вакансии говорится, что им нужно знание jQuery И JavaScript. Т.е. для этой компании оба компонента одинаково важны.
Вот другое описание, в котором указаны лишь “базовые” требования:
И так примерно в половине вакансий, которые я просмотрел. Тем не менее я считаю, что правильное соотношение времени на изучение JS и фреймворков — примерно 65% к 35%, а не 50 на 50.
Нежелание знакомиться с концепцией «чистого кода»
Создавать чистый код должен учиться каждый начинающий разработчик, если он желает стать профессионалом. С концепцией «чистого кода» стоит ознакомиться еще на старте карьеры. Чем раньше вы начнете следовать положениям этой концепции, тем раньше вы привыкнете сразу писать чистый код, который легко обслуживать впоследствии.
Кстати, чтобы понять преимущества хорошего и чистого кода, вам не нужно самим пробовать писать плохой код. Ваши навыки пригодятся позже, во время работы, когда вы ужаснетесь на чужой плохой код.
Слишком раннее начало работы над большими проектами
В начале своей карьеры я совершил большую ошибку: попытался взяться за крупный проект, когда ещё не был к этому готов.
Вы можете спросить, что здесь не так. Ответ есть. Дело в том, что если вы не миддл и не сениор, то вы, скорее всего, не сможете закончить ваш «большой проект». В нем будет слишком много элементов и вещей, которые нужно учесть. И вы не справитесь, если еще в самом начале своей карьеры не выработали привычку писать «чистый код», использовать тесты, масштабируемую архитектуру и т.п.
Допустим, вы все-таки потратили кучу времени на этот проект, не завершили его, а теперь пытаетесь перейти на уровень миддла. И тут внезапно понимаете, что не можете показать кому-либо этот код, потому что он не очень хорош и нужен рефакторинг. Однако на этот «проект века» вы потратили кучу времени, и теперь у вас нет примеров хорошей работы, которые можно добавить в портфолио. И вы уступаете одно собеседование за другим другим тем кандидатам, которые могут показать свои работы, пусть и не очень крупные, в портфолио.
В любом случае, в будущем вам придется провести рефакторинг, поскольку и код не слишком хорош, и технологии вы использовали не совсем те, что нужно. В результате вы понимаете, что проще все переписать с нуля, чем пытаться исправить.
Конечно, все это можно добавить в портфолио, но потенциальный работодатель увидит там массу недостатков и придет к неутешительным для вас выводам.
Нежелание изучать структуры данных и алгоритмов
Можно долго спорить о том, когда нужно начинать изучать структуру данных и алгоритмы. Кто-то предлагает делать это еще до освоения JavaScript, кто-то — после.
Я считаю, что на старте учить это детально необязательно, но разбираться в алгоритмах стоит, поскольку это даст базовое понимание работы компьютерных программ и расчетов.
Алгоритмы — неотъемлемая часть любых расчетов и программ. Собственно, сами компьютерные программы — это сочетание набора алгоритмов и данных, структурированных определенным образом, вот и все.
Отказ от физической активности
Для разработчика очень важно заниматься спортом. Я не тренер, но наблюдал, как меняется мое тело — год за годом. Поэтому могу рассказать, к чему приводит отсутствие физических упражнений.
Моя первая работа была довольно проблемной по целому ряду причин, и одна из проблем была как раз в том, что всего за год я набрал почти два десятка килограммов. Тогда я активно изучал JavaScript.
Если вы не будете заниматься спортом, то рискуете набрать вес, и негативных последствий у этого будет много: ожирение, мигрени (включая хронические), повышенное артериальное давление и т.п. Список проблем воистину бесконечен.
Социальная самоизоляция
Семья и близкие — это важно. С головой погрузившись в изучение JavaScript и недооценивая важность своей психической и эмоциональной жизни, вы рискуете погрузиться в депрессию, стать раздражительным, перестать нормально спать и много чего еще.
Выводы
Надеюсь, что-то из этого вам пригодится. Если вы позаботитесь о себе сегодня, то вам не придется исправлять ошибки позже.
Skillbox рекомендует:
- Практический курс «Мобильный разработчик PRO».
- Прикладной онлайн-курс «Аналитик данных на Python».
- Двухлетний практический курс «Я — Веб-разработчик PRO».
Комментарии (56)
ialexander
26.07.2019 19:32Статья применима не только к JS программистам, все поднятые проблемы актуальны и в других отраслях программирования:
- знание языка против знания библиотек
- алгоритмы
- здоровый образ жизни
DmitryKoterov
27.07.2019 21:079-я ошибка — это писать на чистом JS в 2019-м году, когда можно потратить час на настройку и начать писать на TypeScript. (Несогласным — попробуйте, и, клянусь, через неделю вы будете поражаться, почему не сделали это раньше.)
hd_keeper
27.07.2019 22:39+1Начинал, но преимуществ не почувствовал.
RevanScript
27.07.2019 18:35Преимущество TypeScript начинает ощущаться пропорционально росту сложности проекта
MaZaAa
27.07.2019 19:51-1Это просто пустые слова, по факту разницы не вижу, сложный проект или нет, кроме дополнительный autosuggest в IDE реальной пользы(с учетом оверхеда по времени и гемороя) Typescript не дает.
RevanScript
27.07.2019 20:01а статический анализ? он ещё на этапе написания кода позволяет выявить и избежать кучи ошибок. ну, и видимо вы никогда не пробовали рефакторить большие проекты, без TS даже переименование одного свойства это боль
MaZaAa
27.07.2019 20:22-1Кучи ошибок? я с 2015 года вообще ни разу не работал с теми кто может в момент написания кода нагенерировать кучи ошибок, даже если ошибки появляются, их тут же видит разработчик, а если этого сразу не заметил, то непременно это заметят остальные разработчики или тестировщики и это за 2 секунды пофиксится. Как ни крути выйгрыш временной без TS значительный.
По поводу рефакторить, если есть тенденция рефакторить по крупному, то это уже проблемы адские в архитектуре и таких рефакторингов будет много, опять же тут дело чисто в кривых ручках, а вообще я рефакторил дофига проектов раных рамерах, никаких проблем небыло, как бы опять же есть IDE, есть ты сам, который элементарно делает несколько кликов по проекту, есть тестировщики, есть другие разрабы… А TS все равно от косяков не спасет, только от банальных, которые сразу же видно в консоле и так. У меня было 2 крупных проекта на TS и того: профита 0, оверхед по временным затратам ощутимый, неоправданная головная боль и вынужденные костыли с типами для всех компонентов которые претендуют хоть на какую-то универсальность… Это самые явные пункты, после этого сдраво подумав головой, взвесив все за и против невольно приходишь к выводу, а нахрена оно вообще надо? На бэкенде это полезно и удобно, спору нет, сам писал бэки на ноде с TS, тут без нареканий, а вот на фронте… это мазахизм. Связка Devepors + QA и все, максимально возможная скорость и качество, а если вместо QA писать авто тесты, то это опять же идиотизм ничем не обоснованый в реальной жизни и программист становится тестировщиком ручным в том числе, потому что только ручное тестирование выявляет 99% багов и 1% выявят автотесты и то, потому что ты ещё просто не успел открыть страничку на которой есть этот баг.RevanScript
27.07.2019 20:42ни разу не работал с теми кто может в момент написания кода нагенерировать кучи ошибок
видимо вундеркинды какие-то, которые все переменные в голове могут держать и точно помнят, где и какие данные используются. ну, а все остальные, кто возится с этимидженериками, интерфейсами, типамикостылями, просто идиоты, которые впустую тратят своё время :)
тестирование выявляет 99% багов и 1% выявят автотесты
и юнит тесты значит тоже пустая трата времени, всё ясноMaZaAa
27.07.2019 20:59Вы так говорите как будто 99.999% процентов всех интернет проектов на клиентской части просто каким-то чудом были написаны без TS и продолжают создаваться и развиваться без типизации. И якобы элита предпочитает TS.
MaZaAa
27.07.2019 21:05-1видимо вундеркинды какие-то, которые все переменные в голове могут держать и точно помнят,
Нет, это просто люди у которых есть хотя бы 3 года опыта за плечами и которые реальные программисты, а не те, кто слепо верят т делают то, что им кто-то говорит и/или пишет в интернете не думая своей головой.
и юнит тесты значит тоже пустая трата времени, всё ясно
А какие есть настоящие аргументы в пользу unit тестов против тестировщиков на проекте?Zenitchik
28.07.2019 20:10в пользу unit тестов против тестировщиков на проекте
Э… что? С каких пор они «против»? Только вместе.MaZaAa
28.07.2019 20:20Уже давно против, сейчас тестировщик на проекте это редкость
justboris
28.07.2019 21:38Если уж и заменять труд тестировщика машинами, то это будут интеграционные тесты. Unit — они про другое
YemSalat
29.07.2019 07:53сейчас тестировщик на проекте это редкость
Может вам просто с проектами не очень везет?MaZaAa
29.07.2019 10:34Нет, это просто ситуация на рынке, с каждым годом встретить QA это редкость, из-за статей которые говорят что unit тесты и прочие автотесты это огонь, и люди это видят, которые вообще не шарят(менеджеры и т.п.) и у них сразу складывается идеальная картинка — тестировщикам платить не надо, шикардос, программисты и так сами все будут тестировать да ещё и быстрее и качественее, шикардос, более того, мы ещё читали что TS тема, шикардос, будет у нас все максимально быстро писаться и без багов, а потом волосы на голове рвут и банкротятся потому что, миллион багов оказывается, а по скорости разработки так это вообще труба, сделано только 30% от запланированного, и дальше все вытекающие. Либо должна быть оценка JS + QA x 3, тогда по срокам можно будет попасть более менее с TS + Unit тесты, но проблема того, что будет тонна багов и из-за этого сырой продукт так и останется, потому что настоящего тестировщика/ов на проекте нет.
monolithed
29.07.2019 00:21я с 2015 года вообще ни разу не работал с теми кто может в момент написания кода нагенерировать кучи ошибок, даже если ошибки появляются, их тут же видит разработчик
У вас искаженное восприятие о своих коллегах, и о себе в том числе.
За прошедшие полгода я провел свыше 160 технических интервью, из которых взял каждого 4-го и лишь единицы отправили на первое ревью код, который не ломал обратной совместимости или не вызывал ошибок.
Если вы не видите своих ошибок — это не значит, что их нет.
А какие есть настоящие аргументы в пользу unit тестов против тестировщиков на проекте?
С каждой новой строчкой кода увеличивается регрессионная составляющая, поэтому деньги, время и личная ответственность — это то, чем будет руководствоваться ваш заказчик. Тестировщикам все еще нужно платить, а менеджерам вовремя выпускать продукт.
писать авто тесты, то это опять же идиотизм ничем не обоснованый в реальной жизни и программист становится тестировщиком ручным в том числе, потому что только ручное тестирование выявляет 99% багов и 1% выявят автотесты
Начните писать тесты, чтобы было наоборот.
У меня было 2 крупных проекта на TS и того: профита 0, оверхед по временным затратам ощутимый, неоправданная головная боль и вынужденные костыли с типами для всех компонентов которые претендуют хоть на какую-то универсальность…
Если вы не справились с описанием типов для собственных же интерфейсов, то сложно представить, что вы там написали.MaZaAa
29.07.2019 10:22Я может быть открою для вас тайну, но тестирование фронта это не «жду 4, 2+2 вернуло 4, ура всё работает», на фронте юзкейсы растут с каждой строчкой кода в геометрической прогрессии, и по мимо функционала, там ещё тестируется верстка в разных браузерах, если вы будет по настоящему тестировать код, а не так, как это делают все и считают себя покрывателями кода тестами, то вы не будете писать фичи и фиксить баги, а будете только тесты писать. А ещё самое клевое, когда меняется бизнес логика и надо кучу тестов переписывать по новой, уххх сколько времени выброшено в мусор… А всего лишь, нужен хотя бы 1 тестировщик, а лучше несколько, и вот тогда будет по настоящему качество и скорость разработки и продукт будет выпускаться в срок, а не будет всю жизнь сырым, потому что «блин, ну мы не знали, у нас же все тесты прошли». Но конечно если заказчику пофигу что TS + Unit тесты замедляют работу над проектов в 3 раза, по сравнению с JS + QA, то на здоровье. Как известно самый худший тестировщик — это программист.
Zenitchik
29.07.2019 11:53Если проект состоит из сайтика с двумя скриптиками, то может, без юнит-тестирования и можно обойтись.
Но у нас, например, если бы не было юнит-тестов, тестировщикам пришлось бы тратить три недели вместо одной на проверку каждой минорной версии.
Тестировщики должны юзеркейсы проверять, и случаи когда 2+2 не вернуло 4 — до них просто не должны доходить: они вообще не должны попадать в коммит (и не попадают).
Как известно самый худший тестировщик — это программист.
Кто Вам сказал такую ерунду?MaZaAa
29.07.2019 12:13Как бы в нормальных командах флоу такой: тестировщики тестируют только закрытые разабами баги и только новые фичи, в процессе естественно будут находится ещё баги, потом все это заливается на стейджинг, и только тогда уже происходит полный регрес и чисто стабилизация(фикс багов, без новых фичей), и уже после этого, когда все полностью протестировано и работает стабильно можно выкатываться на прод. Юнит тесты от полных регресов на стейджинге не освобождают это раз, юнит тесты от проверок тестировщиками всех багов и фичей не освобождают это два, если у вас есть проблемы, что разрабы сразу же не видят и/или не думают что их изменения что-то сломали и/или потенциально сломают, то у меня для вас плохие новости это три и архитектура вашего проекта в таком случае архитектурой называться и не может. Отсюда вывод, зачем тратить время на Unit тесты проверяя 2+2, если разрабы и так сами за собой проверяют и когда в любом случае тестировщики за ними перепроверяют? Полагаться на Unit тесты и думать, раз они прошли, то всё в порядке это же просто смешно, я надеюсь вы это понимаете?
Zenitchik
29.07.2019 12:29Полагаться на Unit тесты и думать, раз они прошли, то всё в порядке это же просто смешно, я надеюсь вы это понимаете?
Разумеется. Я вообще не понимаю, с чем Вы спорите. Юнит-тесты это самое первичное тестирование, которое происходит при каждой сборке дев-версии системы и автоматически пинает разраба «чувак, ты накосячил, давай исправляй». И только если система нормально собирается и юнит-тесты не падают — её не стыдно показать тестировщику для тестирования закрытого бага или новой фичи.
Druu
30.07.2019 10:35Но конечно если заказчику пофигу что TS + Unit тесты замедляют работу над проектов в 3 раза, по сравнению с JS + QA
Ну я допустим могу понять, как тесты замедляют, когда они плохие и их много (но не в три раза явно), а тс каким образом замедляет? Наоборот — с ТС есть нормальный тулинг, человеческий автокомплит и рефакторинги.
Каким образом оно может замедлить, вообще в теории хотя бы?MaZaAa
30.07.2019 10:54По поводу автокомплита да, это удобно, но не настолько, учитывая то, какие манипуляции ты должен делать чтобы этого автокомплита достичь. Это не TS подстраивается под тебя и под твой проект, а ты вынужден прогибаться и подстраиваться под TS. Замедляет когда ты описываешь типы, замедляет когда ты пытаешься пропихнуть что-то в компонент который принимает другой тип(вопрос универсальности) и тут уже либо ты убиваешь смысл TS и кастуешь as any или as другой тип, либо в том компоненте добавляешь | anouter interface и тут тоже спорное решение с точки зреня строгой типизации, или чтобы не нарушать ни одного «правильного» канона ты создаешь ещё один компонент который по сути клонирует функционал другого и убиваешь DRY. Мораль такова, каждое нажатие на клавишу занимает время, чем больше мы жмакаем на клавишы, думаем о 100% совподении типов, когда используем язык с димамической типизацией, а не строгой, тем больше мы утомляемся. Вообщем увы, если бы оверхеда по времени не было и не надо было бы постоянно идти на какие-то компромисы, то претензий к TS именно на рфонте у меня был не было. На бэке, я только за TS, вот так это реально нужно, а на фронте ну хз хз.
P.S. если тот, кто топит за TS хоть в каком-то месте использует any или as any, то грошь цена этому топильщику. Это автоматически сводит все типизацию в ноль.Druu
30.07.2019 11:58По поводу автокомплита да, это удобно, но не настолько, учитывая то, какие манипуляции ты должен делать чтобы этого автокомплита достичь.
Какие?
Это не TS подстраивается под тебя и под твой проект, а ты вынужден прогибаться и подстраиваться под TS.
Эм, каким образом? У вас же что с ТС, что без ТС, все ф-и имеют свои типы. ТС просто позволяет вам этот тип записать, ну как в документации. Только эта документация компактна, заведомо актуальна, проверяется компилятором и предоставляет доп. возможности тулинга.
Замедляет когда ты описываешь типы
Чем именно замедляет-то? Написание кода при программировании не является ограничителем скорости. С-но, то, что приходится писать на ~5-10% больше кода само по себе замедлить никак не может.
ты пытаешься пропихнуть что-то в компонент который принимает другой тип
Так это же ошибка, если вы в компонент суете то, чего туда совать не надо. ТС не дает вам написать некорректный код. Сэкономите время на дебаге этой ошибки. Что тут не так?
или чтобы не нарушать ни одного «правильного» канона ты создаешь ещё один компонент который по сути клонирует функционал другого и убиваешь DRY
Вот уже 4 год использую ТС и ни разу не встречался с таким. Можно пример?
думаем о 100% совподении типов, когда используем язык с димамической типизацией
Так со статической типизацией мы как раз о совпадении типов не думаем — за нас думает компилятор. А вот когда типизация динамическая — тут самый настоящий bondage and discipline, как раз ндао постоянно помнить о типах, держать их все в уме, постоянно перепроверять, в уме производить тайпчек и т.д…
Многие вещи на динамических ЯП вообще просто нельзя писать, т.к. слишком error prone. Куча ограничений, короче.
Это автоматически сводит все типизацию в ноль.
Каким образом-то? Тот факт что у вас, например, 5% кода не типизированы ничуть не мешает тому, что остальные 95% типизированы. И всем плюсам от типизированности этих 95% тоже не мешает.
MaZaAa
30.07.2019 12:35Вопрос такой, зачем вам вообще JS? Он вообще не про типизацию
YemSalat
30.07.2019 19:05Ну так он и не про «не-типизацию». Он про платформу и про асинхронную парадигму.
На нем пишут не потому что 1 == '1', а вопреки этому.MaZaAa
30.07.2019 19:32Если бы 1 != '1', то он был бы изначально усложнен для простых задач, для которых он создан(если мы говорим только о клиентской стороне), прикол в том, что люди сами себе придумывают проблемы и усложняют жизнь, когда одни и те же вещи можно было бы решить значительно проще и быстрее и речь тут не о быстрых костылях, а о правильной архитектуре проекта для тех или иных задач, когда у тебя грамотная архитектура, то тебе не нужен TS, но по факту у подавляющего большенства почему-то проблемы с выстраивание архитектур и тут уже принимаются отчаяные меры чтобы немного сгладить эти фундаментальные косяки и просчеты в виде TS, кучей unit-тестов и т.п. Потому что проект настолько не структурирован и его поведение непредсказуемо из-за кривых ручек, что никто в команде не уверен, на что повлияет та или иная строка в коде. TS и unit тесты это просто попытка лечения симптомов, а не лечение болезни как таковой. У меня сейчас огромный и сложный проект, но грамотно спроектированный и структурированный изначально,
в него вливаются новые разработчики и в первый же день и начинают фиксить баги и делать новые фичи и мне даже вопросов не задают, а что да как и почему, потому что там и так все понятно, очевидно и предсказуемо написано и я за этим слежу в мердж реквестах, чтобы все так и писали понятно и очевидно. И без TS и unit тестов все прекрасно разрабатывается и поддерживается, причем с высокой скоростью. P.S. последние 4 месяца нас 7 разрабов на этом проекте (это чисто на фронте) и никто ни разу ничего не сломал случайно и не жаловался что боится что-то сломать.
Да, если на проекте сумасшедшая текучка, квалификация людей мутная, архитектура шаткая, то немного поможет TS и unit тесты, но это уже чисто от безисходности.
MaZaAa
27.07.2019 19:59Если архитектура проекта грамотная, то вообще пофигу есть TS или нету, проект будет масштабироваться до бесконечности четко, а от кривых ручек извините, ничего не спасает.
androidovshchik
27.07.2019 13:28Typescript не сильно отличается от последних стандартов ECMAScript. Я бы скорее предпочел kotlin или dart для трансляции в js
RevanScript
27.07.2019 18:12TypeScript это и есть JS, только с типизацией, с чего вдруг он должен отличаться?
mad_god
27.07.2019 21:53Например, какие проекты не слишком большие и сложные, чтобы их записать в портфолио? А какие уже слишком сложные?
vvm13
27.07.2019 22:13Профессионал в «чём-то» не тот, кто «хороший» в «чём-то», а тот, кто этим «чем-то» зарабатывает на жизнь. В отличие от любителя, для которого это «что-то» не является основным источником дохода. Поэтому мы можем ожидать, что профессионал «лучше» любителя, но это не закон природы — всё может быть наоборот.
Спорт — это не физкультура. Спорт — это состязания. Шахматы — спорт, а пробежки по 10км ежедневно — не спорт.
MSC6502
27.07.2019 23:24Вот так, за изучением чужих фреймворков и проходит жизнь простого js работяги.
andreymal
27.07.2019 01:59+2Семья и близкие — это важно. С головой погрузившись в изучение JavaScript и недооценивая важность своей психической и эмоциональной жизни, вы рискуете погрузиться в депрессию, стать раздражительным, перестать нормально спать и много чего еще.
Передайте автору, что не надо свои личные проблемы в жизни обобщать на всех.
AlexZaharow
27.07.2019 08:49Быть новичком в программировании каждый день — это часть профессии. А так — плохому танцору яйца мешают.
MaZaAa
27.07.2019 09:52Настоящая ошибка это когда на проекте нету хотя бы одного ручного тестировщика, и вообще смешно когда пытаются Unit тестами и вообще авто тестами заменить человека, во первых хз через сколько к этому реально можно будет приблизится и во вторых, и это очень важно, вы этой херней лишаете работы тестировщиков!!! Поставьте себя на их место и будете сидеть без работы.
MrDaedra
27.07.2019 14:35Автомобили-роботы лишают работы водителей, кассы самообслуживания лишают работы кассиров… Вы вообще не задумывались, что тестировщики — одни из самых низкоквалифицированных работников IT и существуют лишь потому, что разработчикам самостоятельно заниматься тестированием было бы намного дороже?
MaZaAa
27.07.2019 16:42Разработчик должен только разрабатывать, а тестировщики должны тестировать. Тестировщик очень и очень нужная профессия, не надо пытаться заменить его за счет унижения разработчиков(писать Unit Тесты и прочую чушь). Абсолютно всё что связано с тестирование ручным и авто, должны заниматься специально обученные люди — тестировщики.
MrDaedra
28.07.2019 09:48Чтобы писать, к примеру, UI тесты, код знать не нужно, а вот чтобы писать юниты, его нужно знать и иногда реыакторить. Я бы тестировщики к такому не допустил. Юниты — отнюдь не чуть. Они могут проверить за несколько миллисекунд сложную логику, которую тестировщик может проверять целый час.
MaZaAa
28.07.2019 14:50Например? что такого может выявить Unit тест, чего не может выявить автотест написанный автотестировщиком?
MrDaedra
29.07.2019 09:18Я не говорил, что они могут выявить что-то особенное, хотя некоторые вещи куда проще проверить с помощью юнит тестов.
Дело в том, что есть пирамида тестирования и она появилась из практики. Она обусловлена тем, что юнит-тесты легче писать, они реже ломаются и, самое главное, проходят быстрее в несколько тысяч раз, чем UI-тесты. Так получилось, что на нашем проекте за стратегию автотестирования отвечают индусы и они заставляли писать селениумы на всё. В результате, за год время прогона тестов выросло в 3 раза и теперь при изменении в коде за день все тесты уже не прогнать. В то же время, юнит-тесты прогоняются всего за 15 минут. К тому же, UI-тесты часто требуют ещё и настройки среды, в отличие от юнитов.
На эту тему на хабре есть статья https://m.habr.com/ru/post/358950/. Сам прочитал по диагонали, но, вроде, неплохая.
rudinandrey
27.07.2019 09:55+1за что же вам всем так не нравится jQuery? донельзя оптимизированная библиотека экономящая кучу времени при разработке. И я говорю даже не о встроенных возможностях поиска элементов или ajax и все вот это. А то что есть куча библиотек, зависящих от jQuery, которые делают твою жизнь сильно проще.
Отказ от unit тестирования, ИМХО было бы лучше если бы люди говоря о unit тестировании, поделились какими то своими болями настоящими, ну вот было так, затестировать забыли, или вообще без тестирования писали, потом случилось вот такое, и все упало.
Да я понимаю всевозрастающую необходимость в тестировании, потому что сейчас микросервисы, приложения пишут со встроенными серверами, ну например там NodeJS, пишем приложение, запускаем, вот нам и сервер. Или там на Python + Flask написали приложение, подняли, тоже отвечает на запросы и что-то делает. И в этом случае если приложение упадет с ошибкой, да, весь сервер перестанет работать. Но почему люди отходят от модели с тем же nginx+php-fpm где если что-то будет вылетать, будет вылетать только в конкретном месте и для конкретного пользователя никак не влияя на других и в целом все будет продолжать работать?!?!?
с остальными пунктами с автором согласен.YemSalat
28.07.2019 12:07ИМХО было бы лучше если бы люди говоря о unit тестировании, поделились какими то своими болями настоящими, ну вот было так, затестировать забыли, или вообще без тестирования писали, потом случилось вот такое, и все упало
Юнит тесты обычно пишутся для того, чтобы при внесении изменений в код, не сломать уже существующий.
Но почему люди отходят от модели с тем же nginx+php-fpm где если что-то будет вылетать, будет вылетать только в конкретном месте и для конкретного пользователя никак не влияя на других и в целом все будет продолжать работать?!?!?
Кто вам сказал что «люди от этого отходят»? Наоборот в последнее время всякие балансировщики, прокси и прочие cloudflare набирают обороты. nginx точно так же используется с node/python. К тому же есть всякие докеры и кубернетисы. Да много всего…rudinandrey
29.07.2019 15:53Юнит тесты обычно пишутся для того, чтобы при внесении изменений в код, не сломать уже существующий.
ааа, ну вот реально действительно хороший кейс. Такое было да.
Я просто думал, ну пишешь ты код, ты все предусмотрел, все работает, зачем тесты то? Все же работает.
Т.е. получается мы пишем рабочий код, покрываем его тестами его текущего состояния, потом меняем что-то, и пропускаем уже через эти тесты чтобы понять что то что нам нужно было в предыдущем состоянии и то что еще нужно работало. Спасибо большое. Это действительно может быть полезным. Век живи, век учись.
Кто вам сказал что «люди от этого отходят»? Наоборот в последнее время всякие балансировщики, прокси и прочие cloudflare набирают обороты. nginx точно так же используется с node/python. К тому же есть всякие докеры и кубернетисы. Да много всего…
да, я просто наверное немного не то имел в виду. Вот nginx+php-fpm как работает, запрос, родился поток, отработал умер, не влияет на другие потоки, т.е. упал с ошибкой, рядом запрос с другими параметрами нормально продолжает работать.
А в модели когда ты пишешь например приложение на node или python+flask и запускаешь его. И если у тебя что-то случится и программа упадет, упадут все запросы, которые параллельно обрабатывались с тем, который привел к фатальной ошибке.
Да, можно запустить какой нибудь наверное монитор, который бы следил, чтобы процесс был всегда запущенным и будет перезапускать его. И вот для таких приложений я хотел сказать что нужно писать тесты и тестировать до продакшена.YemSalat
29.07.2019 18:08Т.е. получается мы пишем рабочий код, покрываем его тестами его текущего состояния, потом меняем что-то, и пропускаем уже через эти тесты
Ну это только основная, «практическая» причина написания юнит тестов.
Еще их можно использовать как документацию/спецификацию (ТДД и т.п.), ну и плюс просто как доказательство работы кода (например на ревью)
А в модели когда ты пишешь например приложение на node или python+flask и запускаешь его. И если у тебя что-то случится и программа упадет, упадут все запросы, которые параллельно обрабатывались с тем, который привел к фатальной ошибке.
Это не так, Flask работает через wsgi, что по сути то же самое что php-fpm. На ноде вообще другая модель, там и так все запросы асинхронно обрабатываются через event loop, и если что-то в отдельном запросе упадет — это вам не уронит главный процесс. К тому же и python и node сервера обычно так же ставятся за nginx/apache proxy-pass.rudinandrey
29.07.2019 23:15Ну это только основная, «практическая» причина написания юнит тестов.
да уж, сколько открытий чудных ) спасибо.
Это не так, Flask работает через wsgi, что по сути то же самое что php-fpm. На ноде вообще другая модель, там и так все запросы асинхронно обрабатываются через event loop, и если что-то в отдельном запросе упадет — это вам не уронит главный процесс. К тому же и python и node сервера обычно так же ставятся за nginx/apache proxy-pass.
здорово, спасибо, надо будет тогда потестировать. Думал как отдельная программа запускается, упадет и все упадет. Спасибо еще раз.
shaman4d
27.07.2019 13:25«Быть JavaScript-разработчиком круто, поскольку на рынке труда постоянно растет нужда в хороших JS-программистах.» пойду пройду какие-нить курсы с гарантированным трудоустройством…
epishman
Рисковано учить язык, от которого ожирение, надо искать что-то подинамичней, но что?
Punk_UnDeaD
Наоборот, для языка с динамической типизацией надо и самому быть динамичным.
epishman
Не, в динамическом языке суетится рантайм, а вот в статическом — вместо GC работает мозг, который как известно потребляет четверть всей энергии организма :)
taliban
да ладно, полно статических языков где gc прекрасно работает