ApeCoder

Понимать. При практике само запомнится. Они уже все записаны по нескольку раз в интернете и intellisense

Как вы ориентируетесь в чужом коде?

Подобное может быть востребовано например для ролика дублирования кода (только надо искать в своей кодовой базе, а не в чужой) - такое есть например в resharper https://www.jetbrains.com/help/resharper/dupFinder.html

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

Вот ещё нашел нечто
theory.stanford.edu/~aiken/moss

Так что, если сделаете алгоритм применение ему можно найти.

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

По-умному называется "декомпозиция" и есть разные статьи на эту тему. Например, вот 8 методов декомпозиции задач

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

Если у вас нет чего-то из того что ниже постараться это внедрить:
- автоматические тесты
- continuous integration
- code review или парное программирование
- автоматические средства рефакторинга
- статическая проверка (typescript, например)

Начать анализировать статистику по причинам возникновения ошибок - часто она в плохом коде.

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

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

Как-то так

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

Либо сделать проверку и выкидывать исключение, но тогда незачем возвращать true - это будет уже не предикат.

Люди могут разобраться даже без сорцов - Марк Руссинович разбирался в свое время по утекшим отладочным символам от винды (см. кстати, его книжку "Windows internals").

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

https://codereview.stackexchange.com/

Варианты:
- событие которое разборщик вызывает после понимания команды. Если обработчик события не обработал, вызывается дефолтное.
- Паттерн стратегия
- То же самое, только DI контейнером или абстрактной фабрикой или еще какой штукой

Изучаете ассемблер
Изучаете машинные коды
Пишете программу на ассемблере
Вучную транслируете в машинные коды
Записывате их в шестнадцатеричной системе счисления
Любым редактором который это поддерживаете.
Получаете работающую программу.

Можно найти какой-нибудь эмулятор старого устройства чтобы почувствовать как ветераны писали код в 1986

А зачем он нужен? Какую задачу решает? Измерение времени?

Посмотреть нет ли взаимосвязи между свойствами. Возможно есть группы связанных свойств, которые можно выделить в отдельные классы.

Обязательные свойства - параметрами конструктора, остальные свойствами.

Посмотреть также паттерны создания, например фабричный метод и билдер.

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

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

по while(true) не понятно какое именно условие выхода из цикла. То есть очевидно что цикл когда-то заканчивается но условие выхода размазано по его телу. Так же если происходит выход из цикла тоже трудно его понимать как черный ящик - т.е. дописывание, например, в конец фнукции какого-то кода не гарантирует его выполнения.