Наша компания сейчас работает над вторым проектом для заказчика из Соединенных Штатов. Оба проекта — облачные SaaS-системы (B2B и B2C, соответственно). Основное их отличие для нашей компании заключается в том, что первый мы самостоятельно разрабатывали с нуля, а ко второму мы подключились как удаленная команда, чтобы улучшить и ускорить разработку. Об особенностях, различиях и некоторых выводах пойдет речь в этой статье.
Как я уже упомянул, первый проект мы создавали с нуля. У нас было только описание идеи будущего продукта, основные сценарии и некоторая техническая информация. Мы были вольны в выборе технологического стека для реализации этого продукта, и выбрали Django/Python + PostgreSQL + Redis + Celery.
С нашей стороны команда состояла из пяти человек: разработчики, QA-инженер, UI/UX-проектировщик. Первые продажи через этот продукт состоялись уже через четыре месяца после начала работы нашей команды.
Так как это был наш первый опыт работы с заказчиком из Соединенных Штатов, то очень важно было поддерживать эффективную коммуникацию. На самом деле, чего-то секретного или уникального здесь нет. Всё как обычно, проблема только в том, что пересечение нашего рабочего времени и рабочего времени заказчика достаточно малó. Начало нашего рабочего дня — это поздний вечер заказчика, а конец нашего рабочего дня — это начало рабочего дня заказчика. В пересечении этих временных промежутков мы старались проводить видео-звонки в Skype, чтобы обсудить какие-то возникающие вопросы.
В действительности, когда уже начался процесс разработки, то вопросов, которые можно и нужно активно обсуждать, достаточно мало. Обычно хватает электронной почты и Skype, а ответы на вопросы зачастую могут подождать. Другое дело — этап проектирования. Здесь вовлеченность заказчика должна быть максимальной, поэтому обеим сторонам приходится подстраиваться и проводить много времени в обсуждениях. Иногда мы начинали свой рабочий день раньше, или позднее его заканчивали.
Второй проект — противоположность первому. Для начала, этот продукт уже успешно работает с 2009 года и имеет более ста тысяч пользователей по всему миру. Так же, он имеет свой офис in-house разработки в США и реализован на другом технологическом стеке: Single Page Application, ASP.NET MVC NancyFX + AngularJS. Плюсом, мы подключились к существующей команде разработки, так что нам теперь нужно коммуницировать и координировать работу с техническим директором, разработчиками и DevOps-инженером со стороны заказчика.
...
Уникальная особенность второго проекта для нас в заключается в том, что мы участвуем в разработке уже существующего продукта с существующей командой. Это позволило нам посмотреть на то, как разрабатываются и поддерживаются IT-стартапы в Соединенных Штатах. Пока я выделил две основных отличительных особенности, которые мне особенно нравятся.
...
Особое отношение к безопасности кода
Нет, конечно, мы тоже к этому очень внимательно относимся и все проверяем, но лучше не допускать и гипотетических шансов к проявлению уязвимостей.
Мы столкнулись с этим при разработке компонента, который должен извлекать метаданные из исполняемых файлов Windows и Mac. Изначально наш разработчик создал решение, которое сохраняет загружаемый файл на диск, извлекает метаданные и удаляет файл с диска. Казалось бы, шансов запустить сохраненный файл нет, однако после обсуждений с разработчиками со стороны заказчика, было принято решение переписать этот компонент так, чтобы вся работа выполнялась в оперативной памяти без записи чего-либо на диск.
Наш разработчик переписал решение. Оно получилось гораздо сложнее, чем было, но исключало даже гипотетический шанс для запуска вредоносного кода.
Взять готовое решение (какую-то библиотеку, например) — это не всегда лучший из возможных вариантов. Хотя от коллег я достаточно часто слышал фразу "Зачем изобретать велосипед?" и другие подобные.
На самом деле, если библиотека поддерживается неактивно или небольшим количеством контрибьюторов, то в последствии она может стать издержкой, устранение которой может потребовать определенного времени и денег.
В качестве примера можно привести тот же компонент для получения метаданных из исполняемых файлов. Mac-приложения загружаются на сервер в виде zip-архива, в котором помимо самого приложения хранятся различные ресурсы и информационные файлы. В одном из таких файлов (info.plist) в немного странном XML-формате хранятся метаданные приложения. Задача — получить их.
В открытом доступе есть open-source библиотека, которая позволяет это сделать. Однако, мы пошли по другому пути и разработали свою собственную реализацию. Во-первых, так мы не засоряем проект не очень нужными зависимостями. Во-вторых, Apple постепенно вводит новый формат info.plist, поэтому если разработчики библиотеки не смогли или не успели бы вовремя адаптировать свое решение, мы оказались бы в неловкой ситуации.
Кроме всего прочего, разработчики из США гораздо внимательнее относятся к лицензиям используемых библиотек. Некоторые из решений не могут быть использованы ввиду каких-то ограничений лицензии. Российских же разработчиков обычно это не сильно беспокоит.
Конечно, у существующей команды есть проблемы, которые мы помогаем им устранить. Хотя казалось бы, продукт уже достаточно давно на рынке, имеет большую облачную инфраструктуру и команда у такого проекта должна состоять из супер-ниндзя-профессионалов. Это так, но нельзя быть лучшими во всем.
Например, у нас достаточно хорошая экспертиза в настройке процесса подготовки и выпуска релизов, а у наших коллег с этим были проблемы. Мы помогали им, в частности, с этим.
Мы начали покрывать код модульными тестами и активно проводить рефакторинг. Существующая команда писала тесты до нас, но на момент начала нашей работы почти все из них не работали, "падали" или были закомментированы. Кроме того, запуск модульных тестов не был встроен в процесс сборки и выкладки на тестовый сервер (Continuous Integration).
Изменению подвергся процесс ручного тестирования. Изначально было проведено регрессионное тестирование, в ходе которого проверили работу продукта на разных операционных системах, браузерах и устройствах, и обнаружили несколько неприятных багов.
Мы продолжаем работу над улучшением этого продукта и занимаемся разработкой нового функционала. На текущий момент с участием нашей команды было выпущено четыре полноценных релиза. Сотрудничество с коллегами из Соединенных Штатов оказалось очень полезным в плане обмена опытом, культуры разработки и поставки программного обеспечения и IT-продуктов.
Особое отношение к используемым библиотекам
Взять готовое решение (какую-то библиотеку, например) — это не всегда лучший из возможных вариантов. Хотя от коллег я достаточно часто слышал фразу "Зачем изобретать велосипед?" и другие подобные.
На самом деле, если библиотека поддерживается неактивно или небольшим количеством контрибьюторов, то в последствии она может стать издержкой, устранение которой может потребовать определенного времени и денег.
В качестве примера можно привести тот же компонент для получения метаданных из исполняемых файлов. Mac-приложения загружаются на сервер в виде zip-архива, в котором помимо самого приложения хранятся различные ресурсы и информационные файлы. В одном из таких файлов (info.plist) в немного странном XML-формате хранятся метаданные приложения. Задача — получить их.
В открытом доступе есть open-source библиотека, которая позволяет это сделать. Однако, мы пошли по другому пути и разработали свою собственную реализацию. Во-первых, так мы не засоряем проект не очень нужными зависимостями. Во-вторых, Apple постепенно вводит новый формат info.plist, поэтому если разработчики библиотеки не смогли или не успели бы вовремя адаптировать свое решение, мы оказались бы в неловкой ситуации.
Кроме всего прочего, разработчики из США гораздо внимательнее относятся к лицензиям используемых библиотек. Некоторые из решений не могут быть использованы ввиду каких-то ограничений лицензии. Российских же разработчиков обычно это не сильно беспокоит.
...
Конечно, у существующей команды есть проблемы, которые мы помогаем им устранить. Хотя казалось бы, продукт уже достаточно давно на рынке, имеет большую облачную инфраструктуру и команда у такого проекта должна состоять из супер-ниндзя-профессионалов. Это так, но нельзя быть лучшими во всем.
Например, у нас достаточно хорошая экспертиза в настройке процесса подготовки и выпуска релизов, а у наших коллег с этим были проблемы. Мы помогали им, в частности, с этим.
Мы начали покрывать код модульными тестами и активно проводить рефакторинг. Существующая команда писала тесты до нас, но на момент начала нашей работы почти все из них не работали, "падали" или были закомментированы. Кроме того, запуск модульных тестов не был встроен в процесс сборки и выкладки на тестовый сервер (Continuous Integration).
Изменению подвергся процесс ручного тестирования. Изначально было проведено регрессионное тестирование, в ходе которого проверили работу продукта на разных операционных системах, браузерах и устройствах, и обнаружили несколько неприятных багов.
Мы продолжаем работу над улучшением этого продукта и занимаемся разработкой нового функционала. На текущий момент с участием нашей команды было выпущено четыре полноценных релиза. Сотрудничество с коллегами из Соединенных Штатов оказалось очень полезным в плане обмена опытом, культуры разработки и поставки программного обеспечения и IT-продуктов.
Комментариев нет:
Отправить комментарий