Массовое ревью кода, июль 2021

 Публичный пост
19 июля 2021  2106

Всем привет! Предлагаю такую активность: желающие получить ревью своего пет-прожекта выкладывают ссылку сюда, а желающие добровольно помочь и сделать ревью заходят и делают.

Правила для авторов кода:
В комменте 1-го уровня пишем:

  • Краткое описание проекта, для чего нужен, в каком состоянии, язык, кто делает, какие планы на будущее.
  • Что хочется от ревьювера и на каком уровне (мелочи, алгоритмы, смысл, производительность или архитектура или что-то еще).
  • URL'ы на 1-3 файла из проекта, на которые хочется получить ревью. Почему не ссылка не весь проект: чтобы ревьюверу не пришлось искать смысловой код самостоятельно.

Правила для ревьюверов:

  • Ну... вы знаете, делали же уже :)
  • Стараемся не жестить. Ревью - это не место для удовлетворения ЧСВ.
  • По дефолту ответ/ревью пишем в комментах 2-го уровня. Если удобнее в другом месте (например, в MR или ещё где-то), то ок.

Возникает вопрос: Зачем это ревьюверам?
Пожалуй, данная картинка всё прояснит:

Связанные посты
6 комментариев 👇
🕵️ Юзер скрыл свои комментарии от публичного просмотра...

effector-easy-router

Есть такой стейт менеджер эффектор. И вот я для него пишу роутер. Проект написан на тайпскрипте, есть биндинги для реакта. Все кому интересно, велком :)

Гитхаб: https://github.com/kirillku/effector-easy-router
Кодсандбокс с примером: https://codesandbox.io/s/effector-easy-router-xx688
Начать лучше всего отсюда: https://github.com/kirillku/effector-easy-router/blob/master/src/createRoute.tsx

  Развернуть 1 комментарий

Есть проектик, к которому много вопросов, это один из моих первых.
Закидайте хейтом и гневными комментариями что ли
https://github.com/shigabeev/address-segmenter

  Развернуть 1 комментарий

@shigabeevilya, интересная штука. Я не профи питонист, поэтому призываю к обсуждению:

  1. Было бы неплохо разделить парсинг в структуру, стандартизацию, и работу с БД адресов. Например, если мне нужен только парсинг, то мне бы не хотелось elastic и что-то качать гигабайтами.

  2. Тесты как будто не тестят, а что-то выводят в stdout. Было бы удобно классическое: pass or fail и где фейл. По тестам мне не понятно, насколько я могу доверять парсеру. Пока не могу.

  3. В docker-compose три elastic'а. А --scale параметр у docker-compose up не подойдет здесь?

  4. Регулярки стоит скомпилить все заранее.

  5. Думаю, не стоит использовать строки для категоризации чего-либо:

a = lambda x: "число" if x.isdigit() and len(x) < 6 else "препинания" if x == ',' else "не распознано"

  Развернуть 1 комментарий

@shigabeevilya, глянув совсем мельком я бы посоветовал попробовать использовать typing - сильно облегчает жизнь.
Кроме того, переорганизовать проект что бы все файлы с кодом лежали в пакете (папка с init.py в корне) - это поможет и отделить код от конфигурации (docker-compose, README, etc).
Попробуй отказаться от использования принтов в пользу логгирования
Постарайся избегать исполнения кода (как в app.py например) на уровне модуля - лучше завернуть его в функции и вызывать его явно.
На любителя, но я бы констаны (переменные на уровне модуля, я предполагаю что они нигде не меняются) выносил или наверх файла, или вообще в отдельный файл.
Постарайся избегать длинных функций и большого количества кода в рамках try/except. Кстати в except можно удобно использовать логгинг что бы показывать ошибку вместе с трейсбеком.
Для конкатенации строк можно использовать f-strings или format - уберегает от ошибок в случае неожиданного не стрингового типа да и вообще выглядит хорошо

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб