Технический Долг Вас Разорит. Если Ты Позволишь, Конечно

Переведено компанией локализации Алконост .

Недавно проект, над которым я работал, наконец-то был запущен.

Хорошо, перезапустил.

Мы говорим о небольшом простом приложении для iPhone. Постография , который позволяет отправлять бумажные открытки с изображениями и текстом с вашего iPhone. Отличный и, казалось бы, простой проект, не правда ли? Приложение, создание которого не должно было занять много времени.

К сожалению, Мы Его не сделали с нуля, а переделали.

А компания, которая первой взялась за разработку (назвать ее здесь не будем), проделала серьезную работу над серверной частью, но эпично провалила первую версию самого приложения.

О да: в конце концов, в некотором смысле, это даже сработало, несмотря на множество ошибок и внезапных сбоев.

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

Это происходит гораздо чаще, чем нам хотелось бы думать.

За блестящими интерфейсами многих приложений скрываются архитектурные ужасы в духе Лавкрафта, которые бросают вызов здравомыслию любого, кто их поддерживает или добавляет новые функции.

Спросите разработчиков — у каждого из них найдется парочка страшилок по этому поводу.

Если ваше приложение относится к числу таких — оно работает, но не оптимально, не элегантно, плохо расширяется или масштабируется — то у вас уже есть прочный технический долг ; и осознаете ли вы это или нет, у вас уже большие неприятности.

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

Это случается даже с передовыми технологическими компаниями.

Возьмем, к примеру, компанию RIM. Помните, когда выпустили планшет без почтового клиента? Помните, как они веками тихо топтались на месте, в то время как iOS и Android продвигались вперед, оставляя BlackBerry позади? Их неудачи не были связаны с выбором дизайна или сознательными управленческими решениями.

Они произошли из-за огромного технического долга, на избавление от которого компании потребовались годы.

Как и денежный долг, технический долг совершенно нормален, если: а) он не становится слишком большим и б) вы знаете о нем все.

Конечно, часто приходится идти на компромисс между, скажем, масштабируемостью и скоростью разработки.

Когда приближается крайний срок и/или заканчивается финансирование, а задача кажется огромной, иногда быстрый хак оказывается правильным выбором.

Также понятно, что все разработчики предпочитают использовать знакомые или интересные для изучения инструменты, а не идеальные для выполнения работы.

Но чаще всего накопление технического долга ради краткосрочной выгоды является ужасной ошибкой.

Как и любой долг, технический долг со временем увеличивается.

Хуже всего то, что большинство нетехнических людей — то есть слишком много менеджеров, руководителей и основателей — обычно недооценивают его опасности или даже не осознают, что создают его, пока им не придется работать месяцами только для устранения технического долга; а их конкуренты тем временем радостно продолжают двигаться вперед. Именно это и произошло с RIM. Так как же стартапам избежать этой незавидной участи? Конечно, найм правильных людей имеет решающее значение.

Тоже помогает парное программирование используя модель " главный инспектор ", что мне особенно нравится.

И я всегда считал, что технические оценки — это хорошая идея: попросите нескольких опытных людей провести неделю за аудитом вашего кода и архитектуры, один раз в самом начале разработки, а затем где-то в середине разработки.

Компания, в которой я работаю, делала это один или два раза, но, к сожалению, технические оценки еще не стали обычной отраслевой практикой.

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

Дальше хватит копать.

Прекратите добавлять новые функции и приведите все в полустабильное состояние, чтобы увидеть, что у вас есть, а чего нет. Затем попытайтесь определить, сможете ли вы не перестраивать свой метафорический дом, а просто заменить его фундамент (даже несмотря на то, что то, что раньше работало, при реконструкции снова сломается, что всегда очень раздражает), или же вам придется отказаться от всего и начать новое строительство.

Каждое из этих решений может оказаться лучшим и самым быстрым.

Но больше всего слушайте своих разработчиков.

Если вы наняли нужных людей, они так же, как и вы, хотят иметь чистый, расширяемый и масштабируемый код. Было почти больно просматривать исходный код Postography, который нам дали.

Сейчас у меня такое чувство, будто мы провели операцию, которая не только спасла жизнь жертве страшной автокатастрофы, но и дала ей возможность стать олимпийской спортсменкой.

Сохранить приложение никогда не поздно, но чем раньше вы начнете, тем проще это будет. О переводчике Статью перевел Alconost. Алконост помолвлен локализация приложений, игр и сайтов на 60 языках.

Нативные переводчики, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов продающих, имиджевых, рекламных, образовательных, тизеров, объяснителей, трейлеров для Google Play и App Store. Более подробная информация: https://alconost.com Теги: #стартапы #развитие #ИТ-финансы #технический долг #перевод #alconost