Комментарии 34
В свободное время я читаю исходники .NET, очень познавательно. Один из лучших способов понять и запомнить топ двадцать паттернов.
Кстати, другого способа понять, как делать архитектуру игр, я не нашёл. Игры на C# типа Transistor и Magicka мне сильно помогли.
Кстати, другого способа понять, как делать архитектуру игр, я не нашёл.
Другой способ есть и он очень даже элегантный — «Пишите код!».
Пишите код:
1. Начинайте решать какую-то задачу.
2. Напишите дополнение для своей задачи.
3. Приведите сложившуюся архитектуру в порядок.
4. Добавьте еще функционал, который ломает вашу стройную архитектуру.
5. goto 3.
Я видел вполне себе неплохие по функционалу проекты с ужасной структурой и кодом внутри ибо никто не критиковал их код.
А можно поинтересоваться ссылочками на код, который вы читаете? Я тоже очень хочу, но утонул в тонне нечитаемых малопонятных модулей на гитхабе. Хочется взять проект и читать его вместо недельного изучения подводных камней устройства системы сборки.
Один из простых способов улучшить или ухудшить свои навыки программирования — читать чужой код
Один из простых способов улучшить или ухудшить свои навыки программирования — читать чужой код или не читать.
Народный лекарь Богомол сухими, как травинки, руками начал дотрагиваться до Буратино.
– Одно из двух, – прошелестел он, – или пациент жив, или он умер. Если он жив – он останется жив или он не останется жив. Если он мёртв – его можно оживить или нельзя оживить.
Золотой ключик, или приключения Буратино — Алексей Николаевич Толстой
Таки да. Код бывает разный. Можно такого legacy начитаться. Самое страшное — это когда из такого кода состоит любимый сторонний проект. Я часто обращаюсь к коду Tornado, и из-за поддержки совместимости он выглядит не так хорошо, как хотелось бы, и, скорее, запутает страждущего.
все мысли по отдельности вроде как знакомы, но тут собраны в хороший цепляющий мотив,
который направляет мышление в конструктивное русло (вместо топтания в рутине или прокр… нации)
Ну делать ревью, это все же не апрувить реквесты, потому вполне доступно даже тем, у кого опыта пока мало, то есть новичкам.
По крайней мере я не представляю как можно давать задачи новичкам, но при этом не допускать их к уже написанному кем-то коду (пусть допуск будет и в ограниченном количестве)
Я подписан на core-libs-dev в OpenJDK. Хотя у меня нет формальных полномочий выступать ревьювером кода, это не мешает смотреть интересные мне запросы на ревью (а иногда даже находить косяки и сообщать о них авторам). Тут было бы желание, а возможность всегда найдётся.
Очень хорошо, что догадались расширить этот принцип и на программирование. По смыслу получается то же самое.
Очень полезная методика.
Беда только в том, что для того, что бы отличить хороший код от плохого — нужно самому уметь что-то делать.
Правда — можно спросить — где посмотреть хороший код.
Хороший код прост и понятен. Плохой код — нет.
Соответственно, чем меньше времени уходит на понимание написанного — тем лучше код. (понятно, что это не какой-то фундаментальный закон, а просто наблюдение, из которого можно привести миллион исключений, но всё же)
Добавлю, что исключительно полезным источником знаний о структуре проекта является история системы контроля версий (если она доступна). К примеру, видите вы некоторую функцию. Где она используется явно, где неявно, надо ли её зарегистрировать в каких-нибудь конфигах, где хранятся связанные с ней ресурсы, где хранятся тесты для неё? Ответы на многие из этих вопросов можно узнать, просто найдя коммит, в котором она появилась, и посмотрев, какие ещё файлы были изменены в том же коммите. Это не всегда работает, но мне часто помогает быстро сориентироваться в структуре.
История отвечает и на много других вопросов. Кажется, что что-то сделано странно и нелогично? Ищем коммит, где это появилось. И видим, что в предыдущей версии было всё логично, но в этом же коммите появился тест, который с предыдущим кодом падал. Вот и ответ, зачем потребовалась странность.
Только вот проблема, если ты полный ноль, то чей код считать достойным изучения.
Может, это будет код такого же новичка или просто плохого программиста.
Тогда можно будет находить подтверждения теоретическим знаниям — тут такой паттерн, а это разбили на классы для уменьшения связности, а тут, наоборот, плохое место, — не удовлетворяет SOLID.
Мне эти все паттерны — будет просто скучно.
Я приступаю к новому языку программирования.
Даже мне — что именно взять в качестве эталона для изучения, что именно принято в новом для меня языке, какой стандарт форматирования, какие приемчики для реализации тех или иных вещей — это будет отдельной проблемой.
Но, конечно, проще, чем начинающему.
Читайте разные проекты на новом языке. Если что-то всегда реализуется одинаково, значит это стандарт для языка. А там, где есть различия — повод самому подумать, как правильно.
Не думаю.
Все люди в среднем (большинством своим) — не выдающиеся люди, обычные, ленивые, неумные и пр.
А читать то чтобы учиться нужно лучший код, хотя бы чтоб чуток выше среднего.
В этом и проблема — как такой код вычленить.
Для любителей JavaScript советую прочитать коды Node.js модулей в Github. "Тонны" модулей создаются и обновляются ежедневно.
Один из простых способов улучшить свои навыки программирования — читать чужой код