Назначение 9: почему мы отказались от кода, на создание которого ушло 9 лет
Опубликовано: 2017-02-17Этот блог о том, почему и как мы смогли отказаться от кода 9-летней давности и начать думать по-новому.
Глава первая: Назначение в процессе
В период с 2004 по 2006 год мы разрабатывали веб-сайты на WordPress для индустрии здоровья и хорошего самочувствия. Практически для всех нужд существовал плагин WordPress, кроме плагина планирования. У нас было так много запросов на плагин для планирования, что мы не успевали!
Итак, мы написали свой сценарий . Скрипт, который позволил бы нам сэкономить время, не создавая один и тот же код снова и снова. Одна из первых проблем, с которой мы столкнулись, заключалась в том, что у каждой вертикали есть свои требования. Итак, мы создали правила планирования, чтобы обобщить наш сценарий для разных вертикалей.
Вскоре спрос на планирование увеличился, и Appointy впервые заработал в январе 2008 года с концепцией «Сделай сам».
К сожалению, в нашем стремлении угодить каждому клиенту, мы продолжали добавлять функции, и Appointy стал непосильным. А потом те же клиенты начали жаловаться. Мы поняли, что уходим от концепции «Сделай сам». Поэтому мы вернулись к чертежной доске с идеей снова сделать его простым, сохранив при этом функциональность.
Это стоило нам целого года. Но мы усвоили важный урок.
Appointy — это начальная компания (никогда не привлекавшая никаких внешних средств), и ей приходилось зарабатывать деньги на клиентах, чтобы выжить . Мы считаем, что лучший способ заработать деньги — сначала решить чью-то проблему, а затем запросить справедливую цену. Чем больше мы сможем помочь нашим клиентам, тем больше мы будем расти.
Мы начали улучшать наш процесс адаптации и поддержки. Но вскоре мы поняли, что каждый бизнес уникален по своей природе и нуждается в чем-то другом. Это просто означало, что нам нужно было не только увеличить нашу команду поддержки, но и привлечь больше программистов. Нам нужен был способ вертикального масштабирования во всех отделах.
Мы стали нанимать больше программистов. Через несколько месяцев, во время собрания по схватке, новый член команды поделился, что он счастлив, что то, что он написал, появилось на нашем производственном сайте. Для него это определенно было достижением. Однако я не был счастлив. Я понял, что в нашей установке что-то не так, если новым программистам требуются месяцы, чтобы стать продуктивными.
Пришло время выйти из комфорта и принять некоторые смелые решения. Мы просто не смогли бы масштабироваться так быстро, как хотели бы при таких темпах!
Глава 2: Трудное, но важное решение
На следующий день я поговорил с несколькими старшими ребятами и попытался разобраться в проблеме. Проблема сводилась к архитектуре, которую мы создали 9 лет назад. Технологии меняются каждый год, поэтому технически мы отстали почти на 9 лет .
Рекомендуется для вас:
Я не знал, как сказать своей команде изменить весь код, который они писали 9 лет. Я не хотел выглядеть сумасшедшим и решил сначала сделать решающий шаг сам. В конце концов, я сам когда-то был программистом (и довольно хорошим!

Я всегда записываю цель перед началом любой новой задачи. Итак, вот моя цель — создать модульную архитектуру с кривой обучения менее недели и разработать молниеносно быстрое приложение. Если Google может получить правильные результаты из триллионов строк менее чем за секунду, то почему не может Appointy?
Я наткнулся на термин RxJS на Angular.io. Несколько часов следил за темой, и мне очень понравилась идея потоковой передачи данных. Концепция была проста: стали бы вы смотреть видео на Youtube, если бы вам приходилось ждать 5 минут каждый раз, когда вы хотели посмотреть?
Я решил попробовать, но на самом деле я не мог сделать это сам. Мне понадобится помощь старших парней.
На следующий день я просто объяснил концепцию потоковой передачи своей команде и попытался вызвать интерес. В течение следующих нескольких дней я продолжал процесс, пока наши рок-звезды (теперь программисты намного лучше меня) не подхватили ритм. Первое семя перемен было посеяно .
За несколько дней мы смогли реализовать всю концепцию потоковой передачи в существующем коде Appointy. Как и ожидалось, он работал хорошо, но не отлично. Нам нужно было сделать больше.
Глава 3: Приостановка разворачивается
Осталось решить еще две проблемы
- Пользовательский интерфейс и пользовательский опыт (UX/UI).
- Скорость загрузки.
Прошло уже 1,5 месяца, а мы только набрались знаний . Пока никаких действий. Я не мог попросить старших парней поработать над UX/UI, и они бы знали, что мы пытаемся избавиться от старого кода, а я не знал, что тогда произошло бы.
Итак, я решил работать с одним из стажеров, которых мы наняли. У этого нового стажера был другой подход к программированию . Он хотел быть быстрым, быстрее всех. Он помог мне внедрить инструменты, чтобы я мог проверять изменения вживую и мгновенно давать ему обратную связь. Мы оба начали приходить рано, в 6 утра, и к тому времени, когда наш офис начинал работу, мы уже работали несколько часов. Новый продукт начал формироваться.
Через несколько дней я понял, что все работает отлично. Мы были на правильном пути, и пришло время поговорить со всей командой. Теперь у меня было некоторое доказательство концепции, подтверждающее, что 9 лет кода можно выбросить, но не без нашей команды рок-звезд.
Настал день. Мы показали новый пользовательский интерфейс и объяснили, что делать дальше. Наша команда рок-звезд начала верить, что этого можно достичь. Это как раз то, что было нужно.
Сейчас, спустя 4 месяца, наша первая версия находится на стадии тестирования.
Результат
- Мы можем сократить время загрузки «Области администратора» с 10 до 2 секунд. (Да, в 5 раз быстрее!!)
- Мы можем снизить нагрузку на наши серверы на 50%.
- Мы можем заставить новых программистов продуктивно работать в течение недели.
- Наконец-то у меня появилось время вести блог!
Что дальше?
- Первым шагом является портирование существующего программного обеспечения. Следующим шагом будет создание крайне необходимых функций (мы собираем запросы функций от наших клиентов, и наш список приоритетов готов).
- Готов наш API, который может использоваться нашей командой или внешними командами для интеграции различных приложений. Например, нам больше не потребуется больше недели, чтобы добавить новый платежный шлюз.
- У нас будет больше пропускной способности для связи с другими компаниями, которые могут повысить ценность вашего бизнеса. Мы уже связались с функцией «Забронировать через Google», чтобы помочь вам привлечь новых клиентов.
PS: За эти 4 месяца мы не только создали Appointy с нуля, но и успешно создали с нуля еще один продукт для планирования конференц-залов. Мы продали его за 130 тысяч долларов, даже не встретившись с покупателем лично.
[Это сообщение Немеша Сингха впервые появилось в официальном блоге и воспроизведено с его разрешения.]






