Визитная карточка канала.
Или пост о том, что тут можно найти.

Кто ведет этот канал?
Мое имя Денис Кузнецов, и я делаю игры на Unreal Engine порядка 10 лет. Я работал как в ААА студиях (Sony PlayStation), так и в небольших инди над различными проектами, большая часть из которых так и не увидела свет. Сейчас я работаю в одной из крупных компаний в РФ и Европе лидом команды очень крутых программистов.

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

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

Тем будет очень много, и все они направлены не только на программирование, но и на то, как нужно работать и, самое главное, мыслить программисту. Но посты буду выкладывать 1-2 раза в месяц, так что не ждите наплыва уведомлений.
Чего вы здесь точно не увидите - это рекламные посты. Данный канал я создал не для заработка, а для того, чтобы делиться опытом.

С моими тезисами будет несогласно очень большое количество людей, и, в целом-то, мне плевать =)

Когда я был маленьким, в классе 6-7, у меня были самые крутые оценки - двойки и тройки. Я не любил учиться, и не понимал, что говорят эти дяди и тёти за столом на другом конце класса. Мне больше нравилось рисовать, играть на Денди (Сеге), прогуливать школу, чем их слушать. Но тогда я не понимал почему.
Примерно тогда мама отдала меня учиться в частную школу Рона Хаббарда* (дада, того самого, что с динозаврами и инопланетянами дружит, а его лично и его саентология признана нежелательной в РФ, и книги признаны экстремистскими).
Я проучился там примерно 1-2 месяца, но потом вернулся назад, так как мы не были даже уровня среднего достатка, и денег у нас не хватило на оплату дальнейшего обучения. Не спрашивайте меня "Как так получилось, и что разве это не было понятно сразу?". Я был слишком мал, чтобы оценивать риски.
За этот короткий промежуток времени, пока я учился в этой школе, я прошел почти весь учебник своего класса по математике, а так же по русскому языку и другим предметам. То есть, я за 1-2 месяца прошел почти весь курс своего класса вместо 9 положенных.
При этом учителя в этой школе мне вообще не помогали. Они только контролировали то, что я изучил и что запомнил, но ни разу не объясняли мне суть предметной области.

Вы спросите:

А чему же тогда они учили?

А учили они учиться.
Учителя сидели со мной от начала и до конца только когда я читал книгу "Учись Учиться" Рона Хаббарда*. Они убедились, что я понял эту книгу от самого начала до самого конца, и только потом допустили меня к школьным предметам.
Дальше я полностью самостоятельно изучал учебники, решал задачи и ни разу не звал ни одного учителя, чтобы они мне объяснили тему предмета. Я проходил все тесты, которые они проводили каждые две недели, отвечал на все вопросы без каких-либо сложностей и имел одни пятерки.

Что же такого было в этой книге?
На самом деле абсолютно ничего сверхъестественного. Там всего 3 правила, которых нужно придерживаться, и тогда любая тема, любая технология, абсолютно любое направление станет легким для понимания.

Текст получился очень большой, и Telegram не дал мне опубликовать его в одном посте, поэтому пришлось переместить его в телеграф =)

Ссылка на продолжение:
https://telegra.ph/Post-o-tom-kak-nado-uchitsya-Och-bolshoj-post-08-17

*Рон Хаббард признан нежелательным в РФ, а его книги - экстремистскими.

Программистам (не знаю, как другим) очень хочется продумать архитектуру системы таким образом, чтобы она охватывала все возможные кейсы. Например, чтобы управление в RTS могло переключаться в FPS или TPS. Чтобы можно было написать систему, которая легко заменяется на другую.

Молодые программисты (я сейчас о возрасте их программистского духа, а не физическом возрасте) особенно сильно стремятся к тому, чтобы написать код "максимально гибким и масштабируемым". Прибегают к различным ухищрениям, продумывают огромные сложные заковыристые связи, которые можно подменять чуть ли не на каждой строчке кода, и это выглядит масштабно, это выглядит действительно круто. Но только в их глазах.
Приходят серьезные дядьки и ничего не понимают. Спрашивают "Что это?" А в ответ:

Теперь можно наш проект на космическом корабле запускать на фазе запуска.

И дальше идет закономерный вопрос, который почему-то все это время игнорировался полностью: "А заказчик это просил?".

Нет…

Была ли идея геймдизайнера запускать игру на космическом аппарате? Нужно ли оптимизировать проект? В интерфейсе класса вот эти 2 функции, написанные впрок, кто-то использует уже? Погодите, а ПМ разве выставил задачу написать целую систему настройки персонажа, его лица, тела, рук, когда он просил добавить возможность менять шляпки?
Я думаю, почти всегда будет один и тот же ответ "Нет". Продумывать системы наперед - это тратить свое время, время команды, компании впустую.
А вы не согласитесь, ведь:

Никто не может сказать, что в будущем потребуется! Продумав код заранее, мы готовимся к будущему!

А что если я вам скажу, что заказчик не придет к вам за этой фичей? Что, если я вам скажу, что вы потратите на несколько часов работы больше сейчас, продумывая систему так, чтобы она могла еще и "Х делать", но этот Х никто никогда не будет использовать? Более того, программисты будут приходить и смотреть на этот Х и думать, что он работает, и даже будут обращаться к нему. Но вы подумали о будущем, и всё же не до конца, и великий баг ждет своего часа.

А время, которое вы потратили уже не вернуть.
Более того, когда придет время использовать наконец-то вашу штуку Х, то ее все равно перепишут и почти всегда с нуля.
И не потому, что ваш код плохой. Просто когда приходит время реально делать то, что требует заказчик, всегда приходит и совершенно другой подход к реализации, чем тот, что был "на всякий случай".

Мы с ребятами в команде недавно прикинули, что было бы, если бы мы сделали работу впрок?
В итоге, получилось, что сейчас, не продумывая заранее, мы написали бы код за 1 час. А потом, когда к нам пришли бы и попросили добавить новую фичу - мы бы потратили еще 4 часа.
Но если бы мы заранее начали думать о том, как эта фича должна быть в коде - мы бы потратили 5 часов.

И вы сейчас скажите:

Никакой разницы! А код был бы готов! Я был прав!

Только к нам никто не пришел. Нас никто так и не попросил добавить эту фичу. В итоге код ушел бы в прод. А время нам никто не вернул бы. Оно бы сгорело безвозвратно.
А та самая милая фича, которая была не в приоритете, оказалась не реализована потому, что нам не хватило на нее 4х часов. И проект провалился, просто потому, что котиков нельзя гладить в игре.

Хорошо, что в команде есть понимание, что "впрок" - это время в мусорку =)

Другой вопрос, когда вам заняться нечем, и вы экспериментируете. Там вы можете продумывать системы хоть на 100 фич вперед и 100 лет поддержки. Вдруг, вы сможете создать такой фреймворк, который будет и для FPS, и для TPS, и для RTS, и вообще тык-пык, и GTA 10 готова?

Я как-то от скуки, например, решил посмотреть, что получится, если геймплейный фреймворк для TPS разделить на десятки плагинов и подключать их в зависимости от необходимости. Получилось гавно, конечно, но я люблю эксперименты =)

Приветственный пост о том, как я открываю комменты для последующих постов (за одно тестирую, все ли верно настроил) =)

Во-первых, в канал пришло 153 человека, чего я не рассчитывал, если честно. Был уверен, что соберется человек 50, и то уже неплохо. Всех рад видеть, всех буду рад читать в комментах, велкоме =)

Во-вторых, открывая комменты, я бы хотел обозначить несколько правил общения:
- Можно поливать грязью мои посты путем проставления смайликов ( 💩 и/или🖕). Никто не узнает, что это вы. Радуйтесь =)
- Я люблю критику, но здоровую, логическую, без эмоций, сарказма и эго. С удовольствием обсужу ваши точки зрения, если в них не будет предвзятости =)
- Старайтесь все-таки оценивать себя и свое восприятие. Может быть, вы не правы? Может быть, вы что-то упустили или забыли? (Я стараюсь эти вопросы задавать постоянно себе).
- Банить буду за любые переходы на личности.

А эт мой кот =) Он будет здесь часто мелькать =)

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

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

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

То есть, после удаления зуба воспаление уйдет, так?

И он взорвался! Он начал на повышенных тонах объяснять мне, какой он специалист, как много лет он трудился и изучал всё. Как он жил в Индонезии, как он жил в каких-то еще странах, где проходил обучение, сколько он операций сделал. Да как я вообще посмел сомневаться в его навыках!
И всё это на ломаном английском (было оч смешно). В итоге, вместо того, чтобы он меня успокаивал, успокаивал я его и объяснял ему, что вопросы важны для моего внутреннего понимания происходящего и планирования будущего =)

Проблема в теме вопросов вот в чем:
Есть люди, которые не могут нормально воспринимать вопросы. Для них это повод вас унизить, вас уволить, ткнуть вас носом в это, воспользоваться вашими незнаниями, и так далее.
Мы растем не в вакууме и так или иначе постоянно взаимодействуем с людьми разного сорта. Когда мы задаем вопросы - мы видим определенные реакции, и те реакции, которые приводят к нежелательным последствиям, оказывают на нас значительное влияние.
Чем больше таких реакций мы видим, тем больше мы перестаем задавать вопросы, чтобы их не видеть. Но в этом случае мы остаемся в пузыре незнания того, что же в итоге должны мы сделать.
Или другой пример. Как программист игровой логики, я сталкивался с большим количеством геймдизайнеров и "геймдизайнеров". И вторые бесились от того, что я приходил к ним и задавал им вопросы, чтобы понять, что они хотят. Я отвлекал их своими вопросами от "работы над проектом" (вместо того, чтобы продумывать игру, они делали ролики), и за спиной они даже начали называть меня канарейкой.
И когда я не выдержал и психанул, то выяснилось, что:

Ты ж лид (программистов)! Ты должен сам всё придумывать и делать (за них игру)!

Здесь стоит добавить, что есть такое понятие, как "Разделение Ответственности", и я обязательно разберу его до основания.

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

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

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

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

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

Следующая тема называется "Как правильно рассказать".

Пост получился очень большим, поэтому я оформил его в телеграфе =)

Предлагаю продолжить там:
https://telegra.ph/Kak-rasskazat-ob-ehtom-09-17

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

Тема поста "Фокус. И два дела одновременно".
Часть людей считает, что это нормально - делать работу и параллельно смотреть фильм / подкаст / сериал / слушать музыку, слова которой вы понимаете.
Ну правда, зачем художнику работать в тишине или под музыку без слов? Он вполне может параллельно смотреть передачу Пучкова, пока рисует космические корабли. А иногда даже играть в игры, ведь это пошаговая стратегия - сделал шаг и потом поработал. Сделал второй шаг - поработал.

Но давайте посмотрим на это с другой стороны и проведем эксперимент:
- Попросите придумать какого-нибудь ИИ вам примеры задач на простые сложения 3-хзначных чисел. Штук 50, например.
- Запустите свой любимый сериал, начните параллельно считать задачи в уме и записывайте ответы.

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

То есть, когда вы делаете два дела одновременно, то мозг начинает распыляться и выполнять некачественно ОБА действия.
Фокус - штука легко сбиваемая. Если человек поймал фокус, то лучше его не дергать или дергать по минимуму, чтобы он мог сделать дело хорошо.
Когда фокус сбивается, то у человека выгружается все из памяти, и возвращение обратно в работу требует большого количества времени.

Человеку сложно восстанавливать свое внимание к деталям, после того, как его просто спросили "Как дела?". В каком-то из исследований я читал, что отвлечение человека от задачи на 5 минут приводит к возвращению в фокус обратно только через 30-40 минут. А параллельные действия и вовсе не дадут вам сфокусироваться нормально на решении задач.

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

Поэтому, если у вас не получается сфокусироваться, вас постоянно что-то отвлекает - для начала попробуйте перестать смотреть сериал параллельно =)
Если вокруг шумно, и разговоры коллег вас отвлекают - сообщите им об этом, попросите их быть тише. Если есть возможность - найдите другое место для работы. Физическое, не компанию.
Если вы не хотите фокуситься на работе из-за нелюбимой работы / начальства / проекта (итд) - зачем вы там работаете? Поменяйте компанию. Если не можете поменять компанию - делайте работу качественно хотя бы для себя. Ведь это опыт, в первую очередь, для вас. Вы иначе тратите свое время, прожигая его.

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

Я смотрел выступление на Ted Talks, где хост рассказывал, что если человек не спит минимум 7 часов ночью (это важно), то это сильно бьет по его мозгу, а качество его работы начинает падать в нулину. Огромное количество побочек и прочего я даже расписывать не буду.
Есть интересные исследования, которые доказывали, что человек, работающий 3 дня по 15 часов, выполняет качественно задание ровно так же, как отдохнувший и выспавшийся человек работает 8 часов 1 день. То есть, отсутствие сна и постоянная напряженность настолько сильно пагубно влияет на принятие решений и размышления, что работу можно смело выкидывать и переделывать заново.

В общем, не теряйте фокус, высыпайтесь, не отвлекайтесь и стремитесь качественно выполнять свои задачи =)

И завершая тему общения (надеюсь, не надоела еще вам =)).

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

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

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

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

Но лучше не забирать эту работу у ГД на свои плечи, а помочь ГД понять вопросами, что он хочет. Тогда вы вместе будете в плюсе - ГД начнет учиться правильно подавать информацию для вас, и вы научитесь ставить правильно вопросы так, чтобы все стало понятным.
Главное, чтобы вопросы не воспринимались, как угроза =)

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

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

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

Время интересных историй =)
Ко мне обратился человек и попросил помощи в обучении программированию. У него были какие-то навыки базовые написания кода на С++, поэтому я попросил его собрать простую игру-виселицу по моему ТЗ. Он ее собрал и добавил кучу своих плюшек. Тогда я попросил его удалить плюшки, чтобы игра соответствовала моему ТЗ. Он поворчал и пошел переделывать.
Через пару дней он вернулся ко мне с тем же самым, но теперь иначе. То есть, он удалил все свои хотелки старые и добавил новые. Но его игра не соответствовала ТЗ.
Я попытался объяснить ему, что сейчас код не важен, но он обиделся и заявил, что программирование - штука сложная, и ему лучше продолжить изучать что-то там свое.

Есть вторая история.
Когда-то там я приступил к работе над одним проектом. Сразу несколько геймдизайнеров уже работали над ним, и была куча документаций о том, как и что работает, но не было прописано то, как именно должен персонаж делать действие Х.
Я спрашивал геймдизайнеров и так, и сяк. Потом делал им всякие инструменты, чтобы они могли поиграться и сказать в итоге, как это действие должно работать. А время шло, а проект надо уже начинать собирать.
В итоге, как бы мне не хотелось, чтобы геймдизайнеры пришли к какому-то представлению о работе фичи, я взял эту часть на себя и подогнал свое решение. Оно не лучшее, но оно работает, и можно двигаться дальше.

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

- А может быть им не важно, если они будут не в таблицах писать тексты, а сразу в инструменте локализаторов?
- А может, им не важно, что потом с текстом будет?
- Может, им вовсе не нужны старые инструменты, и они готовы просто работать в редакторе?

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

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

Общайтесь. Спрашивайте. Уточняйте. И, самое главное, отвечайте на вопросы с улыбкой =) Помните, если вас спрашивают, значит, есть пятно непонимания.

Как всегда - работы много, а посты не получается сделать на 15 слов. Хочется перфекционизма и качественного контента =)
Поэтому слегка задержалси =)

И так. Следующий пост о том, сколько строк кода должен писать программист в день. Прочитать ее по традиции можно в телеграфе по ссылке:

https://telegra.ph/Skolko-strok-koda-ty-pishesh-10-22

Спасибо всем котяткам, кто не остался в стороне и пожелал задать свои вопросы =) Вопросы оказались очень интересными, и я хотел бы ответить разом на всех из них, но каждый вопрос - это огромная тема для поста.

Поэтому я буду шаг за шагом отвечать на ваши вопросы по мере сложности. Чем проще ответить, тем быстрее получите ответ =)

Начнем с вопроса Марии:

Грамотное распределение ответственных за части системы. Особенно когда изначальный автор фичи собирается уйти из компании или перевестись в соседний отдел.

Ответ читаем, как всегда, в телеграфе:

https://telegra.ph/Raspredelyat-dokumentirovat-i-svalit-10-23

И вот я добрался наконец-то до темы, от которой у некоторых бомбит =)
Маргарита задала великолепный, я считаю, вопрос:

Разница между джуном, мидлом и сеньером.

После этого поста большинство "сеньоров" и "лидов" меня очень сильно "полюбит" =)
Здесь я расскажу свое видение Д-М-С-Л-тД и немного расскажу о том, как определять, кто есть и на каком уровне.

Пост получится прям супер большой, и среднее время чтения у него около 20-30 минут. Поэтому запасайтесь терпением и временем =)
И снова идем в телеграф читать:

https://telegra.ph/Dzhun-ty-ili-lid-prekrasnyj-10-25

Пока сервера Arc Raiders упали, я решил выложить пост об еще одном пункте, который рассказываю всем прибывшим ко мне в команду =)

Читали ли вы книгу "Совершенный Код" Стива Макконнелл? Если да, то сколько раз вы ее уже перечитали? =)
Если нет, то пост о том, чтобы вы срочно бросили всё, разбили свои копилки и побежали покупать эту книгу.
Серьезна. Без шуток.

Эта книга не о том, как работает какая-нибудь библиотека, или что надо писать код только в таком-то подходе. Нет.
Эта книга так же не будет вас учить "быть сеньором и обманывать своих руководителей". Нет.
Эта книга написана программистом со стажем в 20 с большим лет, который собирал лучшие практики и подходы к программированию. Стив не просто выдает их в ней, а приводит статистику, которую собирали различные команды и компании, и показывает, что лучше работает в тех или иных ситуациях, на тех или иных проектах. Например, какие подходы нужно применять при разработке медицинских ПО, космического ПО или игр (а эт наша остановка, на минуточку =) ). Какие лучше использовать практики для оценки объемов работ.

Эта Книга прошла испытание огнем и водой, и на втором издании была очень сильно отредактирована, а потом протестирована временем на прочность и осталась Топ-1 для всех программистов. Особенно, если в вашей команде нет сеньоров.
Книга является лучшей, на мой взгляд, передачей опыта кодинга и управления проектами от сеньоров. Макконнелл собрал самые эффективные практики, описал то, как надо продумывать код, как надо продумывать системы, как надо подходить к решению задач и вообще быть программистом. Именно эта книга для меня стала библией программиста, которую я уже перечитал раза 3 и скоро буду перечитывать 4ый раз (и я не шучу).

Хотите знать как:
- Оценивать риски разработки?
- Подходить к решению задач?
- Делать правильно ревью кода?
- Создавать сложные системы?
- Контролировать разработку огромных приложений и минимизировать риски?
- Объяснять не программисту программистские штуки? (Да, этому посвящен целый раздел)
- Правильно организовать работу программистов?
- Работать в парном программировании?
И еще просто милльён важных тем, которые стоит прочитать всем программистам.

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

Стив Макконнелл "Совершенный Код". Читать, если вы хотите быть лучшими.

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

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

Если мне надо понять, как что-то работает - мне надо понять каждую строчку кода. Каждую буковку, каждый символ, каждый пробел. Я разбираю от начала и до конца весь функционал. Из-за этого у меня проблемы с разбором кода =)

Я просто не способен унести все знания и понимания, удерживая всё это в голове. Да и, мне кажется, на это не способен никто.

Я очень сильно люблю Miro (все, кто знает, что это, сейчас должны быстро связать 2+2), и я постоянно свои архитектурные решения раскидываю на досках. Логику, классы, структуры, и так далее. Это очень удобно, когда нужно размотать в голове кучу клубочков идей и выложить их в одно место.

В Miro можно видеть все разом и перемещаться между сущностями буквально в 1 клик и пару движений рукой. Даже этот пост написан в Miro.

И однажды, разбирая очередной код, я настолько устал мотать туда-сюда просто исполинскую функцию, что решил ее собрать в Miro в один большой картинку (тут нет опечатки).

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

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

Я не буду пытаться вам расписать сейчас словами, как это я делаю. Я думаю, что увидеть пример вживую лучше всего, поэтому вот вам ссылка на пример (нужна авторизация в Miro):
https://miro.com/welcomeonboard/RGszV2YvTlliWC9aZDdLWXRPMGVRcGdoTnQ1SFFiZ2ZRaWhWS1Btd1RONUlBbklzM1BCQndXY3ZJVUszYlZ0M21idjVqSnhSN1B0akpWOTFYd3BIa1dmVGdBRlk4TUNSUGNDZnNtelhjV2Z1QzgwbmJXOExadVNqTGJ2aWU5RjYhdjE=?share_link_id=650434945321
В этом примере я разбирал когда-то как Enhanced Input работает в Lyra. А для этого мне нужно было понять, как проект вообще запускается и в какой момент втыкает инпуты в подвязку к абилкам.

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

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

А. Еще есть ClickUp =)

Ну и поделитесь в комментариях, как вы разбираете код, и насколько вам удобно это делать вашим способом =)

Сегодня я хотел бы поговорить об эффектах =) Не визуальных и красивых, не о цветовой гамме IDE (хотя к ней тоже однажды придем) или эффектах восприятия.

Нет. Я хотел бы рассказать вам об эффектах в коде, которые никто не ждал =)
Го в телеграф, там много текста =)
https://telegra.ph/EHffekty-kotoryh-my-ne-ozhidali-12-07