Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

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

Читайте также:
  1. I. Некоторые аспекты современных опытов
  2. II. Культурные аспекты изменения социальной структуры
  3. Адами даму және адам өмірінің әр түрлі аспектілері
  4. Анализ возможностей информационной технологии «Текстовый редактор» в аспекте развития письменной речи и коррекции ее недостатков у школьников с нарушенным слухом
  5. Анализ миграционной ситуации: методологический аспект
  6. АНАЛИЗ НЕКОТОРЫХ АСПЕКТОВ ТЕЛЕФОННОГО КОНСУЛЬТИРОВАНИЯ
  7. Аспекти й різновиди демократії

Каждый из участников цикла разработки ПО должен быть досту­пен для контакта: желательно, чтобы все они работали в одном здании; в локальной сети должны быть доступны служебные, мо­бильные и домашние телефоны; необходимо согласовать часы (хотя бы 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 | Нарушение авторских прав



mybiblioteka.su - 2015-2024 год. (0.007 сек.)