97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф
К счастью, вы читаете эти советы потому, что действительно любите код. Вам это интересно. Это ваше увлечение. Получайте удовольствие от программирования. Радуйтесь, написав код для решения сложной задачи. Пишите программы, которыми можно гордиться.
Ваши заказчики имеют в виду не то, что говорят
Нэйт Джексон
Я еще не встречал заказчика, который не был бы рад возможности рассказать мне, что ему нужно — обычно до мельчайших подробностей. Проблема в том, что заказчики не всегда рассказывают всю правду. В целом заказчики не лгут, но они говорят на своем языке заказчиков, а не на языке разработчиков. У них свой словарь и свой контекст. Они опускают важные детали. Они говорят так, будто вы тоже проработали в их компании лет двадцать. А осложняется это все тем, что на самом деле заказчики часто сами не знают, что им нужно! У одних есть понимание общей картины, но они редко в состоянии толково выразить свое представление. У других общее представление может быть менее ярким, но они знают, чего им не нужно. Так как же можно разработать программный проект для того, кто не способен правдиво рассказать, что именно ему нужно? Выход достаточно прост. Нужно больше взаимодействовать с заказчиком.
Начинайте задавать своим заказчикам вопросы как можно раньше, и задавайте вопросы чаще. Не стоит повторять их же словами то, что они сказали о своих пожеланиях. Помните: они имели в виду не то, что сказали вам. Я часто провожу такую проверку: в разговоре с заказчиком заменяю термины заказчика своими собственными и наблюдаю за его реакцией. Вы не поверите, как часто термин заказчик имеет смысл, совершенно отличный от термина клиент. Тем не менее человек, который объясняет вам, что он хочет видеть в программном продукте, считает эти слова взаимозаменяемыми и уверен, что вы понимаете, какой свой статус он имеет в виду в конкретный момент. А вас это дезориентирует, и качество вашей программы страдает.
Обсуждайте рабочие темы со своими заказчиками бесчисленное количество раз до тех пор, пока не придете к выводу, что вам действительно понятно, что им требуется. Попробуйте вместе с ними переформулировать задачу два-три раза. Обсуждайте с ними то, что происходит непосредственно перед выполнением задачи, и то, что следует за выполнением задачи, чтобы лучше понять контекст. Если есть возможность, обсудите ту же тему с разными людьми в разное время. Рассказы почти всегда будут разными, что выявит отдельные, но связанные факты. Рассказывая об одном и том же, два человека часто противоречат друг другу. Лучше всего разобраться с этими расхождениями, прежде чем приступать к сверхсложной задаче разработки.
Используйте в беседах наглядные средства. Это могут быть такие простые вещи, как доска во время совещания или простой макет на стадии проектирования, либо такие сложные, как действующий прототип. Общеизвестно, что использование наглядных средств во время обсуждения помогает удержать внимание и закрепить информацию в памяти. Пользуйтесь этим обстоятельством, чтобы обеспечить успех своего проекта.
В прежнюю эпоху своей жизни мне довелось поработать «мультимедийным программистом» в команде, выпускавшей гламурные продукты. Одна наша заказчица очень подробно описала, как она представляет себе внешний вид проекта. Цветовая схема, обсуждавшаяся на проектных совещаниях, предполагала проведение презентации на черном фоне. Мы думали, что все оговорено. Целые команды дизайнеров принялись выдавать сотни многослойных графических файлов. Уйму времени мы убили на формирование конечного продукта. В тот день, когда мы показали клиентке плоды своего труда, нас ждала ошеломительная новость. Увидев продукт и цвет фона, она произнесла: «Когда я говорила „черный“, я имела в виду „белый“». Как видите, «черное» не всегда значит «черное».
Авторы
Алан Гриффитс (Alan Griffiths)
Алан Гриффитс прошел через многие модные поветрия в процессах разработки, технологиях и языках программирования. За эти годы он создал работоспособные программы и процессы разработки для многих организаций, печатался в ряде журналов, выступал на конференциях и подружился со многими людьми. Твердо убежденный в том, что здравый смысл — редкий и ценный рыночный товар, Алан сейчас работает независимым консультантом в собственной компании Octopull Limited.
«Не полагайтесь на “автоматические чудеса”», стр. 78
Алекс Миллер (Alex Miller)
Алекс Миллер — технический руководитель и инженер в Terracotta, Inc., специализирующейся на разработке решений кластеризации с открытым исходным кодом на Java. До Terracotta Алекс работал в BEA Systems над линейкой продуктов AquaLogic и был главным архитектором в MetaMatrix. В сферу его интересов попадают Java, конкурентные вычисления, распределенные системы, языки запросов и проектирование программного обеспечения.
Алекс с удовольствием ведет свой блог http://tech.puredanger.com. Вместе с другими разработчиками Terracotta он написал выпущенное в 2008 году «The Definitive Guide to Terracotta» (Полное руководство по Terracotta), Apress. Алекс часто выступает на встречах пользователей и конференциях и является одним из основателей конференции Strange Loop в Сент-Льюисе (http://thestrangeloop.com).
«Сначала скажите “да”», стр. 174
Аллан Келли (Allan Kelly)
Аллан Келли — профессионал в области разработки программного обеспечения, но сейчас работает в роли менеджера команды разработки. Он помогает командам разработчиков повышать эффективность своего труда и внедрять методы гибкого программирования. Аллан работает в Лондоне, предлагает мелким и крупным компаниям услуги по обучению, коучингу и консультированию.
Аллан часто публикуется в журналах, появляется на конференциях и является соавтором «Changing Software Development: Learning to Be Agile» (John Wiley & Sons). У Келли степень бакалавра по информатике и MBA по администрированию. В настоящее время он пишет книгу о шаблонах бизнес-стратегий для компаний, выпускающих программное обеспечение. Подробнее узнать о нем можно на сайте http://www.allankelly.net.
«Прежде чем пенять на других, проверь собственный код», стр. 38
«Две ошибки могут гасить одна другую (и тогда их трудно исправлять)», стр. 192
Андерс Норас (Anders Norås)
Андерс Норас — закаленный разработчик программного обеспечения и оратор. «Энтерпрайзность» EJB подтолкнула его к Microsoft.NET в 2002 году. Он быстро прославился в сообществе Microsoft, поскольку опыт работы с Java дал ему хорошую фору. В 2006 он восстановил свои отношения с бывшей любовью — Java, и сегодня он — полиглот, отбирающий лучшие решения обеих платформ для создания более качественных программ. Андерс — основатель проекта Quaere и участник нескольких проектов с открытым
