Архитектор из дома

[Alexandr]

А ТДД, это там где вначале тесты пишут, а потом код?

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

Нет это как раз таки наоборот - сначала надевают чтобы потом не поймать чего не надо незаметно

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

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

[Интеррапт]

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

Когда конструкция с глубоко внедренными багами уже устоялась - тесты писать к какой-то 10-й версии уже поздно, собственно как и пить боржоми.

[Интеррапт]

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

Так при TDD вначале свет и включается, т.к. вначале описываешь идеальную даму, которая тебе нравится, а нет так, что снял первую попавшуюся даму (т.к. очень приспичило), в этот же день повел в ЗАГС, а потом вдруг начинают всплывать все недостатки. Поменять конечно можно, но связано с разводами и прочей головной болью.

[Alexandr]

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

Когда конструкция с глубоко внедренными багами уже устоялась - тесты писать к какой-то 10-й версии уже поздно, собственно как и пить боржоми.

ну под устоялась можно разное понимать. В моем понимании устоялась - это, когда интерфейс класса понятен и принят, а не, когда уже кучу всего написано.

[Сабина]

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

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

Нашим языком ?
Ну тогда вот вам аналогия. Можно на дам ходить смотреть в Стенфорд на курсы салсы, а можно искать на матч доткоме. В зависимости от выбранного с начала подхода получите очень разный результат . Что интересно в жизни знакомые одинокие русские программисты все же предпочитают в Стенфорд

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

[Alexandr]

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

Так при TDD вначале свет и включается, т.к. вначале описываешь идеальную даму, которая тебе нравится, а нет так, что снял первую попавшуюся даму (т.к. очень приспичило), в этот же день повел в ЗАГС, а потом вдруг начинают всплывать все недостатки. Поменять конечно можно, но связано с разводами и прочей головной болью.

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

[Alexandr]

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

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

Нашим языком ?
Ну тогда вот вам аналогия. Можно на дам ходить смотреть в Стенфорд на курсы салсы, а можно искать на матч доткоме. В зависимости от выбранного с начала подхода получите очень разный результат . Что интересно в жизни знакомые одинокие русские программисты все же предпочитают в Стенфорд

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

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

[Интеррапт]

ну под устоялась можно разное понимать. В моем понимании устоялась - это, когда интерфейс класса понятен и принят, а не, когда уже кучу всего написано.

Ну нет, так дело не поймет, посколько я так понимаю, что вы с TDD дело не имели, правильно? Иначе бы не приводили в качестве аргумента "это, когда интерфейс класса понятен и принят", т.к. это ну никак не противоречит TDD. Наоборот это самая первая стадия - когда к интерфейсу пишутся tests stubs для последующей имплементации процесса red/green/refactor.

[Alexandr]

ну под устоялась можно разное понимать. В моем понимании устоялась - это, когда интерфейс класса понятен и принят, а не, когда уже кучу всего написано.

Ну нет, так дело не поймет, посколько я так понимаю, что вы с TDD дело не имели, правильно? Иначе бы не приводили в качестве аргумента "это, когда интерфейс класса понятен и принят", т.к. это ну никак не противоречит TDD. Наоборот, к интерфейсу могут писаться tests stubs для имплементации процесса red/green/refactor.

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

[Интеррапт]

ну под устоялась можно разное понимать. В моем понимании устоялась - это, когда интерфейс класса понятен и принят, а не, когда уже кучу всего написано.

Ну нет, так дело не поймет, посколько я так понимаю, что вы с TDD дело не имели, правильно? Иначе бы не приводили в качестве аргумента "это, когда интерфейс класса понятен и принят", т.к. это ну никак не противоречит TDD. Наоборот, к интерфейсу могут писаться tests stubs для имплементации процесса red/green/refactor.

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

В смысле "и уж точно у меня нету такого, что сначала пишутся все тесты"? А разве кто-то утверждал, что нужно все приложение сначала в виде тестов описывать? TDD декларирует, что написание тестов должно быть для new feature, после чего уже идет имплементация этой фичи. А фича из себя может представлять как и небольшой кусочек класса, так и несколько классов, в зависимости, что это за фича, но уж никак не приложение целиком. Само приложение может из сотен фич состоять.
Вообщем получается, что вы используется в той или иной мере TDD подход и при этом против него же и ополчились

[Alexandr]

ну под устоялась можно разное понимать. В моем понимании устоялась - это, когда интерфейс класса понятен и принят, а не, когда уже кучу всего написано.

Ну нет, так дело не поймет, посколько я так понимаю, что вы с TDD дело не имели, правильно? Иначе бы не приводили в качестве аргумента "это, когда интерфейс класса понятен и принят", т.к. это ну никак не противоречит TDD. Наоборот, к интерфейсу могут писаться tests stubs для имплементации процесса red/green/refactor.

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

В смысле "и уж точно у меня нету такого, что сначала пишутся все тесты"? А разве кто-то утверждал, что нужно все приложение сначала в виде тестов описывать? TDD декларирует, что написание тестов должно быть для new feature, после чего уже идет имплементация этой фичи. А фича из себя может представлять как и небольшой кусочек класса, так и несколько классов, в зависимости, что это за фича, но уж никак не приложение целиком. Само приложение может из сотен фич состоять.
Вообщем получается, что вы используется в той или иной мере TDD подход и при этом против него же и ополчились

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

ЗЫ про тесты для всего приложения никто не говорил (я себе представил сие, смешно выглядит )

[Интеррапт]

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

Нет, ну можно конечно и так, но для себя я в таком подходе особых преймуществ не вижу. Прежде чем писать функцию, я как бы пытаюсь точно осмыслить - для чего мне нужна эта функция и что я ею решаю. Что на входе, что на выходе. Пишу это в виде теста, который сначала fail (red), а потом уже добавляю имплементацию, которая удовлетворит моим условиям (green). Не совсем понимаю, зачем мне этот процесс на несколько этапов разбивать, в таком случае я скорее всего и на несколько функций разобью, которые можно отдельно протестировать. Я конечно не говорю, что не случается такого, что тесты потом дописываются - это сплошь и рядом, но это как бы не должно быть правилом, с точки зрения TDD.
Но собственно пишите ес-но так, как вам удобней, я для себя выбрал подход (TDD), который во многих случаях мне подходит больше. И в принципе могу с уверенностью сказать, что это качество моего кода таки улучшило, многие ошибки отлавливаются намного быстрее.

[Alexandr]

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

Нет, ну можно конечно и так, но для себя я в таком подходе особых преймуществ не вижу. Прежде чем писать функцию, я как бы пытаюсь точно осмыслить - для чего мне нужна эта функция и что я ею решаю. Что на входе, что на выходе. Пишу это в виде теста, который сначала fail (red), а потом уже добавляю имплементацию, которая удовлетворит моим условиям (green). Не совсем понимаю, зачем мне этот процесс на несколько этапов разбивать, в таком случае я скорее всего и на несколько функций разобью, которые можно отдельно протестировать. Я конечно не говорю, что не случается такого, что тесты потом дописываются - это сплошь и рядом, но это как бы не должно быть правилом, с точки зрения TDD.
Но собственно пишите ес-но так, как вам удобней, я для себя выбрал подход (TDD), который во многих случаях мне подходит больше. И в принципе могу с уверенностью сказать, что это качество моего кода таки улучшило, многие ошибки отлавливаются намного быстрее.

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

[Alexandr]

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

[olis]

Для того чтобы тесты писать индусы существуют

[АццкоМото]

А ТДД, это там где вначале тесты пишут, а потом код?

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

Нет это как раз таки наоборот - сначала надевают чтобы потом не поймать чего не надо незаметно

Это смотря с какой стороны посмотреть.
В любом случае, поведение системы должно быть специфицировано в требованиях, а не в тестах. А тесты обязан писать независимый от разработчика чел.
Пример: нужно мне было намедни отсортировать серверы в порядке top traffic consumers. При этом у каждого сервера свой лимит трафика и, по логике, если 1 сервер истратил 1ГБ из 2ГБ лимита, то он израсходовал кагбэ больше, чем тот, что истратил 10 из 100. Т.е. сортируем по проценту расходования от лимита. Ок, не вопрос. Но у некоторых серверов лимит - 0. Ну, я чешу жжжж голову и считаю, что если такие сервера переслали хоть байт, то это воообще самые злостные нарушители и их нужно сортировать по общему количеству трафика и ставить перед всеми остальными. И, смею заверить, написать и тест несложно и код под него. Или наоборот. И этот баг там так бы и остался на всегда - ибо, как оказалось, лимит 0 - это безлимит. И живой тестер об этом знал, а я - нет. Почему так произошло? Потому что такое поведение не зафиксировано в требованиях. Что бы дал ТДД? Ничего, кроме еще большей путаницы и исправления одной проблемы в нескольких местах

[Интеррапт]

Для того чтобы тесты писать индусы существуют

Использовать TDD или нет - это конечно каждому решать для себя (ну и конечно можно придумать кучу нерелевантных примеров, когда якобы TDD не поможет, забывая, что TDD это не волшебная панацея, а просто очень полезный инструмент). А вот по поводу индусов и тестов, то юнит тесты должен писать сам разработчик ес-но. Чтобы юнит тесты писал не сам разработчик, а другой человек - это в большинстве случаев выглядит как полное непонимание, для чего нужны юнит тесты и какова их роль в девелопменте продукта (это не к вам ес-но относится, а в целом, но я видел, когда хорошие разработчики забивали на тесты и в процессе разработки вылазили косяки, которые очень легко было бы избежать обычным покрытием тестами). А вот functional tests или какой-то performance tests - это должны, как правило, другие люди писать (если конечно позволяют ресурсы). Отдельной строкой стоит integration tests - тут обычно как сам девелопер может участвовать, так и другой человек.

[X37WAL!^]

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

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

Синглтон, как уже давно доказано - это анти-паттерн, ибо не тестируется. А вот а-фэктори - это таки да, наше всё

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

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

[X37WAL!^]

А ТДД, это там где вначале тесты пишут, а потом код?

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

Нет это как раз таки наоборот - сначала надевают чтобы потом не поймать чего не надо незаметно

Это смотря с какой стороны посмотреть.
В любом случае, поведение системы должно быть специфицировано в требованиях, а не в тестах. А тесты обязан писать независимый от разработчика чел.
Пример: нужно мне было намедни отсортировать серверы в порядке top traffic consumers. При этом у каждого сервера свой лимит трафика и, по логике, если 1 сервер истратил 1ГБ из 2ГБ лимита, то он израсходовал кагбэ больше, чем тот, что истратил 10 из 100. Т.е. сортируем по проценту расходования от лимита. Ок, не вопрос. Но у некоторых серверов лимит - 0. Ну, я чешу жжжж голову и считаю, что если такие сервера переслали хоть байт, то это воообще самые злостные нарушители и их нужно сортировать по общему количеству трафика и ставить перед всеми остальными. И, смею заверить, написать и тест несложно и код под него. Или наоборот. И этот баг там так бы и остался на всегда - ибо, как оказалось, лимит 0 - это безлимит. И живой тестер об этом знал, а я - нет. Почему так произошло? Потому что такое поведение не зафиксировано в требованиях. Что бы дал ТДД? Ничего, кроме еще большей путаницы и исправления одной проблемы в нескольких местах

Тут не надо путать тесты разного уровня. Требования к системе в целом с точки зрения юзера или требования к модулю (у которого внутри может быть сотня классов) разумеется должны быть сформулированы юзером или архитектором системы. И они при написании требований должны заодно приблизительно прикинуть, как именно их требования будут тестироваться. А вот поведение каждого из мелких классов внутри - это уже лично девелопера. Если он решил, что некая функция модуля будет реализована при помощи трёх новых классов, то вот тут-то TDD ему и поможет писать первый класс, когда второго и третьего ещё вообще не существует.
В вашем конкретном примере вся путаница была бы локализована в одном единственном классе, который имплементирует (что-нибудь типа) IComparable. И в процессе написания трёх-четырёх примитивных тестов для него вы по идее должны были бы задуматься над пресловутым нулём, который вы должны были подсунуть в одном из тестов. И может быть снять трубку и переспросить тестера. К сожалению мы часто считаем, что некая операция "тривиальна", пихаем её за компанию внутрь класса, который делает что-то сршенно другое...

[NYgal]

Я вот только не могу понять, как с обсуждения позиции архитекта перешли плавно на кодировсчиков?

Ну никто не мешает вам высказаться по изначальной теме и вернуть дискуссию в правильное русло.

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

[Интеррапт]

Я вот только не могу понять, как с обсуждения позиции архитекта перешли плавно на кодировсчиков?

Ну никто не мешает вам высказаться по изначальной теме и вернуть дискуссию в правильное русло.

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

Ну свернула тема в оффтопик, все-равно по делу уже мало было высказываний, вам жалко что-ли?

[NYgal]

Я вот только не могу понять, как с обсуждения позиции архитекта перешли плавно на кодировсчиков?

Ну никто не мешает вам высказаться по изначальной теме и вернуть дискуссию в правильное русло.

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

Ну свернула тема в оффтопик, все-равно по делу уже мало было высказываний, вам жалко что-ли?

В том-то и дело, что картина для архитекторов на разных побережьях - разная.
Могу что-то внятное сказать о восточном поберезье, если интересно:
на свободный график с работой из дому можно попасть 2-мя путями:
1, Старые контакты, хорошо знают, берут, потому что знают, что будет результат.
2. Новый контракт, сначала сильно нарабатывается авторитет, есть уже успешные проектики или ступеньки в проекте, или "подвиги" в маинтенанце чего-то уже существующего,
тогда можно уже руки выкручивать нащет расписания, работы из дому, ухода с полдня по необходимости и тд. Но результат давать надо все равно постоянно.

Ето - насчет атрибута "работа из дому".
Насчет скиллс и круга обязанностей архитектора - и так вроде понятно. Но все равно все сворачивается на код. В лучшем случае в обсуждение включайтся методики рзработки и QA

[Интеррапт]

...

Ну вот подтянулись люди, кто в теме

[Zorkus]

А ТДД, это там где вначале тесты пишут, а потом код?

Ага. Ну т.е. не полностью конечно тесты для всего приложения сразу пишутся, а для определенной единицы (например, класса). Фактически при помощи тестов вначале описывается спецификация, что собственно этот класс/модуль умеет делать и какие результаты ожидаются от той или иной операции, а уже потом под него имплементируется функциональность.

Для меня ТДД был просто пустой концепции ей пока я не увидела ее хорошее исполнение, с тех пор нет вопроса что именно так и надо делать по уму

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

Так ты еще и аджайл исповедуешь?

[Ljolja]

Нет, ну можно конечно и так, но для себя я в таком подходе особых преймуществ не вижу. Прежде чем писать функцию, я как бы пытаюсь точно осмыслить - для чего мне нужна эта функция и что я ею решаю. Что на входе, что на выходе. Пишу это в виде теста, который сначала fail (red),

т.е. сразу делается fake substitute? иначе тест не пройдет компиляцию

а потом уже добавляю имплементацию, которая удовлетворит моим условиям (green).

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

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

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

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

с опытом / набиванием руки многие ошибки уже не делаются, отлавливать не особенно чего надо (don't take it personally)