Комментарии 29
Хм. Вот нахрена советовать всем читать банду четырех? Во-первых, эта книга для определенного уровня, начинающим ее читать просто вредно — пользы не принесет, и потом, это скорее (в какой-то мере) справочник, а не учебник.
Во-вторых, объектно-ориентированное проектирование, в таком виде как оно там подается, уже достаточно много лет активно видоизменяется, ярким примером чему стало появление лямбд в Java, в итоге значительная часть описанных паттернов из этой книги стала просто тривиальной конструкцией языка (а в языках типа лиспа или хаскеля — и всегда была такой).
Ну или Керниган и Ритчи? Серьезно? Не, я не против, классическая книга, и язык, многое определивший в развитии индустрии. Но если вы сегодня, в 2017 не можете назвать более полезную сегодня книгу (а не исторический артефакт, по-хорошему любопытный только ради истории) — это грустно.
Я бы не взялся советовать книги на любой случай. Это зависит от направления, в каком вы хотите развиваться. Есть люди, которые вполне себе живут, программируя под платформы типа MS SQL Server или Oracle, базы данных и все что вокруг них. И зачем им язык C, кроме как ради знания истории?
Если без конкретных названий и авторов — то примерно так, не ограничиваться например ООП, и только паттернами проектирования, чтобы не сужать свой кругозор, а почитать что-то про другие парадигмы, функциональное программирование, например, чтобы представлять, что бывают и совсем другие языки, лисп например, или хаскель. Даже если вы не будете на них работать реально — это даст вам представление, что тоже самое можно делать и иначе, и возможность выбора того способа, который вам и для задачи более удобен.
А уж книгу про язык C начинать читать если вы реально собрались в этом направлении развиваться — скажем, писать что-то в области embedded.
Вот насчет Таненбаума я скорее соглашусь, хотя сам читал как раз другую его книгу, про ОС, и давно уже, лет 30 тому назад.
И вот с этим советом можно только согласиться, хотя следовать ему сложно — пока не прочел, откуда знать, что там внутри:
Но мой вам совет: выбирайте книги, которые дадут в первую очередь понимание, а не просто поверхностную информацию.
И еще — я бы посоветовал почитать что-то из другой области. Ну хотя бы Том ДеМарко, Тимоти Листер — есть несколько их книг по управлению проектами, их стоит почитать разработчикам тоже, потому что они дают понимание, как развивается проект в целом, как управлять рисками, как работать в команде. Ну и потом, они просто прикольные )))
полностью согласен по поводу GoF, к тому же как я помню там еще и терминология несколько странная применяется. Куда более полезна для новичков в этом плане на мой взгляд книга O'Reily.
Я не знаю, про какую вы конкретно, но да — суть в том, что про паттерны с тех пор написали много чего, под разные языки реализации, скажем под .Net или Java. И это было бы практически полезнее, GoF еще и очень абстрактная книженция.
Вот, чтоб было понятнее, почему я против чтения GoF в чистом виде, начинающими: цикл статей Марио Фуско на общую тему, как трансформировались некоторые паттерны с появлением в Java 8 лябмд: https://www.voxxed.com/blog/2016/04/gang-four-patterns-functional-light-part-1/.
Отсюда прекрасно видно, что некоторые изменения языка (или переход на другой язык) приводят к тому, что описанные классические паттерны становятся зачастую просто тривиальными, когда у вас есть функции как первокласные сущности языка, функции высших порядков, и некоторые другие вещи.
И в общем-то, если посмотреть в сторону лиспа, или даже javascript, можно увидеть, что тот или иной паттерн — всего лишь функция, возвращающая другую функцию, к примеру. А если вы под .Net пишете, то в современном c# тоже многие вещи проще делаются, нежели описано в классической книге про паттерны.
Я это к чему — книга GoF вообще пожалуй нужна на сегодня только тем, кто привязан к конкретному, причем скорее всего не самому современному ООП языку. В ФП парадигме есть свои паттерны, хотя их там так обычно не называют, и по ним есть другая неплохая литература. Ну хотя бы недавно упомянутый этот перевод.
Чтобы менеджмент на голову не садился
- The Clean Coder by Robert Cecil Martin
Чтобы научиться писать декларативный и подерживаемый код
- Elegant Objects by Yegor Bugayenko
Для коллаборации команды и разруливания говнокода в монолитных проектах
- Domain-driven design by Eric J. Evans
Чтобы иметь представление как организовывать высоконагруженные проекты и предоставлять клиентам
- Building Microservices by Sam Newman
Тут можно ещё добавить про SCRUM и TDD, остальное практика
Также очень подтягивает изучение другой парадигмы, углубление в алгоритмы и куда же без Математики :)
Scrum и tdd вовсе не обязательно нужно всем. К сожалению, все подобные попытки написать список из пяти (десяти, ста) лучших книг, которые нужно прочесть всем, всегда сводятся в конечном счете к этому.
Что включать, а что нет. Например, нужно ли разработчику непременно уметь работать с VCS? И если да, то с какой-то конкретной (например Git), или вообще? И вроде бы хорошо уметь вообще, а много можно назвать книг, которые бы хорошо рассказывали про версионирование кода в общем, без привязки к Git, SVN или чему-то еще?
Elegant Objects by Yegor Bugayenko
это ведь тот Егор, о котором я думаю?
Почти генератор флейма.
не я понимаю книга вроде популярна о нем много пишут. Вот только почему???
Пять книг по программированию, которые стоит прочесть