Усталость от JavaScript: реалии нашей отрасли

• Эта публикация - перевод статьи. Ее автор - Lucas Fernandes da Costa. Оригинал доступен по ссылке ниже:

  The Ultimate Guide to JavaScript Fatigue: Realities of our industry

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

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

Одна из вещей, которая вдохновила меня написать этот пост в блоге и полностью изменила мою жизнь, - это замечательный пост Патрика Маккензи, который называется «Не называй себя программистом и другие советы по карьере». Я настоятельно рекомендую вам ознакомиться с ним. Большая часть этого поста - совет, основанный на том, что написал Патрик написал, применительно к экосистеме JavaScript, плюс еще несколько мыслей за последние годы работы в области технологий.

Первый раздел будет немного философским, но, уверяю вас, его стоит прочесть.

Реалии нашей индустрии 101

Так же, как и Патрик (см. пост), давайте начнем с самой простой и существенной правды о нашей отрасли:

Программное обеспечение решает проблемы бизнеса

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

Мне жаль об этом говорить, но причина в том, что в разработке программного обеспечения (и любых других отраслях) есть только два аспекта:

Стоимость и доход

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

Вам не платят за код

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

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

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

Многоразовые космические ракеты, самоходные автомобили, роботы, искусственный интеллект: все это существуют не только потому, что кто-то думал: было бы здорово их создать. Все это существует, потому что за этим стоят деловые интересы. И я не говорю, что люди, стоящие за ними, просто хотят денег, я уверен, что они думают, что все это тоже круто, но правда в том, что если бы они не были экономически жизнеспособными или не имели потенциала стать таковыми, - их бы не существовало.

Вероятно, я не должен был называть этот раздел «Реалиями нашей индустрии 101»; скорее, это «Реалии капитализма 101».

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

В 1975 году Бем провел исследование, в ходе которого выяснилось, что около 64% ​​всех ошибок в программном обеспечении, которые он изучал, были вызваны дизайном, тогда как только 36% всех ошибок были ошибками кодинга. В другом исследовании под названием «Программное обеспечение высшего порядка - методология определения программного обеспечения» также говорится, что в проекте NASA Apollo около 73% всех ошибок были ошибками проектирования.

Вся причина, по которой дизайн и требования существуют, заключается в том, что они определяют, какие проблемы мы собираемся решать и решать проблемы - вот что приносит прибыль.

Без требований или дизайна, программирование - это искусство добавления ошибок в пустой текстовый файл.

- Луи Сригли

Этот же принцип также применим к инструментам, которые мы получили в экосистеме JavaScript. Вавилон, webpack, реагируют, Redux, Mocha, Chai, Typcript, все они существуют, чтобы решить проблему, и мы должны понять, какую проблему они пытаются решить, нам нужно тщательно подумать о том, когда большинство из них необходимы, иначе мы закончится тем, что JS Fatigue, потому что:

Усталость JS происходит, когда люди используют инструменты, которые им не нужны для решения проблем, которые у них отсутствуют.

Как однажды сказал Дональд Кнут: «Преждевременная оптимизация - это корень всего зла». Помните, что программное обеспечение существует только для решения бизнес-задач, а большинство программных средств просто скучно, у него нет высокой масштабируемости или высокопроизводительных ограничений. Сосредоточьтесь на решении бизнес-задач, сосредоточьтесь на снижении стоимости и получении дохода, потому что это все, что имеет значение. Оптимизируйте, когда вам нужно, иначе вы, вероятно, добавите ненужную сложность вашему программному обеспечению, что увеличивает стоимость и не генерирует достаточный доход, чтобы оправдать это.

Вот почему я думаю, что мы должны применять принципы разработки Driven Driven во всем, что мы делаем в нашей работе. И, сказав это, я говорю не только о тестировании. Я говорю о ожидании появления проблем перед их решением. Вот что такое TDD . Как говорит сам Кент Бек, «TDD уменьшает страх», потому что он помогает вашим шагам и позволяет предпринимать небольшие шаги для решения ваших проблем. Одна проблема за раз. Делая то же самое, когда дело доходит до принятия новых технологий, мы также уменьшаем страх.

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

Вы когда-нибудь думали о том, как проще было решить, что вы собираетесь смотреть, когда доступно только несколько телеканалов? Или как проще было решить, какую игру вы собираетесь играть, когда у вас было всего несколько патронов дома?

Но как насчет JavaScript?

К тому моменту, когда я пишу этот пост, у NPM есть 489 989 пакетов, и завтра около 515 новых будут опубликованы.

И пакеты, которые мы используем и жалуемся, имеют историю за ними, которую мы должны понять, чтобы понять, зачем они нам нужны. Все они пытаются решить проблемы.

Babel, Dart, CoffeeScript и другие транспилеры исходят из необходимости писать код, отличный от JavaScript, но делая его доступным в наших браузерах. Babel даже позволяет нам писать JavaScript нового поколения и убедиться, что он будет работать даже в старых браузерах, что всегда было большой проблемой, учитывая несоответствия и различную степень соответствия спецификации ECMA между браузерами. Несмотря на то, что спецификация ECMA становится все более и более твердой в наши дни, нам все равно нужен Babel. И если вы хотите больше узнать о истории Бабеля, я настоятельно рекомендую вам прочитать этот отличный пост Генри Чжу.

У модулей, таких как Webpack и Browserify, есть своя причина существования. Если вы хорошо помните, не так давно мы много страдали от множества scriptтегов и заставляли их работать вместе. Они использовали, чтобы загрязнять глобальное пространство имен, и было разумно сложно заставить их работать вместе, когда зависело от другого. Чтобы решить это, Require.js было создано, но у него все еще были свои проблемы, это было не так просто, и его синтаксис также сделал его склонным к другим проблемам, как вы можете видеть в этом сообщении в блоге. Затем Node.js поставлялся с импортными CommonJS, которые были синхронными, простыми и чистыми, но нам все еще нужен был способ сделать эту работу в наших браузерах, и именно поэтому нам нужны Webpack и Browserify.

И сам Webpack фактически решает больше проблем, чем это, позволяя нам иметь дело с CSS, изображениями и многими другими ресурсами, как если бы они были зависимостями JavaScript.

Фронтальные интерфейсы немного сложнее, но причина их существования заключается в уменьшении когнитивной нагрузки при написании кода, так что нам не нужно беспокоиться о том, чтобы манипулировать самим DOM или даже иметь дело с грязными API-интерфейсами браузера (другая проблема JQuery пришел к решению), который не только подвержен ошибкам, но и не продуктивен.

Это то, что мы делали все это время в информатике. Мы используем абстракции низкого уровня и создаем еще больше абстракций. Чем больше мы беспокоимся о том, как работать наше программное обеспечение, а не работать, тем продуктивнее мы.

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

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

И, как правило, стандарты не достаточно быстры, чтобы их можно было создать, и поэтому нам нужно создавать собственные решения этих проблем, поэтому здорово иметь с нами такое яркое и творческое сообщество. Мы постоянно решаем проблемы, и мы позволяем естественному отбору выполнять свою работу.

Инструменты, которые лучше всего подходят для нас, получают больше вкладов и развиваются быстрее, а иногда другие инструменты в конечном итоге включают хорошие идеи из тех, которые процветают и становятся еще более популярными, чем они. Так мы развиваемся.

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

Мы можем ясно видеть это в среде тестирования JS, например, где у нас есть Mocha для запуска тестов и Chai для выполнения утверждений, тогда как в Java JUnit пытается сделать все это. Это означает, что если у нас есть проблема с одним из них или если мы найдем другой, который нам подходит лучше, мы можем просто заменить эту небольшую часть и по-прежнему иметь преимущества других.

В философии UNIX также говорится, что мы должны писать программы, которые работают вместе. И это именно то, что мы делаем! Например, посмотрите на Babel, Webpack и React. Они работают очень хорошо вместе, но нам все равно не нужно использовать другой. В тестовой среде, например, если мы используем Mocha и Chai, мы можем просто установить Karma и запустить те же тесты в нескольких средах.

Как с этим бороться

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

Еще одна важная вещь - начать с самого начала . Перед использованием каких-либо фреймворков JavaScript убедитесь, что вы достаточно узнали о самом JavaScript. Это единственный способ понять их и согнуть их по своей воле, иначе, когда вы столкнетесь с ошибкой, которую вы никогда не видели, прежде чем вы не узнаете, какие шаги предпринять для ее решения. Изучение основных веб-технологий, таких как CSS, HTML5, JavaScript, а также основы для компьютерных наук или даже то, как работает протокол HTTP, поможет вам освоить любые другие технологии намного быстрее.

Но, пожалуйста, не слишком привязывайтесь к этому. Иногда вам нужно рисковать и начинать заниматься самостоятельно. Как написала Саша Грайф в этом блоге, слишком много времени изучая основы, это просто попытка научиться плавать, изучая динамику жидкости. Иногда вам просто нужно прыгнуть в бассейн и попытаться искупаться самостоятельно.

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

Если вы посмотрите на NPM, это ничего нового, у нас уже давно были Maven Central и Ruby Gems.

Чтобы превзойти ваш код, Babel применяет те же самые принципы и теории, что и некоторые из самых старых и наиболее известных компиляторов, таких как GCC.

Даже JSX - это не новая идея. E4X (ECMAScript для XML) уже существует более 10 лет назад.

Теперь вы можете спросить: «Как насчет скриптов Gulp, Grunt и NPM?» Ну, извините, но мы можем решить все эти проблемы с GNU Make в 1976 году. И на самом деле существует разумное количество проектов JavaScript, которые все еще используют его , например, Chai.js. Но мы этого не делаем, потому что мы - хипстеры, похожие на старинные вещи. Мы используем, makeпотому что это решает наши проблемы, и это то, на что вы должны стремиться, как мы говорили раньше.

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

По-моему, цитата Ричарда Фейнмана о лучшей цитате не имеет, когда речь заходит о том, чтобы действительно чему-то научиться:

Что я не могу создать, я не понимаю

И чуть ниже этой фразы, в той же доске, Ричард также писал:

Знайте, как решить каждую проблему, которая была решена

Разве это не удивительно?

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

Именно по этой причине мне нравятся некоторые видеоролики, доступные в Egghead.io, в которых Дэн Абрамов объясняет, как реализовать некоторые функции, которые существуют в Redux с нуля или в сообщениях в блогах, в которых рассказывается, как создать собственный рендеринг JSX.

Итак, почему бы не попытаться реализовать эти вещи самостоятельно или не отправиться в GitHub и не читать свою кодовую базу, чтобы понять, как они работают? Я уверен, что вы найдете много полезных знаний. Комментарии и руководства могут быть ложными и иногда некорректными, код не может.

Еще одна вещь, о которой мы много говорили в этом посте, заключается в том, что вы не должны опережать себя . Следуйте подходу TDD и одновременно решайте одну проблему. Вам платят за увеличение доходов и снижение затрат, и вы делаете это, решая проблемы, поэтому и существует программное обеспечение.

И поскольку мы любим сравнивать нашу роль с тем, что связано с гражданским строительством, давайте сделаем быстрое сравнение между разработкой программного обеспечения и гражданским строительством, как это делает Сэм Ньюмен в своей блестящей книге под названием «Building Microservices».

Нам нравится называть себя «инженерами» или «архитекторами», но этот термин действительно правильный? Мы разрабатываем программное обеспечение для того, что мы знаем как компьютеры менее ста лет назад, в то время как Колизей, например, существует около двух тысяч лет.

Когда в последний раз вы видели падение моста, и когда в последний раз ваш телефон или ваш браузер разбился?

Чтобы объяснить это, я буду использовать пример, который мне нравится.

Это красивый и удивительный город Барселона:

Когда мы смотрим на него так и с этого расстояния, это выглядит как любой другой город в мире, но когда мы смотрим на него сверху, он выглядит так:

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

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

Это то же самое происходит с нашим программным обеспечением. Он быстро развивается, часто нужны рефакторы, а требования меняются чаще, чем мы хотели бы.

Таким образом, вместо того, чтобы действовать как инженер-программист, выступайте в качестве планировщика города. Пусть ваше программное обеспечение вырастет органично и при необходимости адаптируется. Решите проблемы по мере их возникновения, но убедитесь, что все еще имеет свое место.

Выполнение этого, когда дело доходит до программного обеспечения, еще проще, чем делать это в городах из-за того, что программное обеспечение является гибким, гражданское строительство - нет . В мире программного обеспечения наше время сборки - это время компиляции . В Барселоне мы не можем просто разрушить здания, чтобы дать пространство новым, в Software мы можем сделать это намного проще. Мы можем постоянно ломать вещи, мы можем делать эксперименты, потому что мы можем строить столько раз, сколько хотим, и обычно это занимает несколько секунд, и мы тратим гораздо больше времени на размышления, чем на строительство. Наша работа - чисто интеллектуальная.

Поэтому действуйте как планировщик города, позволяйте вашему программному обеспечению расти и адаптироваться по мере необходимости.

Делая это, вы также получите лучшие абстракции и узнаете, когда придет подходящее время для их принятия.

Как говорит Сэм Кобленски:

Абстракции работают только в правильном контексте, и правильный контекст развивается по мере развития системы.

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

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

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

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

Говоря с людьми, вы делитесь опытом, помогающим друг другу в карьере, и мы открываем новые инструменты для улучшения нашего рабочего процесса и, что еще важнее, узнаем, как они решают свои проблемы. Вот почему мне нравится читать сообщения в блогах, в которых компании объясняют, как они решают свои проблемы.

Особенно в нашей области нам нравится думать, что Google и StackOverflow могут ответить на все наши вопросы, но нам все равно нужно знать, какие вопросы задать. Уверен, что у вас уже была проблема, из-за которой вы не могли найти решение, потому что вы точно не знали, что происходит, и поэтому не знали, что именно нужно задавать.

Но если мне нужно было собрать весь этот пост в одном совете, это было бы:

Решайте проблемы.

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

Теперь настало время пойти туда и решить проблемы.