Читайте также:
|
Каждый из участников цикла разработки ПО должен быть доступен для контакта: желательно, чтобы все они работали в одном здании; в локальной сети должны быть доступны служебные, мобильные и домашние телефоны; необходимо согласовать часы (хотя бы 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. ДОСТУПНОСТЬ ДОКУМЕНТАЦИИ
ВСЕ документы, относящиеся к разработке ПО, включая спеки, процедуру изменения спека, стандарты программирования, тест-комплекты, и документы, о которых мы будем говорить в дальнейшем, должны быть доступны в локальной сети, и их расположение должно быть максимально оптимизировано для удобства и быстроты поиска. Все должно быть сделано для того, чтобы заинтересованный сотрудник быстро нашел нужный документ, а не тратил свое время и время своих коллег на долгие поиски.
Несмотря на кажущуюся очевидность и легковесность этого момента, несоблюдение правила о доступности ВСЕХ документов на практике может принести много проблем.
ТРЕБОВАНИЯ
К ПРОВЕДЕНИЮ ЮНИТ-ТЕСТИРОВАНИЯ
Юнит-тестирование (unit testing) — это тестирование, производимое самим программистом. Здесь нужно подчеркнуть, что неправильный подход к введению юнит-тестирования вызовет справедливое раздражение программистов, так как за тестирование платят тестировщикам, а отсутствие требований к юнит-тестированию вообще увеличит стоимость багов.
Тестирование Дот Ком. Часть 1
Дата добавления: 2015-12-07; просмотров: 100 | Нарушение авторских прав