С/С++: вопросы на собеседованиях

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

пытается переписать старый код, так как он ему не нравится.

Как будто что-то плохое

Если это мешает выполнять бизнес задачи в срок, это плохое

А это уже проблема менеджмента, что у программистов не хватает времени на рефакторинг кодовой базы.

Взяли человека с

превосходный код на гитхабе.

И ещё жалуетесь, что он ваш говнокод решил причесать. Фу таким быть

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

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

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

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

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

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

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

В такую компанию я бы вообще не стал устраиваться. Это тоже неадекватность, только уже со стороны работодателя. Правда - она же где-то посередине.

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

Но платить вы хотите, естественно, ниже среднего

Про зп в этом треде вообще ничего не было

у вас наверно очередь стоит за дверью, ну ну))

Не жалуемся

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

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

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

так наоборот же, пожаловались, здесь уже пишут

«Кто вы-то? Я здесь один» (c) слоник

Где ты от жалобу увидел?

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

И если вы думаете, что угробить проект можно только на C/C++ — я спешу вас переубедить, потому что я лично видел падающий проект на JS. Да, угробить проект на C/C++ проще, но на C#/Java/JS/etc это тоже вполне реальная достижимая цель.

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

Все верно. Периодически надо рефакторить старые решения. Потому что лапшекод и заплатки возникают в любом старом проекте. Но на это, как правило, выделяют отдельное время. Программисты приносят менеджеру запрос на то, что «у нас есть вот такие фундаментальные проблемы, нам надо примерно столько дней/месяцев на исправть». Эти задачи вклинивают между бизнес фичами. Если надо, вместе перепридумывают архитектуру. Все идет предсказуемо. А когда кто-то растягивает свою задачу пары дней на пару недель потому что «ну мне не нравится как у нас вот тут сделано, поэтому я решил прям сейчас переписать» это плохо.

у вас наверно очередь стоит за дверью, ну ну))

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

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

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

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

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

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

Это прикольная история, но тесты не работают на:
 — многопоточных приложениях;
 — распределенных приложениях;
 — GUI.

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

Это прикольная история, но тесты не работают на:
— многопоточных приложениях;
— распределенных приложениях;
— GUI.

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

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

тесты не работают на:
— многопоточных приложениях;
— распределенных приложениях;
— GUI.

Работают на всех пунктах, с разной степенью извращения.

Есть вариант получше: выгнать на мороз

Удачи лол! Если он трудоустроен в штат, хер ты его выгонишь, если он сам не захочет уходить.

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

Все верно. Периодически надо рефакторить старые решения.

Рискну прослыть «некрофилом» за ответ на старые комменты, но тем не менее. У нас работает примерно так:

Есть некий code-base несущий условные «золотые яйца» (десятки MLOC). В какой-то момент появляется use-case этим кодом не покрывающийся. Если есть возможность его «дёшево» покрыть добавив ложку го^wдёгтя - именно это и будет сделано. Потом наступает момент когда объем го^wдёгтя превышает критическую массу, и тогда принимается волевое решение этот конкретный кусок кода переписать. Он переписывается, аккуратненько релизится в прод, и цикл повторяется.

Условные «пионеры» пытающиеся переписывать всё подряд обычно посылаются (well, коммиты не пропускаются, и они лишаются премий которые сопоставимы с годовой зарплатой). Обычно люди после этого или сами одумываются, или «растворяются в тумане».

Мне вот просто интересно - а как ещё то? Кто-то делает по другому?

Кто-то делает по другому?

Нас учили модульному проектированию, каждый модуль решает свою и только свою задачу (буква S в методике SOLID). Связи между модулями - минимальны, например - микросервисы. И отлаженный и оттестированный код никогда не меняют, если в нем нет ошибок.

например - микросервисы

И в каждый микросервис содержит телеметрию - единственную выполняемую им задачу.

Мне вот просто интересно - а как ещё то? Кто-то делает по другому?

Навряд-ли. Обычно переписывание всего подряд приводит к куче багов(как бы очевидно, новый код - новые баги) и тем самым замедляет релизы и другую разработку. Потому такое «внезапное улучшение» может испортить жизнь вообще всем.

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

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

Если проект, в принципе, интересный и нужный, но весь этот код он написал единолично, без PR от других людей, то это уже звоночек. Если PR и баги есть, то полезно почитать, как общение происходит.

Мне вот как-то один гражданин вместо добавления достаточно мелкой функциональности переписал весь код в своём стиле =) Что есть смертный грех в open source (золотое правило: в чужом монастыре пишешь в местном, монастырском стиле). До сих пор не уверен, правильно ли я сделал, что дал ему права на репозиторий.

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

Не согласен. PR от других людей возможны только если другие люди об этом проекте вообще знают. А если ты пилишь его в свободное время чисто для души и никуда не выкладываешь? Откуда там PR?

Если есть возможность его «дёшево» покрыть добавив ложку го^wдёгтя - именно это и будет сделано.

Мне вот просто интересно - а как ещё то? Кто-то делает по другому?

Иногда есть ABI stability. И если ты что-то сделаешь криво, то это будет на десять лет, или даже навсегда, без возможности поправить 😭

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

Не согласен. PR от других людей возможны только если другие люди об этом проекте вообще знают. А если ты пилишь его в свободное время чисто для души и никуда не выкладываешь? Откуда там PR?

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

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

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

Ты частное (свой безюзерный проект) распространяешь на общее (все проекты на гитхабе), что неверно.