Александр

Я бы спросил у самих разработчиков, хотят они помогать или это им не надо. С моей точки зрения команда должна быть тесно интегрирована и разработчики сами должны быть заинтересованы в качественных тестах и в их читаемости. И тут язык имеет значение. Разработчики должны понимать тест и в некоторых случаях даже советовать как его улучшить, потому что им всяко виднее как их код работает и где может зафэйлиться. Если же разработчики говорят "отстань со своими тестами" или "У нас некому работать 'обезъяной', поэтому нам важнее что бы ты дальше тыкал руками", то это очевидные организационные проблемы и их нужно решать не выбором языка, а поднятием этого вопроса на уровень руководства.

1. Хорошо помогает начать изучение с простых паттернов проектирования. Прежде всего это простые и понятные паттерны типа "стратегия", "команда", "итератор", "шаблонный метод", "посредник", "цепочка обязанностей". Изучив и поняв эти паттерны вы посмотрите на ООП по новому: не как просто структурированный код плюс данные в одном объекте, а именно как задумывалось его создателем - объект самостоятельная единица взаимодействующая с другими такими же посредством сообщений. Причём она является first class также как в функциональном программировании функция. К тому же на указанных паттернах строятся и остальные. Например, фабричный метод - это частный случай шаблонного метода. Так постепенно придет понимание куда и зачем применять различные паттерны.
2. Когда решаете какую-либо задачу, думайте о нескольких вариантах архитектуры для её решения. Далее старайтесь выбирать
вариант не на основе личных предпочтений или предыдущего опыта (не важно, положительного или отрицательного), а на основе анализа, какой из вариантов здесь реально потребуется с точки зрения дальнейшего развития проекта. Предыдущий опыт также надо учитывать, но все проекты разные, требования разные, и каждая ситуация может отличаться. Надо смотреть как могут изменяться или расшириться системные и функциональные требования (разумеется, для этого надо быть в контексте этих требований - т е знать их самих, манеру работы с проектом заказчика и т д) Во многих случаях, когда вы не сможете выбрать из-за недостатка информации, это логически подведёт вас задавать заказчику дополнительные вопросы. И через этот итеративный процесс приходит понимание, где и как применять паттерны.
3. Обратите внимание на паттерны ERP систем (для примера книга "Шаблоны корпоративных приложений" Мартин Фаулер) Особенное внимание надо уделить такому шаблону как инверсия зависимостей. Данный шаблон лично мне помог совершенно по другому взглянуть на ООП (во второй раз, уже после того как я стал применять другие паттерны ООП) Вот здесь https://blog.byndyu.ru/2009/12/blog-post.html очень понятно на мой взгляд описано (язык C# но всё тоже самое будет для любого ОО языка) Кроме того в этом блоге много всего по проектированию и рефакторингу.
4. Обратите внимание на книгу "Growing Object-Oriented Software, Guided by Tests" Стив Фриман Перевод на русский не гуглится, возможно его и нету. Но книга полезна тем, что в отличие от многих других книг по TDD в ней разбирается не только методика тестирования и написания тестов, но и принцип тест -> код -> рефакторинг. И разбирается на достаточно длинном примере. Из неё вы можете подчерпнуть привычку рефакторить, а не переписывать заново. Причём даже если у вас на проекте цикл другой - например тесты пишутся после функционала, всё равно образ мысли изменится и масштабный рефакторинг не будет вызывать непреодолимого желания выбросить и переписать с нуля.
5. По рефакторингу могу порекомендовать книгу "Работа с унаследованным кодом" Майкл Физерс. Кроме того об этом много статей в уже упомянутом блоге Александра Бындю. Грубо говоря я бы назвал ту подборку статей "как не переписывать и начать жить"
6. Ещё один блог где собрано большое количество полезных материалов по ООП, рефакторингу, проектированию, это блог Сергея Теплякова Вот ссылка на его подборку книг по теме: sergeyteplyakov.blogspot.com/2013/08/blog-post.html
7. Изучайте материалы постепенно. Не стоит сразу пытаться воткнуть только что полученные знания в первый попавшийся проект. Обсуждайте возможные решения с коллегами. Со временем они также станут поддерживать эту практику. Если есть возможность, попрактикуйте парное программирование. Причём не обязательно с более опытным коллегой. Иногда вопросы задаваемые наивным человеком заставляют задуматься гораздо крепче, чем ответы получаемые от мудрецов.

Я не знаком с интерфейсом телеграмма, но думаю что вам нужно создавать поток всякий раз, когда бот получает обращение от нового пользователя. И уже этот поток должен ему отвечать. По окончанию ответа поток должен сам завершаться. В это же время главный поток может продолжать принимать новые обращения.
Это наиболее простая схема асинхронной обработки, но в ней имеются недостатки. Если одновременно обращаются много пользователей, для каждого будет создан поток. Это может привести к серьёзной деградации производительности ОС или даже исчерпанию ресурсов. Эту проблему можно решить разными способами. Например, так как указал Dmitry Roo - через так называемые Future или асинхронные задачи. Но можно также использовать пул потоков и очереди. На мой взгляд решение с очередями будет более контролируемым, но и более трудоёмким и требующим опыта. Для первого шага можно использовать простую схему с созданием нового потока для каждого нового пользователя.

Вы пытаетесь не переменную инициализировать, а поле класса. Его можно инициализировать либо внутри метода, либо при объявлении. Но у вас инициализация лежит внутри определения класса. А так нельзя.