Я может немного идеалистка и витаю в облаках. Но у меня пока такое работает: чем больше заработает мой работодатель, тем скорее он поднимет мне зарплату.
Хорошие работодатели обычно не только под себя гребут, но и с сотрудниками делятся. А иначе – текучка кадров, низкий комплаенс – кому это надо?
В общем, лично мне выгодно работать в интересах работодателя.
Я может немного идеалистка и витаю в облаках. Но у меня пока такое работает: чем больше заработает мой работодатель, тем скорее он поднимет мне зарплату.
Хорошие работодатели обычно не только под себя гребут, но и с сотрудниками делятся. А иначе – текучка кадров, низкий комплаенс – кому это надо?
В общем, лично мне выгодно работать в интересах работодателя.
Я не спорю, что бывают случаи, когда ну никак пул-реквест не попилить на кусочки. Или можно, но слишком сложно.
Но в других случаях надо всё-таки стараться как-то разбивать изменения на удобочитаемые кусочки. А то есть деятели, которые по паре недель фигачат свою фичу, а потом ревью присылают на 2000 строк. Таких надо обучать.
Очень интересная и структурированная статья! А расскажите, какие инструменты вы используете для документирования и рисования диаграмм? Мне только uml на ум приходит, но я не имею опыта в архитектуре ПО.
И ещё, про технический долг, это случайно не про ту компанию, производящую процессоры? Ну это можете не отвечать, я так – посплетничать.
С первого раза не получилось хорошо сформулировать.
Моя мысль в том, что кодом без комментариев можно описать Что делает этот код. Но нельзя описать, Почему он делает это именно так.
Как известно, при написании программы можно сделать одно и то же разными способами. Без комментариев бывает неочевидно, почему выбран этот конкретный случай. И то самое "почему" – один из частых вопросов, возникающих при чтении чужого кода.
Бывает читаешь скудно откомментированный код и думаешь "ну зачем, зачем он тут эти сложности навертел?". А потом спрашиваешь автора и он тебе объясняет, что при определённых сценариях эти сложности вполне оправданы. И ты такая "ах вот оно что! Напиши это в комментарии"
Ко всему уже насоветованному добавлю, что если нет код ревью, то я б сосредоточилась на других способах улучшения качества: тестирование, continuous integration, статические и динамические анализаторы кода (если это применимо к .net и js).
Ну и стараться делать код более устойчивым к изменениям. В смысле, чтоб небольшое изменение не приводило к тому, что надо делать правки в десяти местах. Для этого помнить про SOLID и прочих GoF в процессе разработки.
Конечно, встречалась с такой точкой зрения, что хорошему коду комменты не нужны.
Возможно, в каких-то отраслях программирования реально написать хороший код без комментов.
Но я всю дорогу программировала высокопроизводительные алгоритмы. Куча оптимизаций, эвристик, нетривиальные структуры данных и схемы распараллеливания. Там даже с хорошими комментариями бывает сложно въехать в чужой код.
Интересно было бы посмотреть на пример большого проекта без комментариев.
Вообще, машинное обучение в последнее время перестаёт быть исключительно технологическим вопросом. В некоторых областях оно также затрагивает правовые и морально-этические аспекты.
Хотя про метрики не могу согласиться. Это скорее релевантно для тестирования, а не для ревью. Как измерить "поддерживаемость" и "расширяемость" кода?
Про мотивацию согласна. Для меня лучшей мотивацией является понимание, что на ревью код не делится на Мой и Твой. Это всё Наш код, общий, нашего продукта.
И если автор уйдёт в отпуск (возможно, декретный), нормально остальным будет этот код поддерживать?
У нас диктатура и нельзя коммитить код без ревью другой вопрос, что бывает ревьювится "на отвали". Человеческий фактор никто не отменял.
Ну и про "старшего" и "младшего". У нас в этом полный разнобой. Автор сам выбирает себе ревьюэра (или нескольких). Просто бывает так получается, что кто-то одна прикольно ревьюит и все к ней набегают
Я не смотрю на это как на "убить 3 часа". Скорее как на "поделиться опытом". Но да, ограничивать себя временными рамками полезно. Ещё полезно делегировать. Этим тоже пользуюсь.
Статья не ради одного этого примера же написана. Она для общего понимания принципов работы чисел с плавающей точкой.
Дело в том, о при удалении от нуля увеличиваются интервалы между соседними числами с плавающей точкой. И в зависимости от модели округления (round to zero, round to nearest, ...), может так случиться, что при вычитании единицы, получившееся число станет непредставимо во float и округлится обратно к исходному значению.
Я может немного идеалистка и витаю в облаках. Но у меня пока такое работает: чем больше заработает мой работодатель, тем скорее он поднимет мне зарплату.
Хорошие работодатели обычно не только под себя гребут, но и с сотрудниками делятся. А иначе – текучка кадров, низкий комплаенс – кому это надо?
В общем, лично мне выгодно работать в интересах работодателя.
Я может немного идеалистка и витаю в облаках. Но у меня пока такое работает: чем больше заработает мой работодатель, тем скорее он поднимет мне зарплату.
Хорошие работодатели обычно не только под себя гребут, но и с сотрудниками делятся. А иначе – текучка кадров, низкий комплаенс – кому это надо?
В общем, лично мне выгодно работать в интересах работодателя.
Я не спорю, что бывают случаи, когда ну никак пул-реквест не попилить на кусочки. Или можно, но слишком сложно.
Но в других случаях надо всё-таки стараться как-то разбивать изменения на удобочитаемые кусочки. А то есть деятели, которые по паре недель фигачат свою фичу, а потом ревью присылают на 2000 строк. Таких надо обучать.
Очень интересная и структурированная статья! А расскажите, какие инструменты вы используете для документирования и рисования диаграмм? Мне только uml на ум приходит, но я не имею опыта в архитектуре ПО.
И ещё, про технический долг, это случайно не про ту компанию, производящую процессоры? Ну это можете не отвечать, я так – посплетничать.
Сочувствую
С первого раза не получилось хорошо сформулировать.
Моя мысль в том, что кодом без комментариев можно описать Что делает этот код. Но нельзя описать, Почему он делает это именно так.
Как известно, при написании программы можно сделать одно и то же разными способами. Без комментариев бывает неочевидно, почему выбран этот конкретный случай. И то самое "почему" – один из частых вопросов, возникающих при чтении чужого кода.
Бывает читаешь скудно откомментированный код и думаешь "ну зачем, зачем он тут эти сложности навертел?". А потом спрашиваешь автора и он тебе объясняет, что при определённых сценариях эти сложности вполне оправданы. И ты такая "ах вот оно что! Напиши это в комментарии"
Я вам не скажу за всю Одессу.
Но, вероятно, есть и другие языки и платформы, для которых сохраняется это поведение.
Ну и даже С++ выполняет этот цикл по-разному в зависимости от опций компиляции, и не только уже упомянутых -O0, -O1 и т.д.
Ко всему уже насоветованному добавлю, что если нет код ревью, то я б сосредоточилась на других способах улучшения качества: тестирование, continuous integration, статические и динамические анализаторы кода (если это применимо к .net и js).
Ну и стараться делать код более устойчивым к изменениям. В смысле, чтоб небольшое изменение не приводило к тому, что надо делать правки в десяти местах. Для этого помнить про SOLID и прочих GoF в процессе разработки.
Конечно, встречалась с такой точкой зрения, что хорошему коду комменты не нужны.
Возможно, в каких-то отраслях программирования реально написать хороший код без комментов.
Но я всю дорогу программировала высокопроизводительные алгоритмы. Куча оптимизаций, эвристик, нетривиальные структуры данных и схемы распараллеливания. Там даже с хорошими комментариями бывает сложно въехать в чужой код.
Интересно было бы посмотреть на пример большого проекта без комментариев.
Мне кажется, если в командах где-нибудь по 5+ человек, то и нормально всё – пускай ревьювят внутри себя.
Вот если человека по 3, то это проблема. Надо какую-нибудь жеребьёвку вводить при ревью. Кидать кубик, я не знаю :-/
Как ML инженер не могу согласиться. Достаточная точность – лучшее решение. Иногда и half precision хватает.
Но всегда нужно понимать как работает плавающая точка.
Спасибо за интересную статью!
Вообще, машинное обучение в последнее время перестаёт быть исключительно технологическим вопросом. В некоторых областях оно также затрагивает правовые и морально-этические аспекты.
И что-то нас ещё ждёт в будущем.
Слова не мальчика, но мужа.
Хотя про метрики не могу согласиться. Это скорее релевантно для тестирования, а не для ревью. Как измерить "поддерживаемость" и "расширяемость" кода?
Про мотивацию согласна. Для меня лучшей мотивацией является понимание, что на ревью код не делится на Мой и Твой. Это всё Наш код, общий, нашего продукта.
И если автор уйдёт в отпуск (возможно, декретный), нормально остальным будет этот код поддерживать?
У нас диктатура и нельзя коммитить код без ревью другой вопрос, что бывает ревьювится "на отвали". Человеческий фактор никто не отменял.
Ну и про "старшего" и "младшего". У нас в этом полный разнобой. Автор сам выбирает себе ревьюэра (или нескольких). Просто бывает так получается, что кто-то одна прикольно ревьюит и все к ней набегают
Да, прямо плюсик вам в карму. Очень важный момент про "разбивать изменения". Это всего процесса разработки касается, а не только код-ревью.
Считаю вредной практикой пул-реквесты на 1000+ строк. Надо уметь "есть слона по кусочкам"
Всё так. Но некотрые пункты становятся очень трудновыполнимыми, если дома ты на удалёнке, муж на удалёнке и двое мелких до трёх лет
Я не смотрю на это как на "убить 3 часа". Скорее как на "поделиться опытом". Но да, ограничивать себя временными рамками полезно. Ещё полезно делегировать. Этим тоже пользуюсь.
Вопрос интересный. Достоин отдельного поста. Подумаю как кратко сформулировать и отвечу позже.
Так точно. Напишу ещё какие-нибудь про модели округления, денормалы и прочие весёлые вещи.
Статья не ради одного этого примера же написана. Она для общего понимания принципов работы чисел с плавающей точкой.
Дело в том, о при удалении от нуля увеличиваются интервалы между соседними числами с плавающей точкой. И в зависимости от модели округления (round to zero, round to nearest, ...), может так случиться, что при вычитании единицы, получившееся число станет непредставимо во float и округлится обратно к исходному значению.
Самое интересное не написали. Весь текст ждала фразу "после внедрения CDT наши прибыли возросли на 100500%". Жду теперь продолжения истории.