Год уже как участвую в найме — провожу техническое интервью. Никакой теории не спрашиваю, сплошная практика.
За отпущенные 2 часа большинство не успевает.
Всего две задачи, можно использовать IDE.
Первая — разработать некий сервис + тесты, из сложностей — нужно уметь читать требования на английском, иметь базовые навыки многопоточного программирования, уметь писать юнит-тесты. Разрешаю пользоваться документацией, даже гуглить при сильных затруднениях.
Вторая — до 20 строк забагованного кода, нужно почитать и найти косяки (уже без документации).
Обе задачи вполне себе боевые, первая имитирует процесс разработки, вторая — кодревью.
За год я смог одобрить 9 человек, прошло через меня несколько десятков.
А резюме почти у все были хорошие. Многообещающие.
Зато многие кандидаты говорят, что это был их лучший собес за все время. )))
Они простые.
Минимум — демонстрация замысла автора. В прямом смысле — глядя на тест должно быть понятно, что и зачем автор хотел сделать.
Остальное определяется возможностью повторного использования компонента.
Если компонент идет «в народ» — тесты должны быть ковровыми. В остальных случаях возможны компромиссы.
Все это есть. Я как раз пишу на языках со строгой типизацией, использую статический анализатор, и это не отменяет необходимость юнит тестов. И ревью тож практикую. Первое, на что смотрю при ревью — это именно тесты.
Ваш пример с генератором SQL достаточно интересен. Возможно, юнит тестом тут не обойтись — придется использовать интеграционный. А если в качестве СУБД поиспользовать встраиваемую СУБД, например H2, то интеграционный тест будет не шибко сложнее юнит теста.
А еще можно попробовать разбить генератор SQL на 2 компонента — генератор модели и транслятор модели уже в SQL. Относительно дорогое решение, но в некоторых случаях оправданное, и позволяет обойтись юнит тестами.
За 13 лет работы я прошел этапы восприятия юнит-тестов от «что это вообще» до «без некоторого разумного покрытия юнит-тестами модуль не считается разработанным».
На том и стою.
Прям в детство окунулся. Спасибо. Вы делаете доброе дело. Возможно, во многом благодаря хорошим научно-популчрны книгам и статьям, написанных интересно и доступно, из меня вырос относительно приличный человек.
Вот список практик моего текущего проекта, которые в разной степени направлены на поддержание понятности кода.
Придерживаться общего для проекта стиля. Да, его нужно выработать, задокументировать и автоматизировать контроль.
Давать осмысленные названия переменным, классам, функциям, пакетам.
Выровнять уровни абстракции. В том числе в рамках одного файла.
Стремиться сохранить линейный формат кода на каждом уровне абстракции. Считайте, что вам удалось, если возможно сделать близкое к реальности предположение о том, что делает функция, прочитав её всего лишь раз сверху вниз.
Избегать повторяющихся проверок. В идеале — вытеснить неопределенность в данных на максимально высокий уровень абстракции и сделать некорректное состояние невыразимым на нижележащих.
Написать тесты, которые как минимум демонстрируют замысел.
Зачищать ненужный код, комментарии, и т.д..
Хороший комментарий в коде — это ссылка на документацию или объяснение, почему сделано именно так, а не иначе.
Снабжать commit'ы внятными комментариями.
Не объединять в одном commit'е разрозненные по смыслу вещи.
Делать обзор собственного кода перед созданием pull-request'а.
Не создавать слишком большие pull-request'ы. Если изменений слишком много — лучше создать несколько pull-request'ов.
Делать code review. Никакого merge до консенсуального исправления всех значимых замечаний.
Я, наверное, что-то упустил, но это не важно. Важно то, что всех этих практик все равно оказывается недостаточно. )))
Человек имеет право выполнять свою работу любым законным способом.
Если работодатель не разбирается в аспектах своего бизнеса и не понимает способов решения связанных с бизнесом задач — это его проблема.
Чтоб научиться писать хороший код — нужно много писать и читать код, периодически возвращаясь к доработке уже написанного. Без такой практики этот список не поможет, а вот качестве дополнения будет очень полезен.
Невменяемые сроки и плохая постановка задач — все это есть. Но в хорошем проекте это скорее исключение, чем правило.
Я, конечно, люблю идеальный код, но не являюсь его неуёмным фанатом. Должны существовать измеримые критерии качества кода, и никакой код в проекте не должен быть хуже, чем предусмотрено этими критериями. Критерии, конечно, у каждого проекта могут быть свои.
Очень хорошо, если заказчик понимает, что качество кода непосредственно влияет на качество продукта, на стоимость его развития и поддержки. Если не понимает — лучше инвестировать время в разъяснение, окупится.
А так — да. Никому не нужна корова, всем нужно молоко, шкура, мясо. Никому не нужен бетон, всем нужны мосты и здания. Никому не нужен Х, всем нужен У.
Если человек не страдает самоконтролем, то никакие добрые советы ему не помогут. Неоднократно во время PR review наблюдал откровенный говнокод, которого могло бы не быть, если бы человек просто посмотрел на свою писанину второй раз.
Мне стоило некоторого труда научиться задавать себе вопрос, а не говнокод ли я написал только что?
К сожалению, многие разработчики не задают себе такой вопрос вообще никогда.
Я подписываю разного рода "петиции" не потому, что они имеют "вес". Не в надежде на "помилование". Я просто хочу, чтобы автор петиции и сочувствующие ему знали, что есть другие люди, которые согласны с ними. Чтобы петиция была источником "общественного мнения", потому что почти все остальные источники — блогеры, СМИ, комментаторы, социологические центры — эту функцию не выполняют.
Отделение контракта чтобы не тащить за собой зависимости реализации.
Раздельное управление API и реализацией.
Добавление явных декораторов вместо неявных аспектов.
Улучшение читаемости API.
Сокрытие платформозависимого компонента, конечно же.
Можно, наверное, еще подумать, зачем может быть нужен интерфейс с единственной
реализацией, но и приведенного должно быть достаточно.
Конечно, легко себе вообразить проект, где перечисленные выше причины вообще никогда не возникнут, но в моем текущем проекте и во всех предыдущих за последние лет 6 наличие интерфейса практически у любого сервиса подразумевалось по умолчанию.
За отпущенные 2 часа большинство не успевает.
Всего две задачи, можно использовать IDE.
Первая — разработать некий сервис + тесты, из сложностей — нужно уметь читать требования
на английском, иметь базовые навыки многопоточного программирования, уметь писать юнит-тесты. Разрешаю пользоваться документацией, даже гуглить при сильных затруднениях.Вторая — до 20 строк забагованного кода, нужно почитать и найти косяки (уже без документации).
Обе задачи вполне себе боевые, первая имитирует процесс разработки, вторая — кодревью.
За год я смог одобрить 9 человек, прошло через меня несколько десятков.
А резюме почти у все были хорошие. Многообещающие.
Зато многие кандидаты говорят, что это был их лучший собес за все время. )))
Минимум — демонстрация замысла автора. В прямом смысле — глядя на тест должно быть понятно, что и зачем автор хотел сделать.
Остальное определяется возможностью повторного использования компонента.
Если компонент идет «в народ» — тесты должны быть ковровыми. В остальных случаях возможны компромиссы.
Ваш пример с генератором SQL достаточно интересен. Возможно, юнит тестом тут не обойтись — придется использовать интеграционный. А если в качестве СУБД поиспользовать встраиваемую СУБД, например H2, то интеграционный тест будет не шибко сложнее юнит теста.
А еще можно попробовать разбить генератор SQL на 2 компонента — генератор модели и транслятор модели уже в SQL. Относительно дорогое решение, но в некоторых случаях оправданное, и позволяет обойтись юнит тестами.
На том и стою.
текут
Прям в детство окунулся. Спасибо. Вы делаете доброе дело. Возможно, во многом благодаря хорошим научно-популчрны книгам и статьям, написанных интересно и доступно, из меня вырос относительно приличный человек.
Развитие экономики обычно не "обходится", а "приносит".
Я, наверное, что-то упустил, но это не важно. Важно то, что всех этих практик все равно оказывается недостаточно. )))
Если работодатель не разбирается в аспектах своего бизнеса и не понимает способов решения связанных с бизнесом задач — это его проблема.
Я, конечно, люблю идеальный код, но не являюсь его неуёмным фанатом. Должны существовать измеримые критерии качества кода, и никакой код в проекте не должен быть хуже, чем предусмотрено этими критериями. Критерии, конечно, у каждого проекта могут быть свои.
Очень хорошо, если заказчик понимает, что качество кода непосредственно влияет на качество продукта, на стоимость его развития и поддержки. Если не понимает — лучше инвестировать время в разъяснение, окупится.
А так — да. Никому не нужна корова, всем нужно молоко, шкура, мясо. Никому не нужен бетон, всем нужны мосты и здания. Никому не нужен Х, всем нужен У.
Мне стоило некоторого труда научиться задавать себе вопрос, а не говнокод ли я написал только что?
К сожалению, многие разработчики не задают себе такой вопрос вообще никогда.
Я подписываю разного рода "петиции" не потому, что они имеют "вес". Не в надежде на "помилование". Я просто хочу, чтобы автор петиции и сочувствующие ему знали, что есть другие люди, которые согласны с ними. Чтобы петиция была источником "общественного мнения", потому что почти все остальные источники — блогеры, СМИ, комментаторы, социологические центры — эту функцию не выполняют.
Можно, наверное, еще подумать, зачем может быть нужен интерфейс с единственной
реализацией, но и приведенного должно быть достаточно.
Конечно, легко себе вообразить проект, где перечисленные выше причины вообще никогда не возникнут, но в моем текущем проекте и во всех предыдущих за последние лет 6 наличие интерфейса практически у любого сервиса подразумевалось по умолчанию.
Иногда побаиваюсь сложных задач.
Боюсь языков программирования со слабой типизацией.