Ваш код подскажет вам решения, которые дешевы и легки. Замечайте, когда появляется более простой путь. Разумеется, функция, которую легко сделать, может быть не в точности такой, какую вы себе представляли вначале – ну и что? Если она работает достаточно хорошо и оставляет вам больше времени на другие дела – оставьте ее.
Не беспокойтесь о дизайне; если вы прислушиваетесь к своему коду, хороший дизайн появится сам... Прислушивайтесь к техническому персоналу. Если сотрудники жалуются на то, как трудно вносить изменения — отнеситесь к этому серьезно и дайте им достаточное количество времени на исправления.
Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше.
Разберитесь с долгами
Расплачивайтесь по долгам вашего кода и дизайна
Мы обычно говорим о долгах в денежном выражении, но долги могут принимать и другие формы. Вы можете быстро обрасти долгами кода и дизайна.
Наваяли блок кода, который функционален, но все еще неопрятен — вот вы и набрали долгов. Набросали дизайн по принципу «и так сойдет» — ваши долги выросли опять.
Время от времени так поступать можно. Часто такая техника помогает поскорее довести проект в стиле Get Real до конца. Но все равно нужно признать эти долги и рано или поздно расплатиться с ними — вычистить неопрятный код, переделать ту страницу, которая была сделана так себе.
Точно так же, как вы откладываете часть дохода, чтобы заплатить налоги, регулярно выделяйте время на то, чтобы расплатиться с долгами по коду и дизайну. Если этого не делать, придется платить проценты (исправлять кривой код), вместо того, чтобы платить основную сумму (и двигаться вперед).
Открытые двери
Выпустите данные в мир через RSS, API и т.п.
Не пытайтесь запереть ваших клиентов. Позвольте им получить принадлежащую им информацию когда они хотят и как они хотят. Для этого вам придется отказаться от идеи запечатать данные. Выпустите их. Дайте людям доступ к их информации через RSS. Обеспечьте API, позволяющие другим разработчикам подсоединяться к вашей программе. Поступая так, вы облегчаете жизнь клиентам и расширяете возможности своей программы.
Раньше к RSS-фидам относились как к хорошему способу следить за обновлениями блогов и новостных сайтов. Но у них есть и другие сильные стороны. Они также позволяют клиентам быть в курсе изменяющегося контента приложения без того, чтобы постоянно в него входить. С фидами Basecamp пользователи могут ввести адрес в новостную ленту и быть в курсе того, что делается с проектом: сообщения, списки задач, этапы — без того, чтобы постоянно проверять все это на сайте.
API позволяют разработчикам создавать добавки к вашим продуктам — которые, в свою очередь, могут оказаться неоценимыми. Например, Backpack предоставляет API, которыми Chipt Productions воспользовался для построения программы Mac os x Dashboard. Программа позволяет добавлять и редактировать напоминания, списки и другое на рабочем столе. Клиенты с большим одобрением оценили эту программу, многие даже сказали, что благодаря ей они стали пользователями Backpack.
Вот еще примеры компаний, выпускающих данные наружу и получающих в результате эффект бумеранга:
Google Maps API положило начало интересной тенденции смешанных сайтов, когда люди получают информацию из других источников (например, объявления о квартирах) и наносят их на карту.
Linkrolls предлагает клиентам способ получить новейшие закладки del.icio.us, показанные на их сайтах.
Flickr предоставляет другим продавцам доступ к своим коммерческим API, так что клиенты могут покупать фотоальбомы, запасные хранилища данных для dvd, плакаты и марки. «Цель — открыть все по максимуму и дать вам наибольшее разнообразие выбора того, что вы можете сделать со своими фотографиями», — говорит Стюарт Баттерфилд из Flickr.
Когда компания 37signals выпустила Backpack, мое первое впечатление было...э-э.
Так что, когда Chipt Productions выпустили программку для Backpack для Tiger — и невозможно было ее не попробовать — я посмотрел на Backpack во второй раз. Результат? Совсем другое дело.
Сейчас, когда мне приходит в голову новая идея, я запускаю программку, печатаю, отправляю сообщение — готово. По электронной почте приходит нечто, что я хочу посмотреть? Запускаю программку, печатаю, отправляю — готово. Эта программка установлена — на каждом компьютере Mac, который я использую. И благодаря тому, что программка сетевая — не нужно заботиться о контроле версий или синхронизации — можно просто вводить информацию, не задумываясь, куда она пойдет или как получить к ней доступ позднее.
Слова
В функциональной спецификации нет ни грамма функциональности
Не составляйте функциональных спецификаций
Эти черновые документы обычно не имеют почти ничего общего с конечным продуктом. И вот почему:
Функциональные спецификации — это фантазии
Они не отражают реальности. Приложение не является реальностью до тех пор, пока строители не начнут его строить, дизайнеры — оформлять, люди — использовать. Спецификации — это только слова на бумаге.
Функциональные спецификации как средство умиротворения
Они для того, чтобы каждый почувствовал себя вовлеченным и счастливым. Приятное чувство, но не такое уж полезное. Спецификации никогда не говорят о принятии неприятных решений и не открывают истинных затрат — а это как раз то, что нужно для построения хорошего приложения.
Функциональные спецификации создают лишь иллюзию соглашения
Какое-то количество людей, согласных с текстом — это не есть соглашение. Каждый может читать тот же самый текст и думать о разном. Это безусловно всплывет позже, когда станут говорить: «Обождите, это не то, что я подумал», «Что? Да это же не так, как мы описали», «Да, это именно так, и мы все согласились с этим, тут даже есть ваша подпись». Вы знаете, как это обычно бывает.
Функциональные спецификации заставляют вас принимать наиболее важные решения именно тогда, когда у вас меньше всего информации