Не знаю, от возраста сильно не зависит. Вы просто тот 1 из 10 :) Просто одни люди умеют грамотно структурировать мысли, а другие нет.
Тут стоит уточнить, что до тех пор, пока результатом вашей аналитики пользуетесь только вы - вам аналитик и не нужен особо. А вот если надо что-то узнать, оформить в понятный документ и передать его команде - тут как бы всё ОЧЕНЬ плохо у разработчиков)
Мой опыт подсказывает, что только 1 из 10 разработчиков может выполнять роль аналитика. По крайней мере сколь либо сносно. Роль QA разработчики вообще не могут выполнять) Точнее могут конечно, но качество проверки качества будет очень унылым) Особенно если продукт сложный)
Их нет) Хуже того, сейчас по разным компаниям расползлись бывшие руководители Яндекса, и они сокращают аналитиков везде, где появляются. Тестировщиков, кстати, тоже иногда) Мол роль QA и аналитика может и разработчик выполнять. И это почти цитата, на секунду)
Более 95% сообщений об ошибках компилятора С++ выглядят гораздо хуже, чем сообщения об ошибках всех остальных языков.
Тут полностью поддерживаю, но комитет по С++ делает шаги в этом направлении. static_assert и концепты решают часть проблем, по крайней мере в вашем коде) Используйте их, где только можно. Ошибки boost обречены быть ужасными, тут ничего не поделать)
Также рекомендую ChatGPT (и аналоги) для упрощения жизни себе) Эти инструменты реально хорошо расковыривают километровые логи ошибок.
Лучшее, что я до сих пор обнаружил в этой сфере — это сборщик Meson, но и он полон последствий идиотских решений
Я поработал с Meson довольно много (два года использовал его в продакшене) и могу сказать, что лучший - по прежнему громоздкий CMake. К сожалению, документация Meson оставляет желать лучшего, плюс как только нужно сделать что-то за рамками простых сценариев, реализовано из ряда вон плохо. И он жутко медленный (питончик под капотом, что тут ещё добавить). Впрочем, синтаксис его приятный + нативная интеграция с Conan радует.
CMake можно сделать совсем чуточку проще, используя вот этот набор скриптов
Я люто ненавижу RAII. Я встречаюсь с множеством ситуаций, где RAII мешает решать настоящие задачи инициализации сущностей.
Вы не совсем правильно понимаете RAII. Идеологически его определение может и требует передать всё в конструктор, но суть его на самом деле не в создании объекта, а в уничтожении, как бы парадоксально это не звучало.
Суть RAII - это момент вызова деструктора. Объект должен подчищать за собой все ресурсы которыми он завладел при его окончании времени жизни. При этом вам вообще никто не мешает реализовывать паттерны вида строитель, или тупо сделать пустой конструктор и отложенный вызов метода Init(), хоть это концепутально может быть и не очень верно.
При этом количество раз, где RAII даже в изначальном смысле бывает полезен - сильно превышает количество мест где он бесполезен. Для того, чтобы оценить всю прелесть RAII я рекомендую один раз написать что-то на С++, а потом попробовать переписать это на чистый Си :)
Язык чрезвычайно сложен из-за его истории. В С++ имеется масса устаревших конструкций, через которые приходится продираться для того чтобы найти что-то ценное.
Чтобы решить эту проблему, существуют Core Guidelines, и они регулярно обновляются
В сущности это сборник советов "как идеологически правильно писать на С++". Впрочем, на каждый совет там приведены примеры и обоснования, а также случаи, когда в целом можно и не следовать этим правилам.
Вообще, для поддержки всего, что там написано, существует либа GSL
особенно про выбор операционной системы, где решающим фактором является таск-бар и его геометрия
"Эргономика" использования ОС - это основной фактор для меня, т.к. весь используемый мной софт плюс-минус кроссплатформенный. Я сижу за компьютером по 10 часов в день, хотелось бы чтобы делать это было удобно.
Может ли?) Всё что мы знаем, что текущее состояние резистора какое-то, а все предыдущие его состояния - в нашей памяти)
Будем честны: лишь для (очень) немногих людей работа - это источник удовольствия, и не является необходимым условием для выживания)
Впрочем, лучшее, что я смог нагуглить, говорит что большая часть людей более или менее удовлетворена своей работой (почти везде, кроме Африки).
Кроме Яндекса. Эти будут писать каждый месяц минимум :)
Так, ну это всё направда) Рекомендую ознакомиться с тем, чем занимаются аналитики в крупных компаниях, и понять что это мало имеет отношения к коду)
Декомпозиция - это декомпозиция) Совсем другой навык)
Не знаю, от возраста сильно не зависит. Вы просто тот 1 из 10 :) Просто одни люди умеют грамотно структурировать мысли, а другие нет.
Тут стоит уточнить, что до тех пор, пока результатом вашей аналитики пользуетесь только вы - вам аналитик и не нужен особо. А вот если надо что-то узнать, оформить в понятный документ и передать его команде - тут как бы всё ОЧЕНЬ плохо у разработчиков)
Мой опыт подсказывает, что только 1 из 10 разработчиков может выполнять роль аналитика. По крайней мере сколь либо сносно. Роль QA разработчики вообще не могут выполнять) Точнее могут конечно, но качество проверки качества будет очень унылым) Особенно если продукт сложный)
Их нет) Хуже того, сейчас по разным компаниям расползлись бывшие руководители Яндекса, и они сокращают аналитиков везде, где появляются. Тестировщиков, кстати, тоже иногда) Мол роль QA и аналитика может и разработчик выполнять. И это почти цитата, на секунду)
Oracle вроде проиграл суды по этому поводу, нет?
Занятно, но делает их не ядро, хотя наверное они хотели бы)
Я вижу только один минус - я его не знаю) Последний раз я на Фортране что-то писал лет 10 назад) Мне понравилось)
userver? Или чем не устраивают Либы, из списка Communication?
https://en.cppreference.com/w/cpp/links/libs
Впрочем, если есть деньги - есть Qt)
Тут полностью поддерживаю, но комитет по С++ делает шаги в этом направлении.
static_assertи концепты решают часть проблем, по крайней мере в вашем коде) Используйте их, где только можно. Ошибки boost обречены быть ужасными, тут ничего не поделать)Также рекомендую ChatGPT (и аналоги) для упрощения жизни себе) Эти инструменты реально хорошо расковыривают километровые логи ошибок.
Я поработал с Meson довольно много (два года использовал его в продакшене) и могу сказать, что лучший - по прежнему громоздкий CMake. К сожалению, документация Meson оставляет желать лучшего, плюс как только нужно сделать что-то за рамками простых сценариев, реализовано из ряда вон плохо. И он жутко медленный (питончик под капотом, что тут ещё добавить). Впрочем, синтаксис его приятный + нативная интеграция с Conan радует.
CMake можно сделать совсем чуточку проще, используя вот этот набор скриптов
https://github.com/StableCoder/cmake-scripts
Вы не совсем правильно понимаете RAII. Идеологически его определение может и требует передать всё в конструктор, но суть его на самом деле не в создании объекта, а в уничтожении, как бы парадоксально это не звучало.
Суть RAII - это момент вызова деструктора. Объект должен подчищать за собой все ресурсы которыми он завладел при его окончании времени жизни. При этом вам вообще никто не мешает реализовывать паттерны вида строитель, или тупо сделать пустой конструктор и отложенный вызов метода Init(), хоть это концепутально может быть и не очень верно.
При этом количество раз, где RAII даже в изначальном смысле бывает полезен - сильно превышает количество мест где он бесполезен. Для того, чтобы оценить всю прелесть RAII я рекомендую один раз написать что-то на С++, а потом попробовать переписать это на чистый Си :)
Чтобы решить эту проблему, существуют Core Guidelines, и они регулярно обновляются
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
В сущности это сборник советов "как идеологически правильно писать на С++". Впрочем, на каждый совет там приведены примеры и обоснования, а также случаи, когда в целом можно и не следовать этим правилам.
Вообще, для поддержки всего, что там написано, существует либа GSL
https://github.com/microsoft/GSL
Но на практике я не видел, чтобы ей кто-то всерьез пользовался.
Но эта страничка существует :D
https://en.cppreference.com/w/cpp/compiler_support
Не знаю :) Обычно сотое нажатие на кнопку "ОК" срабатывает, а на тренировку или заведомую возможность другого результата не тянет)
Не нужно, чтобы геленваген был всегда. Важно, чтобы его присутствие ощущалось и вызывало страх.
"Эргономика" использования ОС - это основной фактор для меня, т.к. весь используемый мной софт плюс-минус кроссплатформенный. Я сижу за компьютером по 10 часов в день, хотелось бы чтобы делать это было удобно.
Ставишь Ubuntu и не паришься. 99% выдачи гугла будет всё равно для Ubuntu.