Adamos, "жопорук-мажор" это намёк на меня? Просто как раз я про мак писал в одном из комментов, куда вы влезли со своим мнением, не пояснив, что вы имели ввиду. Я все деньги заработал сам и я ни разу не мажор, так что можно успокоиться. Я говорю про свой опыт. Если вы скрипты гоняете туда сюда, и хеллоу ворды пишете, то это не значит, что теперь всем хватит 16Gb оперативки. Что непонятно в моих словах? Мне не хватало 16 Gb так, что это был ад. Сборка проекта 3 минуты, а иногда 20 минут. Ну да, подумаешь. Ерунда какая. Из-за свопа и было падение скорости сборки в несколько раз.
Ну да, сегодня он изучает, но это не разработка! А как начнётся разработка, он приступит к геморному действу - продать ноутбук и купить новый. Гениально (нет)!
Adamos, если слабое железо нужно, чтобы в полной мере ощутить тормоза приложения и писать их оптимизированными, то это плохой совет. Мне подобное советовали. Для разработки должно быть мощное железо, чтобы не портить себе нервы, чтобы быстро проверять работу кода, а не ждать по пол дня сборки. Для таких проверок можно купить старьё с рук.
По поводу ноутбука не нужно заблуждаться, что будет неудобно, что нужно работать на маленьком экране. Нужно просто купить монитор или два и работать на них дома, а в поездках уже с самого ноута. MacBook Pro для этого идеально подходит, но хороший конфиг сейчас стоит как автомобиль (от 450 000 рублей примерно, если покупать не особо рискуя в одном из магазинов, а не на сайтах у перекупа). Хороший это от - MacBook Pro M1 (если планируется Unity или Unreal Engine, то M1 Max, иначе сойдёт и M1 Pro)/ 32Gb объединённой памяти/ 512Gb SSD. Если ноутбук планируется из мира Windows, то нужно искать такой, чтобы поддерживал вывод на один или два монитора в 4К с 60 кадров в секунду. Я пробовал работать на маке с переходником, который мог позволить работать только в 30 кадров, было впечатление, что это комп тормозит. Непривычно и неудобно.
Если хочется заложиться сразу на будущее, то если это будет ноут, то на нём должно быть от 32Gb ОЗУ, а лучше 64GB. Сегодня это консольные приложения на С++, а завтра это разработка игр на Unreal Engine 5 (и выше в будущем) и С++. Просто поверь мне. 16 GB ОЗУ - это боль и страдания, чуть ты сделаешь шаг влево, шаг вправо. На стационаре или ноуте при любом раскладе должен быть SSD от 1Tb, в крайнем случае, если хочется страдать - 512Gb. Например, сегодня ты учишь С++, завтра ты начнёшь пробовать разработку под мобилы. Менеджеры пакетов много всего кешируют. Среды разработки качают много разных SDK, например, для разработки под Android, здесь нужна одна версия, там другая. Эмулятор отъедает 10Gb легко после первого запуска. Место будет отъедать серьёзно. Чистить в любом случае будет нужно, но не так, что каждый день искать, что удалить.
С++ здесь совершенно ни при чём. Если нужна мобильность, то ноутбук, если на мобильность по барабану, то можно и стационар, так как на него можно поставить хорошую видеокарту и компьютер сойдёт и для работы и для развлечений.
Забыл упомянуть важное. При написании делай упор на приложения с одной Activity. Сейчас почти все так пишут. На YouTube есть доклады на эту тему. Тот есть не трать много времени на написание софта с кучей Activity. Если только в учебных целях: чтобы попробовать на практике все варианты.
Araya, да никто не будет в офисе тебя ничему учить. Повезёт если просто дадут много времени, чтобы разобраться с каждой задачей на работе. И повезёт, если это не правка багов. Самое неинтересное занятие, которое можно придумать — это только править баги на проекте (не имея задач на разработку). Единственная мотивация там остаться — это если у тебя хорошая зарплата. Наставник может ответить на твои вопросы. Рассказать про архитектуру приложения. Иногда отвечать на вопросы, но не на простые, которые ты можешь быстро нагуглить.
Если в конструктор класса передали невалидный параметр, то можно бросить исключение, так как в противном случае всё равно нужно будет создать невалидный объект, да ещё и не забыть проверить его после создания, что он невалидный. Ты проверишь, а твой коллега нет. Вот здесь исключение абсолютно оправдано. Есть и другие ситуации. Нужно исходить из логики.
Вот посмотри как я делал абсолютно тоже самое в Kotlin (requestUserInputAsInt). В Kotlin примере я бросаю исключение, если программист передал неправильные значения диапазона. Когда он поймает исключение, он исправит свою ошибку и больше она не возникнет. А ввод пользователя ожидаемо может быть неправильным, поэтому мы и обрабатываем это так, как будто это ожидаем. https://qna.habr.com/q/1166050#answer_2182636
WPF здесь точно лучше будет работать в плане отрисовки. Да и Windows Forms, по моему личному мнению это пустая трата времени. Можно немного потратить чисто для опыта и расширения кругозора. Все новые технологии, которые как-то связаны с UI так или иначе похожи на WPF и опыт оттуда будет в разы полезнее в будущем. Тот же AvaloniaUI почти один в один - WPF, а работает и на маке и на линуксе и на винде. Кажись, теперь ещё и на телефонах.
Асинхронный метод ShowCell здесь вообще не в тему. Это код должен выполниться синхронно. Parallel.For и Task.Factory.StartNew должны сделать только хуже, если не учитывать, что здесь ещё и синхронизации нет. Это вообще бессмысленные действия.
Ну да, сегодня он изучает, но это не разработка! А как начнётся разработка, он приступит к геморному действу - продать ноутбук и купить новый. Гениально (нет)!