Когда разрыв между аналитиком и программистом в понимании сути задачи (и предметной области) настолько большой, что объяснить ее обычным языком достаточно системно становится невозможно, аналитику остается написать набор тестов — формальных ограничений, которым должен соответствовать фрагмент программы.
Юнит тесты не про бизнес и не про требования, а про процесс разработки.
с которыми можно пренебречь принципом единой ответственности например?
Пренебрегать SRP не нужно, просто он:
Как и вся аббревиатура SOLID, сам по себе не отвечает на вопрос, как сделать и какой код считать качественным;
Неоднозначен, часто трактуется по разному(да и виденье принципа у Мартина, собственно, чуть усовершенствовалось с годами, если глянуть старые и последние определения), и по причине озвученной в предыдущем тезисе, часто приводит к необоснованному догматизму.
TDD дает избыточное перекрытие хрупкими некачественными тестами
Вы же помните что качество и хрупкость тестов прямо зависит от качества кода?)
Вот скажите мне, сторонники TDD, зачем мне тестировать юнит-тестами публичный метод репозитория, в котором вызывается десяток методов query-builder'а и собирается результат?
Ничего не даст. Изолируйте сборку запроса от любой логики, чтобы весь метод сборки покрывался единственным интеграционным тестом, а на логику есть юниты.
не соответствует SOLID
…
Если код не соответствует общепринятым базовым паттернам, то это и не шашечки и не ехать. Это велосипед на костылях и замыкание процессов на себя. Потом проще выкинуть, чем внести изменения.
Честно говоря, когда кто-то говорит что у него код «по SOLID», возникают лишь сомнения, потому что, ну, не в SOLID счастье, а в чуть более базовых принципах.
А без TDD разработчики перед написанием кода:
— разве не задумываются что именно они собираются писать?
— разве не погружаются в суть нужд бизнеса?
— разве не учитывают пограничные случаи и возможные трудности при реализации соответствующих механизмов?
— разве не планируют будущее устройство систем в плане их структуры и архитектуры?
При чём здесь TDD?
TDD — инструмент который позволяет делать это эффективнее.
Почитал Википедию по TDD и прозрел.
TDD и обычная разработка одно и тоже, за исключение момента когда начинают писать тесты. Век живи — век учись.
Не совсем. TDD про сам итеративный процесс и некоторые ограничения в виде "сначала пишется код который проходит один тест, потом пишется следующий тест".
Просто написав все тесты до кода вы не получите TDD, это просто test first подход
И да, если ваш логгер бросает исключения, которые (внезапно!) должны логироваться, то честное слово — у вас проблемы побольше чем выразительность PSR. И, пожалуй, я могу понять если это легаси, с которым приходится жить. Но в новых проектах так делать нельзя.
Что не так с требованиями бизнеса не проводить операцию при невозможности записать лог?
Если код сложнее читать — его сложнее поддерживать. Читать его сложнее программисту, который привык писать по стандарту (с долей вероятности превышающей 50% — PSR) отличному от стандарта который вы используете.
Код сложнее читать когда связность выше, зависимостей больше.
А влияние стандарта на это примерно такое же, как скорость набора с двух разных клавиатур с различающимся на миллиметр ходом клавиш.
Стандарты PSR — не безоговорочный идеал.
PSR — это и есть ± общепринятый стандарт.
Тот самый общепринятый стандарт, от того самого PHP-FIG, из которого вышли разработчики всех мейнстрим-фреймворков?
Ну я обычно использую определение «ООП это как в Java». Пусть не особо формальное, но зато ограничивает пространство возможностей, и ООП «по-кею» в него уже не попадает.
А что с практической ценностью?
Чего должно дать это определение кому-то? Зачем оно студентам?
В целом я согласен про парадигмы и студентов. Больше всего я не люблю необоснованный догматизм вокруг этого определения.
Но существование какой-то картины в голове мне не ясно. Звучит как магия.
Парадигма и не должна иметь внятного определения, поскольку она принцип… Это способ взгляда на мир. Эта та картина мира, которая существует в голове программиста, когда он пишет код.
PSR — всего лишь рекомендации — вы не обязаны их соблюдать.
GRASP — всего лишь шаблны — вы не обязаны их использовать.
SOLID — всего лишь принципы — вам не обязательно им следовать.
Принципы проектирования основываются на ± общепринятых конецпциях делающих код проще в поддержке, вроде внутренней/внешней связности модулей(coupling/cohesion), information hiding.
От несоблюдения PSR, связность не повысится, лишний код не появится(а то и уберётся), поддерживать его тяжелее не станет, а может и легче станет, с лучше отражающими реальность интерфейсами(а не логгер который никогда не бросает исключения по интерфейсу, даже если они критичны), нормальным неймингом.
Нет таких законов
А я не про законы, я про практическую ценность конкретных ограничений.
Только Кей изобрел не ООП, а акторную модель. То что он назвал свое изобретение «ООП» и в джаве штука так же называется всего лишь попытка всех запутать.
Кей изобрёл то что изобрёл(youtube, интервью), и назвал это ООП, а было до появления Java, сильно до. Actor Model продолжение тех идей «ООП».
Путаница пошла когда все подряд, в т.ч. Java, C++ и пр. начали использовать модное слово чтобы привлекать больше аудитории.
То что самому Кею название ООП не нравится — да. Вот его «извинение» от 97г. — youtu.be/oKg1hTOQXoY?t=2270, но историю не переписать.
А в данном случае проблема то не в определении, проблема в том что из-за путаницы термином ООП называют всё подряд, и лекции «по ООП» вне исторического контекста смысла не имеют, а когда сами лекторы этого не понимают начинается всякая чушь вроде примеров ООП в виде наследования Moderator от User и пр.
Юнит тесты не про бизнес и не про требования, а про процесс разработки.
То о чём вы говорите это приёмочные / end-to-end
Связи и зависимости. Coupling/Cohesion.
Пренебрегать SRP не нужно, просто он:
Нет, писать юнит-тесты на это могут советовать лишь отдельные фанатики такого же бесполезного 100%-го покрытия юнитами.
Похоже на проблемы с декомпозицией модулей. Держать сотни публичных методов в голове при разработке — явно не хорошо.
Вы же помните что качество и хрупкость тестов прямо зависит от качества кода?)
Ничего не даст. Изолируйте сборку запроса от любой логики, чтобы весь метод сборки покрывался единственным интеграционным тестом, а на логику есть юниты.
Честно говоря, когда кто-то говорит что у него код «по SOLID», возникают лишь сомнения, потому что, ну, не в SOLID счастье, а в чуть более базовых принципах.
Если всё-таки разобраться, что такое ORM и для чего нужны ORM-библиотеки, никаких проблем с производительностью не будет.
«Эта фигня» к ORM не относится. Не используйте Query Build если не хочется.
TDD — инструмент который позволяет делать это эффективнее.
Каким образом?
Возможно стоит поговорить с тем кто требует, объяснить что вчера прошло, расставить приоритеты.
Это часть процесса разработки, а не что-то, что нужно постоянно согласовать в с бизнесом.
Не совсем. TDD про сам итеративный процесс и некоторые ограничения в виде "сначала пишется код который проходит один тест, потом пишется следующий тест".
Просто написав все тесты до кода вы не получите TDD, это просто test first подход
Зато головы студентам знатно засоряют, и рождают множество недопониманий приводящих к догматизму.
Что не так с требованиями бизнеса не проводить операцию при невозможности записать лог?
Код сложнее читать когда связность выше, зависимостей больше.
А влияние стандарта на это примерно такое же, как скорость набора с двух разных клавиатур с различающимся на миллиметр ходом клавиш.
Стандарты PSR — не безоговорочный идеал.
Тот самый общепринятый стандарт, от того самого PHP-FIG, из которого вышли разработчики всех мейнстрим-фреймворков?
А что с практической ценностью?
Чего должно дать это определение кому-то? Зачем оно студентам?
Почему не дать просто принципы проектирования?
Но существование какой-то картины в голове мне не ясно. Звучит как магия.
Принципы проектирования основываются на ± общепринятых конецпциях делающих код проще в поддержке, вроде внутренней/внешней связности модулей(coupling/cohesion), information hiding.
От несоблюдения PSR, связность не повысится, лишний код не появится(а то и уберётся), поддерживать его тяжелее не станет, а может и легче станет, с лучше отражающими реальность интерфейсами(а не логгер который никогда не бросает исключения по интерфейсу, даже если они критичны), нормальным неймингом.
А я не про законы, я про практическую ценность конкретных ограничений.
Современное ООП это чёрти-что без внятного определения, и гораздо полезнее будет изучать что-то более приземлённое.
И какое такое общепринятое определение?
3 Кита — вздор, и с ними полно людей несогласно, да и в чём практическая ценность — не ясно.
Кей изобрёл то что изобрёл(youtube, интервью), и назвал это ООП, а было до появления Java, сильно до. Actor Model продолжение тех идей «ООП».
Путаница пошла когда все подряд, в т.ч. Java, C++ и пр. начали использовать модное слово чтобы привлекать больше аудитории.
То что самому Кею название ООП не нравится — да. Вот его «извинение» от 97г. — youtu.be/oKg1hTOQXoY?t=2270, но историю не переписать.
А в данном случае проблема то не в определении, проблема в том что из-за путаницы термином ООП называют всё подряд, и лекции «по ООП» вне исторического контекста смысла не имеют, а когда сами лекторы этого не понимают начинается всякая чушь вроде примеров ООП в виде наследования Moderator от User и пр.
…
То есть кто такой Алан Кей вы не знаете, а как лекции по ООП читать — пожалуйста.
Только ООП в том определении в котором этот термин появился ничего общего с этими идеями не имеет.
См. —
wiki.c2.com/?AlanKaysDefinitionOfObjectOriented и www.youtube.com/watch?v=fhOHn9TClXY
P.S. Все лекции по ООП которые называют наследование одним из главных принципов — только вредят.