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

Это Сан-Франциско.

Каждое утро, прогуливаясь 5 кварталов от BART до офиса, я встречаю около 500 человек. 490 из них занимаются технологиями — с гордостью носят футболки и наклейки Adverbly и Verbify — в то время как остальные 10 человек просят лишнюю мелочь или кричат ​​на пожарные гидранты. В этом городе мы имеем огромное влияние на мир, когда дело доходит до определения того, что делает технологические компании великими, и что «лучшие практики» действительно значат для мира. Вопреки тому, что может сказать вам миллениал, библиотека NPM, которая выйдет на следующей неделе и является форком другой, о которой никто не слышал, не делает наши компании великими. Безопасность, надежность, масштабируемость, безопасность (да, это так важно) и способность оценивать и анализировать новые технологии по мере их появления — вот что делает наши компании великими.

Медленный и стабильный

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

Я провел первое десятилетие или около того своей карьеры, создавая веб-сайты под Linux с помощью MySQL и PHP. Да, я знаю, «PHP отстой, лолз»… потерпите меня здесь. Это было до того, как веб-сайты стали называть «веб-приложениями», когда JavaScript использовался для подключения кнопок и выполнения вызовов AJAX и не составлял 99% кодовой базы; когда разработчики знали, что такое JScript и почему Internet Explorer был такой проблемой. Эти веб-сайты не часто ломались, были быстрыми, простыми для понимания в исходном коде и приносили прибыль. Как карьерный разработчик, я был доволен, и мои клиенты были счастливы.

PHP за свою жизнь приобрел довольно плохую репутацию по нескольким причинам; самое большое, на мой взгляд, это то, что он позволяет людям, которые не знают, что они делают, создавать веб-сайты, которые, кажется, работают как положено, но ужасно небезопасны за кулисами. Язык чрезвычайно прощающий и не применяет никаких передовых практик, если вы явно не скажете ему об этом, что приводит к тому, что новички подавляют ошибки и пишут плагины для Wordpress, Joomla и Drupal, которые будут ссылаться на глобальные переменные и ломать другие плагины, создавая склонность к SQL-инъекциям. запросы и использовать их в качестве руководств по блогам, а также хранить пароли в виде простого текста, потому что, если я не знаю, что меня взломали, то никакого вреда не будет, верно? Невероятно раздражающая вещь.

Быстро и рискованно

В 2012 году я переключился на NodeJS в качестве основного языка разработки на стороне сервера, потому что мне нравилась модульность и сообщество, которое, казалось, действительно стремилось придерживаться передового опыта. Я уже был очень доволен ванильным JS, а также был сыт по горло тем, что CodeIgniter был новой модой для всех и их братьев, которые хотели веб-сайт PHP. Вы когда-нибудь пробовали запускать PHPUnit на CI-контроллере? Конечно, есть; у кого нет? Это отстой, верно? *Дай пять.

Несмотря на все замечательные вещи, которые сообщества Node и JavaScript приносят на стол, я думаю, что понятие «мы должны использовать новейшие разработки» должно остыть. Я думаю, что реальная сила открытого исходного кода заключается в том, чтобы показать массам намерения нашего программного обеспечения, чтобы можно было применить интуицию толпы, тем самым защищая и оптимизируя указанные намерения. Я не думаю, что преимущество открытого исходного кода в том, что мы можем выбирать из 70 библиотек, в которых только первая буква слова прописная и которые не обновлялись в течение года.

Новое !== Лучшее

На стороне клиента, когда впервые появились одностраничные приложения, у нас были Backbone, затем Spine, затем Ember, затем Angular, затем Durandal и так далее. Сможете ли вы создать надежный SPA в Backbone в 2016 году? Ага. Так почему же я чувствую осуждение, когда говорю людям, что еще не обновился до Angular 2 и все еще использую 1.5? Знаете ли вы, сколько раз Angular 2 менялся с момента его создания? Если бы я создал сайт на Angular 2, это было бы приложение с самым большим количеством ошибок и рефакторингом, чтобы не отставать от изменений в моей карьере. Для какой пользы? Где выигрыш? Право на хвастовство? Чем это поможет клиенту? Через 6 месяцев или год он, безусловно, будет выглядеть совсем по-другому, будет немного более испеченным и исправленным и немного более готовым к рассмотрению — но до тех пор я окажу своим клиентам медвежью услугу, даже предложив его как опция. Он находится в списке около 5000 других проектов с открытым исходным кодом, о которых я никогда не слышал и которые вышли вчера, и которые я не буду предлагать. Не поймите меня неправильно — я на 1000 % за разнообразие открытого исходного кода. Это мешает другой Microsoft. Я просто думаю, что нам нужно перестать относиться ко всем новым сценариям как к черным поясам и позволить им заработать свои звания. Слепое доверие к сценариям — вот как к нам подкрадываются такие эксплойты, как Heartbleed.

Библиотеки !== Фреймворки

Когда вышел ReactJS, Facebook очень четко заявил, что это только слой представления. Например, вы можете довольно успешно заменить свои директивы AngularJS компонентами React, и ваше приложение Ng будет работать нормально… и, по иронии судьбы, не быстрее. Когда я увидел презентацию разработчиков FB о том, почему они создали React (чтобы решить проблему со значком непрочитанного сообщения), я был законно удивлен. «Односторонний поток данных», — говорили они. По их словам, решен «хаос с двусторонней привязкой». Фундаментальное непонимание MVC начинающими разработчиками привело к созданию совершенно новой библиотеки, которая была принята всем грёбаным сообществом как решение проблемы, которой не было ни у кого больше, потому что «Facebook». Итак, хорошо. все сайты PHP, Perl, JSP, ASP и ColdFusion, которые существовали более десяти лет назад и использовали именно этот поток сохраняемости данных, не учитывались?

Но… но Фейсбук! В порядке. Тогда почему компании продолжают сравнивать AngularJS с React, как будто это одно и то же? Без Flux или Redux, помогающих React, вы не можете начать сравнивать их — поэтому для компаний, которые рассматривают React вместо Angular только потому, что это новая популярность, видно явное непонимание движущей технологии, лежащей в основе имя, которое действительно разочаровывает в этой отрасли, где «модные словечки» продают товары. Angular теперь имеет возможность односторонней привязки данных. Ваш ход, Facebook.

Нет, правда. Библиотеки !== Фреймворки

Несколько лет назад был представлен Knockout.js. Я работал над проектом для клиента, чья внутренняя команда разработчиков требовала, чтобы мы использовали его, потому что быстрый поиск в Google одним из их разработчиков показал, что KO — это новая мода. Ну, во-первых, KO — это просто библиотека привязки. Здесь нет ни маршрутизации, ни слоя HTTP-сервиса API, ни модульности с собственным внедрением зависимостей; поэтому эти функции приходилось выбирать из других библиотек и сшивать вместе, чтобы сформировать наш стек — это не всегда плохо, но для этого проекта это было довольно хаотично. Единственное, что делает KnockoutJS, — это связывание, и это ужасно. Любая переменная, которую вы хотите сделать наблюдаемой, становится функцией, поэтому foo("bar") действует как установщик, поэтому foo() затем вернуть «бар». Хорошо, некрасиво, но хорошо, пока вы не захотите отправить эти данные в вызове API — вы когда-нибудь пробовали JSON.stringify()объект, содержащий функции? Конечно, у вас есть, и вы знаете, что это не работает! *Дай пять! Таким образом, KO предлагает функции ko.toJS() и ko.fromJS() для преобразования значений в наблюдаемые и обратно, которые необходимо вызывать перед отправкой данных в API. Да, отслеживать все это было кошмаром. Почему это вообще набрало обороты? Потому что он был новым. А миллениалы любят новое дерьмо.

MongoDB не для данных, которые вам нужны

Однажды мой бывший технический директор сказал мне, когда я предположил, что у нас есть графовая модель и что мы должны использовать Neo4j: Инвесторы любят MongoDB — теперь они слышали это имя, и оно горячо и сексуально. Я ответил: Зачем нам использовать управляемую документами базу данных для графовой модели только потому, что инвесторы считают Mongo привлекательным? Я проиграл этот спор благодаря некоторым пьяным инвесторам, и, к сожалению, мои опасения оправдались через 8 или 9 месяцев, когда запросы в Mongo стали невероятно сложными и неэффективными, и весь проект был закрыт, что привело к тому, что несколько человек потеряли работу.

Lamborghini тоже сексуальны, но в Baja 500 они не справятся. Нам нужно выбрать правильный инструмент для работы — тот, который имеет смысл, поддерживается и в который активно вносят свой вклад, и который доказал свою эффективность. Я не думаю, что мы — как компании — должны быть частью демографической группы, которая испытывает боль релиз-кандидата. Я утверждаю, что в сообществе есть много разработчиков (включая меня), которые возятся с новыми выпусками в свободное от исследований и разработок время и предлагают отзывы и запросы на вытягивание, чтобы помочь стабилизировать библиотеки, чтобы мы могли в конечном итоге использовать их в работе.

Исключения?

Было бы упущением, если бы я имел в виду, что «все новые библиотеки плохие». Новые библиотеки, которые конкурируют с другими библиотеками за продвижение бренда, — это одно. Новые библиотеки, которые решают законные проблемы, — это другое. Возьмем, к примеру, RamdaJS. В отличие от перехода на служебную библиотеку Underscore-›Lodash, все сошли с ума, потому что мы все получили 0,5 мс вычислительной мощности, Ramda решает реальные проблемы в JavaScript: в основном проблемы с мутациями и контролем области действия. Ramda никогда не мутирует объекты и всегда возвращает измененные копии того, что вы ему даете. Все функции в библиотеке каррируются, что означает, что арность действительно имеет значение. Ramda берет концепции функционального программирования из Scheme и Haskell и делает их доступными в JavaScript, что решает СТОЛЬКО ПРОБЛЕМ! Таким образом, на момент написания этой статьи версия 0.21.0 является обязательной для моих приложений. К сожалению, такие фреймворки, как Angular и Express, зависящие от мутаций, не учитывают потери ссылок, поэтому используйте их с некоторым планированием в этих сценариях. Если вы не хотите верить мне на слово или вам просто очень нравится Lodash, загляните в ветку «fp», которая предлагает каррирование и композицию.

TL;DR

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

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