Почему программисты не любят работать с чужим кодом

Почему программисты не любят работать с чужим кодом

Есть причина, по которой программисты всегда хотят выкинуть старый код и написать новый: они думают что старый код — плохой. Возможно они неправы. Причина, по которой они думают что старый код — плохой, из-за кардинального, фундаментального закона программирования: тяжелее читать код, чем его писать.
Джоэль Спольски.

http://lurkmore.to/Фатальный_недостаток
А Джоэлю надо было просто вступление, чтобы перейти к теме.
Эти люди не знают что такое рефакторинг
Переписывать код заново — антипаттерн. Там скрыто куча информации, его нужно только рефакторить.

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

Еще раз, старый код не нужно выкидывать, его нужно рефакторить.

(0) Ну. Сказал этот чувак это. И чьто? Чьто-чьто. Да ничьто! (с) фильм «Ликвидация».

_Свои_ мысли как-то надо выражать. Если есть, конечно. Чья-то цитата — не Ваша мысль и не аргумент и тем более не аксиома.

Работает — не трогай.
(5) >> новый код всегда должен быть лучше чем старый
Озвучьте критерии этого «лучше».

(0) Здесь важна не только парадигма «старый» – «новый», но и «свой» – «чужой». Однако если чужой код хорошо работает, то зачем его менять? Даже если в нем трудно разобраться. В этом случае просто больше стимула разбираться. Но вот если код работает плохо, то уже не важно, чей он, свой или чужой. Действительно иногда легче переписать даже свой код, чем рефакторить его. Чего уж там говорить про чужой.

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

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

(9) > Озвучьте критерии этого «лучше».

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

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

И для этого её надо переписать на ассемблере с разворотом циклов и прочими прыжками.
Как думаешь. Код. Улучшится?

(0) Не нужно г..внокодить.

Я свой код не переписываю, даже 10 летней давности.
Открываю, он написан по стандартам 1с (похож на код из типовых). Легко читаем, есть коменты. Зачем переписывать?

Хохлы учат русских как писать чистый код. Лекция. Осторожно, укросми

(0) Все подряд переписывать не нужно. А вот кривые и неоптимальные куски кода — нужно. «Кайдзен в бизнесе» должен плавно переходить в «Кайдзен в разработке ПО».

Для тех, кто не в курсе: Кайдзен — это процесс непрерывного усовершенствования.

Свои коды трогать не надо. А вот чужие, кои присутствуют в модулях, надо править, при этом очень ругаться и эту ругань доносить до руководства.
А также постить на мисте.

(0) Не всегда хотят выкинуть старый код.
Вот мне хочется всегда выкинуть говно код, реализованный по принципу «А копирну я одно и тоже раз 200, так же быстро» 🙂

(11) > И для этого её надо переписать на ассемблере с разворотом циклов и прочими прыжками.
Как думаешь. Код. Улучшится?

Чтобы улучшить работу, скажем, учетной программы, совсем необязательно переписывать ее на ассемблере. Хотя бы потому, что с этой задачей можно не справиться физически. Тем не менее, в свое время целые игры писали на голом ассемблере, а у нас в университете учился сириец, который даже собственную операционную систему наваял на ассемблере (что-то типа примитивного ДОСа).

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

+ А потом ковыряешь все 200 процедур и запросов, что бы все это не расплылось в итоге, тратя на это кучу времени 🙂

(0) Как вариант, бывают ситуации когда руководство просит отчеты по отработанному времени и тогда программист разбор такого кода аргументирует как «Переписать код старого программиста».

(15) Такой код как раз и шифруют и пароли ставят 🙂

(0) Все просто — предыдущий программист не оставил документации, либо требования к ПО поменялись, и старый код не удовлетворяет новым запросам.
(12) ЛПиП. Код типовых — не пример для подражания, и второе — за 10 лет изменился достаточно сильно.

(17) + Еще очень важное значение имеет структура данных. Это вообще отдельная песня. Можно быть сколь угодно прекрасным кодировщиком, но легко делать структурные ошибки в данных. Которые как бы и не ошибки, но жизнь пользователей и даже обслуживающих программистов усложняют.

. Часто и свой код легче переписать заново!
А, вообще, зависит от поставленной задачи. Если функционал добавить, иногда лучше старый. А если ошибку найти, то иногда лучше переписать..

(0)Это не всегда оправдано, но всегда полезно. Потому что в процессе написания своего кода после того как наступишь на все грабли и споткнешься обо все подводные камни- ты будешь в теме на все 100% и точно знать как вся эта кухня работает.

«код» в 1с — это слишком громко сказано

(0) Мысль правильная, но изложение.
Человек растет и совершенствуется. Поэтому нередко код, который написан вчера, сегодня уже был бы написан по-другому.
Хорошие программисты рано или поздно приходят к тому, что перестают переписывать. Потому что практически нет нареканий.
(25) Сдавайся :)))))

(15) Ну, когда изменение пары строчек в чужом запросе ускоряет его работу на 2-3 порядка, и таких запросов десятки — сдержаться тяжело.

(0) Во фразе «Есть причина, по которой программисты всегда хотят выкинуть старый код» допущена гипербола. Слово «всегда» — лишнее. Да и вообще, это «не та» цитата Джоэла, которую стоило бы озвучивать на форуме программистов 1С, где платформы и конфигурации меняются как перчатки шесть раз на дню.

PS: и не «Джоэль», а «Джоэл» — пишется не так, как произносится.

(5) ERP хуже УПП. Там даже нормальных отборов нет. Вывод — в 1С ненормальные программисты 🙂
(29) «Вывод — в 1С ненормальные программисты »
Открыл Австралию.
(10) Обычно каждая новая версия программы тормознее и глючнее 🙂

(17) Гибкость и дружелюбность — обычно несовместимы. Чем гибче программа — тем адовее она для пользователей.

Окостылил говнокод?
Ляг, поспи и все пройдет.
Встал, покодил, все равно
Получается говно.

Как не патчил много лет,
Как не фиксил баги,
Все-равно велосипед
На костыльной тяге.

Что б совсем без костылей,
Великов и багов
Нанимайте, говорю,
Нанимайте магов!

(25) Во-во, нет кода кроме машинного.
(30) Не, я просто обосновал эмпирический выводы 🙂

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

каждый раз когда возникает желание переписать чужой код, задайте себе вопрос «а кто за это заплатит?» и желание сразу отпадет

(39) если на окладе, то все оплачено уже

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

(32) > Гибкость и дружелюбность — обычно несовместимы. Чем гибче программа — тем адовее она для пользователей.

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

Возьмем, скажем, дополнительные настройки. Не обязательно, чтобы они мозолили глаза пользователю, главное, чтобы они были. Например, в «семерке» нет возможности штатно установить точные размеры формы, только «на глаз». Нет возможности задать центровку всех окон – они обязательно должны скакать по монитору, потому что такой стандарт придумал де Билл (который Гейтс). Настройки эти пользователю не дали, типа упростили ему жизнь, поэтому народ изголяется, как может, придумал FormEx, 1C++ и т.п. Вплоть до того, что декомпилирует md-файлы и правит там формы вручную.

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

В идеале, допустим, «зарплата» созданная под российское законодательство должна быть теоретически способна быть перенастроенной под законодательство другой страны, например, ЛНР / ДНР или даже какой-нибудь Белоруссии с Казахстаном. Вот это я понимаю – гибкость. А так нынешний ЗУП это идеальный образец жёсткости.

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

История №936401

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

Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученым, но через 5 минут они выбегают с криком: «УТЕЧКА ЯДОВИТОГО ГАЗА. «.
— Как так–то, блять! Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что–то в проекте менял?
— Немного, швабры вынес.
— Швабры потолок держали!
— Что. Что, блять, извините.
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его, блять, демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и уебывайте!

Проголосовало за – 1520, против – 117

Статистика голосований по странам

Как читать чужой код: 6 правил, которые стоит помнить разработчику

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

Вы читаете обновленную и улучшенную версию нашей старой статьи

Почему разработчики не любят разбираться в чужом коде

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

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

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

Как правильно читать код

Научитесь проводить «раскопки» в коде

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

Если вы работаете над кодовой базой, в которой разработчики использовали контроль версий, то у вас есть доступ к метаданным. Изучите следующие команды для Git, чтобы узнать, как изменялся код (они подойдут и для SVN):

git blame

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

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

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

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

git log и git grep

Используйте команду git log , чтобы увидеть историю коммитов по всему репозиторию. Команда git grep поможет вам найти в коммитах конкретный текст, например, название функции someFunction: git log | grep someFunction -C 3 . Последние флаги покажут вам найденные выражения с тремя строками окружающего контекста.

Также git log может показать вам историю отдельного файла. Чтобы ее посмотреть, используйте флаг -p: git log -p index.js . Обращайте внимание на имена авторов коммитов, чтобы знать, кому в будущем адресовать вопросы.

Переключайтесь между коммитами и изучайте историю кода

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

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

Читайте спецификации

Specs или спецификации — это новые комментарии к коду. Читайте unit specs, чтобы выяснить предназначение функций, модулей и возможные пограничные случаи (edge-cases), которые они обрабатывают.

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

Воспринимайте комментарии как подсказки

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

Обращайте внимание на стиль написания кода

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

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

Работая над проектом, посмотрите, какие конструкции используют разработчики из вашей команды. Если они отдают предпочтение циклам, а не функции map , то и вам следует их использовать. Если вам не нравится стиль оформления кода в проекте, обсудите это с командой — это лучше, чем смешивать разные стили в одном файле. Хороший код выглядит так, будто он написан одним человеком.

Избавляйтесь от «мусора» в коде

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

Итог

Не падайте духом, если чувствуете, что вы совсем запутались в чужом коде. Изучение кода — это не линейный процесс. Не ждите, что сразу поймете все на 100%. Обращайте внимание на важные детали, проводите «раскопки», чтобы найти ответы на вопросы, и, надеемся, все станет понятнее.

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

Чужой код ⁠ ⁠

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

Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: «УТЕЧКА ЯДОВИТОГО ГАЗА. «.

— Как так-то, блять! Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:

— Вася, у нас ядовитый газ потёк! В чем проблема?

— Не знаю, должно было все работать. Что-то в проекте менял?

— Немного, швабры вынес.

— Швабры потолок держали!

— Что. Что, блять, извините.

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

— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?

— Включай вентилятор. Он сдует газ с острова.

— Я его, блять, демонтировал сразу же!

— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?

— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.

— Вася, я убрал твой вентилятор! Мы тут задыхаемся!

— Херли вы тогда там делаете? Садитесь на воздушный шар и уебывайте!

5 лет назад

Всё так кроме одного. Прошлому разработчику дозвониться невозможно.

раскрыть ветку
5 лет назад

Я не программист, но мне кажется, что работа со своим кодом через год после его написания будет выглядеть примерно так же

раскрыть ветку
5 лет назад

раскрыть ветку
5 лет назад

Мда. Как сисадмин, не могу не согласиться. В ту же степь — «у нас тут надо срочно добавить на сервер еще функционала». Только серверу уже несколько лет, и любые попытки его тронуть на предмет обновления всегда сопровождались воплем вебмастеров «не трогай, умрет!», потому что он весь облеплен их костылями. А тут надо же, «ну нам же очень надо, сделай как-нибудь».

В итоге проще сделать рядом еще один сервер, свежий и со всем что нужно, и приказать этому стаду долбоебов мигрироваться. ИЧСХ, в 99% случаев, конечно же, окажется что-то, что при попытке переложить его на новую платформу издохнет в корчах, потому что несовместимо с новой платформой.

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

раскрыть ветку
5 лет назад

Похожие посты
1 день назад

Настроение программиста⁠ ⁠

Показать полностью 1
3 дня назад

А логические ошибки разработчик должен видеть сам!⁠ ⁠

4 дня назад

Работает же!⁠ ⁠

4 дня назад

Ответ на пост «Собеседование в IT»⁠ ⁠

Дело было давно. Устроился в крупную IT-компанию, в один из отделов, занимающийся разработкой своей АРМ-системой. Разработка велась уже более 10 лет и к моменту моего начала уже отсутствовали те, кто всё это затеял. Выделили комп, стол, а под ним тумбочка. В ней оставалось какое-то барахло, сказали выбросить. Разобрав тумбочку я обнаружил книжку с основной документацией на систему для разработчиков. Я довольно быстро освоился и через какое-то время с простых задач перешёл к сложным.

И вот спустя несколько месяцев, обсуждаем одну разработку. Я высказался: ну тут всё просто — в ядре есть поддержка этого и этого, по сути нужно только вызвать функцию *** из модуля ***, помню, это было в документации.

В этот момент я заметил удивлённые лица ведущих программистов: «В какой ещё документации?»

Я достал книжку и показал им, они удивлённо отстали её, видя впервые. Некоторые сотрудники работали в отделе более 5 лет и не знали о существовании таковой, другие же припоминали что-то, но считали что всё давно утеряно. А я думал, что такая книжка есть у каждого или в электронном виде где-то.

6 дней назад

Дикая природа IT удивительна⁠ ⁠

Взято из телеграмма — Инкогнито

Показать полностью 1
Поддержать
9 дней назад

Абидна⁠ ⁠

1 месяц назад

Новый уровень редактирования изображений⁠ ⁠

DragDiffusion изменит изображение, согласно вашим манипуляциям. Нужно лишь сместить ключевую точку на фото.

Нейросеть может переместить любые объекты, изменить их размер и вид.

Показать полностью
Поддержать
1 месяц назад

Инициатива наказывает инициатора⁠ ⁠

Показать полностью 1
3 месяца назад

Первые попытки освоить движок Godot — делаем простой платформер⁠ ⁠

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

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

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

Тут наша сцена и связанные с ней узлы.

Создаем карту

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

Все мы иногда статичное тело.

Правой кнопкой мыши жмякаем на нашу 2D сцену «World» и выбираем «Добавить дочерний узел». В списке ищем «StaticBody2d» и теперь у нас есть база. Добавляем два дочерних узла уже в статичный объект — «Polygon2D» и «CollisionPolygon2D».

Для тех кто не понимает на басурманском — объясню, что есть что. Первый — это визуальная геометрическая фигура, а второй — область столкновения (collision — столкновение). Все это нужно для того, чтобы мы могли увидеть наш объект, а игрок не проваливался внутрь него при столкновении.

Рисуем будущую карту при помощи CollisionPolygon2D.

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

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

Теперь нам нужно сделать так, чтобы визуальная фигура повторяла форму области столкновения. Нажимаем на нашу сцену и добавляем к ней скрипт. GD-script во многом схож с языком Python и более-менее прост в понимании. Сначала добавим наши узлы в виде переменных, для этого зажимаем «ctrl» и перетаскиваем в код после блока extends.

Прописываем функцию ready, она будет воспроизводится сразу во время запуска сцены. А дальше просто приравниваем форму фигуры к форме области столкновения (polygon_2d.polygon = collision_polygon_2d.polygon).

Получаем дешевую и сердитую карту — все в гоблинском стиле!

Карта готова, но что делать теперь? Пора добавить нашего персонажа-марионетку.

Создаем новую сцену и для ее основы берем узел CharacterBody2D. Для будущей простоты восприятия я переименовал его в Player. Чтобы увидеть нашу тушку — добавим к ней дочерний узел «Sprite2D», а чтобы можно было еще и потрогать «CollisionShape2D».

Выделяем область столкновения.

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

Тело готово, пора научить его шевелиться и реагировать на физику. Для этого мы создаем для нашего Player свой скрипт.

Наши переменные.

Задаем переменные через const (constants — постоянное значение). Значения констант не могут быть изменены в ходе самой программы, на то они и постоянные. Для чего нужны эти значения расскажу ниже.

const SPEED = 150.0

const JUMP_VELOCITY = -300.0

const FRICTION = 1000.0

const ACCELERATION = 600.0

На этот раз мы берем не функцию ready, а другую — physics_process. В отличии от простого process, здесь время между выполнением функции будет одинаковым. Это обеспечит нам стабильность при передвижении объектов.

Начнем с настройки гравитации!

Дело в том, что система координат X-Y в Godot имеет свои приколы. Ось X идет от отрицательной к положительной слева направо, однако ось Y идет от отрицательной к положительной сверху вниз. То есть ось Y буквально перевернута с ног на голову. Если непонятно — объясню проще:

Хотим передвинуть вправо — прибавляем к оси X;

Хотим передвинуть влево — вычитаем из оси X;

Хотим передвинуть вниз — прибавляем к оси Y;

Хотим передвинуть вверх — вычитаем из оси Y;

Гравитация. беспощадная ты с*ка!

Как же нам заставить персонажа падать под давлением гравитации? Для начала добавим переменную GRAVITY равную 1000. Затем создаем свою пользовательскую функцию и называем ее aplay_gravity.

Мы должны падать когда находимся в воздухе, то есть не на полу. Буквально говорим программе «Если объект не на полу сделай следующее: измени положение по оси Y в положительную сторону на заданное нами расстояние».

if not is_on_floor():

velocity.y += GRAVITY * delta

Что такое delta? Это время между кадрами, благодаря чему перемещение будет стабильным вне зависимости от FPS.

velocity — это параметр скорости изначально зашитый в наш объект. По этой причине его так же не требуется объявлять как переменную. Грубо говоря сюда мы задаем то расстояние, на которое должен переместиться объект по осям X и Y.

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

Отлично, нас прижало как после «Балтики 9»!

Теперь настраиваем прыжки!

Для этого создаем еще одну пользовательскую функцию handle_jump. Мы говорим ей: «Если мы нажимаем кнопку прыжка и находимся на полу — измени положение по оси Y в отрицательную сторону». Напомню, что константа прыжка имеет отрицательное значение.

if Input.is_action_just_pressed(«ui_accept») and is_on_floor():

К гравитации добавляются прыжки.

Прыжок веры.

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

Надеюсь вы еще не забыли, что направление у нас зависит от отрицательного или положительного значения? Есть такая штука в Input как get_axis, где мы задаем две клавиши. Нажатие первой клавиши прировняет переменную к значению -1, нажатие второй клавиши наоборот к 1. Если ни одна из клавиш не нажата, переменная принимает значение 0.

Создаем переменную input_axis внутри physics_process, на этот раз через var, ведь она будет менять свои значения в процессе. А далее задаем машине установку «Если нажата одна из двух клавиш, то мы меняем значение по оси X в зависимости от выбранного направления».

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

Начальная точка — velocity.x

Конечная точка — наша скорость SPEED помноженная на направление (-1 или 1)

Промежутки — наше ускорение ACCELERATION помноженное на время между кадрами delta

if input_axis !=0 :
velocity.x = move_toward(velocity.x, SPEED * input_axis, ACCELERATION * delta)

Вот наш код.

А вот признаки жизни. беги Форест — БЕГИ!

Двигаться мы можем, а вот с остановкой проблема. Что не дает нам вечно кататься по земле? СИЛА ТРЕНИЯ!

Для того чтобы создать силу трения мы делаем похожую функцию. Только теперь конечной точкой у нас выступает 0, а вместо ACCELERATION берем параметр FRICTION. Включается все когда мы не нажимаем кнопки движения, то есть input_axis равен нулю.

if input_axis == 0 :

velocity.x = move_toward(velocity.x, 0, FRICTION * delta)

Бегаю, никого не трогаю. к земле притягиваюсь во время прыжка.

Вишенкой на торте внутри физической функции является move_and_slide которая и отвечает за все эти процессы. Без нее указанные выше шаманские обряды просто не запустятся.

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

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

Если вам интересно и дальше смотреть на то как я собираю лбом грабли, а может и самим чему-то научиться вместе со мной — подписывайтесь на данный блог!

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

Традиционный тематический гоблин в конце!

Показать полностью 18
3 месяца назад

Мой пет-проект: самообучающаяся нейросеть, играющая в змейку на C#⁠ ⁠

Всем привет! Попробую разбавить волны авторским контентом.

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

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

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

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

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

Кому интересно посмотреть или пощупать мой говнокод — милости прошу на гитхаб: https://github.com/tyzegt/NeuralNetworkLib/tree/snake-geneti.

Ниже несколько гифок, иллюстрирующих прогресс обучения: