понедельник, февраля 26, 2007

Какие знания необходимы программисту - часть 2

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

Физические основы

Здесь "физические", от слова "физика" :-) Имеется ввиду наука физика. Наука великая
и странная, нужно нам из неё немного, а именно кое-что, связанное с электрическими цепями, а также электронными компонентами.

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

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

  • "фон Неймановская" архитектура построения компьютера (использование двоичных чисел, код и данные хранятся вместе, концепция "хранимой программы")
  • Не-фон Неймановские архитектуры (гарвардская)
  • Микропроцессор (оп-коды, регистры, устройство с "электронной" или "физической" точки зрения)
  • Шина данных (с "электронной" точки зрения)
Операционные системы

Операционные системы - это можно сказать "сердце" современных компьютеров. Многие
из них даже достаточно успешно скрывают от нас истинную архитектуру и устройство компьютера, процессора, памяти и так далее.
  • Предназначение ОС
  • Процессы и потоки
  • Управление памятью
  • Ввод/вывод
  • Файловые системы
  • Безопасность
  • Структура операционных систем (монолитные ОС, ОС с микроядром, виртуализация)
Сети

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

  • Физические основы (каналы, пропускная способность каналов, виды каналов, виды волн)
  • Семиуровневая модель OSI
  • Безопасность в сетях
Базы данных
  • Типы баз данных
  • Реляционная алгебра
  • Реляционное исчисление
  • Проектирование баз данных (функциональные зависимости, нормализация)
  • Защита данных
  • Объектно-ориентированные базы данных
  • Структуры хранения и методы доступа к данным
Криптография

  • Симметричные и асимметричные методы
  • Хэш-функции
  • Стойкость
  • Криптографические протоколы

Основы программирования

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

  • Язык ассемблера - основы (смысл не в том, чтобы знать какой-то конкретный ассемблер, а в том чтобы знать что это такое, и как именно согласуется ассемблер с "физическими" основами компьютеров)
  • Парадигмы программирования (процедурное, объектно-ориентированное, функциональное, логическое, аспектно-ориентированное, DSL, метапрограммирование)
  • Основные концепции, достоинства и недостатки каждой из парадигм
  • Основы проектирования (объектно-ориентированный анализ, и тому подобное)
  • Компиляторы и интерпретаторы (разница, преимущества и недостатки)

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

Обсуждение

В завершение хочу высказать несколько мыслей по изложенному списку.

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

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

  • На какую именно составляющую влияют такие списки? Зачем в список включено "Х"? Ведь никогда в жизни этим не придётся воспользоваться в реальном программировании!
    • Я согласен, что очень многими вещами из списка в реальной жизни большинству людей заниматься не придётся. Немногие пишут компиляторы, операционные системы или проектируют новые компьютеры.
    • Тем не менее, как мне кажется, существует так называемый "закон дырявых абстракций" (The law of leaky abstractions"). Идея тут такая. "Абстрагированием" мы называем процесс удаления деталей из представления некоторого процесса. Мы, особенно программисты, постоянно строим один уровень абстракции над другим. Например, операционная система предоставляет нам API, который является абстракцией над всем, что реально делает ОС. Так вот "закон дырявых абстракций" говорит нам о том что "Все нетривиальные абстракции, являются, в некоторой степени, дырявыми". То есть рано или поздно мы, программисты, столкнёмся с тем что находимся там, внизу. Вот именно в этот момент нам и понадобится "X" - для того чтобы понять что же именно происходит. Тут может возникнуть ещё один вопрос - а до какого же уровня все нужно учить? Ведь можно попытаться копнуть ещё глубже, а потом ещё? Это на самом деле сложный вопрос, я не буду отвечать на него здесь. Он заслуживает отдельного размышления.
  • Ты сам-то знаешь все о чем в списке понаписал?
    • Нет, к моему большому огорчению знаю не все. А кое-что знал раньше, но успешно забыл.
  • В список не включено 'Y', а без 'Y' невозможно представить себе программиста!
    • Вполне вероятно. Я запросто мог что-то пропустить, а чему-то не придать достаточного значения. С удовольствием узнаю Ваше мнение по этому поводу. Добро пожаловать в комментарии!

3 комментария:

Unknown комментирует...

Интересное интервью http://www.gotdotnet.ru/Channel9/441849.aspx в общем и в частности о знаниях програмистов. А так же пара слов о стартапах

Alex Efros комментирует...

Список просто восхитительный... но я категорически не согласен с тем, что это "знания, которые совершенно необходимы каждому программисту" (хотя сам я имею более или менее глубокие представления по ~75-80% списка).

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

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

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

Lev Kurts комментирует...

2 alex efros: Насчет практических навыков полностью с Вами согласен.Их в списке нет. Но список и предполагался как "необходимое и достаточное" условие. Только как "необходимое".

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