воскресенье, 29 января 2012 г.

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

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

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

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

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

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

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

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

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

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

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

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

воскресенье, 22 января 2012 г.

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

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

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

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

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

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

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

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

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

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

вторник, 17 января 2012 г.

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

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

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

Алан Перлис

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

понедельник, 16 января 2012 г.

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

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

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

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

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

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