Здравствуйте, Ночной Смотрящий, Вы писали:

LB>>Зато разворачиватели строк спроектируют тебе такую write-only архитектуру

НС>Последнее время "архитектура" это одно из тех слов, при виде которых у меня рука тянется к маузеру. Уж лучше код вообще без намеков на структуру, нежели код с Архитектурой.

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

НС>Буквально на той неделе прилетел код на проверку. О там архитектура, да! Ради 4 осмысленных примитивных строк, вызываемых ровно один раз, создан класс-стратегия, к нему привинчен отдельный интерфейс, а потом все это запихнуто в IoC контейнер.

Вам попалась архитектура курильщика.
Плавали, знаем. Я работал на проекте, где предшественники были просто одержимы использованием design patterns. Даже вокруг простого чтения/записи файла была навернута Мощная Инфраструктура с фабриками, стратегиями, адаптерами и прочим добром. Можете себе представить, что там было в более сложных компонентах! Видимо, на собеседовании у кандидатов в жесткой форме требовали знания и применения design patterns. В общем, после рефакторинга были снесены нафиг несколько сотен бесполезных классов и все стало просто и понятно.

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

НС>>Буквально на той неделе прилетел код на проверку. О там архитектура, да! Ради 4 осмысленных примитивных строк, вызываемых ровно один раз, создан класс-стратегия, к нему привинчен отдельный интерфейс, а потом все это запихнуто в IoC контейнер.

CM>Всего навсего?

Там таких стратегий десяток точно наберется. В итоге код на пару классов с несколькими статическими методами раздут до целого проекта.

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

НС>>Последнее время "архитектура" это одно из тех слов, при виде которых у меня рука тянется к маузеру. Уж лучше код вообще без намеков на структуру, нежели код с Архитектурой.
LB>Не соглашусь. Лучше иметь хоть дурацкое, но единообразие в построении проекта. По крайней мере тогда, когда лезешь в неизведанную его часть, понятно чего ожидать и как с этим бороться

Сложно с этим бороться. Рефакторить такое порно очень тяжело. Хуже только копипаста.0

LB>Вам попалась архитектура курильщика.

Нет, мне попалось черезмерное увлечвение архитектурой. Архитектура ради архитектуры, та, которая идет впереди кода и требований.

LB> Видимо, на собеседовании у кандидатов в жесткой форме требовали знания и применения design patterns.

Нет, просто кто то ему рассказал про то, что архитектура это такая серебряная пуля.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Там таких стратегий десяток точно наберется. В итоге код на пару классов с несколькими статическими методами раздут до целого проекта.

Это еще не так страшно. Я видел экземпляры куда хуже.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Сложно с этим бороться. Рефакторить такое порно очень тяжело. Хуже только копипаста.0

Никто не обещал что будет легко.

НС>Нет, мне попалось черезмерное увлечвение архитектурой. Архитектура ради архитектуры, та, которая идет впереди кода и требований.

Архитектура курильщика и есть. Смотришь и думаешь: что они курили?

LB>> Видимо, на собеседовании у кандидатов в жесткой форме требовали знания и применения design patterns.

НС>Нет, просто кто то ему рассказал про то, что архитектура это такая серебряная пуля.

Просто они пока не умеют ее правильно готовить

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

LB>Вам попалась архитектура курильщика.

Насколько я помню, Хант писал, что любовь к ненужным переусложнениям обычно просыпается у программистов, когда они переходят от стадии "новичок" к стадии "продвинутый новичок". С переходом на стадию "компетентный" это проходит, но есть одна проблема — большинство программистов навсегда застревают на стадии продвинутого новичка.

S>>Я про такие трюки слышал, что-то вроде "это будер быстрее на уровне процессора(транзистрово), чем обычное присвоение" (как-то так, не факт, что про xor).
CC>Дык не будет же

Это щас не будет. А вот в 80-х годах прошлого тысячелетия...

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

НС>Буквально на той неделе прилетел код на проверку. О там архитектура, да! Ради 4 осмысленных примитивных строк, вызываемых ровно один раз, создан класс-стратегия, к нему привинчен отдельный интерфейс, а потом все это запихнуто в IoC контейнер.

Ну, о чем на собеседовании спрашивали — то и в production применили.

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

M>Ну, о чем на собеседовании спрашивали — то и в production применили.

Как заказывали!

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

НС>>Там таких стратегий десяток точно наберется. В итоге код на пару классов с несколькими статическими методами раздут до целого проекта.
CM>Это еще не так страшно. Я видел экземпляры куда хуже.

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

Здравствуйте, Тёмчик, Вы писали:

Тё>А потом не может развернуть строку за O(n).
Если соответствующий код является узким местом, то разворачивать в нем строку за O(n) — это охрененный удар по производительности. Перед исполнением высокооптимизированного кода данные должны быть максимально хорошо подготовлены, чтобы лишних операций не требовалось бы делать вообще. И нормальноая асимптотика будет только константа, в крайнем случае будет логарифм, связанный с тем, что тебе приходится еще и экономить память, потому придется жертвовать быстродействием в обмен на экономию памяти. И вообще, высокооптимизированный код — он не об алгоритмах. Он об оптимальном размещении данных. Соответственно строка должна быть уже развернута, она должна храниться именно в развернутом виде, если скорость важна. А как ты будешь ее разворачивать на этапе подготовки данных — в 99 процентов случаях пофиг, достаточно чтоб сложность разворота была бы полиномиальной. Ибо если это какая утилита преобразования данных из одного формата в другой, узким местом будут файловые операции и парсинг. По сравнению с которым любые обращения списка будут занимать доли процента. И в высокооптимизированном коде в узких местах никогда не будет структур типа связанного списка как минимум в классическом понимании. Ибо память сравнительно медленная, прыганье по случайным адресам означает что проц у тебя будет простаивать, дожидаясь пока подгрузятся данные из памяти и постоянно будет перетираться кеш. Потому если у тебя будет реально код, который должен быть быстрый, у тебя будет так называемый coalesce memory access.

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

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

E>И твой список вопросов, на основании которого ты пытаешься определить квалификацию программиста, говорит о том, что сам ты никогда не занимался тем, чтобы из железа выжать максимум. Скорее всего даже профайлер никогда в жизни не запускал. Ибо если бы хотя бы раз приходилось бы таким заниматься, список вопросов был бы ну совсем другой.

Он ж их надёргал из местных срачей, совершенно не понимая что эти вопросы должны выявлять.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Архитектура головного моска в запущенной форме.

Так и я о том же. Как образец архитектуры головного моска, этот — еще довольно умеренный.

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

CM>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>Архитектура головного моска в запущенной форме.

CM>Так и я о том же. Как образец архитектуры головного моска, этот — еще довольно умеренный.

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

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

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

YMMV. Последний любитель чудо-архитектур, с которым я пересекался на работе, оказался редким м№№№ком.

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

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

А при чем тут люди? Дело не в людях, а в том какой у них опыт. Пока на серьезных проектах не соберут себе шишек на задницу — хипста стайл превалирует.

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

E>Здравствуйте, Тёмчик, Вы писали:

Тё>>А потом не может развернуть строку за O(n).
E>Если соответствующий код является узким местом, то разворачивать в нем строку за O(n) — это охрененный удар по производительности. Перед исполнением высокооптимизированного кода данные должны быть максимально хорошо подготовлены, чтобы лишних операций не требовалось бы делать вообще. И нормальноая асимптотика будет только константа, в крайнем случае будет логарифм, связанный с тем, что тебе приходится еще и экономить память, потому придется жертвовать быстродействием в обмен на экономию памяти. И вообще, высокооптимизированный код — он не об алгоритмах. Он об оптимальном размещении данных. Соответственно строка должна быть уже развернута, она должна храниться именно в развернутом виде, если скорость важна. А как ты будешь ее разворачивать на этапе подготовки данных — в 99 процентов случаях пофиг, достаточно чтоб сложность разворота была бы полиномиальной. Ибо если это какая утилита преобразования данных из одного формата в другой, узким местом будут файловые операции и парсинг. По сравнению с которым любые обращения списка будут занимать доли процента. И в высокооптимизированном коде в узких местах никогда не будет структур типа связанного списка как минимум в классическом понимании. Ибо память сравнительно медленная, прыганье по случайным адресам означает что проц у тебя будет простаивать, дожидаясь пока подгрузятся данные из памяти и постоянно будет перетираться кеш. Потому если у тебя будет реально код, который должен быть быстрый, у тебя будет так называемый coalesce memory access.

E>И твой список вопросов, на основании которого ты пытаешься определить квалификацию программиста, говорит о том, что сам ты никогда не занимался тем, чтобы из железа выжать максимум. Скорее всего даже профайлер никогда в жизни не запускал. Ибо если бы хотя бы раз приходилось бы таким заниматься, список вопросов был бы ну совсем другой.

В 99% случаев «запуск профайлера» показывал на такую вот функцию, условно переворота строки, где была O(n^2) или хуже.

Здравствуйте, Тёмчик, Вы писали:

Тё>В 99% случаев «запуск профайлера» показывал на такую вот функцию, условно переворота строки, где была O(n^2) или хуже.
И в чем проблема? Эта функция быстро переписывается и оптимизируется (за счет снижения читабельности кода, как цена за скорость) и работаем дальше. Проблема будет только в том случае, если эта функция разошлась тысячью экземпляров по всему проекту, причем она каждый раз писалась с нуля с вариациями. Но в этом случае проблема не в тормозном коде, проблема что у вас за строчки кода платят, а повторяющиеся куски кода разработчики выделять в функции не умеют.

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

Тё>>В 99% случаев «запуск профайлера» показывал на такую вот функцию, условно переворота строки, где была O(n^2) или хуже.
E>И в чем проблема? Эта функция быстро переписывается и оптимизируется (за счет снижения читабельности кода, как цена за скорость) и работаем дальше. Проблема будет только в том случае, если эта функция разошлась тысячью экземпляров по всему проекту, причем она каждый раз писалась с нуля с вариациями. Но в этом случае проблема не в тормозном коде, проблема что у вас за строчки кода платят, а повторяющиеся куски кода разработчики выделять в функции не умеют.

Забавно, за собственное непонимание азов программирования, меня успели обвинить в куче грехов. Может быть, лучше почитать Кормена?

Здравствуйте, Тёмчик, Вы писали:

Тё>Забавно, за собственное непонимание азов программирования, меня успели обвинить в куче грехов. Может быть, лучше почитать Кормена?
В 99% реальные проблемы производительности не имеют ничего общего с тетой от n. А является банальной невнимательностью. Например дернул ленивую функцию там, где ее дергать не нужно (реальный недавний случай, кстати). Соответственно если проблема возникает — быстро находится результат, быстро фиксится в одном месте кода, и все работает с нужной скоростью. А когда просто банальная проблема в одной функции оказывается важной и критичной — это будет как раз следствием того, что в проекте внутри царит спагетти и копипаст. Вот это да, быстро в случае обнаружения хрен поправишь, зачастую за месяц это хрен поправишь. Плюс при одной и той же тета от n время выполнения может различаться на порядки. За счет боксинга, работы сборщика мусора в результате лишних аллокаций объектов и тому подобной хрени.

Короче, попробуй прочитать про dry принцип, про инкапсуляцию, принцип единственной ответственности и т.д. И постепенно приводи проект в порядок. И настанет время, когда в случае проблем с производительностью вы быстро в одном месте поправите и продолжите пилить дальше, а не будете иметь кучу проблем, как сейчас (иначе бы ты на этом внимание не акцентировал вообще). И погугли про закон амдала еще. И про правило 80 20. Это основы азов программирования, а не развороты списков. И несоблюдение реальных основ на практике гораздо более дорого обходится, чем неправильный разворот списка. А то пипец, прочитал одну книжку по алгоритмам, и на основании одной книжки без опыта считаешь что стал мегагуру программирования. Там вообще то до черта книг нужно помимо читать, причем до алгоритмов. И потом хотя бы лет 5 практически поработать, желательно в разных областях.