Pull to refresh

Comments 34

Советы хороши, спасибо за перевод.
В свободное время я читаю исходники .NET, очень познавательно. Один из лучших способов понять и запомнить топ двадцать паттернов.

Кстати, другого способа понять, как делать архитектуру игр, я не нашёл. Игры на C# типа Transistor и Magicka мне сильно помогли.
Кстати, другого способа понять, как делать архитектуру игр, я не нашёл.

Другой способ есть и он очень даже элегантный — «Пишите код!».

Пишите код:
1. Начинайте решать какую-то задачу.
2. Напишите дополнение для своей задачи.
3. Приведите сложившуюся архитектуру в порядок.
4. Добавьте еще функционал, который ломает вашу стройную архитектуру.
5. goto 3.
Не могу сказать, что вы неправы, но все грабли стоит собирать самому, всё же :)
Для этого желательно иметь чувство перфекционизма (желательно здоровое), иначе будет «и так сойдёт».
Я бы добавил пункт 6. покажите свой код другим разработчикам. Желательно более опытным чем вы.

Я видел вполне себе неплохие по функционалу проекты с ужасной структурой и кодом внутри ибо никто не критиковал их код.
Transistor написана на C#? C открытыми исходниками?? Сейчас глянул — не вижу исходников в свободном доступе.

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

Прекрасный перевод. Полностью согласен с утверждением. Чужой код помогает расширить кругозор и научиться новым методам решений. Проверено на себе. Смог научиться программировать на С# и избавился от «детских» болячек программистов.
Я бы сказал так:
Один из простых способов улучшить или ухудшить свои навыки программирования — читать чужой код
Я бы даже сказал так:
Один из простых способов улучшить или ухудшить свои навыки программирования — читать чужой код или не читать.
UFO landed and left these words here
Один из простых или сложных способов улучшить или ухудшить свои навыки программирования — читать чужой код или не читать.
Скрытый текст
Народный лекарь Богомол сухими, как травинки, руками начал дотрагиваться до Буратино.

– Одно из двух, – прошелестел он, – или пациент жив, или он умер. Если он жив – он останется жив или он не останется жив. Если он мёртв – его можно оживить или нельзя оживить.

Золотой ключик, или приключения Буратино — Алексей Николаевич Толстой

Таки да. Код бывает разный. Можно такого legacy начитаться. Самое страшное — это когда из такого кода состоит любимый сторонний проект. Я часто обращаюсь к коду Tornado, и из-за поддержки совместимости он выглядит не так хорошо, как хотелось бы, и, скорее, запутает страждущего.

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

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

Я подписан на core-libs-dev в OpenJDK. Хотя у меня нет формальных полномочий выступать ревьювером кода, это не мешает смотреть интересные мне запросы на ревью (а иногда даже находить косяки и сообщать о них авторам). Тут было бы желание, а возможность всегда найдётся.

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

Очень хорошо, что догадались расширить этот принцип и на программирование. По смыслу получается то же самое.

Очень полезная методика.
Один из способов улучшить свои навыки — читать хороший чужой код.
Беда только в том, что для того, что бы отличить хороший код от плохого — нужно самому уметь что-то делать.
Правда — можно спросить — где посмотреть хороший код.
На самом деле не так сложно.
Хороший код прост и понятен. Плохой код — нет.
Соответственно, чем меньше времени уходит на понимание написанного — тем лучше код. (понятно, что это не какой-то фундаментальный закон, а просто наблюдение, из которого можно привести миллион исключений, но всё же)
Понятность кода — необходимое, но не достаточное условие хорошего кода.
Может быть очень понятный код, который делает совершенно не то, что нужно.
Особенно в каких-то граничных случаях.
Не примите за менторство, просто мысли вслух.

А по теме, хороший код — исходники Doom.
UFO landed and left these words here

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


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

Я и свой-то не читаю, прости госсподи.


Значит, вы работаете в одиночку над совсем небольшими проектами.
Да.
Только вот проблема, если ты полный ноль, то чей код считать достойным изучения.
Может, это будет код такого же новичка или просто плохого программиста.
Идеально вместе с кодом читать теорию — Макконнелла, Фаулера и т.п.
Тогда можно будет находить подтверждения теоретическим знаниям — тут такой паттерн, а это разбили на классы для уменьшения связности, а тут, наоборот, плохое место, — не удовлетворяет SOLID.
Ну я допустим программист с охренительным стажем.
Мне эти все паттерны — будет просто скучно.

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

Но, конечно, проще, чем начинающему.
Читайте разные проекты на новом языке. Если что-то всегда реализуется одинаково, значит это стандарт для языка. А там, где есть различия — повод самому подумать, как правильно.
Читайте разные проекты на новом языке. Если что-то всегда реализуется одинаково, значит это стандарт для языка. А там, где есть различия — повод самому подумать, как правильно.


Не думаю.
Все люди в среднем (большинством своим) — не выдающиеся люди, обычные, ленивые, неумные и пр.

А читать то чтобы учиться нужно лучший код, хотя бы чтоб чуток выше среднего.

В этом и проблема — как такой код вычленить.

Для любителей JavaScript советую прочитать коды Node.js модулей в Github. "Тонны" модулей создаются и обновляются ежедневно.

Я бы такое даже врагу не пожелал (-:
Only those users with full accounts are able to leave comments. Log in, please.