есть ли книжка по обучению программированию?

скопипастил с книжки?

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

The Pragmatic Programmer

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

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

Спасибо, посмотрю. Другие мнения?

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

У меня чисто практическая задача - обучить новичка наиболее эффективно, с наименьшими затратами своего времени и чтобы ничего не было упущено

Судя по разношерстности списка, у тебя задача подготовить сменщика или помощника _для себя_.

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

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

Чем дальше существует индустрия, тем больше доля таких проектов.

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

Нет, всё же нравится, если дальше посмотреть. Спасибо!

https://kidsjs.blogspot.ru/

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

https://code.org/
https://codecademy.com/

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

Спс.

Это не надёжно, т.к. зависит от способностей новичка, невозможно контролировать, и не гарантирует никакого результата.

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

Почти всё из этого есть в Code Complete, плюс Pragmatic Programmer - уже посоветовали. TDD упоминают и в Code Complete, но книжка Кента Бека, имхо, приятнее именно для въезжания. По ООП лучше Гради Буча я не видел. VCS я начинал с SVN/CVS и хендбука SVN мне вполне хватило, базовые понятия рассмотрены хорошо + бранчи/версионирование/структура проекта.

Про командную разработку/методики поиска самому интересно, никогда не встречал ничего вменяемого, подпишусь.

Ну так у тебя часть вопросов напрямую зависит от принятых в конкретной конторе coding standards.

ТС я лично думаю что вы ищете совсем не то что надо искать. Дело в том что програмирование оно как интернет, очень разнообразно, и как и в интернете тут бывает что популярные вещи (идеи/подходы/технологии) могут затмевать непопулярные но более эффективные. Идея взять всё это и поделить на ноль, вернее уместить куда-то в одном месте, эта идея обречена на провал.

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

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

Поэтому пусть будет изобилие. Разбираясь в этой свалке вы тренируете себя, и учитесь самостоятельнмоу мышлению, которое со временем даст вам то что вы ищите.

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

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

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

Я могу вам дать одну рекомендацию которая возможно вам поможет если вы к ней серьёзно отнесётесь. Вот она: никогда нельзя строить железобетонных конструкций. Этот принцип способен вас уберечь от проблем и позволить легко перемещаться между парадигмами, не зацикливаясь и позволяя свежо смотреть на происходящее. Очень часто проблемы у людей от того что они застревают на концепциях и привязываются к ним, пытаются условно говоря «забивать гвозди молотком (в особо запущенных случаях даже молоком)» потому что начинают восхвалять свой любимый молоток и пытаться найти ему новые применения, сделав его чем-то большим чем он является сейчас.

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

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

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

Повезёт если автор будет адекватным, а если он всего лишь будет популярным и завернёт фуфловые идеи в красивый фантик? Это уведёт вас в сторону.

Жизнь вообще может удасться, а может и неудачно сложиться. Панацеи нет. Скажем так, я наверное ищу книгу, которая согласна со мной там, где я уверен в себе и поправляет меня там, где я не уверен.

Поэтому пусть будет изобилие. Разбираясь в этой свалке вы тренируете себя,

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

И на всякий случай - я сам это читать не собираюсь, я собираюсь с помощью этого обучать.

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

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

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

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

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

Зато я буду знать, чего ему не хватает. Если он не захочет учиться, он просто не сможет ничего путного сделать и придётся с ним расстаться, но это ортогонально к моему вопросу. Тратить энтузиазм впустую неохота.

Спасибо за список!

Насчёт методик поиска вот что я имею в виду: нужно знать набор «точек входа в поиск», например, корень дерева кода, лог VCS, корень директории с документами (желательно спайдер иметь, который это индесирует). Корень стандартов по средствам, корень доки по каждой библиотеке, система учёта требований, корень доки с release notes по каждой версии. Плюс StackOverflow и тематические ресурсы по выбранным технологиям.

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

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

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

Например, я знаю, что много теряю из-за отсутствия осознанного подхода к фиксации найденного и поэтому часто буксую.

Я что-то сомневаюсь, что такому подходу можно научиться по книгам. Это в большей степени творческий процесс, чем какая-то формальная методика, обычно приходит с опытом. И то не ко всем, я видел многих «профессионалов», не понимающих, зачем нужен git bisect и неспособных даже нагрепать call-tree какой-то функции в большой легаси-базе. Странно от новичка ожидать, что он после методички будет мастерски находить root cause-ы.

Но это только моё мнение, основанное на моих наблюдениях. Может, кто-то сумел какую-то методику выработать.

Читай книги и учись!

Прав много по книгам не на учишься.

ну и то, что я ещё сам не выучил или не упоямнул

Рецепт серебряной пули забыл

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

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

Если считать, что «всё есть инструмент», в т.ч. и сотрудник, выгодно ли мне как работодателю оплачивать копание новичка на помойке в поисках чего-то годного и быть заложником того, в каком порядке ему какой хлам попадётся?

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

Как мне кажется книга вам здесь гарантии не даст. Она тоже является инструментом, как и само программирование, и как бы не был прекрасен инструмент но без желания и интереса ремесленника его освающего толку не будет. Бывают и другие аномалии, к примеру ремесленник так сильно полюбил свой инструмент что начинает его использовать там где не надо. Или начал противопоставлять любимый инструмент прочим инструментам. Как вы верно сказали панацеи нет, однако по прочтению ваших постов складывается впечатления что именно её вы и ищите.

Вообще честно говоря от ваших постов сильно попахивает советским союзом, где партия сверху спускает «план» (что читать и в какой последовательности) и новичок погнал его исполнять. Мне кажется это как раз новичок должен прорываться снизу вверх без всяких планов, а сверху спускается лишь задача что сделать надо. Вы новичка таким подходом делаете безруким и недумающим (ИМХО), ждущим что за него подумают и скажут что и как делать. Если вы собственник этого бизнеса в котором эту задачу решаете, то на мой взгляд всё проще решается, а именно привлекается уже заинтересованный человек по которому видно что он старается и учится разбираться, который не нуждается в планах сверху, и если что и надо ему для работы (к примеру лицензия IDE) то просит именно подобное у начальства.

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

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

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

К вашему сведению, хирурги достаточно времени обучаются на трупах, если мне не изменяет память это 5 лет практики в моргах (которая берёт начало ещё в мед. институте), и лишь после этого они получают допуск к живым пациентам (кажется на первых стадиях в качестве помощника).

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

PS: Если вы не нашли в этом посте чего-то полезного для себя, то пожалуйста просто не отвечайте. Я бы не хотел вовлекать вас в спор мнений.