что мне может гипотетически помочь?

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

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

3. эта картинка:

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

посмотрела одну лекцию, разобралась получше с композициями, решила одну из 5 оставшихся задачек и никто не умер ✨

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

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

однажды ты спросишь меня, что я выберу: внутренние классы или внешние? в ответ я промолчу, и ты так и не узнаешь, что я просто потеряла дар речи после сегодняшней лекции и выбираю только один класс — свой пятый, где мне 11 лет и я бью крапиву палкой и ничего вот этого всего не знаю

работаем дальше, коллеги

сегодня по плану: чучуть посмотреть, как откроют яндексовский лекторий, сходить на учебную консультацию и вернуться слушать спикеров, обещают прикольное

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

ну я

если вы думали, что я забила на Яндекс Лекториум, то вот и нет ✨

послушиваю иногда фоном лекции, что-то понимаю, что-то нет, но в голове зато хоть что-то остаётся. и сегодня я попала на СУПЕРСКУЮ лекцию про архитектуру кода для джавистов: конечно, из понятного мне было процентов 30, но какие они, эти 30!!

читал лекцию Сергей Федосеенков, глава отдела разработки битуби продуктов Маркета, и иллюстрировал всё примерами из жизни и практики (круто и наглядно!). иногда на каком-то базово-гуманитарном уровне не верится, что все эти сложные и абсолютно человечески реализованные сервисы — это просто набор компуктерных команд, методов, переменных и классов. но вот ты видишь, как знающий человек показывает тебе на примере кода, как реализуются бизнес-стретегии, как функционируют соединения к базам данных, в которых хранятся условные заказы с чипсиками — и ну это с ума сойти, это РЕАЛЬНО 🥹

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

📌 нужно всеми силами избегать дублирования кода, потому что это приводит к проблемам. например: если вы посадили баг или вам нужно доработать код, не всегда очевидно, где искать продублированные куски. в итоге что-то дорабатывается, что-то нет, и выходит так себе

📌 kiss: keep it simple, stupid. мне кажется, знаменитейший принцип, знакомый всем, от новичков до супер-прожжённых прогеров. не нужно решать задачу сверх-сложными методами, а лучше инкапсулировать логику совсем просто, супер-наивным способом, чтобы потом всегда можно было вернуться к переработке кода или даже всей архитектуры и не потеряться в трёх тысячах сосен :') в трёх соснах блуждать приятнее. а может быть, окажется, что этих трёх как раз и достаточно

📌 есть ещё пять принципов SOLID, спикер не стал останавливаться на каждом, но пояснил, что это аббревиатура, и каждая буква в ней — какой-то принцип объектно-ориентированного программирования. я почитала об этом отдельно, очень хорошие и важные принципы, которыми мы уже сейчас на занятиях пользуемся и сами того не знаем :) напишу о них отдельный пост завтра-послезавтра!

в общем, час пролетел продуктивно: по большому счёту я вдохновлялась сложной терминологией и пыталась на каком-то интуитивном уровне понять, о чём идёт речь 😂
но и без полезностей не ушла! так что продолжаю ратовать за подход к обучению «вписывайся в любые учебные авантюры, а там уж если и поймёшь процентик, то тоже хороший результат» 👀

это я, когда уезжаю трогать песок у моря в другие города по выходным

нашла целую подборку на гитхабе всяких полезностей по джаве: руководства, статьи, учебники. там не только джава, на самом деле, по индексу выше можно найти что угодно ❤️‍🔥

о личном, но об очень важном: второй день подряд просто лежу 👀
давление фигарит, еле глаза разлепляю, сегодня сделала основной костяк работы и отпросилась спать. какой там код...
в какой-то момент засомневалась, стоит ли идти на занятие в таких условиях. а потом решила, что стоит!

пусть я и послушаю лекцию по касательной, но 1) я её потом ещё разок пересмотрю и 2) так я всё равно сделаю хоть что-то. а хоть что-то лучше, чем ничего 🤞🏻

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

я и мои домашки:

за всю неделю, что у меня болел зуб, я 🤕🦷:

1. не пропустила ни одной лекции и жёстко собой горжусь!!

2. возобновила решение домашек: начинаю с наиболее актуальных, затем возвращаюсь к стареньким долгам. не сомневаюсь, что скоро выполню все 🍀

3. постигла дженерики, обëрточные типы, линкед листы и работу всего этого добра на примере реальных программ;

4. и мощно возвращаюсь с кучей постов на давно интересовавшую меня тему, с которой хотелось разобраться как следует. wait for it 🤞🏻✨

итак, руки наконец-то ✨дошли✨

встречайте: сегодня весь день в эфире — принципы SOLID для всех, кто постигает таинство ООП.

в основе этого и последующих постов — материал, найденный на родном хабре 👈🏻

давайте начнём с предисловия: SOLID — это аббревиатура. или, вернее, мнемонический акроним. про каждую буковку поговорим отдельно, а пока — вот общая картинка 👀

идея названия принадлежит Майклу Фэзерсу, а сформулировал принципы программист Роберт Мартин. идея была простая, но важная: выделить самые важные правила ООП, благодаря которым можно будет создавать легко поддерживаемые и расширяемые системы. словом, гибкая и адаптивная разработка без SOLID — это не солидно 😉

🎯 s: single responsibility
(принцип единственной ответственности)

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

в соответствии с этим принципом программисты разделяют различные типы поведения, чтобы изменения, внесенные в одно поведение, не влияли на другие.

каждому классу — своя логика!

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

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

🚪o: open-closed
(принцип открытости-закрытости)

классы должны быть открыты для расширения, но закрыты для модификации. то есть все программные сущности по идее должны позволять менять свое поведение без изменения их исходного кода. зачем? во избежание ошибок, конечно же. одно изменение в программе = изменения во всех зависимых модулях. поэтому лучше добавить новое, чем переписывать старое.

кажется, что два этих признака (расширение vs запрет на изменение) друг с другом не вяжутся. кажется, что расширить поведение модуля — значит, внести в него изменения, не так ли? так как тогда выполнить оба условия?