необязательно читать код на ревью, чтобы реджектнуть except:pass

достаточно инспекций на коммит

Я читал что это питонический путь

питонический путь это поймать эксепшен и _залогировать_ его, вместе с трейсбэком

необязательно читать код на ревью, чтобы реджектнуть except:pass

Блин, а это твой второй годный перл за сегодня. У тебя гитхаб есть?

необязательно читать код на ревью, чтобы реджектнуть except:pass

дело

два чая этму джентельмену

но все таки кажется что ви лукаите

у нас тоже есть проблемы с процессами, я бы даже сказал огромные проблемы. и на текущем проекте мы пытаемся эту ситуацию исправить, это медленно т.к. мотивации и immediate profit. но например в OpenStack Community, которое иначе обвалилось бы под собственной тяжестью с процессами все сильно лучше чем в остальных больших проектах. и у них неплохо бы поучиться как нужно вести проекты.

линтеры, анализаторы и пост-ресив хуки - вот это базис нормального процесса

необязательно читать код на ревью, чтобы реджектнуть except:pass

Да, даже линтеры могут с этим справиться

Блин, а это твой второй годный перл за сегодня. У тебя гитхаб есть?

есть, но там почти ничего нет, я не пишу опенсорс (потому что ленивый)

я прост к тому что все хер кладут делать код ревью в современном девеломпенте, даже там где это заявлено

делают только на что-то критическое

Я читал что это питонический путь

нет. питонячий путь либо обработать по месту, где нужно. либо как уже сказали залогировать с трейсбеком и послать алярм.

есть, но там почти ничего нет, я не пишу опенсорс (потому что ленивый)

А есть что-нибудь, на что подписаться можно, что бы регулярно видеть твои перлы?

Кроме этого канала, где я итак уже сижу.

я прост к тому что все хер кладут делать код ревью в современном девеломпенте, даже там где это заявлено

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

А есть что-нибудь, на что подписаться можно, что бы регулярно видеть твои перлы?

больше негде

я прост к тому что все хер кладут делать код ревью в современном девеломпенте, даже там где это заявлено

Это не так, я в некоторых проектах апрув (или несколько апрувов) обязательное условие для прохождения задачи по флоу

задача процессов усложнить положение хера

Понятно, что это далеко не везде так. Но в РФ точно есть такие компании

Это не так, я в некоторых проектах апрув (или несколько апрувов) обязательное условие для прохождения задачи по флоу

я работал в одной крупной конторе где также присутсвали выходцы со всех крупных продуктовых компаний в постсоюзе

ну и в общем таки да, есть конечно команды(проекты или целые конторы) где не просрали еще все процессы

но в целом уровень просранности процессов как правило прямо пропроционален размеру

энтропия, бессердечная ты сука

и про опенстэк не соглашусь

у нас тоже есть проблемы с процессами, я бы даже сказал огромные проблемы. и на текущем проекте мы пытаемся эту ситуацию исправить, это медленно т.к. мотивации и immediate profit. но например в OpenStack Community, которое иначе обвалилось бы под собственной тяжестью с процессами все сильно лучше чем в остальных больших проектах. и у них неплохо бы поучиться как нужно вести проекты.

в опенстек комьюнити (по крайней мере нескольколетней давности) процессы выглядели довольно тяжеловесными

Это не так, я в некоторых проектах апрув (или несколько апрувов) обязательное условие для прохождения задачи по флоу

у нас без двух аппрувов мердж не проходит, прям в репе настроено

я работал в одной крупной конторе где также присутсвали выходцы со всех крупных продуктовых компаний в постсоюзе

Это, к сожалению, ничего еще не значит. Есть много разработчиков, которые стараются писать нормальный код, покрывать его тестами и т.д. только когда знают, что иначе им дадут по руками. Стоит ослабить хватку (перестать это контролировать) как они сразу начинают говнокодить

в тоц же самой конторе была целая волна беженцев из мираниса

Поэтому если собрать разрабов из нормальных компаний, но не выстроить процессы, то результата может не быть

в опенстек комьюнити (по крайней мере нескольколетней давности) процессы выглядели довольно тяжеловесными

я не утверждаю, что у них вот прямо все идеально.

и ы целом этот ваш опенстэк прямо скажем и его процессы подходят только для самого опенстека

было задорно посмотреть как они предсказуемо пофейлились натаятнуть сову на глобус

в тоц же самой конторе была целая волна беженцев из мираниса

Москва \ Харьков? Волна беженцев из Мирантиса была совсем по другой причине.

Москва

я честно говоря не заинтересован особо

я слышал беженца из Мирантиса, который очень экспрессивно описывал проблемы опенстек комьюнити

хотя

Москва \ Харьков? Волна беженцев из Мирантиса была совсем по другой причине.

Мирантису конец пришел, вот и разбежались

я знал одно разраба, который там работал

Мирантису конец пришел, вот и разбежались

ну по слухам, там сейчас опять все наладилось. знаю многие вернулись.

код его был ужасен

ну они понабежали к нам и ппытались свою ичь развеселую с герритом натянуть на C++ продакшен

тем не менее

в геррите как таковом ничего плохого вроде нет

сам опенстек ок

код его был ужасен

я знаю одного архитекта, который такую хуйню делал, что мертвые позавидовали бы живым.

код в сымсле

у них действительно неплохая иннфра

ну у нее слишком большой культурный багаж

Это, к сожалению, ничего еще не значит. Есть много разработчиков, которые стараются писать нормальный код, покрывать его тестами и т.д. только когда знают, что иначе им дадут по руками. Стоит ослабить хватку (перестать это контролировать) как они сразу начинают говнокодить

согласен с этим!

в геррите как таковом ничего плохого вроде нет

геррит ужасен с точки зрения UI, но после него подходы к ревью гитхаба и т.п. с ними кажутся лютым говном.

процесы должны вырасти из культуры команды\компании

в том куске кода опенстека, который я видел, была огромная куча тестов, которые тестировали не функциональность, а реализацию, и из-за этого любые изменения влекли за собой огромное количество перелопаченных тестов, в которых какие-то внутренние вызовы поменялись с какими-то другими аргументами итд. больше изменений - больше кода ревьюить - дольше цикл - грустно

а не быть натянутым менеджментом

геррит ужасен с точки зрения UI, но после него подходы к ревью гитхаба и т.п. с ними кажутся лютым говном.

А мне в целом нравится ревью в bitbucket'е

кончено, есть определенный минимум миниморум адекватности

в общем

не просрать процессы это большое исскуство

я очень рад за вас, если в ваших конторах не просраны они и это не сарказм а реальнэ белая зваисть

А мне в целом нравится ревью в bitbucket'е

Я с битбакетом плотно не работал. Что там у них? Просто в гитхабе это боль, несколько итераций ревью выливаются либо в кучу мусорных коммитов, которые потом нужно сквошить, либо же если делаешь rebase \ изменение истории - в невозможность посмотреть диффы между двумя версиями кода на PR.

Я с битбакетом плотно не работал. Что там у них? Просто в гитхабе это боль, несколько итераций ревью выливаются либо в кучу мусорных коммитов, которые потом нужно сквошить, либо же если делаешь rebase \ изменение истории - в невозможность посмотреть диффы между двумя версиями кода на PR.

несколько итераций ревью выливаются либо в кучу мусорных коммитов вот это не понял. Можешь поподробнее рассказать?

несколько итераций ревью выливаются либо в кучу мусорных коммитов вот это не понял. Можешь поподробнее рассказать?

вот к примеру есть у тебя PR, ты сделал ревью и оставил комменты, автор PR сделал изменения, дальнейшие действия?

вот к примеру есть у тебя PR, ты сделал ревью и оставил комменты, автор PR сделал изменения, дальнейшие действия?

Если строка кода, к которой был коммент, исчезла, то в bitbucket'е есть отдельная вкладка, где все эти комменты отображаются вместе с оригинальным (который был на момент написания коммента) куском кода

ну и версия там тоже явно указывается

ERROR: S client not available

Если строка кода, к которой был коммент, исчезла, то в bitbucket'е есть отдельная вкладка, где все эти комменты отображаются вместе с оригинальным (который был на момент написания коммента) куском кода

Ок, я немного не о том. Ты изменения в PR как делаешь, новыми коммитами или изменением истории?

Ок, я немного не о том. Ты изменения в PR как делаешь, новыми коммитами или изменением истории?

никогда не меняю историю. Только локальную могу

т.е. всегда новыми коммитами

никогда не меняю историю. Только локальную могу

В итоге у тебя возникает в PR куча коммитов типа "fix, fix, fix, fix, fix"

да

Дальше, делаешь ли ты squash при мердже в мастер?

нет

В итоге у тебя возникает в PR куча коммитов типа "fix, fix, fix, fix, fix"

ну и отлично

В итоге у тебя куча мусорных коммитов в истории.

Зато история отражает реальность

Зато история отражает реальность

+

И в случае чего по ней можно восстановить что делал разработчик

И где ошибся

и потом можно вернуться к PR'у и посмотреть что там комментили и как фиксили

после squash'а все потеряется

И где ошибся

в этом нет смысла

имеет смысл понимать, зачем были внесены изменения

а не какие вначале ошибочные изменения были

засквошенный коммит, реализующий какой-то небольшой кусок функциональности, с нормальным мессаджем - твой бро

а fix fix fast fix pls

не твой бро

в этом нет смысла

есть, когда разработчик накосячил и пытается понять где косяк

типа “а я вчера 2 часа дня же закоммитил не то"

И в случае чего по ней можно восстановить что делал разработчик

история гита не содержит комментарием ревьюера, так что использовать для этого гит не слишком целесообразно.

смотрит - а коммит засквошен, не откатить

засквошенный коммит, реализующий какой-то небольшой кусок функциональности, с нормальным мессаджем - твой бро

+1

есть, когда разработчик накосячил и пытается понять где косяк

если коммит именно что-то чинит, то "Fix bla bla bla" это отдельный коммит

история гита не содержит комментарием ревьюера, так что использовать для этого гит не слишком целесообразно.

при мерже же может добавляться

так нефиг писать чушь

а если это просто дописывается онгоинг фича, то надо сквошить

но фокус в том, что у сквоша тоже есть недостатки. и вот тут мое имхо геррит имел одну очень крутую фичу, которых ни у кого больше нет. а именно трекал отдельно review request и позволял смотреть диффы между ними.

если дописвается - пусть разраб сам думает, но лучше более подроная история, чем её отсутствие