пособие по выживанию

КРИС КАСПЕРСКИ

Спецвыпуск: Хакер, номер #071, стр. 071-012-4

С другой стороны, в мелких командах никакая исследовательская деятельность невозможна в принципе. Главное здесь — получить рабочий продукт в отведенные строки, не отвлекаясь на посторонние вопросы. Ты хочешь экспериментов, чувствуешь, что можешь значительно увеличить производительность и функционал кода, если сменишь парадигму программирования, библиотеку, компилятор и т. д. Тебе интересно посидеть с Кнутом, осваивая новые алгоритмы, чтобы в конечном счете выбрать самый эффективный из них, но... Команду это не интересует! Код работает — и это главное! Навряд ли оптимизация увеличит объемы продаж. Лучше выпустить еще один минимально работающий проект. А потом еще один и еще... Постепенно это гонка превращается в настоящий марафон, требующий только тех знаний, которые уже есть, и никак не способствующий творческому развитию.

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

В принципе, обладая достаточной напористостью (и авторитетом) можно «раскрутить» лидера команды на любой проект, убедив его, что все будет ОК. Это самая легкая часть, но потом приходится сложнее. Самые замечательные и элегантные (на бумаге) конструкции зачастую рассыпаются в прах при столкновении с реальностью. На поздней стадии нередко вскрываются непредвиденные трудности, которые без дополнительных (и весьма крупномасштабных) исследований никак не удается обойти. Проект затягивается, требуя все новых вложений, но бросить его, похоронив тысячи строк кода, жалко. Команда высаживается и нервничает, теряя время и деньги, а ты — авторитет.

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

[соображения о стиле программирования.]

Стиль программирования — весьма щекотливый вопрос. В одних командах имеется свод правил оформления листинга (учитывающий буквально все: от расстановки фигурных скобок до системы наименования переменных), в других — ничего подобного нет. Пиши как хочешь и на чем хочешь! У каждой практики есть свои плюсы и минусы. Даже плохой стандарт кодирования, поддерживаемый всеми участниками, лучше, чем его полное отсутствие. Команда на то и команда, чтобы работать совместно, попеременно заглядывая то в свои, то в чужие листинги. И, если каждый начнет следовать своим привычкам, образуется форменный балаган, в котором через некоторое время будет совершенно невозможно разобраться.