Часть 1 из серии, состоящей из нескольких частей, в ходе которой мы работаем над обновлением консоли задач. Ознакомьтесь с нашей методологией и ключевыми примечаниями, как мы решили на лучшей платформе JavaScript для ключевого компонента нашего продукта.
Решение проблем лежит в основе того, что делает сотрудников Supahands. Мы никогда не соглашаемся делать что-то только потому, что «так делалось всегда».
Вместо этого команда постоянно вводит новшества и выясняет, как работать быстрее и лучше.
Так же, как и Supahands Workplace, Task Console родилась из этого - из чувства безотлагательности быть более эффективным и точным с точки зрения работы, которую мы делаем для клиентов.
Но прежде чем мы начнем говорить о том, из чего будет состоять последняя консоль задач, давайте сначала уменьшим масштаб и оценим, какой была консоль задач раньше.
Как запускалась консоль задач
2 года назад, когда Супахандс впервые начал работать с предприятиями, а не с частными лицами, большая часть работы проводилась через Google Таблицы.
Это не было идеальным решением, но оно соответствовало требованиям, которые у нас были в то время - платформа для совместной работы, которая позволяла нескольким SupaAgents работать над одним и тем же проектом, в то время как специальный консультант по бизнес-решениям вручную выполняет проверку качества перед отправкой его обратно клиенту.
Google Таблицы отлично работали для 50-часовых проектов. Но когда через год количество проектов стало увеличиваться в размерах, мы поняли, что нам нужно создать собственную платформу.
Ведь к тому моменту мы уже работали над разными типами проектов. И мы знали, какие функции нам нужны.
Итак, первая итерация Task Console была запущена в 2017 году и протестирована с одним из наших крупных проектов проверки данных на то время. Он не выглядел изощренным, но выполнял свою работу.
Что еще более важно, это позволило нам увеличить производительность в 3 раза.
Использование Task Console показало более многообещающие результаты, и мы реализовали ее потенциал как платформы, которую можно было бы использовать для более крупных проектов. К этому моменту инструмент управления данными Task Console уже прошел через различные проекты с разными рабочими процессами.
Поэтому мы начали сосредоточиваться на добавлении дополнительных функций, таких как инструмент аннотации изображений, и дополнительных функций безопасности и качества для проектов, которые мы выполняем.
Обновление начинается
По мере роста доступности платформы нам нужно было уделять больше внимания ее пользователям. Итак, мы вошли в 2018 год, сосредоточившись на обновлении важнейшего компонента консоли задач - Launchpad - с целью повышения ее производительности и удобства использования.
Панель запуска - ключевая часть всей системы консоли задач, поскольку она используется для настройки и мониторинга инфраструктуры каждого проекта.
Чтобы получить разные точки зрения и найти решение, которое будет работать лучше всего, продукт, технология и дизайн участвуют в процессе принятия решения о том, какую среду JavaScript использовать.
Поиск подходящего фреймворка может оказаться непростым делом. Их так много, и у каждого есть свои плюсы и минусы.
Поскольку у нас было четкое представление о том, чего мы хотим достичь, мы сузили выбор до Angular, Vue, Ember и React.
Затем были сформированы микрокоманды, которым была определена основа для исследования с учетом ключевой цели. Мы также должны были учитывать вероятную возможность того, насколько сложно будет нанять людей, которые уже были бы знакомы со структурой, которую мы выбираем в конце.
Примечание. Наше окончательное решение не основано на том, какие рамки, по нашему мнению, превыше всего. Это что-то уникальное для каждой организации и того, что они стремятся создать. Но мы надеемся, что это руководство, с нашей точки зрения, даст вам представление о том, что выбрать для вашего следующего начинания.
Угловой
Angular был и остается очень популярным фреймворком. Он был разработан и до сих пор поддерживается инженерами Google, но мы решили не обращать внимания на компании, стоящие за каждым фреймворком, и больше сосредоточиться на том, соответствует ли он нашим требованиям.
Инженеры Angular Стивен Фуин и Игорь Минар также объявили, что будет обеспечена долгосрочная поддержка фреймворка по мере его дальнейшего развития и выпуска новых выпусков.
Но со всеми его функциями это также означало, что кривая обучения части существующей команды в Supahands для ознакомления с ней будет очень крутой.
Это повлияет на время нашего производства - ситуация, которая не была идеальной, учитывая траекторию роста, на которую мы выходили в начале этого года.
Сообщество Angular также медленно сокращалось, несмотря на их попытки удержаться на лидирующей позиции среди других JavaScript-фреймворков.
Затем это замедлит рост размера команды, поскольку мы будем искать новых сотрудников в команде, которые уже были с ней знакомы.
Vue
Несмотря на то, что он относительно невелик по сравнению с другими в нашем списке, Vue уже догоняет своих предшественников. Мы видели в нем карманную ракету - маленькую, быструю и мощную одновременно.
Тот факт, что его используют крупные китайские компании, такие как Alibaba и Sina Weibo, свидетельствует о том, насколько быстро он работает, несмотря на свой размер.
Как и Angular, у него была хорошая и исчерпывающая документация. Но преимущество Vue перед Angular состояло в том, что кому-то было очень легко научиться, если он знал основы JavaScript и HTML.
Многие ресурсы, с которыми мы столкнулись в процессе исследования, думали, что Vue не хватает поддержки, которую мы получили бы от других более крупных фреймворков, просто потому, что он не поддерживается крупной организацией, но нас это не беспокоило.
Хотя мы действительно сталкивались с обсуждениями отсутствия поддержки Vue из-за языковых барьеров, мы не осознали этого в ходе наших собственных исследований.
Мы обнаружили, что английский по-прежнему является основным языком сообщества Vue, несмотря на то, что он был создан китайскими разработчиками.
Но по сравнению с другими фреймворками сообщество относительно невелико. Это вызовет проблемы с наймом, поскольку это означает, что найти кого-то, кто сможет подобрать Vue, будет сложнее. Таким образом, это влияет на наши планы по быстрому масштабированию в 2018 году.
Ember
Ember был разработан для больших и сложных приложений с учетом удобства обслуживания. Благодаря принудительному дизайну он способен обрабатывать большие объемы объектов, моделей и данных.
Кроме того, он создан опытными разработчиками серверной части, которые ценят условность выше конфигурации, что делает его отличным выбором для сложных проектов.
Хотя Ember - это полнофункциональный и чрезвычайно надежный фреймворк, он может оказаться слишком надежным для того, что нам нужно для Launchpad.
Несмотря на то, что мы хотели значительно улучшить скорость и производительность проекта, наши требования были очень простыми.
Несмотря на доступную для Ember документацию, это один из самых сложных фреймворков для освоения. И это не та структура, которая пользуется популярностью в регионе, где мы работаем, поэтому нам сложно нанять кого-то с нужным опытом.
Реагировать
React можно приписать улучшению подхода Facebook к разработке. На момент своего выпуска он был революционным, делая веб-страницы очень динамичными и очень отзывчивыми.
Это также платформа со средой, которая меняется так быстро и часто, что разработчикам нужно быстро адаптироваться, если они хотят не отставать.
Но из-за его популярности среди разработчиков обучающих ресурсов предостаточно, и его все же легче освоить по сравнению с Ember. Это также означало, что найм разработчика, знакомого с React, также будет намного проще.
Команду также привлекла гибкость React с точки зрения его архитектуры и тестирования, и мы обнаружили, что он пользуется наибольшей поддержкой сообщества JavaScript из трех других фреймворков.
С точки зрения документации, хотя React не был нашим фаворитом, он нам все равно очень понравился, поскольку он был кратким и достаточно всеобъемлющим, чтобы любой новый член команды мог его усвоить.
Мы хотели, чтобы консоль задач могла беспрепятственно взаимодействовать с Workplace и обрабатывать даже более крупные проекты. Консоль задач должна быть быстрой и масштабируемой. Но ему также нужна была команда для поддержки, которая могла бы работать так же быстро.
Помня об этих требованиях, мы остановились на React из-за простоты его обучения, его поддержки и способности масштабировать продукт так, как мы хотели.
Далее о консоли задач
Так что же дальше с консолью Supahands Task Console? Наши рабочие процессы для различных проектов становятся все длиннее, и для этого нужна такая же надежная архитектура, чтобы поддерживать их все. Итак, мы с нетерпением ждем возможности очень быстро представить новые функции в Task Console.
Мы всегда хотели использовать консоль задач, которая помогает нам принимать больше решений на основе данных. С новой прочной конструкцией это скоро станет реальностью.
Но мы оставим это раскрытие на потом;)
Мы определенно не говорим, что React - лучший JavaScript-фреймворк для всех - это полностью зависит от ваших потребностей, от того, как вы хотите их достичь, от возможностей вашей команды в настоящее время и от того, в каком направлении вы ожидаете.
