Переведено в Alconost Translations.
Недавно проект, над которым я работал, наконец запустился. Ладно, перезапустился. Речь о небольшом простеньком приложении для айфона Postography, которое позволяет рассылать бумажные открытки с картинками и текстом с вашего айфона. Отличный и, вроде бы, несложный проект, правда? Приложение, на создание которого не должно было уйти много времени.
К сожалению, мы не делали с нуля, а переделывали его. И компания, которая первой взялась за разработку (не будем называть ее здесь), серьезно поработала над серверной частью, но эпически провалила первую версию самого приложения. Ах, да: в конце концов оно в некотором смысле даже работало, невзирая на множество ошибок и внезапных сбоев. Но при этом его исходный код представлял из себя такую клоаку из глобальных переменных, плохо структурированного кода, хаков, мусорных команд и блокировок, что дописывать или редактировать его было почти невозможно без полного переписывания.
Такое случается гораздо чаще, чем хотелось бы считать. За сверкающими интерфейсами многих приложений скрыты лавкрафтовские архитектурные ужасы, бросающие вызов здравомыслию любого, кому довелось поддерживать их или добавлять новые возможности. Спросите разработчиков — у каждого из них найдется парочка страшных историй об этом.
Если ваше приложение из таких — работает, но неоптимально, не элегантно, плохо расширяется или масштабируется — значит, за вами уже солидный технический должок; и независимо от того, осознаете вы это или нет, у вас уже большие проблемы.
Я люблю использовать жилищную метафору: ваш дом может отлично выглядеть, комнаты в нем могут быть кофмортными и хорошо оформленными, однако стоять вся эта красота может на настолько плохом фундаменте, что случись у вас гость поплотнее, которому захочется сбежать по лестнице, — все рухнет. Дело может быть даже не в фундаменте, а в непригодной для строительства почве под ним, и тогда замена фундамента никак не поможет: придется строить дом заново в каком-нибудь другом месте.
Это случается даже с передовыми технологическими компаниями. Возьмите хотя бы RIM. Помните, они выпустили планшет без почтового клиента? Помните, как они тихо топтались на месте целую вечность, пока iOS и Android ушли вперед, оставив BlackBerry в кильватере? Их неудачи не были обусловлены выбором дизайна или сознательными решениями руководства. Они случились из-за огромного технического долга, на избавление от которого у компании ушли годы.
Как и денежный, технический долг — вполне нормальное явление до тех пор, пока а) он не становится слишком большим, и б) вы знаете о нем все. Конечно, часто приходится прибегать к компромиссам между, скажем, масштабируемостью и скоростью разработки. Когда приближается дедлайн и/или заканчивается финансирование, а задача представляется огромной, бывает, что и быстрый хак оказывается правильным выбором. Можно понять и то, что все разработчики предпочитают использовать знакомые или интересные для изучения инструменты, а вовсе не идеальные для выполнения работы.
Но чаще всего накопление технического долга ради краткосрочной выгоды — это ужасная ошибка. Как и любой долг, технический долг усугубляется со временем. Еще хуже то, что большинство нетехнических специалистов — то есть слишком много менеджеров, руководителей и учредителей — обычно недооценивают его опасность или вообще не понимают, что создают его, до тех пор, пока им не приходится месяцами работать лишь на устранение технического долга; а их конкуренты тем временем счастливо продолжают движение вперед. Именно это и произошло с RIM.
Так как же стартапам избежать этой незавидной судьбы?
Конечно же, критично важно нанимать правильных людей. Помогает также парное программирование c использованием модели «главный/ проверяющий», которую я особенно люблю. И мне всегда казалось, что технические оценки — хорошая идея: пускай несколько опытных специалистов потратят неделю на аудит вашего кода и архитектуры, один раз в самом начале разработки и еще раз где-то в середине процесса. Компания, на которую я работаю, проводила такое один или два раза, но, к сожалению, технические оценки пока не стали обычной практикой для отрасли.
Что можно сделать, если вы уже накопили серьезный технический долг? Прежде всего, вытащите голову из песка и признайте, что у вас есть большая проблема. Дальше — прекратите копать. Перестаньте добавлять новые возможности и приведите все к полустабильному состоянию, чтобы увидеть, что у вас есть и чего нет. Потом постарайтесь определить, можно ли не перестраивать ваш метафорический дом, а лишь заменить его фундамент (даже при том, что работавшие ранее вещи снова сломаются в ходе реконструкции, что всегда очень раздражает), или же придется бросить все и начать новое строительство. Каждое из этих решений может оказаться самым лучшим и быстрым.
Но больше всего прислушивайтесь к своим разработчикам. Если вы наняли правильных людей, то они хотят чистого, расширяемого, масштабируемого кода так же, как и вы. Было почти больно просматривать доставшийся нам исходный код Postography. Сейчас я чувствую себя так, будто мы провели операцию, которая не только спасла жизнь жертве страшной автомобильной аварии, но и дала ей возможность стать олимпийским атлетом. Никогда не поздно спасти ваше приложение, но чем раньше вы начнете — тем легче это сделать.
Автор: alconost
