Об изучении языков программирования

Очередное интересное высказывание, на этот раз найденное в последней книге Бертрана Мейера “Почувствуй класс”:

Язык, который не влияет на ваш способ мышления, не стоит изучения.

Алан Перлис

Мысль разумная. Конечно, вокруг языка формируется еще и сообщество с собственной культурой, но я, например, не вижу особого смысла изучать Java для C# программиста или наоборот. Чем сильнее отличается культура, идиомы и паттерны в новом языке программирования, тем, потенциально, больше нового вы для себя узнаете.

Влияние психологии команды на архитектуру

Листаю замечательную книгу “Идеальная архитектура”, которая, по-сути, является сборником статей “архитектурной” тематики.

Во второй главе есть такое любопытное примечание:

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

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

Только в здоровой атмосфере возможно приняте ошибок, которое практически невозможно при нездоровой атмосфере. А без этого сложно себе представить хорошую архитектуру; ведь ошибки – это лишь вопрос времени, и чем раньше “архитектор” их осознает, тем более качественными будут “управляющие воздействия” по их устранению. Ну а кто же признает свои ошибки при нездоровых отношениях в команде?

Еще раз о повторном использовании

Сегодня открыл книгу “банды четырех”, чтобы уточнить определение одного из паттернов проектирования и в первой же главе увидел выделенную когда-то цитату:

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

Эрик Липперт, один из разработчиков компилятора C# очень часто говорит о проблеме “преждевременного обобщения” (premature generialization), с которой я, например, сталкиваюсь постоянно.

Многие разработчики разрабатывают повторноиспользуемые компоненты (или выделяют их из своего приложения) принимая во внимание лишь один кейс использования. Они пытаются предсказать будущее, рассматривая какие-то гипотетические кейсы использования или делают “задел на будущее”, который никогда не понадобится. В итоге “библиотечный код” получается излишне сложным и совсем не таким “повторноиспользуемым”, как о нем думал его разработчик.

О паттернах проектирования

Сейчас листаю весьма интересную книгу Боба Мартина и наткнулся на следующее высказывание:

“Паттерны проектирования – чудесная вещь. Они способны помочь в решени многих задач проектирования. Но из того, что они существуют вовсе не следует, что их нужно употреблять к месту и не к месту.”

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

О программировании

Первый абзац в предисловии книги SICP (Структура и интерпретация компьютерных программ):

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

Мне уже нравится эта книга!

О разработке ПО, отладке и Эйнштейне

Брайан Керниган (Brian Kernighan) когда-то выразил такую мысль:

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

Читая книгу Энди Ханта “Pragmatic Thinking and Learning” в одном из эпиграфов я встретил знаменитую цитату Эйнштейна:

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

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

 

Оригинальная цитата Брайана Кернигана:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Оригинальная цитата Альберта Эйнштейна:

We can’t solve problem by using the same kind of thinking we used when we created them.

О понимании нужного уровня абстракции

В одной из своих заметок о Reactive Extentions Ли Кэмпбел (Lee Campbell) выразил следующую мысль:

You should always understand at least one layer below what you are coding.

Или в вольном перевод:

Вы должны понимать как минимум на один уровень абстракции ниже того уровня, на котором вы кодируете.

Нужно сказать очень ценное замечание, следование которому поможет вам не только при написании кода, но также при его отладке и сопровождении.