All streams
Search
Write a publication
Pull to refresh
5
0

Machine learning engineer

Send message

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

Хорошие работодатели обычно не только под себя гребут, но и с сотрудниками делятся. А иначе – текучка кадров, низкий комплаенс – кому это надо?

В общем, лично мне выгодно работать в интересах работодателя.

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

Хорошие работодатели обычно не только под себя гребут, но и с сотрудниками делятся. А иначе – текучка кадров, низкий комплаенс – кому это надо?

В общем, лично мне выгодно работать в интересах работодателя.

Я не спорю, что бывают случаи, когда ну никак пул-реквест не попилить на кусочки. Или можно, но слишком сложно.

Но в других случаях надо всё-таки стараться как-то разбивать изменения на удобочитаемые кусочки. А то есть деятели, которые по паре недель фигачат свою фичу, а потом ревью присылают на 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%". Жду теперь продолжения истории.

Information

Rating
Does not participate
Location
Россия
Registered
Activity