KK
Хорошо - будешь первым разработчиком, который девелопит 100% по заветам TDD
Size: a a a
2020 January 27
А⚙
Познакомимся?
Влад, тиндер в другом окне
VB
Вечно все любят в крайности ударяться. Либо 100% покрытие, либо 0%.
Но тип нет, так не работает.
Но тип нет, так не работает.
KK
Лично у меня процесс проектирования совмещён с написанием кода - мне так проще всё продумывать. Сразу вижу как идеи выглядят в коде. И если мне не нравится - думаю дальше и пишу другой код.
А что бы написать тест - надо уже, как минимум, представлять интерфейс будущей реализации и что она вообще будет делать. Т.е. надо сначала всё спроектировать "на бумажке". У меня такое может получится только для совсем очевидных, типовых задач.
А что бы написать тест - надо уже, как минимум, представлять интерфейс будущей реализации и что она вообще будет делать. Т.е. надо сначала всё спроектировать "на бумажке". У меня такое может получится только для совсем очевидных, типовых задач.
DF
Интересный аргумент
AZ
Лично у меня процесс проектирования совмещён с написанием кода - мне так проще всё продумывать. Сразу вижу как идеи выглядят в коде. И если мне не нравится - думаю дальше и пишу другой код.
А что бы написать тест - надо уже, как минимум, представлять интерфейс будущей реализации и что она вообще будет делать. Т.е. надо сначала всё спроектировать "на бумажке". У меня такое может получится только для совсем очевидных, типовых задач.
А что бы написать тест - надо уже, как минимум, представлять интерфейс будущей реализации и что она вообще будет делать. Т.е. надо сначала всё спроектировать "на бумажке". У меня такое может получится только для совсем очевидных, типовых задач.
просто типичный up/down down/up проектирование
AZ
в тдд ты говоришь "я буду отправлять сообщения в сервис заказов", а как он устроен ты не думаешь
AZ
подход снизу-вверх нарушает инверсию контроля
λ
Дайте и я вставлю свои 5 копеек))
Действительно, если у вас публичное API и вам его долго поддерживать, то тдд будет хоть и тормозить на начальном этапе разработку, но в дальнейшем это сослужит огромную службу
Но в основном программы это не публичное API, и задачи обычно идут чехардой и нет времени сначало писать тест, а потом писать код, да в итоге это поддерживать становится сложно, но это обычно никому не интересно, потому что потом продукт может и переписаться с нуля, когда (и если) все устаканиться)))
Действительно, если у вас публичное API и вам его долго поддерживать, то тдд будет хоть и тормозить на начальном этапе разработку, но в дальнейшем это сослужит огромную службу
Но в основном программы это не публичное API, и задачи обычно идут чехардой и нет времени сначало писать тест, а потом писать код, да в итоге это поддерживать становится сложно, но это обычно никому не интересно, потому что потом продукт может и переписаться с нуля, когда (и если) все устаканиться)))
Тдд это же не про публичное апи, а повсеместный белый ящик
λ
А вообще тдд плохо работает с неполными требованиями, когда разработка с ресерчем чередуются.
λ
Можно ещё упомянуть Рича Хикки (хоть я его не люблю, но то что он кое в чём смыслит сомнений думаю не возникает).
Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design.
Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design.
Рич Хикки упоротый поклонник монотипизации
NL
Рич Хикки упоротый поклонник монотипизации
в смыле "поклонник"?
λ
короче, он говорит, что TDD часто не самое разумное на что можно потратить время 😊
Хотя тут он прав
λ
в смыле "поклонник"?
Да
A
Тдд это же не про публичное апи, а повсеместный белый ящик
Именно 🙂 И изначальное высказывание человека про тдд именно об этом, потому что очень и очень редко, когда тз заранее все известно, редко публичное апи и т.д.
NL
Да
Своё не очень восторженное отношение к его выступлениям я уже выражал здесь:
https://t.me/haskell_blah/138179
https://t.me/haskell_blah/138179
λ
Своё не очень восторженное отношение к его выступлениям я уже выражал здесь:
https://t.me/haskell_blah/138179
https://t.me/haskell_blah/138179
Ну в целом это всегда так
λ
У сторонников нормальных типов аргументы, а у сторонников монотипизации софизм, диалектика и прочая философия
λO
тдд ведёт к плохому дизайну
λ
тдд ведёт к плохому дизайну
Интересно