OSBP 4/8: Reviewing Changes [open source crash course]
Vložit
- čas přidán 4. 06. 2024
- Open Source Best Practices (OSBP), a crash course for BSc students of Innopolis University.
Blog: www.yegor256.com
Books: www.yegor256.com/books.html
GitHub: github.com/yegor256 (don't hesitate to follow in order to stay informed)
Telegram channel with recent news and updates: t.me/yegor256news (subscribe to not miss a thing)
Twitter with daily and weekly updates: / yegor256 (follow me!)
iTunes: podcasts.apple.com/us/podcast...
SoundCloud: / yegor256
0:00 Introduction
2:45 2006, Martin Fowler
6:17 1. Raise issues, don't resolve them
9:19 1976, Michael Fagan
12:18 1989, Frank A. Ackerman
17:57 2018, Mateus Freira dos Santos
21:45 2. Educate the author
27:45 2012, Brendan Cleary
36:28 2018, Caitlin Sadowski
40:11 3. Don't run the code in the branch
46:35 4. Reject it, if it's too big
49:55 2012, Frederic Painchaud
57:52 5. Reject it, if it lowers code coverage
1:01:17 6. Reject it, if it doesn't reproduce a bug
1:08:25 7. Rely on the CI status, but not too much
1:11:14 2023, Mairieli Wessel
1:14:48 8. Employ ChatGPT - Věda a technologie
![OSBP 5/8: Setting Guidelines [open source crash course]](http://i.ytimg.com/vi/mWi2S5FJiJ4/mqdefault.jpg)
![OSBP 5/8: Setting Guidelines [open source crash course]](/img/tr.png)
Subscribe, be among the best!
t.me/yegor256news
Great talk! I really appreciate all the work you do!
great
39:55 а может всё-таки в значительной степени вероятно, что девелоперы с большим опытом на проекте могут писать сразу хороший код, к которому очень сложно придраться?
Я к сожалению часто сталкиваюсь с пунктом (4) -- большой PR, да еще и без тестов. Я обычно задаю два вопроса человеку: 1. Как ты тестировал свой код? 2. Ты хочешь чтобы я ревью сделал или просто кнопку нажал?
Тестируйте в ветках
@@egormerkushev Не надо в ветках ничего тестировать. Автор PR должен приложить тесты, а CI показать, что они зеленые. Тесты еще не только для проверки нужны, а чтобы понять что хотел сделать автор и как именно его код должен работать. Это своего рода документация, которая всегда будет актуальной.
@@mormeoiв зачем вы задали вопрос и на него же сами ответили?
@@egormerkushev потому что еще есть вариант не делать ревью, а просто нажать ок. Если PR не удовлетворяет описанным критериям то я иногда так делаю.
@@mormeoi не скажу, что не сталкиваюсь с такими же pr, но всё же у нас в проекте на ревью проверяется вручную архитектура решений, все остальные вопросы проверяется та и иная автоматика и тесты. Архитектура - это сложно выражаемая числами субстанция в коде, к сожалению. Поэтому она является обычно центральным вопросом в этих дискуссиях.