Pull to refresh

Comments 16

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

Не согласен. Статья содержит информацию, которую стоит доносить, повторять много раз в разных формах. От знающих не убудет, для незнающих и сомневающихся пойдёт только на пользу.

Давайте по порядку. Совет первый: «поддерживайте гибкость в нужных местах». Как проверить что это выполняется? Мало того что «нужные места» субъективный параметр, но не факт что вообще вычислимый.


Рефакторинг перед добавлением фич и готовность выкинуть код — полезные советы.


Про тестирование — спорно, зависит от проекта. Есть вещи которые тестировать дорого. Кодревью полезно, но это и так все знают.


Сведите зависимости к минимуму это совет в духе «станьте богатым». Без конкретной методики смысла не имеет.


По поводу фич — вне компетенции программиста.


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

Совет первый: «поддерживайте гибкость в нужных местах». Как проверить что это выполняется?

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

Про тестирование — спорно, зависит от проекта. Есть вещи которые тестировать дорого. Кодревью полезно, но это и так все знают.

Про тестирование — не спорно. С опытом понимаешь важность тестирования. Это как раз то, что постоянно подвергается сомнению. Видимо совет как раз для вас :)

Про «все знают» уже говорилось, от вас не убудет.

Сведите зависимости к минимуму это совет в духе «станьте богатым». Без конкретной методики смысла не имеет.

Вы передёргиваете. Здесь нет никаких обещаний.

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

Тоже самое можно сказать про ваши аргументы :)

Вы не думали что излишние абстракции как раз от предположений что там будут изменения? Предположение вообще не надежный способ предсказания будущего. Как в одном фильме: “предположение — мать всех провалов”.

Ну я не знаю, я и мои коллеги — мы все делаем предположения. Думаем наперёд. Не знал, что это плохо. Может тогда и думать вообще вредно? :)

Про тестирование — не смешите мои тапочки. У меня было сильно больше одного проекта, где автоматическое тестирование было слишком дорогим занятием. Более того один проект буквально пришлось спасать потому что разработчики так заморочились над тем, чтобы код был тестируемым, что стало невозможно отследить какие фактические параметры передавались и как работала логика.


А прямо сейчас у меня хобби-проект — Разработка мода к игре. в Нем автотесты написать вообще невозможно.

Поддерживаю! Разговоры про авто-тесты это как поговорка, что лучше быть здоровым и богатым, чем бедным и больным. Вроде правда, но достижимо не для всех.
Давайте так. Тесты улучшают качество кода и улучшают качество и скорость сопровождения. Не знаю как у вас, у меня этот тезис подтверждается раз за разом. Тест пишется один раз, потом постоянно окупается. Да, ничего не бывает бесплатно. Но тесты — это хорошая и правильная инвестиция. Мой многолетний опыт это подтверждает. На гитхабе любой уважающий себя и других разработчик обязательно напишет тесты к библиотеке.

Ваш один неудачный опыт вообще не показатель, уж извините меня. А фломастеры «нравится/ненравится писать тесты», обсуждать не очень интересно. Конечно, бывают исключения, но вы на этих исключениях строите свои выводы, что вообще-то неправильно.

Это как спорить с утверждением, что надо вести здоровый образ жизни, приводя в пример условия, где это невозможно, например, боевые действия. И после этого говорить, ну… можно и не вести здоровый образ жизни, так тоже нормально. Речь идёт о полезных советах, а не про все-все условия и обстоятельства в жизни.
Как, на ваш взгляд, стоило перевести слово velocity в данном случае? Спасибо

А вот не знаю честно говоря. Можно поступать как финансисты и не переводить специальные термины. У них факторинг, а у программистов велосити.

Про тестирование — спорно, зависит от проекта. Есть вещи которые тестировать дорого

Что тестировать дорого — можно тестировать реже:
Частота тестирования и проведения code review должна быть соизмерима с вредом, нанесенным проекту в случае провала


По поводу фич — вне компетенции программиста

Ну, кагбэ, да:
Carl Tashian о том, как продакт- и проджект-менеджерам справляться с техническим долгом

Речь разве не про автотесты? Или ещё есть люди которые выпускают код в прдакшн без проверки вручную?

Здесь это есть с точки зрения "не лезь в (технические) долги, если это не очень надо". Конечно, статья очень общая, практически обзорная. Не книга, не справочник, не учебник — одним словом, статья. Однако, пока читал, не заметил здесь вопросов, не относящихся к техническому долгу. Я с другой планеты, да?

Sign up to leave a comment.