Disclamer
Источник: https://www.joelonsoftware.com. Эта статья - вольный перевод без претензии на достоверность.
В переводе не стремился сохранить формулировки автора, а использовал перефразирования, которые использую в своей речи сам.
Тест содержит 12 быстрых вопросов, и каждый ответ “Да” дает один балл. Градация результата такова: 12 баллов - идеально, 11 - это приемлемо, 10 и меньше - у команды есть проблемы. Ну а если команда набрала только лишь 2-3, то у нее действительно серьезные проблемы.
Даже если эта команда разрабатывает самый классый продукт, она не должна забывать о качестве и процессах. Если команда стремится к тому, чтобы набирать 12 баллов в тесте Джоела, то она сможет доставлять фичи на прод и онбордить новичков гораздо быстрее, влияние человеческого фактора и шанс появления серьезных багов будет меньше.
Тест Джоела
1. Используете ли систему контроля версий?
Даже можно не обсуждать этот вопрос. Если не используют, то можно поинтересоваться, какой постфикс в имени zip-архива с исходным кодом на данный момент.
Стоит спросить про GitFlow, который команда применяет. Если она не применяет установленный какой-то, то стоит расспросить подробно, ведь команда может и не знать, что пользуется одним из них.
2. Можете ли вы сделать билд (в прод) в один шаг?
Если не могут, то во сколько шагов? Что мешает автоматизировать процесс до нажатия одной кнопки / запуска одного скрипта.
3. Делаете ли ежедневные билды?
Иными словами, используют ли CI-инструменты. Если нет, то почему нет.
4. Ведете ли систему баг-трекинга?
Софт пишут люди, и люди ошибаются. Это значит, что в софте были, есть и будут “таиться” баги, какие бы классные спецы его ни писали.
хорошая система баг-трекинга хранит следующее:
- Шаги для воспроизведения
- Ожидаемое поведение
- Наблюдаемое поведение (которое отличается от ожидаемого)
- На кого назначен баг (кто над ним работает)
- Будет ли баг пофикшен или нет
5. Фиксите ли вы баги перед тем, как начать писать новый код?
В идеальном мире разработчики фиксят баги до того, как эти баги попадают в продакшн. Однако мир не идеален, и разработчики чинят не всё и не всегда. Спроси, кто в команде решает, какие баги нужно фиксить и какие остаются техническим долгом.
Если команда не заморачивается над багами, то что можно сказать о такой команде?
6. Есть ли у вас план работ?
Разработчики должны знать, куда движется проект. Ведь только так они смогут проработать такую архитектуру сейчас, чтобы в нее “безболезненно” вписались любые будущие изменения. При этом важно находить баланс и не программировать будущую функциональность.
Также стоит заметить, что этот вопрос не только о планах развития продукта, но и о сроках выполнения. Поставленные сроки дисциплинируют разработчиков, если, конечно же, они запланировали эти сроки.
7. Есть ли документация?
Странная вещь - эта документация: все согласны, что она нужна и полезна, но никто ее не пишет.
Разработчики предпочитают писать такой код, чтобы он сам “говорил за себя ясно и понятно”. При это степень “ясности и понятности” может быть такой, что только одному автору и понятен код, и то здесь и сейчас. Ведь через полгода вполне вероятно, что автор сам забудет написанную им логику.
Человеко-понятные комментарии к коду нужны, и главное - отразить в них скорее не поведение кода, а объяснение причин такого поведения. Ссылки на тикет тоже будут полезны.
Ведение документации в Вики/Конфлюенсе также полезно, особенно когда разработчики внедряют что-то совершенно новое: новую архитектуру, сторонний модуль или интеграцию с внутренними или внешними сервисами. Любая мысль, написанная “на бумаге”, лучше, чем ничего.
8. Работают ли разработчики в тишине?
Вхождение в поток - очень важно. Не одна статья об этом написана. Состояние потока тяжело поймать и легко потерять, когда вокруг шумно. Поэтому стоит поинтересоваться у будущей команды, в каких условиях они работают.
Прерывания потока обходятся “дорого”, поэтому небольшие комнаты на ограниченное количество человек предпочтительнее, по-моему, чем опэнспейс на 100 человек.
9. Используете ли вы наилучшие из имеющихся инструментов?
Если сборка проекта “тормозится” мощностями компьютера, то лучше стоит апгрейднуть этот компьютер. Разработка GUI с двумя мониторами гораздо эффективней, чем с одним и постоянными сменами активного окна.
Тот же самый принцип актуален и для софта. Если есть решение, где нужный функционал предоставлен “из коробки”, но он стоит N денег, то лучше выбрать его, чем брать не совсем подходящий, требующий доработки напильником, но бесплатный. Ведь в любом случае вы заплатите за использование этого бесплатного инструмента временем настройки разработчиком.
“Top notch development teams don’t torture their programmers (Лучшие команды разработчиков не мучают своих програмистов) (с) Joel Spolsky”
10. У вас есть тестировщики?
В целом стоит узнать, как команда подходит к тестированию своего продукта. Есть ли юниттесты, интеграционные, ручные и/или автотесты?
11. Пишут ли код кандидаты на позицию во время интервью?
Ты и так узнаешь ответ на этот вопрос, ведь обычно сессия вопросов кандидата команде идет как раз в конце собеседования. Если кодинга не было, то стоит задать вопрос “почему”.
Ты врядли наймешь кондитера для выпечки торта для своей свадьбы без пробы, так и нанимать программиста без проверки его навыков кодирования не стоит.
12. Используете ли вы “коридорное (hallway)” тестирование?
Коридорное тестирование - это когда ты берешь случайного пользователя (как будто в коридоре) и просишь его протестировать новую фичу. Так ты увидишь в реальной жизни, как незнающий продукт человек взаимодействует с ним.