Войти
ФлеймФорумОбщее

Как обучить команду писать в одном стиле? (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
13:57, 26 авг. 2019

9К720
Ты не понял. Я же в топик старте описал проблему, что дело не в скобочках или отступах.

Ты открываешь qwe.cpp Васи Пупкина и видишь такую картину: 45 приватных методов, каждый из которых по 3-4 строчки. Человек понимаешь прочитал где то на хабре, что делать большие методы класса - это зло. Поэтому насоздавал 45 маленьких. Да ещё с мало подходящим по смыслу названиями и непонятными аббревиатурами. А потом он говорит: в жопу ваш си плюс плюс, я хочу писать на rlang, переходит в другой отдел, а за этот код приходится кому то отвечать.


#16
14:02, 26 авг. 2019

Panzerschrek[CN]
Если правил будет слишком много и все они будут непонятными - никто не будет их соблюдать. Но если ты говоришь, значит в твоей конторе это всё таки работает.

Ладно, подумаю. Потом поделюсь опытом.

#17
14:07, 26 авг. 2019

9К720
Panzerschrek[CN]
Я рад что вы не добавили меня в список игнора скриптом из этого треда:
https://gamedev.ru/flame/forum/?id=246373

Ваши советы не редко имеют практическую пользу.

#18
14:25, 26 авг. 2019

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

#19
(Правка: 15:26) 15:11, 26 авг. 2019

f1ufx_
> Да ещё с мало подходящим по смыслу названиями и непонятными аббревиатурами.
На хабре была хорошая статья "Code review по-человечески", как-то так.
Почитай. Суть в том, что если нет тестов, если нет наименований понятных - ты имеешь право попросить переделать. Если ты правда не понимаешь что там в 45 мелких методах и считаешь что они не нужны, при этом на код написаны тесты и в целом он не такой плохой - значит надо проверить ваше руководство по стилю языка. Вот например для крестов вариант https://google.github.io/styleguide/cppguide.html Там не только отступы должны быть, а запрещенные фичи языка и в целом рекомендации по фичам.
Там должны быть прописаны спорные моменты и  что мелкие методы запрещены.
В вашем корпоративном руководстве по стилю такого нет, а код все равно не нравится и непонятный? Ну может дело в тебе?

Хорошее руководство по стилю определяет не только внешние элементы оформления вроде соглашения о присвоении имён или правила отступов, но и как использовать функции данного языка программирования. Например, JavaScript и Perl набиты функциональностью — там есть много вариантов реализации одной и той же логики. Руководство по стилю определяет Один Правильный Способ программирования, так что вы больше не увидите, что одна половина вашей команды использует один набор функций языка, а другая половина — совершенно другой набор функций.

Как только у вас появилось руководство по стилю, больше не придётся тратить циклы ревью на обмен сообщениями с автором в спорах, каким способом лучше именовать файлы. Просто следуйте руководству и двигайтесь дальше. Если в вашем руководстве отсутствует инструкция по определённому вопросу, обычно и не стоит о нём спорить. Если вы встречаетесь с вопросом по стилю, который не описан в руководстве, но достоин обсуждения, решите его вместе с командой. Затем запишите решение в руководство по стилю, чтобы больше никогда не возвращаться к этому обсуждению.


f1ufx_
> и будут непонятными - никто не будет их соблюдать.
Еще раз. Если правил много и они непонятны - правила говно. Потому что невозможно следить вручную. И кто нибудь, возможно и ты закодишь неформатированное говно. Потом тебе тяжело будет объяснять людям почему не надо комитить неформатированный код. Почитай про фундаментальную ошибку аттрибуции.

Чекстайл должен быть автоматизирован. Запретите лямбды. Там где  без них не обойтись - можно ставить какой нибудь //suppress-warning lambda
Все нормальные чекстайлы так умеют.  Если не умеют - язык говно. Придется проверять на соответсвие стилю руками. Если в руководстве по стилю этот случай не описан - либо надо это там написать (после обсуждения с командой и тебе, да, ты же возмущаешься) - либо не возмущаться а пойти и почитать про фичи языка.
Короче, если хочешь единого стиля - эти проверки надо как можно сильнее автоматизировать, требовать тесты и т.д.. Если же все проверки прошел, стилю соответсвует, а тебе код тяжело понять - ну, может быть ты недостаточно квалифицирован?

#20
(Правка: 17:15) 17:14, 26 авг. 2019

f1ufx_
> Если правил будет слишком много и все они будут непонятными - никто не будет их соблюдать.
А вот это я утаскиваю к себе в новую книгу.

#21
17:51, 26 авг. 2019

Алексей Патрашов
Не забудь добавить в свою новую книгу описание новых фишек cmake, в особенности
FetchContent_Declare

И что файлов проекта должно быть два: один девелоперский, другой для билдбота, состоящий исключительно из команд
ExternelProject_Add

Сам придумал, сам эксплуатирую. Существенно облегчает доставку продукта. Его в таком виде хоть в bitbake завернуть можно хоть в ebuild - когда продукт уже разбит на части, и циклические зависимости исключены - это очень удобно.

#22
18:02, 26 авг. 2019

Алексей Патрашов
Деплой я считаю - неотъемлемая часть организации работы команды. В отсутствии внимания к этой проблеме, деплоймент проекта может скатиться вплоть до того, что сборка в режиме debug будет полностью неработоспособна, и вся команда будет пользоваться printf для отладки. Это в разы увеличивает человекомесяцы разработки. И я видел такие случаи. Такое реально бывает. Причём даже в иностранных компаниях.

#23
18:09, 26 авг. 2019

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

#24
(Правка: 18:29) 18:23, 26 авг. 2019

Panzerschrek[CN]
> Написать документ с правилами написания кода, очевидно же. На review проверять
> код на соответствие этому документу.
[1] плюсую!

Документировать надо, чтобы:
- при разборках было на что опереться
- при найме новых разработчиков, не пришлось передавать знания устно

f1ufx_
> Раньше я думал что ответ прост: astyle
> ...
> И всё равно этого не хватает. Потому что сама логика написания кода у разных
> программистов разная. Например один любит возвращать tuple, другой использует
> лямбды, даже в циклах, любит делать вложенные циклы по многу раз, третий
> использует final или другие фенички одинадцатых плюсов там где это нахрен не
> надо и тп и тд.
тебе вам (команде) нужен анализатор кода, который не расставляет скобочки и отступы, а который отслеживает использование фич.
Если использованные фичи, не соответствуют правилам, изложеным в документе (1), то
- либо не позволять делать такой коммит (не рекомендуется, ибо это тупо!)
- ставится пометка, на исправление, по адресу человека сделавшего комит
И, собственно, релиз не будет допущен, пока логика кода не будет исправлена, на соответствие документу (1)

... как крайний случай, компилировать код, в строгом соответствии со стандартом C99 :D
тогда уж точно крестовые фичи не пролезут.

Код с запашком ссылает вот на этот список 
f1ufx_
> Было бы здорово, чтобы каждый отвечал за свой кусок кода, и тогда пиши ты как
> хочешь. Но бывают ситуации, когда программист сам путается в своих же
> примудростях и не успевает к дедлайну.
Для отчётности перед Боссом, это вообще идеальный вариант.
Т.к. за каждым человеком можно отследить, либо:
- количество комитов, помеченных на исправление логики
- количество дней когда некий файл висел помеченным на исправление логики
А ещё, можно будет указать, что мы потратили N-человеко часов на переписывание.

#25
(Правка: 18:47) 18:46, 26 авг. 2019

9К720
> На хабре была хорошая статья "Code review по-человечески", как-то так.
https://habr.com/ru/post/340550/
https://habr.com/ru/post/342244/

в статье не рассматривается один вопрос - где взять ресурсы на code review.
Code Review, делается такими же программистами, как и автор изменений.
А это значит, что у них есть свои задачи и свои дедлайны, и ковыряться в чужом коде им не хочется.

#26
18:51, 26 авг. 2019

skalogryz
> где взять ресурсы на code review
А на это не надо особо ресурсов.
Просмотреть код раз в 10 проще, чем его написать. Если каждый раз код будет смотреть по два-три человека, то это увеличение временных затрат на 20-30%.
Казалось бы, это много. Но есть сглаживающий этот момент фактор. Код смотреть сильно проще, чем его писать, а значит интенсивность этого труда меньше. Код можно смотреть в те части рабочего дня, когда сил на написание кода уже нету - обычно ближе к вечеру.

#27
18:59, 26 авг. 2019

skalogryz
> Code Review, делается такими же программистами, как и автор изменений.
Да, это принудиловка и боль, отвлекает от основной работы, нередко приводит к переработкам и работе в выходные дни. Но за это обычно хорошо платят, к тому же порядок кто-то должен обеспечивать (не путать с кумовством и микроменеджментом), иначе все развалится и работы не будет ни для кого.

#28
19:00, 26 авг. 2019

Panzerschrek[CN]
> Просмотреть код раз в 10 проще, чем его написать.
боюсь что зависит, от
а) знания кода, который меняется.
Т.е. если ты знаешь код (что он должен делать и как устроен), то оценка правок в такой код будет проще.
Если же изначальный код, тебе неизвестен, а code review делать нужно; то чтобы сделать его правильно, нужно будет вникать и в начальный код, и в правки.
А я бы не сказал, что это проще, особенно ближе к вечеру.

б) количества правок.
Если общее количество правок, большое. (что ещё хуже, в большом количестве файлов); то просмотр изменений может занять так же значительное время.

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

#29
(Правка: 19:04) 19:03, 26 авг. 2019

totoro
> Но за это обычно хорошо платят
можно в этом месте по-подробнее?! (ни разу не встречался с финансовой мотивацией для выполнения code review)

Страницы: 1 2 3 4 Следующая »
ФлеймФорумОбщее