Выбрось это и начни с нуля
Вы когда-нибудь создавали доказательство концепции за один день, которое вы все еще пытаетесь выпустить шесть месяцев спустя? Ты не одинок.
На протяжении многих лет мне посчастливилось участвовать в ряде хакатонов. Идея всегда одна и та же - собрать кучу умных людей в одной комнате и провести один день (или выходные, если вам действительно нравится), создавая что-то новое.
Такой энтузиазм и оптимизм - вот чем мы живем как разработчики. Имея ограниченное время и четкий набор целей, мы добиваемся более заметного прогресса за один день, чем обычно достигаем за неделю.
Почему? Потому что на хакатонах скорость разработки ставится выше всего остального.
Хакатоны = Скорость?
Ограниченные временные рамки хакатона вынуждают нас свести проект к наиболее важным функциям. Это усиление менталитета стартапа - то есть, если вы не можете доказать свою концепцию за один день, она не увенчается успехом.
Имея в руках нашу мини-дорожную карту, мы добиваемся поразительных результатов за очень короткое время. Это часто приводит к ошибочному предположению, что мы можем создавать программное обеспечение быстрее, просто собирая его воедино на хакатоне.
Если можно, я хотел бы развенчать этот миф.
Десять лет назад (почти сегодня), на моем первом хакатоне, я помогал воплотить в жизнь новый проект. Собралась вся команда - разработчики программного обеспечения, маркетологи, дизайнеры и все, кто мог писать код, брать в руки телефон или тестировать программное обеспечение в процессе его разработки.
На этом этапе мы хотели доказать, что концепция жизнеспособна как с технической, так и с деловой точки зрения. Большое внимание уделялось удобству работы пользователей, но не чистому коду, тестированию или масштабируемости.
Имея всего восемь часов, чтобы написать проект с нуля, мы, естественно, срезали углы. Каждая функция требует времени, и вы должны расставить приоритеты для этих функций в зависимости от времени, которое у вас есть.
Это стандартно для любого проекта, но особенно важно во время хакатона. Какая польза от приложения, которое может обрабатывать 10 000 одновременных пользователей, если вы ожидаете при запуске всего несколько десятков? Зачем сосредотачиваться на интернационализации, если ваш первый выпуск будет только для одного региона?
Итак, мы подошли к концу дня и получили рабочее доказательство концепции с небольшим количеством дыма и зеркал, чтобы демонстрация выглядела немного более законченной, чем она была на самом деле.
С точки зрения пользователя проект выглядел готовым к работе, поэтому мы решили завершить его на следующей неделе. Заинтересованность заинтересованных сторон была высока, и мы были уверены, что к концу месяца проект будет запущен.
Он так и не вышел в эфир. Мы потратили еще пару дней, пытаясь преодолеть финишную черту, но обнаружили, что нам еще очень далеко. Интерес заинтересованных сторон упал до такой степени, что они не смогли оправдать время, необходимое для завершения проекта.
Проект прекратился, потому что мы в первую очередь сосредоточились на низко висящих фруктах и наиболее заметных предметах. Вы когда-нибудь слышали о принципе 80/20? На выполнение 80 процентов работы уходит 20 процентов времени.
Это звучит здорово, пока вы не поймете, что оставшиеся 20 процентов работы займут 80 процентов вашего времени. Это смертельный удар для многих проектов хакатонов, потому что в конце первого дня вы думаете, что почти на финише.
Если бы до завершения потребовалось еще четыре дня, мой первый проект на Хакатоне, вероятно, был бы успешным. Но в большинстве подобных случаев правило 80/20 действительно следует называть правилом 99,5 / 0,5.
Давайте перечислим некоторые вещи, которые могут нам понадобиться, но которые мы редко рассматриваем при проверке правильности концепции.
Ремонтопригодность
Обычно это первое, чем мы жертвуем ради скорости разработки.
Все жестко запрограммировать. Не беспокойтесь о разделении забот. Скопируйте и вставьте код в свое приложение, а не создавайте повторно используемые классы. Вы можете все исправить позже, верно?
Автоматизированное тестирование
Чтобы написать надлежащие тесты, нужно время. Принято (почти) повсеместно, что автоматизированные тесты ускоряют разработку в долгосрочной перспективе, но только самые стойкие сторонники тестирования могут возразить, что они приносят краткосрочные выгоды.
Если у вас есть всего восемь часов, чтобы написать доказательство концепции, тесты - это роскошь, которой у вас нет.
Автоматическое развертывание
Подобно тестированию, автоматическое развертывание - это преимущество, которое вы пожинаете со временем. Это такие вещи, которые я настраиваю один раз для проекта, а потом забываю.
Следовательно, когда я начинаю новый проект, мне приходится заново учиться тому, как я создавал последний. Я потрудился сделать это для подтверждения концепции? Черт возьми, я просто копирую и вставляю файлы на сервер вручную, как маггл.
Масштабируемость
Предполагая, что я даже дошел до развертывания на сервере, масштабируемость не является проблемой для подтверждения концепции, если только PoC не определяет, как масштабировать. Мне, вероятно, не нужно даже масштабироваться, кроме демонстрации приложения на моем ноутбуке.
Конфигурация и настройка
У большинства приложений есть пользователи, и обычно у этих пользователей есть предпочтения относительно того, как они хотят работать.
Помните знаменитую цитату Генри Форда?
«Вы можете выбрать любой цвет, только если он черный».
Примените это к теме настройки программного обеспечения, если вы хотите создать что-то быстро.
Устойчивость
Это одна из тех вещей, которые вам не понадобятся до того момента, когда вы это сделаете. Вы можете срезать углы на хакатоне, не выполняя регулярное резервное копирование базы данных, но они вам чертовски нужны, прежде чем вы начнете работать.
После хакатона
Итак, вы создали PoC. В зависимости от того, насколько он хорош, это может означать Proof of Concept или Piece of Crap.
Вы создали что-то, похожее на готовую программу, потому что именно так вы впечатляете заинтересованных лиц, которые позволяют вам провести день в проекте хакатона.
И потому что нет смысла иметь масштабируемую, протестированную, автоматически развертывающуюся стопку ничего. Лучше иметь кучу чего-нибудь и добавить это позже.
За исключением того, что добавление этого материала не выглядит гламурным или видимым. Ваши заинтересованные стороны могут не набраться энтузиазма, чтобы поддержать ваши усилия. Им нужен результат сейчас, поэтому они просят вас «произвести» то, что вы уже создали.
Как трудно это может быть? Черт, я попадаю в эту ловушку как опытный разработчик, поэтому я не виню нетехнических сторон в совершении той же ошибки.
Предполагая, что вы можете создать свой PoC, есть ряд причин, по которым вам не следует этого делать.
Жертвенная архитектура
Лучшее, что вы можете сделать с доказательством концепции, - это выбросить его и начать заново. Вы доказали, что концепция работает, так что давайте сделаем это правильно.
Не создавайте свое приложение на слабом фундаменте. Это похоже на создание пробной концепции автомобиля из картона, а затем попытку установить туда двигатель.
Однажды я создал интерфейс в стиле проводника Windows для управления статическими активами в системе управления контентом. Это было хорошо.
Спустя пару лет я построил почти идентичный проект для другой компании. Этот был лучше, потому что я научился с первой попытки. Если бы я построил его снова сейчас, я уверен, что это были бы световые годы вперед.
Я не предлагаю вам продолжать изобретать велосипед, просто вы признаете, что ваша первая попытка может оказаться не самой лучшей работой.
Если вы попытаетесь создать свое ошибочное доказательство концепции, вы лишите себя возможности переоценить и пересмотреть решения, основанные на новом понимании.
Если вы хотите узнать больше о жертвенной архитектуре, вы могли бы сделать намного хуже, чем прочитать Мнение Мартина Фаулера по этому поводу.
Ожидания
Поскольку большинство прототипов подразумевают определенную ловкость рук, вы можете впасть в извиняющееся мышление, в котором сомневаетесь в своей способности выполнять поставленные задачи. Почему проект не продвигается? Почему качество такое низкое?
Ожидается ловкость рук при создании прототипа - не извиняйтесь за это и честно скажите, что еще предстоит сделать. Управляйте ожиданиями и не зацикливайтесь на поддержке проекта, который не готов к работе в прайм-тайм.
Если вы искажаете правду, чтобы проект казался завершенным, вы накажете свое будущее, установив ожидания выше, чем они должны быть.
Как интерфейсный разработчик меня часто хвалят за изменение шрифта кнопки, чем внутреннего разработчика за реализацию сквозной безопасности для всего приложения. Это сложно, необходимо и невидимо для пользователя.
Проблема в том, что если PoC выглядит завершенным, пользователь подумает, что это так. Вы, наверное, уже сделали внешний вид потрясающе, чтобы PoC выглядел хорошо, но он просто маскирует липкую ленту, скрепляющую все это за кулисами.
Планирование и выбор
Иногда ваше доказательство концепции написано с использованием имеющихся у вас языков и фреймворков. Это не всегда означает, что это правильный выбор.
Иногда язык или структура не имеют большого значения. Java против C #, React против Angular - есть много очевидных моментов принятия решений, которые, вероятно, не повлияют на успех или провал вашего проекта, учитывая, что варианты имеют аналогичные возможности.
Однако иногда ваш выбор оказывает фундаментальное влияние на конечный результат. Вы всегда должны находить время, чтобы переоценить свой выбор, прежде чем вы решите «произвести» свою PoC.
Однажды я построил доказательство концепции системы, которой требовалась динамическая структура данных. Я решил создать его с использованием SQL Server, поскольку это была единственная технология баз данных, которую я знал тогда.
Базы данных NoSQL начали набирать популярность, и когда проверка концепции была закончена, мне следовало переоценить и написать систему с использованием MongoDB.
Вместо этого я «произвел» свой PoC и в итоге получил систему, которая была медленной и сложной в обслуживании. Шесть месяцев спустя я все равно переписал его с помощью MongoDB.
Помните: PoC не всегда бывает успешным. Вот почему мы их пишем - в моем случае PoC не удалось с технологической точки зрения - он доказал, что реляционная база данных не подходит для моего случая использования.
Когда ваша PoC подходит к концу, остановитесь и подумайте. Подходите к проекту так, как будто вы начинаете с нуля, и выбирайте подходящие технологии, а не те, которые есть у вас под рукой.
Заключение
Я могу вспомнить множество других проектов, над которыми я работал, которые выиграли бы от мышления жертвенной архитектуры. Вы, вероятно, сами работали над некоторыми из них - я знаю множество людей, которые жаждут возможности просто подметать стол и начать все заново.
Это не значит, что вам следует - быть честным с самим собой относительно прилагаемых усилий и помнить, что это не выбор по принципу «все или ничего». Вы можете переписать одни части системы, а другие оставить как есть. Но вам нужно будет сбалансировать стабильность, развитие функций и ремонтопригодность.
Важно остерегаться предположения, что вы можете или должны что-то производить.
Иногда лучше договориться, будете ли вы переписывать PoC, прежде чем писать его. В противном случае вы можете просто отполировать какашку.
