Акция «Шаг навстречу» с 1 по 30 апреля
Не проходите мимо! Студия «Koritsa» в очередной раз идет навстречу клиентам...
На протяжении всего апреля специальное предложение: при заказе любого сайта «под ключ» - мы проводим бесплатную внутреннюю оптимизацию сайта для продвижения в поисковых системах.

Также продолжает действовать акция «Большой босс»: при заказе сайта на сумму от 999$ - мы предоставляем скидку в 10% от стоимости заказа.
-10 %
от 999$
Не теряйте времени! Звоните прямо сейчас +38 095 136-61-16. До завершения акции осталось: 5 дн. 13 ч. 43 мин. и 44 сек.
Студия дизайна и рекламы Koritsa
Информационные материалы → Разное

Тест Джоэла. Часть Вторая.



3. Выполняете ли вы ежедневные билды?
При использовании контроля исходного кода иногда какой-нибудь программист случайно делает вставку, которая нарушает нормальных ход сборки. Например, он добавляет новый исходный файл, и все прекрасно компилирует на своей машине, но при этом забывает добавить исходный файл в ре-позиторий кода. Заблокировав свою машину, он идет домой, забывчивый и счастливый. Однако после этого все остальные не могут работать, поэтому они также идут домой (правда в гораздо худшем настроении).
Нарушение хода сборки настолько - вещь настолько рас­пространенная и неприятная, что стоит делать ежедневные билды, чтобы ни один сбой не прошел незамеченным. В больших командах хороший способ сразу исправить нарушения состоит в том, чтобы делать ежедневные билды каждый день после полудня, скажем, во время ланча. Каждый программист до ланча выполняет столько изменений, сколько ему заблагорассудится. Когда они все уходят на ланч, выполняется билд. Если все прошло хорошо, то это прекрасно! Каждый получает последнюю версию и продолжает работать. Если же произошел сбой, вы исправляете ошибки, но при этом каждый программист может продолжать работать с утренней, ненарушенной рабочей версией.
У нас, в команде разработчиков Excel, было правило, согласно которому каждый, кто нарушил компоновку, в качестве "наказания" должен был следить за компоновкой, пока ее не нарушит кто-то другой. Это был хороший стимул не нарушать ее и хороший способ пропустить каждого программиста через процесс компоновки, чтобы все знали, как он выполняется.
4. Используете ли вы базу данных ошибок?
Меня не волнует, что вы скажете. Если вы разрабатываете код, даже в команде из одного человека, то без упорядоченной базы данных, в которой указаны все известные ошибки, обнаруженные в коде, поставляемый вами код будет низкого качества. Многие программисты думают, что смогут удержать список ошибок у себя в голове. Чушь. Я сразу не могу помнить больше двух-трех ошибок, а на следующее утро или в горячке поставки даже они забываются. Вам абсолютно необходимо официально регистрировать ошибки.
Базы данных ошибок могут быть сложными или простыми. В минимально полезной базе данных по каждой ошибке должны быть представлены следующие данные.
• Действия, выполняемые для воспроизведения ошибки.
• Ожидаемое поведение.
• Наблюдаемое (вызванное ошибкой) поведение.
• Кому поручено исправить.
• Исправлена ошибка или нет.
Если единственным препятствием к регистрации ошибок является сложность соответствующего программного обеспечения, то всего лишь заведите простую таблицу из пяти столбцов с таким нужными полями и начинайте ее использовать.