В рамках этого этапа наши сотрудники проведут строгое ревью github-репозиториев для предыдущих двух проектов: бота и веб-сервера.
-
Прежде чем приступить к этому этапу, отправьте свои репозитории нам для проверки через вот эту форму заявки на ревью проектов. Только получив эту форму, мы начнем проверку :)
-
После прохождения вами этапа код-ревью напишите менеджеру программы обучения в личные сообщения в телеграмме.
Проверка кода в рамках ревью будет не только на предмет формальных требований ниже, но и на предмет продуманной и ясной архитектуры, читаемого и понятного кода, удобного интерфейса работы с вашими функциями. Код пройдет проверку только тогда, когда будет настолько хорош, чтобы мы сами не боялись брать его на поддержку :) Конечно, ровно эти же правила затем будут применяться и при всех ревью уже на реальных проектах после приема на работу.
- Весь проект скомпилирован с флагами
-Wall
и-Werror
и нет ни одной ошибки и ни одного варнинга от компилятора. - Весь код проверен через
hlint
и не вызывает ни одного варнинга. - Весь код отформатирован при помощи форматтера
ormolu
. - Все импорты либо
qualified
, либо содержат явный import list. - Не используются нетотальные функции (Partial functions).
- Вложенность условных операторов и операторов выбора не превышает 2 уровней.
- Не используются длинные кортежи, когда удобнее использовать ADT.
- Ошибки внимательно обрабатываются и не глушатся:
- Не используются
error
иundefined
. - Названия функций выбраны в соответствии с проблемой, которую эти функции решают.
- Каждая функция решает только одну проблему.
- Использованы паттерны проектирования: Service/Handle Pattern или Tagless Final/ReaderT.
- Основной функционал покрыт чистыми юнит-тестами. E2E тесты в рамках программы обучения писать не требуется.
- Проект запускается и работает с конфигом проверяющего (например, чтобы можно было проверить работу бота с другим токеном).
- Все изменения в проект в процессе код-ревью вносятся через пулл-реквесты. В ПР указывается ссылка на ишью.
- По максимуму исключено использование синонимов типов
type
в пользуnewtype
. - Не запрещается использовать RecordWildCards и OverloadedRecordDot в случаях, когда это улучшает читаемость кода.
-
https://wiki.haskell.org/Programming_guidelines (правила про Haddock можно игнорировать)
-
HaskellerZ - Feb 2018 - Getting things done in Haskell and Zurich Friends of Haskell
https://www.youtube.com/watch?v=-X1vrxQUETM — смотреть первую часть до 51 минуты, там идет набор разных правил по разработке на Хаскеле. Паттерн Handle стоит рассмотреть, но необязательно применять.
Слайды: https://github.com/jaspervdj/talks/blob/master/2018-haskellerz-getting-things-done/slides.md
Обязательно изучить репозиторий, который там есть в ссылке, там то приложение, о котором рассказывал спикер: Fugacious.