Век учись, а дураком помрёшь.
Контакты
Местоположение
Беларусь

Достижения

Все достижения (2)

Наибольший вклад в теги

Все теги (54)

Лучшие ответы пользователя

Все ответы (76)
  • Насколько адекватно требовать домашнего развития от разработчиков?

    @majstar_Zubr
    C++ & gamedev
    Это вполне адекватно, потому что в таком случае работодатель преследует лишь одну цель - помочь вам как можно скорее найти другое место работы.
    Ответ написан
  • Game-dev путь. Что мне делать?

    @majstar_Zubr
    C++ & gamedev
    У вас должна быть цель стать профессионалом в области. Потому что только профессионал может выбирать, с кем работать, где работать, над чем работать - над крупными проектами для правительств, над банковским софтом, над веб-проектами или над играми.

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

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

    Что вы можете сейчас сделать - взять прицел. Конкретно сформулируйте профессию и специализацию. Оптимизируйте процесс полученния знаний: как бы не ругали образование в ВУЗах СНГ, все же это нехилая экономия времени, если вы сразу будете получать профильное образование.

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

    А на самом деле надо. Вы должны получать удовольствие от получения знаний, потому что иначе вы не сможете сделать игры, которые могли бы приносить новый опыт игрокам. Чтобы транслировать новый опыт через генераторы опыта - игры - нужно уметь и любить этот опыт (субъективный и эмоциональный) получать, и представлять, как его давать людям. Разработка игр - всего лишь автоматизация этого процесса.

    Так что, запасайтесь попкорном и начните с языка Си. Освойте структурное программирование. Алгоритмы, структуры данных. Архитектуру компьютера, ОС. Не торопитесь как можно быстрее неправильно понять как можно больше вещей за кратчайший промежуток времени. Перечитывание и практикуете, пока не станет понятно так, что сможете научить кого-нибудь другого. Макконнелл, Роберт Мартин, Кент Бек, Эрик Эванс, Мартин Фаулер + 1 год дополнительного быдлокодинга на java и c# и c++ и у вас появится понимание ООП, ФП, типовые устройства моделей памяти и сборщиков мусора. Ещё за год научитесь писать настоящий ООП код, читать чужой код, даже если он написан в процедурно-макаронном стиле как книгу. Но надо ли вам эти три скучных года, потерянных полностью для личной жизни? Не проще ли получить solid knowledge и постепенно получать практику в среде опытных специалистов?

    Подытожу: становитесь профессионалом, на это у вас уйдёт ~10 лет после введения привычки учится в свободное время. Периодически смотрите на требования вакансий и составляйте себе древо знаний, которое хотите получить.
    Ответ написан
  • В чем суть процедурного программирования?

    @majstar_Zubr
    C++ & gamedev
    alex4answ, процедурный стиль использует только понятия модель памяти, типы, инструкции, программа и подпрограмма.

    Вот и всё. Никаких составных типов. Концепция "состояние" в коде никак не выражается. Держите её если хотите в голове либо в комментариях.

    Никаких сущностей в коде. Держите из в голове или в комментариях.

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

    Но это всё уже вводится в структурном программировании.

    Процедурное программирование вводит модель памяти с понятиями стек и куча. Хотите сделать функцию в процедурной парадигме - вам придется оформить её в виде подпрограммы и вызывать её из другой. Причем понятия линковки нет, вы будете делать это используя адрес в куче, а какие-то данные, типа, аргументы, будете сами на стэк ложить, каждый раз при вызове подпрограммы "функция".
    Ах, да, захотите функцию для сложения двух чисел, придется сделать ctrl-c, ctrl-v и в теле подпрограммы написать сложение двух кусков данных взятых со стека. Для разности - копируете код, в теле меняете инструкции. И так для каждой функции.

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

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

    А максимум абстрагирования, которое вводит процедурное программирование, это символьное произвольное именование адреса в памяти. Да и вместо типов, скорее, используется смещение байтов для коллекции, которым просто даны имена.

    Дело в том, что о процедурной парадигме можно говорить только ретроспективно. В основном, процедурная парадигма это классический ассемблер.

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

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

    Т.е. берёте вы современный компилятор / интерпретатор любого языка, пишете решение в один файл, не используете составные типы, а только интегрированные простые (если вы выбрали язык со строгой типизацией), не используете функции, а только операторы, как закончите, смотрите на код - вы решили задачу в рамках процедурной парадигмы.

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

    А вот в языке с полной поддержкой процедурной парадигмы можно делать такие подпрограммы, которые косплеят функции, но возвращают несколько "аргументов", причем пишут прямо в память. Да и в принципе, в процедурной парадигме можно делать свой ABI, нет никаких стандартов, нет правил, ничто не истинно и всё дозволено.
    Ответ написан
  • Зачем мне использовать this, если есть замыкания?

    @majstar_Zubr
    C++ & gamedev
    Меньше кода - меньше ошибок;
    Меньше кода быстрее писать;
    Меньше кода проще понять;
    Использование конструкций языка по их непосредственному назначению лучше выражают намерения;
    Ответ написан
  • Нормально ли для программиста быть трудоголиком, любить рутину, иногда быть уставшим и тупить от этого?

    @majstar_Zubr
    C++ & gamedev
    Предлагаю обобщить проблемы в одну и решить её.

    Обобщенная проблема называется дисциплинированность. Придерживание дисциплины - сложная работа для силы воли, и поэтому её сводят к формированию привычек и жёсткому следованию и слежению за исполнением того, что составляет привычку.

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

    Мытьё посуды, ремонт чего-то, чтение книги, кода, контрибуция в пет/опенсорс проект, семья - для всего нужно ввести правило, уделять не менее N времени в день/неделю/месяц.

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

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

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

    1) вернуться к азам - перечитать основополагающие для вас книги, например, для меня это Совершенный код, Экстремальное программирование и Тайм-менеджмент для системных администраторов; если есть подозрения, что вместо паттерна вы используете антипаттерн, то пришло время для тотальной работы над ошибками;

    2) начать записывать каждое решение задачи за день, самое важное - указывать время начала и время конца, если вы не ведёте ежедневник (в любом виде, достаточно весьма обобщенного лога деятельности за день);

    3) отдых и перерывы (кофе-брейк, перекур, переменка) отмечать тоже обязательно, и важно не путать отдых и паузы. Отдых сотредоточен на восстановлении организма после физического или интеллектуального стресса, в то время как брейки сотредоточены на недопущении вхождения в поток и на чередовании видов деятельности, что приводит к экономии ресурсов, выделенных на день.

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

    Проблема зарывания в работу/задачу решается введением строгого ограничения на продолжительность работы. Поставьте на своем смартфоне беззвучные и без вибраций будильники с перерывами в час+8 минут со смещением 5 минут к последующему будильнику. Позже оптимизируете под себя, просто важно ввести привычку поставить все на паузу, выкинуть из головы все на бумагу или в текстовый файл и 5 минут подышать свежим воздухом, выпить чаю, etc.

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

    Когда вы начнёте прививать привычку, вас может поначалу демотивировать количество времени, которое вы тратите на тривиальные задачи, и количество свободных часов в будний день. Но вы должны понять, в этом и заключается мощь и сила дисциплинированности: время в сутках строго ограничено, физиологические и интеллектуальные ресурсы на день строго ограничены, каждый день вы в магазине, где вы и покупатель, и продавец, каждый день у вас торги, tradeoffs, что я сделаю сегодня, а что я откладываю, если я дело откладывал всю неделю, то почему не хватает времени будет очевидно, если вы ведёте лог, учёт трат времени а своем ежедневнике. Только так можно понять, то ли задача неадекватная, то ли просто месяц для этой задачи неподходящий.

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

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

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

Лучшие вопросы пользователя

Все вопросы (9)