А. Некачественные и/или изменяющиеся спецификации

⇐ ПредыдущаяСтр 16 из 45Следующая ⇒

Об этом мы уже говорили.

Б. Личностные качества программиста

Такие, как халатность, невнимательность и лень.

В. Отсутствие опыта

Программист может просто не знать, как нужно сделать правильно.

Г. Пренебрежение стандартами кодирования

О стандартах чуть позже.

Д. Сложность системы

Современные интернет-проекты отличаются такой сложностью, что мозг простого смертного порой просто не в состоянии проанализировать все последствия создания/изменения/удаления кода и предугадать появление проблемы.

е. Баги в ПО третьих лиц,т.е. баги

• в операционных системах;

• в компайлерах (compiler — ПО для переведения (например, C++) кода в машинный язык и создания исполняемых файлов);

• в веб-серверах;

• в базах данных и др.

Цикл разработки ПО 89

Ж. Отсутствие юнит-тестирования,

х.е. тестирования кода самим программистом: "И вообще, почему я должен искать баги в своем коде, когда есть тестировщики?" (Поговорим о юнит-тестировании через минуту.)

З. Нереально короткие сроки для разработки

Об этом мы тоже скоро поговорим.

Возможности оздоровления кода и превентирования багов до передачи кода тестировщикам(иллюстрации последуют немедленно) включают:

1. Наличие требований к содержаниюспеков и следование правилам их изменения;

2. Возможность прямой, быстрой и эффективной коммуникации между программистами и программистами и продюсерами;

3. Инспекции кода;

4. Стандарты программирования;

5. Реальные сроки;

6. Доступность документации;

7. Требования к проведению юнит-тестирования(о котором мы поговорим уже через 30 секунд);

8. Реальные финансовые рычаги стимуляции написания эффективного и "чистого" кода;

9. Наличие понятий "качество" и "счастье пользователя" как основных составляющих корпоративной философии.

Подробности.

1. НАЛИЧИЕ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ СПЕКОВ
И СЛЕДОВАНИЕ ПРАВИЛАМ ИХ ИЗМЕНЕНИЯ

Оспеках мы уже говорили.

2. ВОЗМОЖНОСТЬ ПРЯМОЙ, БЫСТРОЙ И ЭФФЕКТИВНОЙ
КОММУНИКАЦИИ МЕЖДУ ПРОГРАММИСТАМИ

И ПРОГРАММИСТАМИ И ПРОДЮСЕРАМИ

Здесь есть следующие аспекты:

А. Психологические аспекты

Очень важно привить в культуру компании следующее правило: "Если к тебе обратились — помоги".

Тестирование Дот Ком. Часть 1

Пример

Программист приходит к продюсеру с просьбой объяснить некую часть спека. Продюсер говорит, что он сейчас слишком занят. "Давай завтра, добро?"

Очень часто после пары "давай завтра" программист что делает? Правильно! Он пишет код так, как его понимает, — без всякой гарантии, что сей код отразит требуемое.

Следующий аспект:

программист (как и все остальные участники цикла) никогда не должен стесняться спрашивать (хоть двести раз!) и подтверждать свое понимание е-мейлами типа: "Просто хотел уточнить, что я правильно понял, что пункт 12.2 такого-то спека говорит..." Если же программисту не отвечают, когда он подходит, прекрасно — нужно послать е-мейл и сохранить этот е-мейл, как и е-мейлы "Я хотел уточнить". Если снова не отвечают, программист должен идти к своему менеджеру и просить его принять меры. И это не стукачество, а деловая практика — business is business.

Следующий аспект:

Менеджмент должен регулярно устраивать так называемые Team Building Activities (мероприятия по сплочению коллектива) с той простой целью, чтобы между членами команды кроме профессиональных налаживались и человеческие контакты. Причем, как показывает опыт, совместный выезд для игры в пейнтбол раз в месяц гораздо эффективнее для сплочения коллектива, чем совместная проспиртовка мозгов во время пятничных застолий.

Б. Технический аспект

Каждый из участников цикла разработки ПО должен быть доступен для контакта: желательно, чтобы все они работали в одном здании; в локальной сети должны быть доступны служебные, мобильные и домашние телефоны; необходимо согласовать часы (хотя бы 4 часа в день), когда все (и тот, кто ушел в 6 часов вечера и в 3 утра) находятся в офисе.

3. ИНСПЕКЦИИ КОДА

У некоторых программистов есть такая концепция: "Если я пишу код, который могу понять только я, то меня не уволят".

Ну, во-первых, при желании можно уволить даже президента "ЮКОСа", во-вторых, такой подход к работе априори неправи-

Цикл разработки ПО

лен: в интернет-компаниях никто никого силком не держит, и если ты согласился работать на определенных условиях, то будь добр работать профессионально и добросовестно.

Если же компания не выполняет взятых на себя обязательств (например, по оплате), то мы просто ищем другую компанию — ведь никто никому не давал клятву верности.

Постановка мозгов

Компания держит каждого из нас до тех пор, пока мы ей нужны, и если какая-то конкретная позиция перестает быть необходимой для бизнеса, то человеку просто говорят: "Гуд бай" независимо от того, сколько у него

детей плачет по лавкам; котов мяукает по печкам.

Как поет Тимур Шаов: "Это бизнес, господа..."

Вместе с тем, если вы находите компанию с лучшими для себя условиями и, работая на старом месте, прошли интервью и получили письменное предложение о работе, то вы просто идете к своему менеджеру и говорите, что собрались уходить, но можете подумать о том, чтобы остаться, только если компания сделает для вас то-то и то-то, например повысит заработную плату.

Несмотря на то что бизнес есть бизнес, нужно оставаться профессионалом, даже если предложение о новой работе удивительно выгодно и искушение все бросить велико. Никогда не уходите из компании, не передав дела и не закончив старые проекты. Ведите себя профессионально !

После небольшого отступления продолжаем основную тему.

В-третьих, чтобы избежать подобных проблем, чреватых багами и трудностью их фиксирования (fix — починка, ремонт), в компании должны проходить инспекции кода(code inspection).

Это может быть еженедельное совещание, например, следующего формата: менеджер программистов распечатывает код любого из программистов, и последний в присутствии коллег рассказывает, что, как и почему. Будет ли программист писать код, понятный только ему, если на совещании его обязательно спросят: "Товарищ, а что это вы здесь написали?"

4. СТАНДАРТЫ ПРОГРАММИРОВАНИЯ

С пунктом 3 перекликается идея создания стандартов программирования.

92 Тестирование Дот Ком. Часть 1

Пример

Вспомним Вавилонскую башню, а вернее, тот момент строительства, когда все вдруг стали говорить на разных языках (множественность стандартов). Последствия печальны: проект был начисто заброшен, название кинокомедии "Some like it hot" перевели как "В джазе только девушки" и японские фанатки "Тагу" убеждены, что "Мальчигей" — это название места для романтических свиданий нетрадиционных девушек на Красной площади.

Такая же катавасия творится в компании, когда программисты вроде бы и используют тот же язык, например C++, но при написании кода каждый руководствуется своими привычками.

Пример

Допустим, что отсутствуют стандарты названия новых классов C++. S этом случае, если Саня любит называть свои классы в формате "CREDITCARD" (все заглавные и нижнее подчеркивание), а

Леха — "CreditCard" (заглавные только первые буквы каждого слова и слитное написание),

то, например, Леха, не зная о привычках Сани, но верный своим привычкам, помня лишь "Кредиткард" и желая обратиться к функции из CREDITCARD, в своем коде так и запишет: "CreditCard". В итоге код не будет работать, так как C++, ничего не знающий ни о Лехе, ни о Сане, ни о кредитных картах, думает о CREDITCARD и CreditCard как об абсолютно разных классах.

Стандарты могут включать:

• правила о комментариях;

• правила об именах таблиц в базе данных, классов, функций и различных видов переменных;

• правила о максимальной длине строки;

• прочее.

Документ со стандартами должен быть доступен на интранете.

Стандарты программирования — это неотъемлемая часть процесса, когда в компании работают два программиста и больше. Они по определению должны быть обязательны для всех.

5. РЕАЛЬНЫЕ СРОКИ

В стартапе изначально и по определению сроки на разработку нереальны, и приходится балансировать между

• "поспешишь — людей насмешишь" и

• необходимостью закончить кодирование в срок.

Цикл разработки ПО 93

Несмотря на то что стопроцентно действующих рецептов нет, вот хорошая идея для облегчения нелегкой жизни программистов:

после ознакомления со спеками программисты должны предоставить менеджменту примерные оценки (сметы) сроков для разработки кода, и исходя из этих смет менеджмент может, если нужно

• перераспределить нагрузку и

• посмотреть, имеет ли смысл убирать что-то из менее приоритетных функционалъностей ради того, чтобы чисто и тщательно написать остальной код.

Единственное утешение состоит в том, что, когда стартап как бизнес становится более зрелым, сроки и рабочие часы стабилизируются во многом потому, что менеджмент понимает, что лучше дать реальный срок (например, перенеся некоторые из спеков в следующие релизы), чем поступиться качеством.

6. ДОСТУПНОСТЬ ДОКУМЕНТАЦИИ

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

Несмотря на кажущуюся очевидность и легковесность этого момента, несоблюдение правила о доступности ВСЕХ документов на практике может принести много проблем.

7. ТРЕБОВАНИЯ

К ПРОВЕДЕНИЮ ЮНИТ-ТЕСТИРОВАНИЯ

Юнит-тестирование (unit testing) — это тестирование, производимое самим программистом. Здесь нужно подчеркнуть, что неправильный подход к введению юнит-тестирования вызовет справедливое раздражение программистов, так как за тестирование платят тестировщикам, а отсутствие требований к юнит-тестированию вообще увеличит стоимость багов.

94

Тестирование Дот Ком. Часть 1

Дата добавления: 2018-05-02; просмотров: 353; Мы поможем в написании вашей работы!
Поделиться с друзьями:

⇐ Предыдущая 11 12 13 14 151617 18 19 20 Следующая ⇒

Мы поможем в написании ваших работ!