Sergey

декомпозицию и т.д.

Sergey

говорят помогает

Sergey

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

Sergey

они сначала делают и потом уже задают вопросы когда "не работает"

Sergey

потому такие практики как TDD и выдумывают

Sergey

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

Sergey

(воприки мнению что это про тесты)

Sergey

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

Sergey

и формировать какие-то критерии приемки и т.д. выстраивать более четкую декомпозицию (потому что с херовой декомпозицией неудобно тесты писать)

fink3L

и формировать какие-то критерии приемки и т.д. выстраивать более четкую декомпозицию (потому что с херовой декомпозицией неудобно тесты писать)

ну это уже можно делать после того как у тебя получился один огромный метод

fink3L

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

Sergey

но если ты сделаешь это ДО у тебя не будет тратиться время на этот огромный метод

Sergey

хотя прототипы делать иногда полезно

Sergey

> и правильного мышления это не добавит, просто загонит тебя в рамки, где будет сложно сделать не правильно цель этого всего заставить тебя думать ДО того как ты напишешь этот жирый метод)

Sergey

так с точки зрения времени и трудозатрат эффективнее выходит

Sergey

1 час на жирный метод, 0.25 часа подумать, 0.5 час тест, 0.5 час реализация

Sergey

0.25 часа подумать, 0.5 час тест, 0.75 час реализация

Sergey

что быстрее?

Sergey

я понимаю, я к тому что.... а ты уверен что с точки зрения эффективности это правильно? (хотя я не видел код потому ничего не могу судить)

Иногда эффективен иногда - нет. Бывает что бизнкс требования свои сам не понял, бывает я накосячил.

Sergey

0.25 часа подумать, 1 час реализация, 0.5 часа тест, 0.25 часа рефакторинг кода что бы тесты норм писались, 0.25 часа дописать тесты

Sergey

Иногда эффективен иногда - нет. Бывает что бизнкс требования свои сам не понял, бывает я накосячил.

для первого - есть BDD, а второе это нормально

Ilia

И с жирным методом каждая доделала это боль и большее время на ее поддержку

Sergey

не косячат только роботы, но поскольку их делают люди то....

fink3L

И с жирным методом каждая доделала это боль и большее время на ее поддержку

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

Ilia

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

Так не делай их)))

fink3L

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

fink3L

хз как это объяснить

Sergei

Я ортодоксальную мысль выскажу - "жирные методы" это ни хорошо, ни плохо. Это - "никак". Мне всё равно, как написано внутри STL. Абсолютно всё равно. Почему? Потому что мне нет нужды разбираться в том, как оно работает. Мой вывод: нет "жирных" и "тощих" методов - есть те, которые (а) необходимо поддерживать и (б) непонятно как работают - и вот они-то и есть беда. Соответственно бороться разумно и полезно "за читаемость", а не "с толщиной".

🐴

Я ортодоксальную мысль выскажу - "жирные методы" это ни хорошо, ни плохо. Это - "никак". Мне всё равно, как написано внутри STL. Абсолютно всё равно. Почему? Потому что мне нет нужды разбираться в том, как оно работает. Мой вывод: нет "жирных" и "тощих" методов - есть те, которые (а) необходимо поддерживать и (б) непонятно как работают - и вот они-то и есть беда. Соответственно бороться разумно и полезно "за читаемость", а не "с толщиной".

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

Sergey

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

Ну влияет, да - это цена, которую ты/команда платишь )

🐴

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

🐴

Вот че надыбал