Общая картина
From The Joel on Software Translation Project
Автор: Джоэл Спольски
Переводчик: Евгений Виговский
В оригинале статья называлась The Big Picture и была написана 21 января 2007
Рецензия на Dreaming in Code (Грезы о коде), Скотта Розенберга (Scott Rosenberg).
Глаза работают, используя механизм подкачки страниц. Они так хорошо с этим справляются, что вы даже не замечаете.
С высоким разрешением вы можете обозревать лишь небольшую зону, и то прямо посередине там большое слепое пятно, но вам все равно кажется, что вы обладаете панорамным обзором высокого разрешения. Почему? Потому что ваши глаза очень быстро двигаются, и в нормальных условиях они постоянно с радостью скачут по всему, чему бы вы не пожелали. А ваш разум создает целостную абстракцию, предоставляя вам иллюзию полного обзора, в то время как на самом деле у вас есть лишь небольшая зона обзора высокого разрешения, большая зона обзора крайне низкого разрешения и возможность подкачки всего, что вы хотите увидеть — столь быстрой, что вы ходите целый день, думая о том, что вся картинка целиком проецируется в маленький кинотеатр в вашем мозгу.
Это действительно очень полезно, многие вещи работают таким же образом. Ваши уши хорошо настраиваются на важные части бесед. Ваши пальцы могут добраться и дотронуться до всего чего им угодно, будь это отличный свитер из мериносовой шерсти или тоннели вашего носа, давая вам полную картину того, какое все это на ощупь. Когда вам снятся сны, ваш мозг задает все те же вопросы, которые он использует для опроса чувств (что это? Посмотри туда!) но ваши чувства временно отключены (в конце концов вы же спите), поэтому в ответ получает случайные ответы, из которых вы потом в голове складываете забавную историю, которая называется сном. А потом? когда вы утром пытаетесь пересказать сон своему парню, даже если он кажется совершенно, абсолютно реалистичным, вы внезапно осознаете, что "не знаете, что случилось на самом деле", так что остается только заткнуться. Если бы вы поспали еще пару минут, ваш мозг спросил бы у ваших чувств, что это за млекопитающее плавает с вами в розовых кущах и получил какой-то бредовый случайный ответ (утконос!), но вы проснулись, и до тех пор, пока вам не понадобилось пересказать историю вы даже не осознавали, что вам надо было знать, что там с вами было в розовых кущах, чтобы ваша история звучала логично для слушателя. Каковой она никогда не является. Так что пожалуйста, не рассказывайте мне о своих снах.
Один из неприятных побочных эффектов заключается в том, что ваш мозг по дурной привычке переоценивает то, насколько ясно он все понимает. Он всегда думает, что у него есть полная картина, даже когда у него ее нет.
Эта ловущка особенно опасна, когда дело касается разработки программ. У вас в голове есть масштабная картина всего того, что вы хотите сделать, и она кажется настолько ясной, что не возникает даже и мысли проектировании чего-либо. Вы просто можете погрузиться в работу и начать воплощать ваше видение.
Скажем, для примера, что ваше видение — это переделка старинного ДОСовского менеджера личной информации, который был очень-очень удачным, но совершенно недооцененным. Это кажется простым. Работа всех компонентов кажется настолько очевидной, что вы даже не пытаетесь ничего спроектировать… вы просто нанимаете кучу программистов и начинаете фигачить код.
В итоге вы сделали две ошибки.
Первая, вы стали жертвой старого трюка вашего мозга вселившего в вас чрезмерную самоуверенность. «О, да, мы отлично знаем, как это сделать! Нам все совершенно ясно. Не надо никаких спецификаций. Просто напишем код».
Вторая, вы наняли программистов до того как все спроектировали. Потому что, труднее чем пытаться проектировать софт — только пытаться проектировать его командой.
Не могу вам сказать сколько раз я бывал на собраниях хотя бы с одним или двумя программистами, пытающимися выяснить, как что-то должно работать, не приходя в итоге ни к чему. Поэтому я шел в свой кабинет, брал листок бумаги и выяснял. Каждый раз, когда мне приходилось взаимодействовать с другим человеком, я не мог как следует сконцентрироваться для того, чтобы спроектировать чертову функцию.
Что меня убивает, так это команды, у которых возникает дурная привычка созывать совещания каждый раз, как требуется выяснить, как что-то будет работать. Вы когда-нибудь пытались писать стихи на заседании какой-нибудь комиссии? Это как будто толпа жирных строителей пытается написать оперу, сидя на диване и смотря «Спасатели Малибу». Чем больше толстых строителей вы посадите на диван, тем меньше вероятность того, что вы получите от них оперу.
Хотя бы телек выключите!
Теперь, это было бы довольно нахально с моей стороны попробовать догадаться, что случилось с командой Chandler, и почему им потребовались миллионы долларов и годы работы, чтобы прийти к тому, что у них есть сейчас, а есть у них довольно бажное и неполноценное приложение – календарь, которое не очень впечатляет при сравнении его с другими 58-ю Web 2.0 календарями, вышедшими в прошлый год, каждый из которых был разработан двумя студентами в свободное время, при том что один из них на самом деле просто нарисовал зверюшку-талисман.
У Chandler даже и талисмана то нет!
Как я и говорил, я не могу нахально заявить, что знаю, что пошло не так. Может быть ничего. Может они чувствовали, что идут верным путем. Отличная новая книга Скотта Розенберга, которая должна была стать аналогом книги Soul of a New Machine для самого горячего стартапа десятилетия с открытым кодом, заканчивается крушением надежд. Скотт резко обрывает рассказ ввиду того, что Chandler 1.0 не собирался появиться в скором времени (и возможно потому, что Розенберг не мог рисковать, ведь к тому времени как книга вышла бы, мы уже возможно не использовали бы книги, впитывая вместо этого знания путем приема таблеток внутрь).
Но все равно, это отличный взгляд на тот особенный тип софтверного проекта, который не прекращает бешено крутить колесами, при этом оставаясь на месте, благодаря тому, что видение было грандиозным, а детали были немного неясными. Насколько я могу судить, исходное видение Chandler было близко к тому, чтобы стать «революционным». Я конечно не знаю насчет вас, но я не могу закодировать «революционность». Мне надо больше деталей для написания кода. Как только спецификации начинают описывать продукт прилагательными («это будет невероятно круто») вместо конкретных описаний («это будут панели из полированного алюминия, а все иконки будут немного отражаться, как будто их поместили на пианино»), знайте, вы в беде.
Единственными конкретными идеями проекта насколько я могу судить по книге Розенберга были: «один-к-одному», «без хранилищ» и «интерпретация дат на естественном языке». Возможно это недостаток книги, но начальные спецификации определенно выглядели крайне размыто.
Концепция «один-к-одному» была raison-d’être для Chandler… зачем вам покупать сервер Microsoft Exchange для координирования расписаний? Оказалось, что синхронизация «один-к-одному» была слишком сложна, ну или что-то типа того, и эту функцию убрали. Теперь есть сервер под названием Cosmo.
Под концепцией «без хранилищ» подразумевалось, что вместо того, чтобы иметь одно хранилище для почты, другое для календаря, а третье для заметок, будет существовать одно унифицированное хранилище для всего.
Как только вы начинаете задавать вопросы относительно концепции «без хранилищ», вы понимаете, что она не будет работать. Вы складываете почту в календарь? Куда? В тот день, когда она была получена? И что, теперь у меня крайне важная пятничная встреча с акционерами засыпана двумя сотнями рекламных писем про Виагру?
В конечном счете, концепция «без хранилищ» переросла в идею печатей, так, например, вы можете «поставить печать» с электронным адресом на любой документ или заметку или элемент календаря, и тут же этот элемент будет кому-то отправлен по электронной почте. Угадайте, что же случилось? Эта функция присутствовала в Microsoft Office в течении последних лет десяти. Она наконец-то была убрана из Office 2007, потому что всем было все равно. Существует слишком много простых способов отправлять разные вещи по электронной почте.
В самом деле, я думаю что идея «без хранилищ» более всего понравится архитектурным астронавтам, людям которые смотрят на подклассы и видят абстрактные базовые классы, и которые любят перемещать функциональность из подкласса в базовый класс, не имея на это никаких других причин кроме архитектурной эстетики. Как правило, это ужасный способ разработки пользовательского интерфейса. То, что позволяет вашим пользователям понять модель поведения вашей программы — это метафоры. Когда вы заставляете вещи выглядеть и вести себя так же, как ведут себя вещи в реальном мире, пользователям будет легче понять, как пользоваться программой, а приложение будет более простым в использовании. Когда вы пытаетесь скомбинировать две абсолютно непохожие вещи (письма и напоминания) в одно целое в пользовательском интерфейсе, страдает простота использования, потому что больше не существует применимой метафоры из реального мира.
Еще одна клёвая штука о которой Капор продолжал рассказывать всем, кто хотел слушать, заключалась в том, что расписание позволит вам вбить, например, «следующий вторник», и как по волшебству вы получите напоминание на следующий вторник. Это чертовски модно, но любой более-менее пристойный органайзер последнего десятилетия это делает. Не революционно.
Команда Chandler так же переоценила объем помощи, который они смогут получить от добровольцев. Open source работает не совсем так. Он хорош в реализации содранных функций, потому что есть спецификация, от которой можно отталкиваться – реализация того, что ты копируешь. Он очень хорош в тех случаях, когда просто чешутся руки добавить что-то необходимое. Мне нужен параметр командной строки для поддержки EBCDIC, так что я добавляю его и отправляю код. А когда у вас только и есть что приложение, которое ничего не делает, ни у кого руки не зачешутся. Потому что никто им не пользуется. Так что у вас нет добровольцев. Почти все в команде разработчиков Chandler получали зарплату.
Я снова должен сильно извиниться перед командой Chandler если вдруг Розенберг упустил суть, или дал совершенно неверное представление о том, что действительно сдерживало прогресс, и моя необъективность — желание объяснить такие неудачи недостатками проектирования — тут хорошо видна.
Не смотря на вышесказанное, из проекта вышло кое-что хорошее — восхитительная книга в стиле Soul of a New Machine или Showstopper о проекте по разработке ПО, который так и не смог во что-то вылиться. Крайне рекомендую.
