Re[28]: Собеседования в Яндекс++ - О работе

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

S>будет принципиальная разница?

Будет, так как после одного вызова shared_descriptor_count() следующий обязательно вернёт не 0, если только не вызовется секция после else. компилятор учитывает первое, но не учитывает второе, так как логика преобразований в тех функциях после else не очевидная для компилтора, он не достаточно умён, чтоб это учитывать, вместо цикла компилятор генерировал исполнение тела цикла единыжды. Тот continue выглядит костылём, но он там нужен.

S>Попробуйте сперва.

Чо там пробовать? Лямбды вообще уродливы.

S>Бла-бла-бла. Написали говнокод а теперь пытаетесь умными словами прикрыться.

Да вообще как хотите, хотите бла-бла, хотите ещё что. Мне параллельно Ваше мнение. Уровень его кометентности оценил сразу по первым двум сообщениям и по тому последнему, про обязательное отсутсвие разницы с continue и без него. Вы писали всегда простейший код и думаете что всё везде так же просто или может быть сделано просто. Ничего подобного.

S>Кстати, понять, почему вот это имеет смысл:
S>

node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());

S>тоже очень не просто.

Догадайтесь с двух раз, ладно, c трёх раз. Вы видите где-нибудь инкремент текущего storage_chunk? А он происходит. По вашему, что происходит когда делается его get, и что происходит когда делается его set? get простая операция, но set-это уже другая история. Скажу по секрету, там несколькими функциями, минимально возможным количеством кода и количеством данных, описана достаточно массивная логика. Любители простоты вроде Вас наплодили бы раз в десять-двадцать больше кода и больше данных, со всеми вытекающими последствиями для производительности кеша CPU.

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

A>Что из литературы доводилось читать по принципам и подходам к организации кода?
A>Например, есть Steve McConnell “Code Complete”, Robert Martin “Clean Code”.

Упомянутое, помнится, пролистывал вскользь, пытаясь зацепиться за что-то интересное, что не отдавало бы привкусом очевидности. Как и многое и вообще почти всё остальное из фонда литературы про софт. Не находил там ничего интересного. Но много интересного находил в чтении исходников известных проектов, в общении с их разрабами. Одно время, до 2010-го, тесно работали с Sun-ом, и много общался с разрабами solaris-а. Это было интересней в этом находил реальную пользу для себя, но не в чтении книжек. Большую часть из них писали люди, которые сами софт не пишут, чему они могут научить?

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

S>Будет, так как после одного вызова shared_descriptor_count() следующий обязательно вернёт не 0, если только не вызовется секция после else.

Глаза разуйте: у вас нет ничего после else. Ваш while имеет вот такой вид:

while(some-condition) {
   if(another-condition) {
      break;
   }
   else {
      ...
      continue;
   }
}

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

Ну или у вас при копировании вашего фрагмента скобки поплыли.

S>>Попробуйте сперва.

S>Чо там пробовать? Лямбды вообще уродливы.

Было очевидно, что вы не пробовали. Пропробовали бы, то увидели бы, что ваш основной код внутри первого while сократился бы раза в 1.5. Что сделало бы его понятнее.

S>Да вообще как хотите, хотите бла-бла, хотите ещё что. Мне параллельно Ваше мнение. Уровень его кометентности оценил сразу по первым двум сообщениям и по тому последнему, про обязательное отсутсвие разницы с continue и без него. Вы писали всегда простейший код и думаете что всё везде так же просто или может быть сделано просто. Ничего подобного.

Давайте сперва разберемся с тем, понимаете ли вы вообще свой код.

S>>Кстати, понять, почему вот это имеет смысл:
S>>

node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());

S>>тоже очень не просто.

S>Догадайтесь с двух раз, ладно, c трёх раз. Вы видите где-нибудь инкремент текущего storage_chunk? А он происходит. По вашему, что происходит когда делается его get, и что происходит когда делается его set? get простая операция, но set-это уже другая история. Скажу по секрету, там несколькими функциями, минимально возможным количеством кода и количеством данных, описана достаточно массивная логика. Любители простоты вроде Вас наплодили бы раз в десять-двадцать больше кода и больше данных, со всеми вытекающими последствиями для производительности кеша CPU.

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

А если же у вас get идемпотентен, то вызывать set_current_storage_chunk для того, чтобы еще раз назначить значение для current_storage_chunk... Ну как-то странно это.

В общем, куда не ткни, запашок какой-то подозрительный начинает доноситься.

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

S>Вот прямо с текущего экрана, смотри:
S>

   
S>    node_desc_type* allocate_next_cluster_shared_segment(bool wait){
S>       void* basep;
S>       DEBUG << " Prepare to fetsh(может fetch?) shared journal segment ... ";

S>

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

S>Глаза разуйте: у вас нет ничего после else. Ваш while имеет вот такой вид:

Это вы глаза разуйте. Это что? Пушкин?

     node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());
     node_descp->set_shared_segment(journal_store(node_descp->get_current_storage_chunk()).first_descriptor_shared());

S>Было очевидно, что вы не пробовали. Пропробовали бы, то увидели бы, что ваш основной код внутри первого while сократился бы раза в 1.5. Что сделало бы его понятнее.

Ещё раз гляньте выше. Там лямбды вообще не к месту, и только синтаксического хлама добавят.

S>Давайте сперва разберемся с тем, понимаете ли вы вообще свой код.

Я то понимаю, боюсь что Вы всё никак не допрёте.

S>Если у вас get_current_storage_chunk() не является идемпотентной операцией, т.е. get_current_storage_chunk() каждый раз возвращает разное значение

Между вызовом set, get возвращает одно и то же значение, после-другое. Это очевидно, Карл!

S>А если же у вас get идемпотентен, то вызывать set_current_storage_chunk для того, чтобы еще раз назначить значение для current_storage_chunk... Ну как-то странно это.

set вызывается один раз. Один раз, Карл. Всё остальное время мы получаем значение через get. Зачем через get? Потому-что set могут вызвать другие, это очевидно же.

>S В общем, куда не ткни, запашок какой-то подозрительный начинает доноситься.

В общем, это Вы не въезжаете в достаточно очевидные вещи, которые там расписаны чёрным по белому, ясней некуда. Но до Вас это всё никак не доходит. Может это пованивает не от кода. а от Ваших умственных способностей?

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

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

S>>Вот прямо с текущего экрана, смотри:
S>>

   
S>>    node_desc_type* allocate_next_cluster_shared_segment(bool wait){
S>>       void* basep;
S>>       DEBUG << " Prepare to fetsh(может fetch?) shared journal segment ... ";

S>>

Опечатка, не принципиально. Поправлю. Спс.

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

S>>Глаза разуйте: у вас нет ничего после else. Ваш while имеет вот такой вид:

S>Это вы глаза разуйте. Это что? Пушкин?

S>

S>     node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());
S>     node_descp->set_shared_segment(journal_store(node_descp->get_current_storage_chunk()).first_descriptor_shared());
S>

Это находится не после else. А внутри. И continue ваш идет после этих строк. Вот еще раз вам, раз вы в собственном коде запутались:

while(journal_store(node_descp->get_current_storage_chunk()).shared_descriptor_count() == 0){
   if(node_descp->get_current_storage_chunk() >= get_journal_storage_chunk_count()){
       break;
   }
   else {
      node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());
      node_descp->set_shared_segment(journal_store(node_descp->get_current_storage_chunk()).first_descriptor_shared());
      continue; // ВОТ ОН. ЗДЕСЬ!
   } // А дальше, после else, ничего нет.
}

S>>Было очевидно, что вы не пробовали. Пропробовали бы, то увидели бы, что ваш основной код внутри первого while сократился бы раза в 1.5. Что сделало бы его понятнее.

S>Ещё раз гляньте выше. Там лямбды вообще не к месту, и только синтаксического хлама добавят.

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

S>Я то понимаю, боюсь что Вы всё никак не допрёте.

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

S>>Если у вас get_current_storage_chunk() не является идемпотентной операцией, т.е. get_current_storage_chunk() каждый раз возвращает разное значение

S>Между вызовом set, get возвращает одно и то же значение, после-другое. Это очевидно, Карл!

Да вы просто не понимаете о чем вам говорят. Давайте, раз уж вы настолько тяжелый случай, на пальцах вам объясним:

class Demo {
   int v_{};
public:
   void set_v(int v) { v_ = v; }
   int get_v() const noexcept { return v_; }
};
Demo d;
d.set_v(10); // В этом есть смысл.
assert(10 == d.get_v()); // И в этом есть смысл.
d.set_v(d.get_v()); // А в этом уже смысла нет.

Смысла в строке d.set_v(d.get_v()) нет потому, что get_v не может вернуть значение, отличное от того, что раньше было назначено через set_v.

Вреда от этого так же нет. Это бессмысленная операция.

Но у вас set_current_storage_chunk для get_current_storage_chunk имеет смысл. Что говорит о том, что get_current_storage_chunk может вернуть значение, отличное от того, что раньше было установлено через set_current_storage_chunk. Либо значение current_storage_chunk может поменяться вообще без применения set_current_storage_chunk.

И то, и другое выглядит крайне странно.

Но у вас, очевидно, собственная логика. В ее рамках все нормально.

S>В общем, это Вы не въезжаете в достаточно очевидные вещи, которые там расписаны чёрным по белому, ясней некуда. Но до Вас это всё никак не доходит. Может это пованивает не от кода. а от Ваших умственных способностей?

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

PS. По большому счету, весь ваш вложенный while можно было бы записать так:

while((journal_store(node_descp->get_current_storage_chunk()).shared_descriptor_count() == 0) &&
   (node_descp->get_current_storage_chunk() < get_journal_storage_chunk_count())
{
   node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());
   node_descp->set_shared_segment(journal_store(node_descp->get_current_storage_chunk()).first_descriptor_shared());
}

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

S>Догадайтесь с двух раз, ладно, c трёх раз. Вы видите где-нибудь инкремент текущего storage_chunk? А он происходит.

То есть, у тебя set/get имеют какие-то сайдэффекты, которые никак не видны из их названий?

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

Брр...
Код ужасный.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

Нет.
Более того, это даже не С++, скорее С с классами.
Форматирование тоже вырвиглазное.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

S>вместо цикла компилятор генерировал исполнение тела цикла единыжды. Тот continue выглядит костылём, но он там нужен.
Может стоит вместо этих диких приседаний таки взять нормальный промышленный компилятор, который компилит правильно?

S>Догадайтесь с двух раз, ладно, c трёх раз. Вы видите где-нибудь инкремент текущего storage_chunk? А он происходит.
Говнокод?

S> По вашему, что происходит когда делается его get, и что происходит когда делается его set? get простая операция, но set-это уже другая история. Скажу по секрету, там несколькими функциями, минимально возможным количеством кода и количеством данных, описана достаточно массивная логика. Любители простоты вроде Вас наплодили бы раз в десять-двадцать больше кода и больше данных, со всеми вытекающими последствиями для производительности кеша CPU.

жесть!!!
Гнать нахрен!

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

S>но категория работодателей, которым такой style не понравится, мне не интересны
Ещё бы!

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

S>Комментарии и пробелы оттуда специально удалены? Или это код как он есть?

Код, конечно, ужасен, но комментарии бы сделали его ещё хуже. Они не нужны.
Пробелы — дело вкуса, ИМХО. А вот структура кода — это конечно жесть.

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

S>Это находится не после else. А внутри.

Я это называю именно после else, а не внутри. "после" в Вашем понимании-это вообще после всего блока if — else.

S>PS. По большому счету, весь ваш вложенный while можно было бы записать так:
S>

while((journal_store(node_descp->get_current_storage_chunk()).shared_descriptor_count() == 0) &&
S>   (node_descp->get_current_storage_chunk() < get_journal_storage_chunk_count())
S>{
S>   node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());
S>   node_descp->set_shared_segment(journal_store(node_descp->get_current_storage_chunk()).first_descriptor_shared());
S>}
S>

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

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

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

S>>Догадайтесь с двух раз, ладно, c трёх раз. Вы видите где-нибудь инкремент текущего storage_chunk? А он происходит.

L>То есть, у тебя set/get имеют какие-то сайдэффекты, которые никак не видны из их названий?

Это приватные функции, выполняющие определённую роль. Тот кусок кода-это из интерфейсной юзерспайсовой оболочки, предоставляющей доступ к функционалу высокопроизводительной системы стораджа через демон, функционирующий в юзерспайсе. Сама система-это система организации хранения данных, оптимизированная с учётом особенностей реализации драйверов шин блочных устройств в linux, а также особенностей взаимодействия кеша CPU, с областями памяти, которые выделены под зоны для DMA, в которых отображаются данные с диска. Она работает в обход подсистемы блочного IO ядра и слоя файловых систем в ядре. Основная функциональная часть реализации функционирует в kernel space. В юзерспайсе многопоточный демон, общающийся с кернел левелом через модифицированную подсистему epoll. Похожую вещь чуваки пропихивают в майнстрим. Сейчас в процессе превращения стораджа в распределённую систему хранения. Пока данные синхронизируются через упомянутый демон, организующий кластерный кворум в режиме мастер-мастер. Но есть планы реализовать обмен данными посредством RDMA. Требование к системе всегда было одно-производительность. Ради этой цели приходится идти на самые разные трюки. Порой код выглядит нечитабельным или малопонятным, но иначе никак. К тому куску выше это не относится, там тестовый набросок.

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

CC>Брр...
CC>Код ужасный.

Ждём примера Вашего кода, c нетерпением.

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

Вот вам ещё кусок кода.

db_ngine::statement db_engine::evaluate_statement(const db_context &ctx)
{
    while (_node != nstore().end_nodes() &&
           (_node->node()->type().stage() <= ctx.stage() || skip_run(*_node->node(), ctx))){
        db_statement * const first_ok = eval_node(*_node, ctx) ;
        if (first_ok){
            const unsigned ndx = first_ok->_ndx ;
            PCHECK(ndx < nstore().section_count) ;
            PCHECK(first_ok < _first_ok || code().section_count > 1 || !*(nstore().begin_done() + ndx)) ;
            const ASTB &ast = first_ok->parser_s() ;
            if (ast.attributes() & ASTB::STAGE){
                PCHECK(ast.converter().type().need_request()) ;
                if (first_ok < _first_rstage)
                    _first_rstage = first_ok ;
            }
            if (!(ast.attributes() & ASTB::NEXT)){
                *(nstore().begin_done() + ndx) = &ast ;
                if(nstore().section_count>1)
                    for(db_statement *s=first_ok; s<nstore().end_statements(); ++s)
                        if(s && s->root()->is_evaluated() && s->root()->value()) 
                            if(s->_ndx!=ndx){      
                                const ASTB **ptr=nstore().begin_done()+s->_ndx;
                                if(!*ptr || *ptr>&s->parser_s()) 
                                    *ptr=&s->parser_s();
                                   *ptr=&s->parser_s();
                            }
                db_section *cursection = nstore().begin_sections() + ndx ;
                db_statement *secbegin = nstore().begin_statements() + cursection[0].start ;
                db_statement *secend = nstore().begin_statements() + cursection[1].start ;
                PCHECK(db::xinrange(first_ok, secbegin, secend)) ;
                for (db_statement *reduced = first_ok < _first_ok || first_ok == secbegin
                         ? first_ok + 1
                         : secbegin ;
                     reduced != secend ; ++reduced)

                    if (!reduced->root()->is_done())
                    {
                        mark_done(*reduced->root()) ;
                        reduce_tree(*reduced->root()) ;
                    }

                if (first_ok < _first_ok)
                    _first_ok = first_ok ;
            }
        }

        do if (++_start_node == nstore().end_nodes())
           {
               *std::remove(nstore().begin_done(), nstore().end_done(), nullptr) = nullptr ;
               break ;
           }
        while (_start_done->is_idle()) ;
    }
    ......

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

N>Код, конечно, ужасен, но комментарии бы сделали его ещё хуже. Они не нужны.
Ещё как нужны, банально чтобы объяснять почему тут написана какая то бредятина.
Всё что он тут расписывает "почему так" надо было написать в комментах.
Любое место, которое вызывает WTF должно быть либо откомментировано если по другому никак либо исправлено.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Это всё классический варианта «стокгольмского синдрома».
Инженерное мастерство профессионального разработчика — это получить тоже самое в плане производительности, но с другим более «чистым кодом».
Т.е. нет смысла оправдывать херовый код тем, что он производительный или что авторы думали о производительности.

Времена изменились, на рынке труда от разработчиков senior_и_выше требуется не только выдать работающее производительное решение, но и сохранить инвестиции в кодовую базу. Потому и требования к написанию кода теперь иные, далекое не те что 15-20 лет назад.

Тот кусок что приводился в ветке — это нечто на гране говнокода. Т.е. годится лишь на уровень прототипа, демонстрирующего работоспособность какой-то идеи или технологии. Одноразовый код, который пишется для последующего выкидывания на помойку истории. Если же подобное тащить в продакшен, то сейчас это называется: увеличивать «технический долг» на проекте.

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

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

A>>Что из литературы доводилось читать по принципам и подходам к организации кода?
A>>Например, есть Steve McConnell “Code Complete”, Robert Martin “Clean Code”.

S>Упомянутое, помнится, пролистывал вскользь, пытаясь зацепиться за что-то интересное, что не отдавало бы привкусом очевидности. Как и многое и вообще почти всё остальное из фонда литературы про софт. Не находил там ничего интересного. Но много интересного находил в чтении исходников известных проектов, в общении с их разрабами. Одно время, до 2010-го, тесно работали с Sun-ом, и много общался с разрабами solaris-а. Это было интересней в этом находил реальную пользу для себя, но не в чтении книжек. Большую часть из них писали люди, которые сами софт не пишут, чему они могут научить?

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

В плане личностей авторов, то если к «дяде Бобу» ещё есть вопросы, то персона Макконнелла хорошо известна.
Дядя Боб интересен не столько свершениями, сколько идеями, которые в момент их публикации смотрели на 10 лет вперёд, по части развития индустрии софтваре. Его повествования с рассуждениями обретают ценность лишь по прошествию некоторого времени, в ретроспективе.

	От:	smeeld
	Дата:	04.06.19 19:56
	Оценка:	-2

	От:	smeeld
	Дата:	04.06.19 20:08
	Оценка:

От:	so5team	https://stiffstream.com
Дата:	04.06.19 20:16
Оценка:	+2

От:	StatujaLeha	на правах ИМХО
Дата:	04.06.19 20:30
Оценка:

	От:	smeeld
	Дата:	04.06.19 20:32
	Оценка:

	От:	CreatorCray
	Дата:	05.06.19 01:30
	Оценка:	+6

	От:	a7d3
	Дата:	05.06.19 02:18
	Оценка:	15 (1) +4

	От:	a7d3
	Дата:	05.06.19 02:30
	Оценка: