Comments 52
Добавить бы в эту структуру перевод на английский и ссылки на онлайн-курсы/книги/интернет-ресурсы по каждому пункту.
Чтобы целиком одним махом закрыть сети, ОС и железо, я могу порекомендовать:
А по программированию классику. Чистый код (или Совершенный код — дело вкуса), Рефакторинг, что-то по паттернам, Программист-прагматик, книги Джоэла Спольски. Ну и, конечно, книги по своим языкам и технологиям.
- Архитектура компьютера, Таненбаум
- Компьютерные сети, Таненбаум
- Современные операционные системы, Таненбаум
А по программированию классику. Чистый код (или Совершенный код — дело вкуса), Рефакторинг, что-то по паттернам, Программист-прагматик, книги Джоэла Спольски. Ну и, конечно, книги по своим языкам и технологиям.
Вот что-то
Как это нередко бывает в науке, три года назад статью о «классификации знаний в программировании» уже опубликовали под названием «теоретический минимум для программиста». Там есть и список литературы, и перевод на английский язык.
Исходя из описаний всех уровней, я не программист, а дырка от бублика.
Мне кажется, что вы знаете из этого всего больше, чем думаете, что знаете :)
Возможно вы заблуждаетесь. Метакогнитивные искажения — не шутка!
Из того, что автор учился программировать по такой системе, совсем не следует, что она чем-то хороша.
… но уж точно не следует, что отсутствие системы лучше, чем такая система.
Вот тут вы как раз не правы. Отсутствие системы лишь осложняет выбор направления движения, а плохая система изначально ставит на неверный путь.
В этом случае, прежде чем заявить, что «уж лучше ничего, чем такая система», нужно очень основательно подойти к перечислению причин, чем она плоха. В идеале, конечно, хорошо было бы конструктивно построить хорошую систему, лишённую хотя бы части перечисленных недостатков.
Но даже просто критика «нет, так нельзя» – обязательно должна быть обоснована тезисами, почему именно нельзя, и даже если мы не можем сказать, как же всё-таки можно, всё равно должно быть понятно, что перечисленные минусы перевешивают плюсы системы. Только так – иначе получается, чтоваши нашим «Principia Ньютона – плохая система, потому что так нельзя». Впрочем, тут я, наверное, передёргиваю. Или нет: философия науки требует в первую очередь систематизации, потому что так развитие идёт быстрее (теория перестала сходиться с экспериментом? Не беда, пришло время научной революции).
Я бы сказал не «изначально ставит на неверный путь», а «приводит к построению в голове модели, не обладающей необходимой предсказывающей способностью», причём оценить эту самую способность можно только a posteriori. Связывая первую мысль со второй, я склонен считать, что всё-таки наличие системы лучше её отсутствия.
Я тоже несогласен с отдельными моментами на схеме (например, привязка к языку может и должна осуществляться не на уровне схем, а на уровне конкретных преподавателей и их курсов, и то – если они сами того хотят), но мне кажется, что Ваш тезис ниже про «с ног на голову» – явный перебор.
Схема имеет право на жизнь. Её всегда можно взять и доработать, переработать, и так далее – думаю, автор не будет против.
Система появляется там, где сложная сущность становится чем-то большим, чем сумма составляющих. Лично мне «сходу» представляется возможным только один вариант проверки ценности этой схемы: показать её заинтересованному неайтишнику (но лучше всё же технарю) и спросить через N минут, что он из неё уяснил.
И последнее: утверждение «из того, что автор учился программировать по такой системе точно не следует, что лучше никакая, чем такая» (а именно оно складывается из Вашего и моего комментариев) мне видится вполне себе правдивой импликацией, поэтому неправым я себя на этот счёт не почувствовал.
Но даже просто критика «нет, так нельзя» – обязательно должна быть обоснована тезисами, почему именно нельзя, и даже если мы не можем сказать, как же всё-таки можно, всё равно должно быть понятно, что перечисленные минусы перевешивают плюсы системы. Только так – иначе получается, что
Я бы сказал не «изначально ставит на неверный путь», а «приводит к построению в голове модели, не обладающей необходимой предсказывающей способностью», причём оценить эту самую способность можно только a posteriori. Связывая первую мысль со второй, я склонен считать, что всё-таки наличие системы лучше её отсутствия.
Я тоже несогласен с отдельными моментами на схеме (например, привязка к языку может и должна осуществляться не на уровне схем, а на уровне конкретных преподавателей и их курсов, и то – если они сами того хотят), но мне кажется, что Ваш тезис ниже про «с ног на голову» – явный перебор.
Схема имеет право на жизнь. Её всегда можно взять и доработать, переработать, и так далее – думаю, автор не будет против.
Система появляется там, где сложная сущность становится чем-то большим, чем сумма составляющих. Лично мне «сходу» представляется возможным только один вариант проверки ценности этой схемы: показать её заинтересованному неайтишнику (но лучше всё же технарю) и спросить через N минут, что он из неё уяснил.
И последнее: утверждение «из того, что автор учился программировать по такой системе точно не следует, что лучше никакая, чем такая» (а именно оно складывается из Вашего и моего комментариев) мне видится вполне себе правдивой импликацией, поэтому неправым я себя на этот счёт не почувствовал.
Но даже просто критика «нет, так нельзя» – обязательно должна быть обоснована тезисами, почему именно нельзяМожно начать с того, что по этой же логике схема должна быть снабжена пояснениями, почему она хороша. Потому что из самого факта своего существования это никак не следует. Что я и написал, в общем-то;)
Впрочем, я могу сказать, что мне не нравится.
1. Слишком много теории на базовом уровне, и слишком высокий порог вхождения. До уровня «специальной базы» нужно добавить «уровень знакомства с темой», на котором начинающий мог бы «поиграть в программирование» и понять, нравится ли ему вообще это.
2. Слишком много внимания уделено аппаратуре, если придерживаться одинакового объема знаний в каждом элементе на каждом уровне.
3. Неверный подбор ЯП.
4. Однобокое представление, из которого упущены некоторые важные вещи, как уже отметил MarcusAurelius.
5. Все смешано в кучу. Начиная с базового уровня следовало бы выделить несколько векторов развития. Web-технологии, CS, embedded и т.д.
6. Нужно как-то указать на предполагаемый уровень знаний, который подразумевается на соответствующем уровне. Потому что каждому из квадартов на каждом уровне можно посвятить всю жизнь, наверное, и узнать далеко не все.
Можно начать с того, что по этой же логике схема должна быть снабжена пояснениями, почему она хороша. Потому что из самого факта своего существования это никак не следует. Что я и написал, в общем-то;)
С первой частью («да, должна») согласен на 200 процентов. Да, обязательно. Автор любой работы, как правило, в самом её начале обозначает, чем именно хорошо то, что он сделал, если он считает, что сделал хорошо. Или пишет «А хорошо ли я сделал?» – если не уверен.
Со второй частью – не уверен. Ну, то есть, что лучше: несколько схем-конкурентов, или ни одной? Но тут опять боюсь переступить грань между логикой и риторикой.
Касательно пунктов:
(6) Точно можно, однозначно далеко не всё (последний университет — Анри Пуанкаре, наверное, навсегда останется последним...). Наверное, базовым автор имел в виду школьное образование.
(5) Нет, не всё. Да, располосовать направления (сливающиеся на нижних уровнях) – это нужный и важный ход. Просто автор, как мне кажется, не сделал акцента на «целевой раскраске», благодаря которой (например) человек, мечтающий создать лучший в мире ЯП, мог бы пальцем провести от цели к основам и визуально оценить весь груз необходимых для этого знаний (это всё равно нереально a priori, но хотя бы визуализация...)
(4) Угу, упущены. Но ведь автор – не Пуанкаре. Детализация – не первая вещь же.
(3) Согласен, выбор ЯП вообще, как по мне, – дело преподавателя, а не этой схемы
(2) Слишком много? Не знаю, не уверен. Если под «аппаратурой» понимать электротехнику и схемотехнику, то это не совсем «в области программирования», если «программирование на низком уровне, системное ПО» — то даже наоборот: в районе второго уровня по идее следует поместить теорию языков программирования и методы трансляции (нам, например, читали на 4м курсе, свой (простейший, разумеется) интерпретатор или компилятор был в качестве курсовой), а чуть ДО asm (или в начале курса по нему) – то, как асм появляется из микрокоманд. До сих пор прекрасно помню наш лабораторный эмулятор 8086, микропрограммируемый, и то, как мы писали свои ассемблеры на нём.
(1) Сказать, много ли теории, можно будет только тогда, когда к каждому из квадратиков схемы будет приложена образовательная программа соответствующей дисциплины. Как мне кажется. Порог вхождения, как я понял, автор имеет в виду школьный (хотя лучше всего было бы, если бы автор прямо сказал: «Я подразумеваю, что человек, приступающий к квадратикам „Общая база“, успешно закончил среднюю школу).
Получается (сугубо субъективно):
1) схема неплохая (и слитно, и раздельно), есть устранимые недочёты (Боже, выглядит как копипаста рецензии. Честно, это не было целью -_-),
2) схеме нужно больше
3) на схему неплохо бы добавить упущенные элементы,
4) снабдить каждый из квадратиков схемы образовательной программой по предмету (естественно, это дело экспертов по каждому из квадратиков, а не одного Пуанкаре, которого всё равно нет),
5)… (новые стандарты в образовании?)…
6)… выгода?
4. Функциональное программирование, модели распределенных вычислений, кибернетика — это не детали. Это просто огромный пласт знаний. Нельзя его просто так выкинуть.
2. Я не уверен, что это нужно всем. Для того, чтобы хорошо программировать, конечно, необходимо иметь представление, как работает оборудование и компиляторы, понимать указатели. Но не более того. Курс по полупроводникам не даст многого Web-программисту.
Мне кажется, такую схему просто невозможно грамотно составить одному человеку. Это фактически по сложности учебный план целого института. И, собственно, возможно на учебные планы институтов и следует ориентироваться? Если составлять свою схему, то нужно создавать репозиторий на Github-е и привлекать энтузиастов :) Тогда, возможно, и выйдет что-то дельное.
2. Я не уверен, что это нужно всем. Для того, чтобы хорошо программировать, конечно, необходимо иметь представление, как работает оборудование и компиляторы, понимать указатели. Но не более того. Курс по полупроводникам не даст многого Web-программисту.
Мне кажется, такую схему просто невозможно грамотно составить одному человеку. Это фактически по сложности учебный план целого института. И, собственно, возможно на учебные планы институтов и следует ориентироваться? Если составлять свою схему, то нужно создавать репозиторий на Github-е и привлекать энтузиастов :) Тогда, возможно, и выйдет что-то дельное.
То что эта схема чем-то хороша, следует не из того, что автор учился программировать именно по ней, это следует из самой схемы. Она не идеальна, конечно, но ни что не идеально.
1. Имеет смысл больше уделить внимание разным парадигмам программирования: функциональному, декларативному, императивному, ООП, автоматному, реактивному, метапрограммированию ( habrahabr.ru/post/227753/ ) и т.д. По этому поводу советую почитать письмо Дейкстры habrahabr.ru/company/hexlet/blog/248921/
2. Моделирование данных, как по мне, это более важная дисциплина, даже чем теория алгоритмов, и вот структуры данных, лучше поместить именно в моделирование данных, (а не в теорию алгоритмов), рядом с реляционной, иерархической, сетевой и др. моделями данных.
3. Жаль, что не увидел в этой схеме место кибернетики (науки об управлении), за то управлению командами разработки, по сути менеджементу (лженауке об управлении) место нашлось.
2. Моделирование данных, как по мне, это более важная дисциплина, даже чем теория алгоритмов, и вот структуры данных, лучше поместить именно в моделирование данных, (а не в теорию алгоритмов), рядом с реляционной, иерархической, сетевой и др. моделями данных.
3. Жаль, что не увидел в этой схеме место кибернетики (науки об управлении), за то управлению командами разработки, по сути менеджементу (лженауке об управлении) место нашлось.
3. Жаль, что не увидел в этой схеме место кибернетики (науки об управлении), за то управлению командами разработки, по сути менеджементу (лженауке об управлении) место нашлось.
Я не силен в кибернетике и скорее всего ее отсутствие — упущение. А вот что касается управления командами и проектами, т.е. элемента менеджмента, я не согласен. Во-первых, это реально нужно в практике тем, кто собирается стать даже на самую нижнюю ступень руководства. Во-вторых, программисты работают в проектах по какой-то системе. Если взята готовая модель, программисты должны понимать, как она работает, даже будучи ее объектом. Ну а если модель формируется в команде эмперически, то тем более лучше иметь какие-то знания в этой области, чтобы сделать лучше.
Законы управления едины, что в технических, программных, экономических и социальных системах. Есть конечно особенности, но фундаментальная наука об управлении — это кибернетика, и она содержит все обобщения, теорию и подходы даже для управления коллективами людей, а менеджмент не содержит фундаментальной научной базы и является всего лишь устным народным приданием, передаваемыми из уст в уста легендами о том, как когда-то у кого-то что-то сработало.
По большому счету мне хватило 2х базовых книг — Искусство программирования, и Компиляторы (книга дракона), чтобы иметь базу. Все остальное практика. Еще могу рекомендовать UML 2.0 и паттерны проектирования, для понимания проектирования систем.
Веб-технологии никак не связаны с базами данных.
Да, потому что в этой классификации «веб-технологии» — это более узкое понятие, чем обычно имеется в виду:
Дело в том, веб — это не только сайты, где БД действительно используются в большинстве случаев. Но даже на сайтах далеко не на всех есть БД. Сайт может быть статическим, либо в роли хранилища может быть не БД, а, например, файловая система или Amazon S3. Сами по себе технологии, на которых строится Интернет, не опираются на базы данных.
Но, когда мы говорим о программистах, которые делают сайты, то в подавляющем большинстве случаев требуется знание баз данных. Просто идет оно отдельным пунктом, а не в составе знания с веб-технологий.
веб-технологии (HTTP-протокол, веб-сервер, CGI, кэширование и проксирование, клиентское программирование);
Дело в том, веб — это не только сайты, где БД действительно используются в большинстве случаев. Но даже на сайтах далеко не на всех есть БД. Сайт может быть статическим, либо в роли хранилища может быть не БД, а, например, файловая система или Amazon S3. Сами по себе технологии, на которых строится Интернет, не опираются на базы данных.
Но, когда мы говорим о программистах, которые делают сайты, то в подавляющем большинстве случаев требуется знание баз данных. Просто идет оно отдельным пунктом, а не в составе знания с веб-технологий.
Что-то после просмотра всех этих уровней, у меня сложилось ощущение, что я не имею права работать не то что, инженером, даже программистом.
Я не владею ни теорией вероятностей, не обладаю познаниями в физике и электротехнике, только поверхностными знаниями по С++ и информатике.
Я не владею ни теорией вероятностей, не обладаю познаниями в физике и электротехнике, только поверхностными знаниями по С++ и информатике.
В общем-то, теорвер, электротехника и физика обязательно изучаются в ВУЗе на программистских специальностях/направлениях. Это не что-то из ряда вон.
Да, но дело в качестве преподавания и в нанизывании этих знаний на общий скелет инженера. Зачем мне все эти предметы: теория информации и кодирования, теорвер, ТАУ (теория автоматизированного управления), СМО (системы массового обслуживания), численные методы, системный анализ, планирование эксперимента, я понял много позже выпуска, после практического опыта программирования поднял книги, и теперь основой вдохновения для написания своего кода, я вижу как раз эти дисциплины, а не расхожие паттерны из популярных книжек.
Да, я изучал все эти предметы, естественно. Но я ими НЕ ВЛАДЕЮ, вот в чем соль.
(а даже расчет цепи без реактивки по 1-2 Киргхофу смогу сделать. Но это примитивные знания).
Я переводился на ВМК на старших курсах, и на лекции тервера мне ходить не доводилось. Из спецпредметов меня зацепили ПМС, Конструирование, Операционные системы. Да, я исправно ходил на лекции и делал все лабы, но ВЛАДЕНИЕ основами, которые приведены в посте от этого глубже не стало.
(а даже расчет цепи без реактивки по 1-2 Киргхофу смогу сделать. Но это примитивные знания).
Я переводился на ВМК на старших курсах, и на лекции тервера мне ходить не доводилось. Из спецпредметов меня зацепили ПМС, Конструирование, Операционные системы. Да, я исправно ходил на лекции и делал все лабы, но ВЛАДЕНИЕ основами, которые приведены в посте от этого глубже не стало.
Владеть математикой должен математик. Электротехникой — электротехник. Программисту достаточно обзорных знаний в областях, далеких от непосредственно применяемых в работе. И уж тем более речи нет о том, что программист должен знать все, перечисленное на схеме (плюс еще то, что я упустил :)). Но все же чем больше знать будет, тем будет для него лучше, это уж точно. Не сейчас, так через 10–20 лет, когда нужно будет конкурировать с молодыми.
ИМХО: годы опыта заменяют месяцы обучения. Я это и на своей шкуре прочувствовал, и по коллегам вижу. По моим прикидкам, если бы я пошел по схеме снизу вверх в универские годы (а не сверху вниз, как вышло на практике), то сэкономил бы несколько лет опыта, которые ушли на получение знаний через практику.
Ни слова о безопасности и криптографии?
Наверное, криптографию нужно было всадить на 1-м уровне с опорой на обработку информации. Могу ошибаться, но мне кажется, что вне экспертного уровня это небольшая область знаний. А вот самая соль и криптографии, и безопасности как аспекта во всех других областях знаний, должна проявляться на экспертном уровне, который я вообще не раскрывал, обозначив лишь 3 примера.
А где собственно заявленная в теме классификация?
Интересная классификация. Нас примерно так и учили. Плюс у нас была компьютерная графика, теория формальных языков, трансляторы и т.д.
Вообще, все предметы складываются в общую картинку только к старшему курсу. Вот чего не хватает в вузах — в самом начале некоего курса, где бы подробно разъяснили зачем нужны те или иные предметы, как они взаимосвязаны и как пригодятся в будущем
Вообще, все предметы складываются в общую картинку только к старшему курсу. Вот чего не хватает в вузах — в самом начале некоего курса, где бы подробно разъяснили зачем нужны те или иные предметы, как они взаимосвязаны и как пригодятся в будущем
Ну хотя бы подграфы общая и специальная база я знаю полностью :) А дальше всего понемногу. Есть вообще люди, которые знают весь граф? Это же огромный объем информации.
Знать можно по-разному. Если обзорные знания по всем областям реально можно получить (а нужно ли сразу по всем — имхо индивидуально), то глубокие знания по всем ним получить уже просто физически не реально, и не нужно. Получить обзорные знания по любой дисциплине на схеме можно прочитав одну хорошую книгу. Причем, общую базу все изучают в школе, а из того, что выше большую часть — на всех более-менее программерских специальностях в ВУЗах.
Очень отвлеченно. Выводы выдают дилетанта.
Sign up to leave a comment.
Классификация знаний в области программирования