Здравствуйте, Ikemefula, Вы писали:
IT>>Был у нас на одном проекте в IBM архитектор, любитель паттернов и мелких недо функций. I>Я эту легенду слышал лет пятнадцать назад. Похоже, тебе тот орхетектор очень много здоровья отнял.
Двенадцать. Это вообще был мега проект. В плане впечатлений. Совместный проект IBM, Microsoft и Pfizer, 50+ человек одних только девелоперов, светила индустрии, понты выше крыши. Я туда шёл с трясущимися коленями и со словами "чуваки, научите меня правильно жить". Когда уходил, то у меня в жизни больше не осталось авторитетов и были окончательно разрушены все идолы, а светила низвержены с небес и рассеяны по площади щелбонами и поджопниками.
Кстати, Шариш (этот тот самый 1архитектор) со своими жалкими 77-ю классами вскоре был повержен. В соседней команде был один ещё более мега-чувак, Майкл Дрыскал (да, именно так), который решил, что 77 классов смотрятся мелковато и в похожей ситуации залудил 130 классов. Очень любил паттерны и всякие мелкие недометоды.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pzz, Вы писали:
Pzz>Другой вопрос, что разбиение кода на мелкие функции далеко не всегда облегчает его понимание. Поэтому к этому совету надо относиться критически.
Да тут выше холивар на пустом месте. Обе стороны приводят аргументы вида крайних случаев.
Требование к разбиению кода на функции произрастает из требований читабельности. Т.е. разбиение кода на функции должно увеличивать читабельность кода, а не наоборот. Объявление функции/класса, создаёт новую абстракцию, на которую мы можем ссылаться в дальнейшем, что упрощает понимание кода. Но. Это упростит понимание, только в том случае, если абстракция переиспользуется многократно. В противном случае мы лишь повышаем сложность кода ( вместо однократного прямолинейного чтения кода нам требуется изучить абстракцию, запомнить её имя и вернуться в контекст её использования ). Как следствие, зачастую определять новую функцию имеет смысл только для устранения копи-пасты. И вот тут самое главное, различить что называется common code от coincidental code (общий код vs совпадающий код). Сommon code это код, практически всегда не завязан на контекст использования, и фактически является строительным блоком сам по себе ( для классов есть семантически близкое понятие — ADT ). Coincidental code напротив, бессмысленнен вне контекста использования, и наличие идентичного кода это всего лишь совпадение. Скорее всего при попытке вынести совпадающий код в отдельную функцию, для неё будет очень сложно придумать имя (скорее всего это будет очень специфичное имя). И что самое неприятное, вынесение coincidental code в отдельную абстракцию порождает сильное зацепление (coupling) там, где его не должно быть. Типичные примеры common code — алгоритмы. Типичные примеры coincidental code — одинаковые шаги в тест кейсах.
__>не трогая остального кода, чтоли? __>вот стоит человек, прыгает на одной ноге и пытается вилкой суп есть. я ему — ну ты бы ложку хоть взял и прыгать прекращай. а он — это у меня протез ножной заглючил, пытаюсь вот поесть приспособиться. говоришь ему сесть, тот отвечает, что ничего менять не может, хочет стоя. дурацкий способ есть? конечно же. можно ли его сделать нормальным, оставляя человека прыгать на одной ноге? нельзя.
Т.е. ты сова стратег из анекдота?
Жили-были мыши. Все их обижали. Однажды пришли мыши к сове:
-Мудрая сова, помоги! Все нас едят. Скоро нас не останется. Что делать ?
Подумала сова и говорит:
-Мыши! Станьте ежами! Будете колючими и для охотников недоступны.
Побежали мыши радостно:
-Станем ежами! Станем ежами!
Вдруг одна остановилась:
-А кто-нибудь знает: как стать ежами?
Никто. Побежали обратно к сове.
-Сова! А как нам стать ежами???
-Мыши! Идите на хуй! Я не тактик, я — стратег !
Здравствуйте, IT, Вы писали:
IT>Опять лишь штампы, догмы и наклеивания ярлыков. Демагогия, короче. IT>Вот тебе метод на 300 строк. Иди и сделай его в 30 короче.
На плюсах — запросто. Главное, чтобы потом коллеги за шаблонное колдунство не побили
А вообще подобные огромные switch..case зачастую являются гнездом багов. Особенно на языках, бедных средствами статического анализа и автоматического рефакторинга. В отсутствие тестов баги могут оставаться незамеченными годами.
Здравствуйте, WolfHound, Вы писали:
WH>А вот скажи мне как писать тесты до кода если задача ставится так: WH>Сделай хрень, которая должна делать примерно то-то. Возможны небольшие отклонения от идеального решения, ибо идеальное решение будет работать дольше жизни вселенной. WH>При этом нужно уложится в 50 миллисекунд. А лучше в 10.
Элементарно. Наливаем кофе. Чтим кывт. Смотрим трубку. Решаем немного поработать. Дробим задачу на подхрени. IDE не открываем! Потом каждую подхрень дробим на еще более мелкие подхрени. Повторяем, пока не наступает просветление. И только потом открываем IDE и начинаем реализовыать подхрени, выбрав самую маленькую для начала. Покрываем юнит-тестами. По пути наступает еще пара эпизодов просветления.
WH>Имей в виду что при решении таких задач весь код несколько раз переписывается.
При решении задачи методом "шашка наголо" разве что.
Если задачу изначально раздробить, и каждую дробинку протестировать в отдельности, то переписывать скорее всего придется чуть меньше, чем почти ничего.
WH>Запускать все тесты на каждый коммит весьма странная затея.
Ага, тесты должны выполняться при каждой сборке. Еще до коммита.
Здравствуйте, landerhigh, Вы писали:
IT>>Вот тебе метод на 300 строк. Иди и сделай его в 30 короче. L>На плюсах — запросто. Главное, чтобы потом коллеги за шаблонное колдунство не побили
Ну так давай. Зачем дело встало?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>На плюсах — запросто. Главное, чтобы потом коллеги за шаблонное колдунство не побили IT>Ну так давай. Зачем дело встало?
Здравствуйте, IT, Вы писали:
L>>То есть инвестора нет? Жаль, но свободного времени у меня тоже. IT>Т.е. просто так языком потрепать время всегда есть, а поотвечать за свои слова — нет. Всё как обычно
На слабо меня брать бесполезно.
Совершенно верно, время пофлудить при ожидании компиляции есть. Точнее, отметить, что километровые switch..case являются рассадником багов и плохо поддерживаются.
Но доказывать что-то кому-то ценой своего несвободного времени, когда я могу его потратить с заметной отдачей? Зачем?
Здравствуйте, landerhigh, Вы писали:
L>На слабо меня брать бесполезно.
Да кому ты нужен?
L>Совершенно верно, время пофлудить при ожидании компиляции есть. Точнее, отметить, что километровые switch..case являются рассадником багов и плохо поддерживаются.
Такие пустопорожние ответы здесь мало кого интересуют. Покажи код, тогда поговорим.
L>Но доказывать что-то кому-то ценой своего несвободного времени, когда я могу его потратить с заметной отдачей? Зачем?
У людей, любящих только потрепать языком есть два стандартных ответа: "это секретная информация" и "у меня нет на это времени". Впрочем, признаю, ты внёс в это небольшое разнообразие, предлагая оппоненту заплатить ему за доказательство тобой твоей собственной точки зрения.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>На слабо меня брать бесполезно. IT>Да кому ты нужен?
Слив защитан.
L>>Совершенно верно, время пофлудить при ожидании компиляции есть. Точнее, отметить, что километровые switch..case являются рассадником багов и плохо поддерживаются. IT>Такие пустопорожние ответы здесь мало кого интересуют. Покажи код, тогда поговорим.
Код чего?
L>>Но доказывать что-то кому-то ценой своего несвободного времени, когда я могу его потратить с заметной отдачей? Зачем? IT>У людей, любящих только потрепать языком есть два стандартных ответа: "это секретная информация" и "у меня нет на это времени". Впрочем, признаю, ты внёс в это небольшое разнообразие, предлагая оппоненту заплатить ему за доказательство тобой твоей собственной точки зрения.
Я заявил две вещи. Первое, что на плюсах подобные длинные switch..case зачастую можно вообще убрать с помощью шаблонной магии (все подобное делали), а второе — что поддерживать такую колбасу очень сложно, внести баг, который никак себя не будет проявлять годами проще пареной репы. С чем ты не согласен?
Здравствуйте, landerhigh, Вы писали:
L>Слив защитан.
Дружище, я вижу ты ещё и большой специалист по сливам
L>Я заявил две вещи. Первое, что на плюсах подобные длинные switch..case зачастую можно вообще убрать с помощью шаблонной магии (все подобное делали), а второе — что поддерживать такую колбасу очень сложно, внести баг, который никак себя не будет проявлять годами проще пареной репы. С чем ты не согласен?
Твои заявления мало интересны. Покажи код как ты "с помощью шаблонной магии" и всё такое. Просто слов мы тут уже достаточно наслушались и сами наговорили. Давай код.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>Я заявил две вещи. Первое, что на плюсах подобные длинные switch..case зачастую можно вообще убрать с помощью шаблонной магии (все подобное делали), а второе — что поддерживать такую колбасу очень сложно, внести баг, который никак себя не будет проявлять годами проще пареной репы. С чем ты не согласен? IT>Твои заявления мало интересны. Покажи код как ты "с помощью шаблонной магии" и всё такое. Просто слов мы тут уже достаточно наслушались и сами наговорили. Давай код.
А если покажу? Примера под рукой нет, надо поискать или набросать.
Здравствуйте, IT, Вы писали:
IT>Вот тебе метод на 300 строк. Иди и сделай его в 30 короче.
Не в тему холивара о длине функций, но пришлось не так давно, и уже не первый раз, писать подобное для JavaScript. Свой код не буду приводить (там еще производятся действия, которые будут отвлекать от сути), но например вот 15 строк кода который траверсит весь AST JavaScript-а. Идея в обходе всех объектных свойств вместо хардкода путей обхода, структура этого AST это позволяет. Твой метод Visit читал не досконально, но теоретически ведь можно в твоем случае без хардкода структуры обхода просто делать перебор свойств типа Expression (или типа коллекции/массива Expression) у переданного в Visit объекта, и вызывать Visit для значений этих свойств (или свойств элементов коллекции Expression), если порядок обхода свойств не важен?
Если нам не помогут, то мы тоже никого не пощадим.
