Здравствуйте, __kot2, Вы писали:

__>маленькие ф-ии это еще полдела. они должны быть названы так, чтобы по названию было понятно, что она делает, не заглядывая внутрь. и сами классы тоже должны быть маленькими и называться не datahelper, а так, чтобы вы могли понять что делает этот класс, не заглядывая в него. так, например, ф-ия работы с временной зоной не должна находиться внутри utils.cs и являться частью класса datetimehelper, она должна называться timezone и находиться в модуле timezone или хотя бы datetime

Понятное именование и хорошее структурирование это как бы само собой разумеещееся.. Только я не понял про функцию работы с временной зоной, которая должна находиться в модуле timezone. Что тут подразумевается под модулем? И ещё, что плохого если функция будет находиться, например, в классе DateTimeExtensions (предоставляющем extension methods для DateTime)?

__>и вам не придется никуда прыгать по коду, так как класс timezone описывает временную зону и странно ожидать там что-то другое

А если мне надо посмотреть как оно там работает? Если ко мне подходит бизнес-аналитик и просит посмотреть как работает расчет Number of Shares in Issuance, потому что возможно где-то в алгоритме у нас ошибка? Если у меня есть метод CalculateNSI(Issuer issuer) на 1 экран (как сейчас реально есть), я просто открою его и всё будет на ладони. Если же я его открою, а там вызовы других функций, я начну в них заходить, смотреть что там делается, возвращаться, заходить в следующую функцию и т.д.

MC>>В результате я как-то забросил подход с микро-функциями и все эти субъективные лимиты (в 5-10 строк, полэкрана, 1 экран, 2 экрана, 30 строк и т.д.) и тупо продолжил писать по ситуации: вижу что лучше сделать extract method — делаю, если функция на 1-2 экрана отлично читается линейно или её сложно уменьшить — оставляю как есть.
__>а тесты?

Тесты как писались, так и пишутся

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

Exception : The timeout period elapsed prior to completion of the sentence parsing.

__>но скорее всего вы плюнете на эту задумку и оставите только функциональные тесты, время выполнения которых постепенно докатится до 4 часов на коммит

У меня несколько сот написанных мной тестов (вперемешку, юнит- и функциональных) выполняются где-то минуту. Что я делаю не так?

__>и вы, наконец, поймете, в чем разница между юнит тестами и функциональными.

А в чём разница? Может я правда её до сих пор не знаю, судя по тому что вы (я перейду обратно на вы, кажется вам так комфортнее) написали? Или вы просто думаете, что вокруг вас только вчерашние студенты, не знающие разницы (ну или "старпёры застрявшие в 90-х")?

Здравствуйте, __kot2, Вы писали:

__>маленькие ф-ии это еще полдела. они должны быть названы так, чтобы по названию было понятно, что она делает, не заглядывая внутрь. и сами классы тоже должны быть маленькими и называться не datahelper, а так, чтобы вы могли понять что делает этот класс, не заглядывая в него. так, например, ф-ия работы с временной зоной не должна находиться внутри utils.cs и являться частью класса datetimehelper, она должна называться timezone и находиться в модуле timezone или хотя бы datetime

Понятное именование и хорошее структурирование это как бы само собой разумеещееся.. Только я не понял про функцию работы с временной зоной, которая должна находиться в модуле timezone. Что тут подразумевается под модулем? И ещё, что плохого если функция будет находиться, например, в классе DateTimeExtensions (предоставляющем extension methods для DateTime)?

__>и вам не придется никуда прыгать по коду, так как класс timezone описывает временную зону и странно ожидать там что-то другое

А если мне надо посмотреть как оно там работает? Если ко мне подходит бизнес-аналитик и просит посмотреть как работает расчет Number of Shares in Issuance, потому что возможно где-то в алгоритме у нас ошибка? Если у меня есть метод CalculateNSI(Issuer issuer) на 1 экран (как сейчас реально есть), я просто открою его и всё будет на ладони. Если же я его открою, а там вызовы других функций, я начну в них заходить, смотреть что там делается, возвращаться, заходить в следующую функцию и т.д.

MC>>В результате я как-то забросил подход с микро-функциями и все эти субъективные лимиты (в 5-10 строк, полэкрана, 1 экран, 2 экрана, 30 строк и т.д.) и тупо продолжил писать по ситуации: вижу что лучше сделать extract method — делаю, если функция на 1-2 экрана отлично читается линейно или её сложно уменьшить — оставляю как есть.
__>а тесты?

Тесты как писались, так и пишутся

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

Exception : The timeout period elapsed prior to completion of the sentence parsing.

__>но скорее всего вы плюнете на эту задумку и оставите только функциональные тесты, время выполнения которых постепенно докатится до 4 часов на коммит

У меня несколько сот написанных мной тестов (вперемешку, юнит- и функциональных) выполняются где-то минуту. Что я делаю не так?
В Linq2db (это тот самый проект с "непродуманной архитектурой", из которого приводили метод на 250-300 строк) 40000 тестов выполняются 15 минут. Как так?

__>и вы, наконец, поймете, в чем разница между юнит тестами и функциональными.

А в чём разница? Может я правда её до сих пор не знаю, судя по тому что вы (я перейду обратно на вы, кажется вам так комфортнее) написали? Или вы просто думаете, что вокруг вас только вчерашние студенты, не знающие разницы (ну или "старпёры застрявшие в 90-х")?