2020-09-09 10:42:46
12 шагов к лучшему коду.Джоэл Спольски известный IT-специалист, работавший на Microsoft Office, Trello, Stack Overflow, Glitch. В далеком 2000 году он опубликовал статью "The Joel Test: 12 Steps to Better Code".
Это трехминутный тест команды программистов о качестве и скорости их работы. 12 простых, но глубоких вопросов.
Если Вы и Ваша команда набирает 12 ответов "да" - это отлично, 11 - терпимо, но меньше 10 - ужасно. Топовые компании и топовые команды получают 12 баллов. Это делает их топовыми и создает разницу между качественными и популярными продуктами и остальными.
Ниже наш вольный перевод с некоторыми комментариями.
1. Используете ли вы систему контроля версий?
Совместная работа программистов становится трудозатратной и ненадежной без системы контроля версий (Version Control System - VCS). Без нее сложнее узнать кто и что делает, найти ошибки и сделать откат изменений, вызвавших баги. Плюсом к этому добавляется невозможность потерять весь код, т.к. VCS обычно распределенны.
2. Можете ли вы сделать билд за один шаг?
Чем меньше шагов, тем лучше. Меньше ошибок, больше скорость разработки, быстрее доставляется код конечным пользователям.
3. Делаете ли вы ежедневные билды?
Это нужно, чтобы проверить работоспособность проекта.
Я бы добавил сюда Continuous Integration (CI). Чем больше автоматизированных проверок и тестов запускается, тем качественнее получается продукт и быстрее находятся проблемы.
4. Если у вас список багов?
Невозможно запомнить все баги, которые нужно фиксить или с которыми необходимо смириться и предупредить пользователя.
5. Исправляете ли вы баги перед написанием нового кода?
Баги старого кода нужно исправлять перед написанием нового. Чем дольше ждать исправление бага, тем дороже оно по времени и деньгам. К тому же чем старше код, тем сложнее вспомнить о его проблемах.
Баги чинятся за нелинейное и непредсказуемое время - новый код пишется за почти предсказуемое время.
Расписание с большим количеством багов - непредсказуемое. Расписание с большим количеством нового кода - предсказуемое.
Поэтому если старые баги починены, то вы почти всегда готовы сделать релиз в нужное время.
6. Актуальное ли ваше расписание?
Программистам может быть неважно расписание, но бизнесу оно необходимо, чтобы планировать свою работу: сделать демо, запланировать старт продаж, начать маркетинговую компанию, и т.д.
Бонусом к этому, расписание позволяет решать какой функционал делать, а какой нет, чтобы успеть вовремя. Т.е. отделить важное от неважного.
7. Есть ли у вас спецификации?
Все согласны, что делать их хорошо, но вместо того, чтобы сначала сделать документ, описывающий решение, люди идут воплощать это решение в коде.
Если решение оказалось неправильным, то может быть очень тяжело его поменять. Но поменять решение в спецификации легче, которая представляет собой обычный текст с картинками, чем в уже реализованном коде.
Да и программистам стоит научиться писать не только код, но и выражать свои мысли текстом.
8. Спокойные ли условия работы программистов?
Людям, работающим головой, важно иметь тихое и приватное место для работы, которое поможет сохранить состояние потока. В него очень тяжело попасть и это занимает некоторое время, но выйти из него можно моментально из-за кого-нибудь "раздражения".
9. Используете ли вы лучшие инструменты, которые можно купить за деньги?
Лучшие инструменты делают программистов счастливее и в конечном счете продуктивнее.
Именно поэтому многие компании тратят большие деньги на технику и программы для разработки ПО.
10. Есть ли у вас тестировщики?
Нужно иметь 1 тестировщика на каждые 2-3 разработчика, чтобы не выпускать плохой код.
Джоел в этом плане олдскульный (статья написана в 2000 году), я в это не верю. Я верю в то, что большую часть своего кода должны тестировать сами разработчики. Подтверждение этому здесь.
11. Пишут ли код кандидаты во время собеседования?
Крутое резюме и ответ на сложные вопросы не всегда покажут навык кандидата. Но написание небольшого фрагмента кода это покажет.
1.2K views07:42
А
