Я понимаю, что вы процитировали типовой ответ первого уровня поддержки пользователей. А я, наивный, полагал что мне повезёт услышать честный ответ. Мол так и скажите — не прокатывает по юридическим причинам выложить Uber BY в глобальный стор. Могли бы выложить в глобальный и сделать заглушку для всех стран кроме РБ, к примеру. Так же как это реализовано в основном приложении. Ну реально, вы же сделали заведомо мёртвый usecase для иностранцев.
Единственный раз когда мне более менее честно ответили в поддержке, это когда я прислал видео с демонстрацией бага с расчётом стоимости поездки.
В 95% проектов, в которых я участвовал документация скорее даже мешала. Потому что не тратилось достаточно ресурсов на её ведение и документация как правило была сильно устаревшей. Только один раз был проект, делавшийся практически по канбану, где каждая задача включала обязательную разработку/обновление документации. И это делало практически бесплатным введение новых людей в проект.
Отладчиком пользоваться умею, впрочем как и читать код. Проблема в том что я слишком часто возвращаюсь к типичным мыслям юных разработчиков — переписать всё нафиг (хотя сисадминский опыт из детства кричит с другой стороны, что «работает, не трогай»). И начинаю часто отвлекаться на мелочи типа, вот тут надо по ссылке передать, а не shared_ptr плодить, вот тут сырые указатели, тут нет const, тут класс надо разбить на несколько, чтобы SOLID получился, там метод слишком длинный, сложный для отладки и т.п. Всё это в целом мешает главному — пониманию общей архитектуры проекта и уже более детальному пониманию каких-то узлов.
Немного не в тему, к сожалению достучаться через адреса техподдержки до людей, которые хоть что-то решают нереально.
Но очень хочется узнать, чем думал яндекс, когда делал приложение Uber BY (я так думаю, с Uber Russia аналогичная ситуация) доступным только из белорусского AppStore? Теперь, когда ко мне приезжают иностранцы я не могу сказать «вызовите убер». Мне приходится надеятся на то, что человек не полениться заранее сменить свой регион в телефоне, скачать нужное приложение и только потом лететь в Беларусь. Зачем вся эта свистопляска, нужно было сразу сделать как в Германии — мол в РБ убера нет, качайте заранее альтернативы. Тем более что приложение Uber By смотрится как дешёвый скин к Яндекс.Такси (к тому же, с порезанным функционалом).
У меня такая проблема и я не знаю, как с ней бороться. Поэтому всегда стараюсь попадать на свежие проекты.
Может есть какие-то практики, которые позволят научиться читать и понимать чужой код?
Спасибо за замечание. Если честно, скопипастил с какой-то своей старой лабы. Сам уже очень давно не использовал синглтоны на практике. Думаю суть посыла автор понял.
Для code review есть замечательный сайт codereview.stackexchange.com. Хабр немного не для этого.
Про 3-й пункт, минимально вот так:
template < typename T >
class Singleton
{
public:
static T& instance()
{
static T inst;
return inst;
}
protected:
Singleton() {}
virtual ~Singleton() {}
private:
Singleton( const Singleton& ) = delete;
Singleton& operator=( const Singleton& ) = delete;
};
// Ну и использование:
class MyClass : public Singleton<MyClass>{ ...
По поводу высокой связанности, в Qt есть сигналы/слоты. Неплохой пример, правда под QtQuick/QML можно глянуть тут.
Но я бы на вашем месте намного больше парился насчёт понимания многопоточности. Прочитайте про atomic/volatile. Про оптимизации компиляторов и т.п.
С ходу, то что с телефона разглядел:
1) Косяки с многопоточностью. Если вы хотите останавливать поток по bool переменной, её нужно сделать atomic.
2) Куча синглтонов. Они не нужны в принципе, но если уж очень хочется, то сделайте их через базовый класс.
3) Какие-то ненужные обвёртки вокруг stl контейнеров, которые ничего не делают. Самописный QSettings.
4) GUI сильно связан с логикой.
Первый способ крайне опасный, если вы не пишите приложение чисто для себя. Привет sql инъекции. Допускаю, что вы код накидали чисто для примера, но в любом случае не стоит так делать.
Именно поэтому в cpp core guidelines для мер использовать специальные типы данных. Тогда не будет никакой путаницы с корректностью рассчётов даже при повсеместном auto
Если при включении оптимизации выше чем O1 в релизной сборке у вас начинаются проблемы, то это прямой показатель того, что что-то где-то криво запрограммировано.
Предложите, как можно сокращённо назвать msvs for Mac? Классическую студию мы с коллегами называем «вижла», что понятно. С Visual Studio Code тоже быстро разобрались, она стала называться «вэ эс код». Но маркетологи Майкрософта не успокаиваются :). Подскажите, как можно лаконично называть вижлу для мака?
Конечно, мы также продолжаем поддерживать и улучшать кроссплатформенную разработку на C++
Вот можно про этот момент чуть подробнее? А то вообще нет никакой информации о перспективах С++ в рамках MSVS 2019.
И ещё вопрос. Может я не совсем правильно понял, но MSVS 2019 для Windows и MSVS 2019 для MacOS — это две совершенно разные IDE, которые теперь будут одинаково называться?
Нормально устранить получится только для жёсткой конструкции. В крайнем случае — конструкции с предсказуемой механикой. Человеческое тело к таким не относится, разве что удастся натренировать рефлекс «вытянуться по стойке смирно» в случае отказа одного из двигателей, что очень сложно.
Я прошёл схему Pascal -> C -> WinApi (имхо, паскаль лишний в этой цепочке, но он был полезен более слабым ученикам). Плюсы изучал самостоятельно и первые года 2-3 реальной работы писал на си с классами, пока не познакомился с Qt. Не могу сказать, что это было плохо, но и не сказать что было хорошо. Минусы в таком подходе очевидны — мне было очень сложно приучиться к ООП мышлению и было сложно понять назначение паттернов проектирования. Много времени я был где-то между сильным джуном и слабым мидлом.
Считаю, что в этой цепочке просто не хватило следующего звена — а именно хорошего жёсткого курса по ООП с изобилием практики. Да, в универе у нас читали ООП (на примере консольных приложений в Делфи, никаких формочек) и читали хорошо. Но на лабах это не закреплялось. К тому же на тот момент я уже работал и мне было не до универа.
У меня как-то раз был спор на собеседовании, где я быстро понял, что мне сбивают цену. Я проявил упрямство, попросил дать ноутбук чтобы продемонстрировать что я прав (если не ошибаюсь, про инлайнинг и RVO спорили). На что директор начал психовать, мол что вы тут за цирк устраиваете и т.п. Пришлось в лоб сказать, что если враньё начинается уже на собеседовании, то работать я сюда не пойду. После чего ушёл. Через пару месяцев, когда я уже успешно работал в другой фирме мне позвонили эти ребята и сделали оффер. От которого я конечно же отказался. Оффер к тому же был на 50% серый.
И да, главный вопрос: зачем нужно это приложение в принципе? С учётом того, что его полностью заменяет или даже значительно превосходит Яндекс.Такси.
Я понимаю, что вы процитировали типовой ответ первого уровня поддержки пользователей. А я, наивный, полагал что мне повезёт услышать честный ответ. Мол так и скажите — не прокатывает по юридическим причинам выложить Uber BY в глобальный стор. Могли бы выложить в глобальный и сделать заглушку для всех стран кроме РБ, к примеру. Так же как это реализовано в основном приложении. Ну реально, вы же сделали заведомо мёртвый usecase для иностранцев.
Единственный раз когда мне более менее честно ответили в поддержке, это когда я прислал видео с демонстрацией бага с расчётом стоимости поездки.
В 95% проектов, в которых я участвовал документация скорее даже мешала. Потому что не тратилось достаточно ресурсов на её ведение и документация как правило была сильно устаревшей. Только один раз был проект, делавшийся практически по канбану, где каждая задача включала обязательную разработку/обновление документации. И это делало практически бесплатным введение новых людей в проект.
Отладчиком пользоваться умею, впрочем как и читать код. Проблема в том что я слишком часто возвращаюсь к типичным мыслям юных разработчиков — переписать всё нафиг (хотя сисадминский опыт из детства кричит с другой стороны, что «работает, не трогай»). И начинаю часто отвлекаться на мелочи типа, вот тут надо по ссылке передать, а не shared_ptr плодить, вот тут сырые указатели, тут нет const, тут класс надо разбить на несколько, чтобы SOLID получился, там метод слишком длинный, сложный для отладки и т.п. Всё это в целом мешает главному — пониманию общей архитектуры проекта и уже более детальному пониманию каких-то узлов.
Немного не в тему, к сожалению достучаться через адреса техподдержки до людей, которые хоть что-то решают нереально.
Но очень хочется узнать, чем думал яндекс, когда делал приложение Uber BY (я так думаю, с Uber Russia аналогичная ситуация) доступным только из белорусского AppStore? Теперь, когда ко мне приезжают иностранцы я не могу сказать «вызовите убер». Мне приходится надеятся на то, что человек не полениться заранее сменить свой регион в телефоне, скачать нужное приложение и только потом лететь в Беларусь. Зачем вся эта свистопляска, нужно было сразу сделать как в Германии — мол в РБ убера нет, качайте заранее альтернативы. Тем более что приложение Uber By смотрится как дешёвый скин к Яндекс.Такси (к тому же, с порезанным функционалом).
У меня такая проблема и я не знаю, как с ней бороться. Поэтому всегда стараюсь попадать на свежие проекты.
Может есть какие-то практики, которые позволят научиться читать и понимать чужой код?
Извините за оффтопик, но вы очень наивны и слишком верите вашим СМИ.
Спасибо за замечание. Если честно, скопипастил с какой-то своей старой лабы. Сам уже очень давно не использовал синглтоны на практике. Думаю суть посыла автор понял.
Про 3-й пункт, минимально вот так:
По поводу высокой связанности, в Qt есть сигналы/слоты. Неплохой пример, правда под QtQuick/QML можно глянуть тут.
Но я бы на вашем месте намного больше парился насчёт понимания многопоточности. Прочитайте про atomic/volatile. Про оптимизации компиляторов и т.п.
С ходу, то что с телефона разглядел:
1) Косяки с многопоточностью. Если вы хотите останавливать поток по bool переменной, её нужно сделать atomic.
2) Куча синглтонов. Они не нужны в принципе, но если уж очень хочется, то сделайте их через базовый класс.
3) Какие-то ненужные обвёртки вокруг stl контейнеров, которые ничего не делают. Самописный QSettings.
4) GUI сильно связан с логикой.
Первый способ крайне опасный, если вы не пишите приложение чисто для себя. Привет sql инъекции. Допускаю, что вы код накидали чисто для примера, но в любом случае не стоит так делать.
Предположу, что куча COM legacy.
Именно поэтому в cpp core guidelines для мер использовать специальные типы данных. Тогда не будет никакой путаницы с корректностью рассчётов даже при повсеместном auto
Если при включении оптимизации выше чем O1 в релизной сборке у вас начинаются проблемы, то это прямой показатель того, что что-то где-то криво запрограммировано.
Предложите, как можно сокращённо назвать msvs for Mac? Классическую студию мы с коллегами называем «вижла», что понятно. С Visual Studio Code тоже быстро разобрались, она стала называться «вэ эс код». Но маркетологи Майкрософта не успокаиваются :). Подскажите, как можно лаконично называть вижлу для мака?
Вот можно про этот момент чуть подробнее? А то вообще нет никакой информации о перспективах С++ в рамках MSVS 2019.
И ещё вопрос. Может я не совсем правильно понял, но MSVS 2019 для Windows и MSVS 2019 для MacOS — это две совершенно разные IDE, которые теперь будут одинаково называться?
Нормально устранить получится только для жёсткой конструкции. В крайнем случае — конструкции с предсказуемой механикой. Человеческое тело к таким не относится, разве что удастся натренировать рефлекс «вытянуться по стойке смирно» в случае отказа одного из двигателей, что очень сложно.
Я прошёл схему Pascal -> C -> WinApi (имхо, паскаль лишний в этой цепочке, но он был полезен более слабым ученикам). Плюсы изучал самостоятельно и первые года 2-3 реальной работы писал на си с классами, пока не познакомился с Qt. Не могу сказать, что это было плохо, но и не сказать что было хорошо. Минусы в таком подходе очевидны — мне было очень сложно приучиться к ООП мышлению и было сложно понять назначение паттернов проектирования. Много времени я был где-то между сильным джуном и слабым мидлом.
Считаю, что в этой цепочке просто не хватило следующего звена — а именно хорошего жёсткого курса по ООП с изобилием практики. Да, в универе у нас читали ООП (на примере консольных приложений в Делфи, никаких формочек) и читали хорошо. Но на лабах это не закреплялось. К тому же на тот момент я уже работал и мне было не до универа.
Мне кажется, что тема не раскрыта. Я пока не вижу ни одного реального применения этой «фичи»
Благодарю за пояснения.
У меня как-то раз был спор на собеседовании, где я быстро понял, что мне сбивают цену. Я проявил упрямство, попросил дать ноутбук чтобы продемонстрировать что я прав (если не ошибаюсь, про инлайнинг и RVO спорили). На что директор начал психовать, мол что вы тут за цирк устраиваете и т.п. Пришлось в лоб сказать, что если враньё начинается уже на собеседовании, то работать я сюда не пойду. После чего ушёл. Через пару месяцев, когда я уже успешно работал в другой фирме мне позвонили эти ребята и сделали оффер. От которого я конечно же отказался. Оффер к тому же был на 50% серый.