Как научить себя писать качественный код и не овертаймить. Опыт Unity3D Technical Lead

Всем привет! Меня зовут Иван Бондаренко, я Unity3D Technical Lead в PAGA GROUP. В этой статье я хочу поднять тему развития профессиональных навыков. Разработчик это не та профессия которой можно научится раз и навсегда. Мы не можем стоять на одном месте, так как сама индустрия развивается довольно бурно и нам нельзя отставать. Ниже мы рассмотрим один из сотен подходов к развитию. Он не так популярен среди разработчиков, и подходит не всем. Но он самый быстрый из тех, которые знаю я.

Несколько слов о теории

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

Либо после нескольких недель работы с написанным такими теоретиками модулем, вы понимаете, что если выбросить 80 процентов их кода, то по сути ничего не поменяется. И это на поздних этапах разработки приложения (да, да, я про оверинжиниринг). И это люди, которые потратили тысячи часов на умные книжки и пространные споры о парадигмах... Есть ли способ избежать такого результата при этом затратить меньше времени на развитие? Как раз такой подход я и собираюсь предложить.


Начнем с конца, с результатов. У меня была довольно стремительная карьера. Уже после двух с половиной лет опыта разработки я получил позицию Lead в крупной компании. При этом я даже не позиционировался на нее, а в широкомасштабном тестировании знаний занял 2-е место среди десятков разработчиков, где были люди и с 10-летним стажем и т.д. У меня в команде есть разработчик, который год назад был на позиции Trainee, а сейчас он уверенный Top Middle. И причина не в низком критерии оценивания, а в том что я тестировал данный подход к обучению на своей команде.

В последнее время мы практически никогда не срываем сроков, никто не овертаймит, а новые пришлые разработчики отмечают что еще не видели такого, цитирую: «Понятного кода». Пока что все активные программисты, работающие по этой системе, поднимали по уровню за год, хотя выборка небольшая и не заслуживает доверия. Заинтересовались? Тогда поехали.

Своевременный отдых важен, как и работа по 8 часов в день

Итак. Начнем с того, что никакие советы вам не помогут, если вы ленивы и не «пылаете» своей профессией. Каждый час, потраченный на что-то другое, кроме работы — это наглая кража у себя самого. По статистике вы должны провести 10 тысяч часов именно за работой в любой сфере, чтобы стать профессионалом. Потратили 2 часа в день на Tik-Tok в рабочее время — уменьшили скорость своего развития на 25%. А это не 5 лет до Senior, а все 7.

Правда, я видел разработчиков и с 15-летним опытом на уровне мидла. Даже не хочу знать, чем они занимаются в рабочее время.

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

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

Итак, есть три этапа развития:

  1. Говнокод (вы учитесь, как нельзя писать, у себя);
  2. Тыканье-Мыканье (вы учитесь, как нельзя и нужно писать, у других);
  3. Креативная фиксация (вы пишете, как вам подсказывает подсознательный суфлер).

Рассмотрим эти этапы развития подробнее.

Говнокод

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

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


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

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

Это касается любой профессии, не только разработчиков. Вот к какому врачу вы пошли бы? Который знает как нужно делать или к тому, который точно знает, что делать не следует? Вероятность выжить у второго намного выше. Такой принцип в медицине поставили на первое место. Все помнят первый постулат Гиппократа: «Не навреди!» (постулат то второй конечно, но не суть). Специфика нашей специальности немного другая, но важность этого аспекта остается той же.

Вы должны научится чувствовать на подсознательном уровне, что делаете что-то не то. Именно «ЧУВСТВОВАТЬ» эту вязкую паутину сквозных связей без древовидной структуры зависимостей. Это первичное понимание плохого запаха кода. Оно научит вас меньше ошибаться еще на начальных этапах выбора подхода к решению задач.

Этот этап должен завершится с переходом вашего скилла на уровень Middle. На этот этап уйдет примерно год, если у вас есть талант и аналитический склад ума. Больше, если у вас есть настойчивость, что не менее важно.

А что если бы вы следовали другим путем? Обычно альтернативный вариант оставляет артефакты в виде недостатка опыта неправильных путей. Разработчики зачастую несут это «добро» и на более поздние уровни вплоть до Senior. Даже у опытных «помидоров» этого типа есть участки кода, которые ведут к дестабилизации довольно явно и они узнают об этом только на поздних этапах проекта. Добрать такой опыт на более поздних этапах сложнее и дольше, так как им довольно тяжело отучиться от устоявшихся привычек.

Тыканье-Мыканье

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

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

По сути нам нужно создать Чашку Петри, способствующую зарождению паттернов из обрывков интересных решений и собственных идей. Учить при этом паттерны даже не старайтесь. Можете пролистать их для интереса, но ни в коем случае не вникать и не смотреть примеры их реализации — по крайней мере до уровня Top Middle, то есть до окончания данного этапа. Хотя полезных статей и документации это не касается. Так же не советую читать умные книги по разработке и теории программирования. Объясню свою позицию.

Я разделяю все подходы к набиванию скилла на 2 группы: теоретические и практические. Суть разбиения проста: нужно разделить векторы информационных потоков на 2 категории: те, что идут к вам, и те, что идут от вас. Для понимания примером может быть просмотр фильма. Вы полностью отключаете любые потоки информации, идущие от вас, сконцентрировавшись на прием информации. А противовесом служит компьютерная игра, когда обмен информацией обоюдный. Еще примером может быть просмотр роликов с курсами на Youtube и просто практика на проектах.

Таким же образом можно отделить опыт полученный от теории и от практики. Эти два похожих способа получения опыта приносят совершенно разные плоды по своей сути. Для лучшего понимания приведу свое излияние в более абстрактное поле на конкретных примерах.

Представьте себе двух детей. У одного обеспеченные родители и они покупают своему ребенку конструкторы, развивающие игрушки и огромные наборы LEGO cо сборными бэтмобилями и фигурками LEGO Ninjago. Все детство он читает инструкции по сборке, строит огромные города из конструкторов, учится нестандартному мышлению игрушками головоломками. Со временем наборы LEGO смешиваются и он начинает творить из деталей что-то свое. Он вырастет умным и успешным образованным человеком и становится инженером. Проектирует сложные промышленные установки, высоконагруженные высотные здания сложной конструкции и сверхсложные производственные линии на гектары площади. Он достиг успеха и уважения.

Второй же ребенок родился у родителей со скромными достатками и все детство сидит в песочнице собирая бэтмобили из камешков, глины и палочек. Мастерит игрушки, вырезая их из деревяшек (рогатки например), и строит замки из веток, испытывая их на прочность. Ум пытливый и своим упорством он добивается позиции главного инженера в своей компании. Из-за пластичности ума, незашоренности инструкциями и правилами, умения видеть лишнее и отсекать его, он создаёт компании с необычной структурой лишенной всего ненужного упрощая управленческие процессы. Это очень уменьшает производственные линии в разы, как и затраты на их обслуживание. Ломает привычные устоявшиеся правила и делает революцию в промышленности. Потом он запускает людей на Марс на своих же ракетах. Ну, а пока Илон все еще этим занят, продолжим.

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

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

Почему это важно? Как говорил сын главы дома Атрейдесов про залежи спайса: «Вы не можете владеть тем, что не можете уничтожить». То, что вы постигли сами, вы можете сломать, разобрать на мелкие детали и пересобрать, выбросив лишнее. Вы по-настоящему владеете этими знаниями и они вам подчиняются, а не диктуют свои правила.

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

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

Логично утверждение: «Я вот знаю одного лодыря-разработчика, который тоже не читает книг и ему лень изучать паттерны. А вот код его — говно, никакой пластичности ума я не вижу и вообще у него уши большие.» И вы окажетесь правы. Этот подход требует от разработчика довольно твердого характера, самодисциплины и упорства. Дело в том, что в процессе у вас часто не будет ничего получаться. Тут главное не останавливаться, а пробовать снова. С маниакальной настойчивостью биться головой об стену пока она не сломается.

Вы скажете: «Но это все какая-то графоманская водичка. Что делать то? Конкретики в студию, месье».

Рефакторинг

Ну что ж. Несколько месяцев назад в Discord dev-канале один из новых разработчиков задал такой вопрос: «А как все-таки лучше развиваться?» Я ответил — рефакторинг. На вопрос: «Почему?», я сразу же задумался. А действительно, почему? Ведь звучит логично: участвуя в новых проектах, вы получаете много опыта, потому что вы пишете много нового кода, новые задачи способствуют поиску также новых решений. Но давайте задумаемся, так ли это? Когда вы пишете новый код, то какие решения вы используете? Не новые.

Строя очередной дом, строитель не использует новые навыки при работе, а идет уже проторенными путями. Может быть новая ситуационная схема, форма, требования, материалы и дадут возможность научится делать новые вещи, но не дадут найти новые пути сделать что-то. Так же и разработчик. Участвуя в новых проектах, вы научитесь работать с новыми технологиями и задачами, но также вы научитесь очень малому количеству новых способов решения задач. То есть вы станете больше, но не лучше. А ведь вопрос был в развитии, то есть в том, как стать лучше.

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

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


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

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

Креативная фиксация

Третий этап должен выйти, наверное, самым не похожим на альтернативные подходы к развитию. Дело в том, что обычно опытные «помидоры» — это персонажи из мультфильмов похожие на пришельцев с огромными мозгами в прозрачной оболочке. Нам же более подходит образ старого монаха, сидящего в позе лотоса на склоне горы, познавшего Дзен, вещающего фразы на подобии «Чтобы научиться чему то новому, твоя голова быть подобна пустой чашей». А дело в подходе решения задач.

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

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

В нашей же ситуации есть более интересный подход — стихийная архитектура. Чтооооо?!!! Какая такая еще стихийная архитектура? Присядь, мой юный падаван. Сейчас все будет.

Наверное, каждый разработчик помнит такие моменты, когда вы решаете какую-то задачу, но четкого решения не видите. Вот что-то такое на языке вертится и вот его хвост мелькает, но целостной картины нет. Тут вы садитесь и просто втупую начинаете писать код. Вы так же не видите картины в целом, помните только прошлую строчку кода и знаете, какая будет следующая. И через 15 минут горячечного тыкания пальцами по клавиатуре запускаете скрипт. O my God!!! It’s alive!

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

Вот примерно так же работает и стихийная архитектура. Вы читаете первые наброски проекта и начинаете уже что-то ваять. Это пригодится. И вот это. А вот тут нужно хвосты вывести, не знаю, зачем, но чувствую, что пригодится. Именно ЧУВСТВУЮ. На этом этапе ваша главная задача отточить эту «чуйку». Я сам не знаю, как это точно работает, но понимаю что мой «внутренний суфлер» сидит где-то в подсознании. Я научился доверять ему и это дает свои плоды.

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

Выбросив весь код и взяв только контент, за 2 месяца я его переписал полностью, еще месяц потратил на портирование на другой игровой движок. При этом как самого движка, так и TypeScript я до этого не знал. Проект между прочим был многопользовательским и серверный хост с полной синхронизацией на вебсокетах без готовых решений писал я же. Через 3 месяца я отдал все это в отдел QA, и они нашли всего 17 багов. Код проекта уменьшился в 7-8 раз. Количество возможностей конфигурации возросло экспоненциально. При этом я писал разные модули проекта отдельно и собирал в конце. Они вполне себе состыковались с минимальной полировкой, удаленного и отредактированного кода было не более 10%.

При этом ни одной блок-схемы и проектирования наперед практически не было, если не брать в учет работу с back-end программистами которые занимались хранением данных пользователей.

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

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

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Рефакторинг же даст пищу для размышлений и наставит на путь истинный. Когда вы рефакторите код, то пробуете улучшить вещь, которая была создана вашими старыми навыками. В процессе вы вынуждены искать новые пути и, следовательно, расширять свой кругозор.

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

Вибачте, але це висмоктано з пальця. Ну або тільки з вашого особистого досвіду.
Чому ви думаєте, що хтось, роблячи рефакторинг гавнокоду, не отримає новий гавнокод? Абопоставлю питання інакше, як взагалі програміст початкового рівня зрозуміє, що це гавнокод?
А ось для цього потрібно читати розумні книжки і ходити на доповіді крутих фахівців, що ви і відмовляєте робити на початку вашого посту.

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

Якщо програміст прочитав десятки крутих книг, побував на сотнях доповідей крутих фахівців і його код не став кращим, то ніякий рефакторинг не допоможе.

Нічого проти доповідей крутих фахівців і не йшлось про що я згадував. Про знання з книжок на ранньому етапі не маю нічого проти, просто в даному підході вони можуть зашкодити. Так само думають біля третини знайомих мені фахівців і на цю тему було не мало спорів. При рефакторінгу гівнокоду однозначно вийде інший гівнокод, але малоймовірно що він стане гіршим, а скоріш за все — кращим. І писав що як раз основна задача новачків навчитись «Наслідкам». Бо, на мою думку, якщо ви будете писати як сказав розумний дядько, то це навчання буде менше ефективним. Тобто за фундамент ми беремо повне розуміння негативних «Наслідків» і відштовхуючись від цього фундаменту вже вчитись як писати правильно. У будівництві та медицині цьому приділяють дуже багато уваги. Як ви думаєте чому? В статті приділено багато тексту саме поясненню такої позиції. Перечитайте перший абзац в якому я писав що це не єдиний шлях розвитку.

Я все-таки не розумію, чому читання книг може зашкодити тим, хто їх читає? Можете обґрунтувати на прикладах із власного досвіду?

Була в мене одна однокурсниця. Дівчина була талановита і старанна та отримувала лише одні 5-ки. І от один раз на матаналізі викладач почав ставити їй питання на тему. Дивлячись у книжку я бачив що вона строчить все слово в слово. Тобто вона завчила матеріал на зубок і так робила постійно. Викладач теж буд не типовий і зрозумів це. Почав просити її розказати те як вона розуміє цей матеріал своїми словами. І тут вияснилось що вона не розуміє його. Від слова зовсім. Вона заучувала його просто на памʼять як китайську мову без розуміння про що ти говориш. Після цього вона не отримувала на його уроках більше 3-ки й це був єдиний предмет на якому в неї було щось крім 5-ки. Зараз на співбесідах я теж бачу дуже багато розробників які роблять так само. Розбираються у патернах, на зубок розказують усі принципи SOLID, можуть розповісти й про інші парадигми та й навіть приводять приклади задач де вони це все реалізовували. Але коли починаєш виводити його на дискусію і просиш трішки теоретизувати, то стає ясно що ці знання поверхневі і якби виразитись: «нескладні». Ви точно цього не пам’ятаєте, як і 90 відсотків сеньйорів, але коли ти вперше починаєш читати поглиблену літературу по архітектурі на рівні джуна, та вроді приклади є, й розумієш що пишуть, а таке відчуття що знання не твої. Вони не складуються в пазл в голові, коли всі частинки лежать на свому місці. Коли звʼязки наче магнітами самі притягуються до них і робиться такий звук кліка коли деталь входить в паз. Це в основному якісь абстрактні фігурки яки ти сидиш і пробуєш тикати їх у всі місця де бачиш. Типу ось я знаю такий патерн... Куди б його вткнути. Пробуєш сюди тикати, потім отут. І на 10-тий раз кудись все-таки вткнув і так ти робиш і далі в таких ситуаціях. Це не зовсім очевидно, але така людина починає використовувати патерни де треба, а де й не треба. А це прямий шлях до оверінжинірингу. Звісно з часом це проходить і до тебе доходить де їх слід використовувати, а де й спростити треба. Але це втрата часу. Я не претендую ні істину в першій інстанції. Це лише виводи з мого досвіду. Та я дотепер находжу лише підтвердження їм.

Переписанный с нуля код всегда будет лучше того что писался изначально — как минимум потому что на данный момент тебе полностью известно требования к проекту, которые (особенно в геймдеве) изменяются всегда «на лету». Так что в данном случае заслуга лежит скорее на стороне менеджеров которые смогли позволить двухмесячный «простой» продукта, чем на программисте с «внутренним суфлером» :)
А, учитывая, что про то как легко было поддерживать проект дальше не было ни слова, как и про то, как быстро в него смогли «влиться» другие программисты (а то есть — не показаны основные критерии качества архитектуры) — непонятно к чему был этот рассказ вообще

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

Підписатись на коментарі