О создании сложных систем

Еще одна цитата из SICP:

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

Программирование и моделирование

Я тут начал читать замечательную книгу под названием "Структура и интерпретация компьютерных программ", а по сему я надеюсь на пополнение коллекции цитат из этой книги:) Итак, начнем.

Любая компьютерная программа – это порожденная человеческим разумом модель реального или воображаемого процесса. Эти процессы, возникающие из нашего опыта и мысли, многочисленны, сложны в деталях, и мы всегда понимаем их лишь частично. … Хотя наши программы представляют собой искусно собранные наборы отдельных символов, мозаики переплетенных функций, они непрерывно развиваются: мы изменяем их по мере того, как наше восприятие модели приобретает все большую глубину, расширяется и обобщается, до тех пор, пока модель не достигнет, наконец, метастабильного состояния в рамках следующей модели, с которой мы продолжим сражаться дальше.

Что такое разработка ПО? Часть 2

И еще одна мысль от Стива Макконнелла о том, что такое разработка ПО:

"Те, кто считает программирование искусством, указывают на эстетические аспекты разработки ПО и утверждают, что наука не допускает такого воображения и творческой свободы, а те, кто считает программирование наукой, указывают на огромное количество ошибок в программах, утверждая, что столь низкая надежность недопустима, и черт с ней с творческой свободой. Обе эти точки зрения грешат неполнотой и ставят во главу угла неверный тезис. Разработка ПО– это искусство, наука, ремесло, археология, тушение пожаров, социология и еще много других видов деятельности человека, взятые вместе. В некоторых областях это любительство, в других – профессионализм. Это столько же различных вещей одновременно, сколько существует программистов. Но правильно поставленный вопрос состоит не в том, что такое есть разработка ПО на данный момент, а скорее в том, чем должна быть профессиональная разработка ПО. С моей точки зрения, ответ на этот вопрос ясен: профессиональная разработка ПО должна быть инженерией. Такова ли она сегодня? Нет. А должна быть? Несомненно."

Что есть разработка ПО

Читаю книгу Стива Макконнелла "Профессиональная разработка ПО", вот одна из любопытных цитат:

"Один из моих любимых вопросов во время собеседования с претендетами на должность программиста, следующий: "Как бы вы описали ваш подход к программированию?" ... Мне больше всего нравится такой ответа: "При проектировании ПО я архитектор. Когда я конструирую интерфейс пользователя, я художник. Когда я пишу код я ремесленник. А когда я тестирую программу, я ужасная сволочь."

Об иерархиях наследования

Очередная интересная мысль от Бертрана Мейера, на этот раз касается она проектирования иерархий объектов:

Произвольно или нет, но многие учебные презентации создают впечатление, что структуру наследования следует проектировать от наиболее общего (верхней ее части) к более специфическим частям (листьям). В частности, это происходит потому, что лучший способ описать существующую структуру – это идти от общего к частному, от фигур к замкнутым фигурам, затем к многоугольникам, прямоугольникам, квадратам. Но лучший способ описания структуры вовсе не означает, что он является и лучшим способом ее создания.

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

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

Сказка о повторном использовании

Очередная цитата из книги Бертрана Мейера “Объектно-ориентированное конструирование программных систем”.

Эта сказка опубликована в разделе “Сказка о поиске классов”, но мое название, мне кажется более уместным (после прочтения будет ясно, почему).

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

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

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

Наконец, в один из темных зимних дней, когда снег покрыл все окружающие горные вершины, он вошел в комнату Мастера. С бьющимся сердцем, пересохшим от волнения голосом он задал свой сакраментальный вопрос: "Мастер, как мне найти классы?"

Мудрец склонил свою голову и ответил медленно и спокойно: "Возвращайся назад, откуда пришел. Классы уже найдены".

Оглушенный, он и не заметил, как слуги Мастера выводили его прочь. "Мастер", - теперь он почти кричал, - "пожалуйста, еще только один вопрос. Как называется эта история?" Старый Учитель покачал головой: "Разве ты еще не понял? Это сказка о повторном использовании".

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

Мейер в своей книге повторяет, наверное, десятки раз о том, что в современном мире проектирование должно сводиться не к “выявления” новых абстракций, а к выбору готовых классов, которые можно было бы использовать повторно.

На данный момент, это все еще является сказкой и я, честно говоря, сомневаюсь, что она когда-либо станет былью.

Как важно быть скромным

Очередная потрясающая цитата от Бертрана Мейера:

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

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

О сопровождении

Снова добрался до двухкилограммового талмуда Бертрана Мейера «Объектно-ориентированное конструирование программных систем». В одной из глав об объектной методологии разработки ПО, Мейер пишет:

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

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

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

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

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

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

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

Алан Перлис

Мысль разумная. Конечно, вокруг языка формируется еще и сообщество с собственной культурой, но я, например, не вижу особого смысла изучать 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.

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

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

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

Многопоточность

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

Брайан Гетц (Brian Goetz) “Thinking in Java”

Комментарии

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

“Дядюшка” Боб Мартин. “Чистый код”

Профессионализм

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

“Дядюшка” Боб Мартин. “Чистый Код”.

О взаимозаменяемости разработчиков

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

Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений

Об изменениях в ПО

Изменения в ПО неизбежны. Задача в том, чтобы уметь управлять ими.

Бертран Мейер “Объектно-ориентированное конструирование программных систем”.