Comments 85
Грокаем алгоритмы (Адитья Бхаргава)
второе издание, в первом есть ошибки, когда не понимаешь в начале, что это ошибки это сложно изучать
и даже получить сертификаты о его прохождении онлайн.
А вы сами проходили этот курс? Для получение сертификата за CS50 нужно отправить им видео презентацию на английском о себе и своём итоговом проекте. Но курс и правда отличный, рассчитан на самостоятельную работу.
Высоко-нагруженные приложения (Мартин Клеппман)
В youtube есть разборы этой книги по главам
Делай как в Google (Титус Винтерс, Том Маншрек, Хайрам Райт)
А вы сами её читали? Что полезного применяете из книги?)
В книге много воды
любую тему, по моему, лучше со статей и видео начинать изучать.
увидеть ваш минимум книг
"Проект 'Феникс'" и "Прикладные структуры данных и алгоритмы" Джей Венгроу - очень хорошая книга
Абсолютно верный коментарий. Полностью согласен относительно книги Делай как в Google (Титус Винтерс, Том Маншрек, Хайрам Райт) особенно в контексте того, что сейчас происходит в индустрии и в Google в частности.
А вы сами проходили этот курс?
Начал, но не закончил. Мне больше понравилось смотреть на Youtube - довольно большой кусок посмотрел (самое интересное на мой взгляд).
Делай как в Google. А вы сами её читали? Что полезного применяете из книги?)
Да, хорошая книга. Иначе бы не стал рекомендовать.Там вообще много всего, как нанимать, как быть лидером, как измерять продуктивность инженеров. Я скорее жалею, что многие эту книгу не читали.
любую тему, по моему, лучше со статей и видео начинать изучать.
Я раньше много читал, сейчас читаю довольно редко, чаще статьи читаю, но всё ещё считаю, что толково составленные книги помогают расширить кругозор. Разборы конечно хорошо, но не всегда разборщик может передать правильно, что хотел сказать автор - каждый замечает и передаёт то, что считает важным сам. Так что видение разборщика может отличаться от видения автора.
"Проект 'Феникс'" и "Прикладные структуры данных и алгоритмы" Джей Венгроу - очень хорошая книга
Супер. Спасибо за рекомендации!
В youtube есть разборы этой книги по главам
Киньте плиз URL ?
уже опередили )
отличная подпорка, но имхо Agile лишняя, это не про разработку, есть более достойные издания.
.
Я бы добавил сюда "Чистую архитектуру" Дядюшки Боба - книга легко читается и дает понимание того, откуда и зачем появились современные принципы.
На счет паттернов, я бы предпочел не общую книгу, а книгу, которая содержит примеры на языке, на котором я пишу. Читал паттерны ООП банды 4-х, которую никто не обновлял с 1993 или 1995 года, и читать примеры на c++ или smalltalk (если вы знаете вообще о таком) сущее наказание и вынос мозга.
"Кабанчик" вряд ли будет сильно нужен джуну, который пока не умеет программировать, как будто эта книга больше для уровня миддл и выше, когда начинается этап проектирования.
И тем не менее, книжка от банды 4 - очень познавательная.
Да, она познавательная, но есть один нюанс. Разбирать примеры на C++ сложно, так как язык не самый популярный и какие-нибудь Java/C#/JS подошли бы лучше. А если вы разработчик на Python, то разобрать код еще сложнее.
Также книга написана довольно муторно, можно было ее переписать в более попсовом формате, чтобы легче было читать. В целом, если книга не обновляется в течении 25-30 лет, это не очень хорошо. Можно было даже выпустить несколько разных вариантов с примерами под разные языки, Java Edition или Python Edition.
Всё ещё нюанснее: если вы пишете на Питоне или ещё чём-то современном, то половина шаблонов от банды 4 вырождаются в тривиальный однострочник или вообще не применимы, и это трудно читать и непонятно зачем на это обращать внимание, и можно нахвататься плохих практик если возможности своего языка знаешь не полностью.
Соглашусь, что куча паттернов может быть решена особенностями языка, библиотеками или фреймворками. Это не исключает того, что паттерны стоит знать. Поэтому я бы изучил паттерны по какой-то простой попсовой книге или на сайте на том языке, который я использую. А потом дополнительно какие-то моменты смотрел бы уже сразу под свой стек.
"Чистую архитектуру" Дядюшки Боба - книга легко читается
Серьёзно? Мне было очень сложно её читать - как будто писал человек без педагогического таланта. Изложение непоследовательное, термины вводятся без объяснения, концепции не перетекают одна в другую и т.п.
Я вообще не могу всерьез воспринимать взрослого человека, который настаивает, чтобы его звали "Uncle Bob"
Не знаю насчет американцев, но, вообще-то, в разных культурах прозвища воспринимаются по-разному. Бразильцы, скажем, выходят на игру в футболках, на которых написано "Халк" (это же не имя, а прозвище). И в протоколе матча так и пишут - Халк! Роналдиньо какой-нибудь, "маленький Роналдо", русский аналог был бы ''Васенька" или "Петруша". По-русски звучит дико, а бразильцам норм. Были у них и ''Япончик" и "Китайчонок" (переводя на русский).
Зачем ходить в другие культуры, у нас точно так же куча батек, вождей, отцов нации, защитников и прочего кринжа, который форсят нарциссы, дорвавшиеся до какой-то публики или власти, пытаясь скрыть свою низкую самооценку. Так что "дядюшка Боб" один из этих примеров, нормальный человек представляется по роду деятельности или профессии, но даже тогда там используют общепринятые обращения вроде "профессор"
Я решил Чистую архитектуру в этот список не добавлять, так как сразу хочется ещё парочку книг докинуть. Но ещё подумаю.
книга легко читается и дает понимание того, откуда и зачем появились современные принципы
Она потому легко читается, что там несколько описанных в начале концептов бесконечно повторяются на протяжение всего текста. Это, считай, статья уровня "старого" хабра раздутая до книги.
Я Мартина в целом уважаю, но эту книгу могу рекомендовать только если совсем больше почитать нечего.
А можете ссылки на Ютуб дать? Оно ? https://www.youtube.com/playlist?list=PLLrf_044z4JrBw4S8bCgf77kPO8xrxczU
В подборке хорошие книги, добавил себе парочку на будущее.
Но я бы лучше составлял 2 отдельные подборки: для начинающего и для более опытного программиста. Потому что сейчас там многие книги в основном для опытного, у которого есть какие-то пробелы или желание знать больше. Джуны, даже если и поймут материал, то не смогут его смаппить с текущим опытом. Скорей всего, читать им будет очень сложно.
А какие бы книги вы для новичков добавили?
Кому-то нужно придумать книгу, которая лежит на столе и, если не пишешь комментарии, бьёт тебе по роже.
Если вашему коду нужны комментари, перепишите его
Неправда, в коде всегда существуют неявные зависимости между компонентами, для того, чтобы понять которые, надо одновременно смотреть в несколько компонент, особенно в event-driven моделях и микросервисах, как вы будете в этом жить без документации (авто- или нет - неважно). плюс к этому логика может быть достаточно сложна, и верхнеуровневые комментарии человеческим языком о том, что тут происходит - всегда полезны. На такой "переписанный код" без комментариев сам автор смотрит через год и вспоминает - "А что я тут делал-то?"
Об этом прекрасно говорится в книге "A philosophy of software development" (чтобы в тему статьи)
особенно в event-driven моделях и микросервисах
Пишу огромный проект на Vert.x. Это как бы квинтэссенция понятия "event-driven микросервисы" в мире джавы. Комментов у нас по пальцам пересчитать, только в изолированных оптимизированных функциях. Интересно, какую именно проблему event-driven систем они должны решить?
Проблему шаринга знаний о домене между разработчиками в первую очередь
Ну я тоже за все хорошее против всего плохого. Шаринг знаний это замечательно. Непонятно только, почему у вас в одной куче event-driven системы, микросервисы, шаринг и комментарии. Мы шарим знания через BDD-тесты и соблюдение гигиены в коде. Проблема нехватки комментариев вообще не стоит на повестке дня.
В одной куче все, потому что эта куча называется "неявные зависимости" и "верхнеуровневые описания". Вы же тоже когда что-то изучаете, читаете книги или документацию, а не смотрите голый код и исходники компилятора. Тем более велкам в серьёзные библиотеки, какого-нибудь майкрософта, там комментариев местами больше, чем кода, в несколько раз. Не надо стараться выглядеть самым умным, ничего кроме техдолга это не породит. Самоочевидные комментарии зло, но они нужны не для того, чтобы код словами пересказывать, и отвечать на вопрос "как", а для того, чтобы отвечать на вопрос "зачем" и "что тут происходит". Если бы в 5 строчках алгоритма быстрого вычисления обратного корня quake вместо комментария "what the fuck" стояло нормальное описание приближенных вычислений через битхак, не надо было бы про это снимать целые видео.
Кажется, вы говорите о документации. Документация вещь полезная, безусловно. Но поддерживать ее в актуальном состоянии отдельная задача, с которой справляется далеко не большинство проектов
Я писал от тех комментариях, которые поясняют головоломки внутри модулей (функций, классов). Вот это видится мне злом, хотелось бы чтобы код был написан так, чтобы в таких комментариях не было необходимости
Иногда код выражает объективно сложные вещи, а не только запутывает простые.
Если вы перекладываете джейсон, то это можно написать просто. Но если вы пишете, например, оптимизирующее преобразование в компиляторе, то просто это написать невозможно.
Документация вещь полезная, безусловно. Но поддерживать ее в актуальном состоянии отдельная задача, с которой справляется далеко не большинство проектов
Это потому что этому нас как то не учат. Вон, тех инженеров, которые про бетонно-железные системы, говорят, во время обучения просто задалбливают написанием этой самой документации. А программистов?
Что, кстати, напомнило - а чего в эту пачку книг нужно накидать, где рассказывается, как делать процесс документирования не таким занудно-противным?
К "базе", имхо, можно еще Брукшира добавить
Вообще не понимаю чего все так нахваливают CS50, там же сплошная вода и клоунада с беготней по сцене. Такое ощущение что никто его так и не посмотрел а просто рекомендуют по привычке, т.к. им тоже когда-то рекомендовали
Я смотрел и мне понравилось. Чувак реально заражает. От препода очень многое зависит, как люди будут учиться. В школе по физике всегда была 3, ушёл на платный курс, где был потрясающий преподаватель, и 3 поменялась на 5 буквально за полгода.
Возможно, вам больше подходит скучное начитывание лекций, не знаю.
Немало проматываю, но, когда дело доходит до объяснений, он хорош)
По мне так хороший вводный курс про CS для не-технарей, которые видят компьютер первый раз в жизни (до того пользовались телефоном).
Более концентрированная подача информации будет для них сложной, более серьёзная - скучной.
Это супер-базированная книга
Шта?
Так и хочется процитировать реплику из к/ф «Гений»: «По-русски говори, да?»
Простите мне мою интернет-мемность.
Так всё-таки, что означает словосочетание "супер-базированная книга"?
От слова "база" в контекста фундаментальных знаний. "Базированная" - значит передающая базовую, само собой разумеющуюся информацию.
Всё-таки "базовая" и "базированная" – это противоположные по смыслу слова в русском языке. Не то чтобы я считал возможным спорить с интернет-мемами, но аккуратное использование естественного языка мне кажется сродни аккуратному программированию.
К слову, смыслы слов могут меняться с течением времени. А если конкретно по теме, то, например, "базировать" - это располагать базу где-то (в лесу). Другое семантическое значение - основывать на чём-либо утверждение.
И во всех значениях речь про закладывание какой-то основы, базиса.
Если владеешь русским языком, то нетрудно догадаться. Либо можно развести холивар на пустом месте.
P.S. Слово холивар требует объяснений?)
От слова "база" в контекста фундаментальных знаний. "Базированная" - значит передающая базовую, само собой разумеющуюся информацию.
Вы просто написали про интернет мемность, а в интернет мемах это слово имеет вообще другое значение ))
Во-первых, я передал смысл правильно. В контексте интернет-мема это слово может использоваться в разных значениях, например, слово используют как насмешку над тем, как люди считают что-то базой, что ей может не являться, а просто быть ультраправой позицией (если речь про политику), что отсылает нас к такому явлению как консерватизм, например.
И также есть такое определение: "не подвержен влиянию общей культуры; он не изменит свой стиль, мнения или ценности", то есть речь про нечто незыблемое, основополагающее.
"Это базы. Based. Это вот база. Потому что это — основа, это, так сказать, база. Всё, это база! Это основа! Это базис." (мемная фраза)
Нет более печального зрелища - чем программист не освоивший гугл.
Не буду увлекаться спором о частностях, но если эту статью и комментарии будут читать новички, для них отмечу, что большинство указанных книг мне представляются совершенно ненужными или даже вредными для неокрепшего ума. Имею высшее образование в области программирования и 30 лет стажа в разработке. Не то, чтобы я хотел сказать, что моя точка зрения правильная, а у автора статьи – нет, но я хочу показать, что любые такие списки очень субъективны.
На самом деле, всё зависит от предполагаемого рода занятий в программировании. Что хорошо для пилота Формулы-1, мало поможет машинисту экскаватора, и наоборот. Спрашивайте людей, которые занимаются именно тем, чем хотели бы заниматься вы.
А если вас интересуют фундаментальные основы программирования, начинайте с SICP. Коммерческой ценности непосредственно в приобретённых знаниях будет мало, но, так сказать, ум отформатируется эффективным образом.
Короче говоря, сначала ответьте самому себе на вопрос, что вы хотите получить от чтения – деньги или ум, потом – каким именно образом вы предполагаете это сделать, потом ищите наставника на выбранном направлении. А книжки – это инструмент достижения поставленной цели.
Ну, я бы поспорил. В моих референсах больше базы, которая может понадобиться в практической работе. А в вашем референсе чтиво для продвинутого инженера, который хочет понять, что такое метациклический интерпретатор и как вычислять квадратный корень методом Ньютона.
С моей точки зрения, человеку, который понимает, как устроен метациклический интерпретатор, большая часть базы ваших референсов вообще не понадобится. Объектно-ориентированное проектирование – это, в сущности, объяснения, как решить сложную задачу по-простому, если нет возможности сделать это по уму.
Это всё вопрос упакованности знаний. Так называемые “паттерны проектирования” гораздо продуктивнее рассматривать в качестве синтаксических конструкций метаязыка. Почему продуктивнее? Потому что такое знание объективно и верифицируемо. Но проще, конечно, заучить со скрижалей.
Это как мы в школе учим, что квадратное уравнение имеет корни, когда дискриминант неотрицательный, а в институте в матанализе это обстоятельство оказывается небольшим следствием теоремы Коши (а ещё заодно и комплексные корни появляются). Аналогия тут достаточно глубокая, я её почерпнул из статьи Шилова про семантику высших порядков.
А после прочтения SICP, можно посмотреть пару плей-листов:
https://www.youtube.com/watch?v=bPCBb1U56yw&list=PLQyMGME-L41Pokb8WFI2hgTEA2GhwL_Jy
https://www.youtube.com/watch?v=n3wEM7P11kI&list=PLQyMGME-L41NPK0U-XzRVmU6DKl0iePrT
В дополнение к этому списку категорически рекомендую классику Software Engineering: "Мифический человеко-месяц" Фредерика Брукса.
Хотя эта книга не поможет пройти собеседование и писать эффективный код, она ориентирует во "внутренней кухне" процессов создания ПО и обеспечивает базовый уровень адекватности при общении с коллегами, руководством и заказчиками.
Может лучше сразу переходить к "Как разработчику ПО выжить в безнадежном проекте"? ))
Она написана около 50 лет назад. Читается легко, но я бы не сказал, что по ней можно составить представление о современных процессах в IT. Эту книгу мне напомнила прочитанная позже "Идеальный программист" того же дяди Боба, много воспоминаний о былом. Познавательно, но не более.
Давно слышу про эту книгу, но так и не прочитал. Спасибо за рекомендацию, возьму на заметку!
Уже не нужно это всё читать, ИИ скоро заберёт Вашу профессию.
Между прочим, неплохой тест. Если ИИ может объяснить или даже выполнить то, что написано в книге, то это – книга про бессодержательные вещи, которые скоро возьмёт на себя ИИ.
Но это, конечно, тест не для начального уровня обучения.
Вы уверены?
А теперь?
А как же Таненбаум?
И Кнута и Таненбаума надо читать, когда ты совсем уже взрослый специалист, кмк. Тут я попытался какой-то минимальный минимум собрать.
Кнута вообще не надо, если честно. Представляет интерес в исторических (раньше люди писали вот так) или коллекционных целях.
Корман, Сэджвик, Шень (из наших) - просто на голову лучше если цель разобраться с алгоритмами.
Кнут просто очень глубоко копает. Он не зря же свою машину MIX придумал, а, в частности, потому, что эффективность алгоритма в конечном итоге зависит от конкретного железа. А многие другие авторы дальше О в своём анализе не заходят.
Другое дело – нужна ли такая глубина рассмотрения обычному прикладному программисту? Наверное не нужна. Тем более что MIX весьма отдалена от современных архитектур.
Та часть, которая одинакова - у Кнута написана просто хуже чем у более современных авторов.
Вторая часть (скорость исполнения на конкретной машине) - тоже кажется излишней и вот почему:
1. прикинуть - если вы программист а не кодер - вы и сами на пальцах можете с нужной вам степенью упрощения
2. точно рассчитать - за исключением вырожденных простейших случаев в реальности невозможно (*)
*) собственно я этим занимался при написании компиляторов и аппаратуры.
Обоснованно рассчитать сколько % перформанса принесёт та или иная оптимизация в компилятор и\или железо - реально невозможно для большинства реальных ситуаций.
Согласен, да, просто накинул на вентилятор)))
Я бы добавил Фаулера – либо Шаблоны корпоративных приложений, либо Рефакторинг
Паттерны и чистый код - считаю скорее вредными (джунам вредно, уже миддлам - вообще что там читать кроме "договоримся о терминологии"). Кажется это книги не для инженеров, а для кодеров. Они плохие и по цели "вместо фокусе на результате - фокус на инструменте", так и по средствам - мне кажется они опасно близки к обещанию серебрянной пули.
Code Complete Макконела - считаю на 2 головы выше чистого кода.
ну и SICP https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
Возможно выскажу непопулярное мнение, но по-моему книги по программированию вообще читать не обязательно. Новичку надо основательно изучить 4-5 первых семестров в профильном ВУЗе и научится гуглить (яндексить, чатджипитить, ...) Неновичку не нужны рекомендации общего назначения.
Сам я прочитал только книгу дракона, и то, больше для развлечения.
Рекомендуя и читая, гражданина Мартина надо помнить, что последний раз он участвовал в разработке ПО более 30-и лет назад.
Спасибо большое, хорошая подборка. Сейчас дочитываю System Design (Алекс Сюй). Хочу отметить, что книга именно обзорная и достаточно поверхностная. По ней нельзя научиться проектировать и даже проходить архитектурные интервью( что не одно и тоже) . Скорее можно получить представление о задачах и ожиданиях на таких интервью.
"Алгоритмы" Томас Кормен
Спасибо за статью.
Еще приложение в копилку, 'algorithms & data structures with unique interactive visualizations"
https://play.google.com/store/apps/details?id=com.iov.lordofalgorithms
Про ООП, паттерны и чистый код лучше читать вот эту статью: https://habr.com/ru/articles/885980/
Ну то есть, тот кто не прочитал все эти книги - плохой программист. Даже если это автор одной из них.
Что-то никто не догадался привести список тех книг, которые не следует читать в виду их низкого качества, обилия воды и наличия ошибок.
Не знаю, может кто-то тут уже писал, но не уверен, что книга про TDD научит писать тесты, немножко она о другом. Да и для совсем новичка может рановато, не самый простой подход к разработке, хотя примеры там очень доступные. У меня не то, чтобы гора опыта за плечами, но я читал и её, и Хорикова, и если выбирать, то наверное начал бы со второй.
Слово «одновременно» в данном случае определяет ключевую разницу между
объектно-ориентированным программированием и другими методологиями про-
граммирования. Например, при процедурном программировании код размещается
в полностью отдельных функциях или процедурах. В идеале, как показано на
рис. 1.1, эти процедуры затем превращаются в «черные ящики», куда поступают
входные данные и откуда потом выводятся выходные данные. Данные размещают-
ся в отдельных структурах, а манипуляции с ними осуществляются с помощью
этих функций или процедур.
(Взято из книги "Объектно-ориентированное мышление" (Мэтт Вайсфельд).)
Такие рассуждения побуждают прочитать эту книгу с карандашом в руках и, затем, написать критический разбор.
Теоретический минимум по Computer Science (Владстон Феррейра Фило)
Пробовал её читать, не понравилось. Я настолько привык, что в таблицах истинности обычно пишут нули и единицы, что воспринять галки и крестики не могу. У меня от них глаза вытекают.
Я бы предложил почитать:
Гради Буч, ..., Объектно-ориентированный анализ и проектирование с примерами приложений;
Фаулер Мартин, Рефакторинг. Улучшение существующего кода;
Мартин Роберт, Чистая архитектура. Искусство разработки программного обеспечения;
Альфред В. Ахо, Моника С. Лам, Рави Сети, Джеффри Д. Ульман. Компиляторы: принципы, технологии и инструментарий;
Касперски Крис, Техника оптимизации программ. Эффективное использование памяти (она несколько устарела, но увы, свежего издания не будет).
Ну и конкретно по языкам... Я пишу на С++, поэтому и книжки про него:
Страуструп Бьерн, Язык программирования С++
Джосаттис Николаи М., Стандартная библиотека C++. Справочное руководство
Ну и, если честно, программировать, не зная что под крышечкой, как-то странно.
Поэтому нужно что-то по цифровой схемотехнике и архитектуре ЭВМ.
Минимум книг, которые нужно прочитать начинающему или продолжающему свою кривую обучения программисту