Цитата: Хаак

Бывший MVP (Most Valuable Professional – Самый Ценный Специалист) Microsoft Фил Хаак о повторных использованиях и обобщениях при разработке ПО

«Избегайте преждевременного обобщения», советует Хаак. «Не создавайте систему способную предсказать любое изменение. Пусть она будет достаточно гибкой для внесения изменений».

Чтобы определить, когда требуется обобщение, Хаак использует Правило Трех: «Когда вы в первый раз увидите, что что-либо может повторяться, не обобщайте это. В следующий раз сделайте все аналогичным способом, возможно даже при помощи копипастинга, но только не обобщайте. В третий раз хорошенько подумайте, как это можно обобщить».

Updated: Знакомство с Vim

По просьбе читателей поправил текст старой статьи "Знакомство с Vim. Настройки". Добавлено краткое описание режимов, а сам контент сделан более последовательным.

Еще раз об MDA

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

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

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

Как сделать merge в cleartool

В ClearCase сделать слияние (merge) для файлов с разных веток довольно просто. Проблемы начинаются, если на сливаемых ветках добавлялись или удалялись файлы. Оказывается, слияние директорий в ClearCase — задача непростая.

Выполнить слияние двух веток можно следующей командой:

cleartool findmerge . -fversion <version/label> -co -nc -merge -gmerge

Эта команда выполнит слияние с ветки version или label на текущую ветку для всех файлов, содержащих изменения. Ключ -gmerge удобно использовать при работе в графической среде — при возникновении конфликтов cleartool запустит визуальный инструмент для разрешения конфликтов вручную. Но при работе, например, по SSH, указывать этот ключ смысла не имеет; в этом случае используется консольный инструмент разрешения конфликтов. Тем, кто пользуется консольным, можно только посочувствовать.

Пример. У меня в текущей папке есть файлы file1, file2 и file3. На ветке /main/mybranch1 выполнены изменения для файлов file1 и file3. Чтобы слить изменения с ветки /main/mybranch1 на текущую ветку, мне необходимо выполнить команду:

cleartool findmerge . -fversion /main/mybranch1/LATEST -co -nc -merge -gmerge

В результате выполнения файлы file1 и file3 будут вычекнуты (checkout) на текущую ветку и модифицированы в соответствии с изменениями на ветке /main/mybranch1. Мне останется лишь выполнить checkin для измененных файлов. Файл file2 останется нетронутым.

Но вот, предположим, что на ветке /main/mybranch1 добавлен еще один файл — file4. Выполнение findmerge никак не коснется этого файла, потому что на текущей ветке этого файла нет. Значит, нужно сначала сделать merge для директории.

Описание команды merge говорит о том, что слияние директорий происходит в три шага:

1. убедиться, что на "той" ветке нет вычекнутых элементов;
2. вычекнуть директорию в текущей ветке;
3. выполнить команду cleartool merge для директории.

Только после этого можно будет безболезненно выполнить cleartool findmerge.

Итак, синхронизируем текщую директорию с веткой /main/mybranch1:

ct co -nc .
ct merge -to ./ ./@@/main/mybranch1/LATEST
  Added file file4 to ./.

Теперь можно зачекать измененную директорию (а можно сделать это потом). И наконец-то можно выполнить долгожданный findmerge:

cleartool findmerge . -fversion /main/mybranch1/LATEST -co -nc -merge -gmerge

Будет выполнено слияние для файлов file1, file3 и file4. Теперь нужно внести в репозиторий результаты слияния веток. Заносим всё сразу — зачем мелочиться? :)

ct ci -c "Merged from /main/mybranch1." `ct lsco -r -cview -short`

Ух. Кажется, несложно. Но когда у нас нужно синхронизировать не одну директорию, а, скажем, десяток? Все эти действия превращаются в пытку :( К счастью, действия, необходимые для синхронизации директорий, довольно легко автоматизировать каким-нибудь простеньким скриптом. Что я и сделаю на досуге :)

Цитата: Papadimoulis

Alex Papadimoulis о разработке корпоративного ПО (" Avoiding Development Disasters")

Единственный способ избежать (...) провалов, быть реалистом насчет успеха. И если взглянуть на вещи здраво, то корпоративное ПО обязано проработать минимум 15 лет. Все, что не может продержаться это время, должно считаться неудачным.

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

Грамотно спроектированная система, созданная на протяжении последних восьми–десяти лет не требует масштабной модернизации.

Использование OSS в своих разработках

В очередной раз пересортировывал гигабайты статей и заметок, собранных на моем жестком диске, и наткнулся на текстовый файл с некоторыми правилами использования Open Source Software в своих разработках. Думаю, здесь этой заметке самое место.

Когда ваш продукт обязан быть Open Source

- если вы изменяли чужой GPL-код или исправляли в нем ошибки;
- если расширяли функциональность GPL-кода добавляя свой код;
- копировали фрагменты кода из GPL-продуктов в свой код;
- использовали заголовочные файлы из GPL-кода;
- статическая линковка вашего кода с GPL-кодом или LGPL;
- динамическая линковка с GPL-библиотеками или LGPL;


Когда ваш продукт не обязан быть Open Source

- при использовании GCC для компиляции вашего кода;
- при использовании открытых стандартов (HTTP, TCP/IP, SOAP, POSIX и т. д.);
- при взаимодействии вашей программы с OSS с помощью командной строки, пайпов или сокетов;
- при использовании архитектуры ПО, изолированной от OSS.

MDA: ловушка для разработчиков

Основной смысл MDA (Model Driven Architecture) заключается в том, чтобы вся разработка программного обеспечения выполнялась на уровне модели. То есть, грубо говоря, разработчик вносит все изменения в продукт посредством рисования квадратиков, стрелочек и прочих графических элементов. А дальнейшее преобразование из схемы в конкретную реализацию для конкретной платформы должно выполняться некими автоматизированными инструментами практически без вмешательства человека.

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

Частично эта проблема решается путем спекуляции терминами типа "самодокументирующийся код", хотя на самом деле, самодокументирующийся код — это миф. Однако, я признаю, что с помощью жесткого(!) контроля над соблюдением стандартов кодирования, возможно попытаться свести к минимуму проблемы документирования изменений.

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

Теперь вернемся к MDA. Как правило, для моделирования структуры и поведения ПО обычно используется язык UML или подобные ему. На текущий момент существует довольно много инструментов, которые позволяют сгенерировать из UML-модели некий код на каком-нибудь языке программирования. И уже довольно много команд используют эти инструменты для разработки своего ПО. Это, конечно, еще ненастоящий MDA, но суть не в этом.

Суть в том, что при использовании UML-моделей проблема отсутствия документирования изменений никуда не уходит. Но в отличие от текстовых файлов, сравнение двух UML-моделей превращается в нетривиальную задачу.

Да, некоторые UML-инструменты позволяют выполнять сравнение моделей и представлять результат в каком-то читаемом виде. Однако, каждый производитель пытается сделать это своим неповторимым способом, и на сегодняшний день работоспособность, мягко говоря, оставляет желать лучшего. И что, на мой взгляд, более важно, совместимость UML-инструментов различных производителей практически равна нулю. Даже стандарт XMI каждый производитель умудряется трактовать по-своему, хотя сама цель существования стандарта — облегчить импорт/экпорт UML-моделей между инструментами различных производителей.

В результате всего этого, проекты, перешедшие на использование таких инструментов, но не сменившие политику документирования изменений, как правило, погружаются в хаос изменений, потому что выяснить, как выглядела модель три версии назад, становится возможным только визуальным сравнением схем. Обычно внесениями изменений в модель занимается один человек — архитектор, — и поэтому контроль изменений происходит у него в голове. Критический случай — когда этот человек покидает проект. Всё. Конец фильма. Заключительные титры.

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

Двойная загрузка grub

После установки Linux с загрузчиком grub захотелось сделать возможность двойной загрузки — Linux и Windows XP с разных физических дисков (hd0 и hd1, соответственно). В доках по установке Ubuntu и Gentoo был обнаружен пример текста grub.conf для загрузки Windows с одного из логических разделов:

title=Windows XP
rootnoverify (hd0,5)
makeactive
chainloader +1

Попытки прикрутить к grub такой вариант успехом не увенчались. Как выяснилось, причина в том, что операционные системы находятся на разных физических дисках. Для того, чтобы все работало корректно нужно добавить вызовы map в код загрузки:

title=Windows XP
rootnoverify (hd1,0)
makeactive
map (hd0,0) (hd1,0)
map (hd1,0) (hd0,0)
chainloader +1

Теперь все работает правильно :) Кстати, в процессе также обнаружил, что в Ubuntu 7, в отличие от Gentoo, можно вызывать root (hd1,0) вместо rootnoverify (hd1,0).

Восхитительное чтиво

Сегодня ковырялся в Сети в поисках наилучшего перевода на русский язык сказки "Алиса в Стране Чудес". И совершенно случайно наткнулся на незнакомый мне доселе текст "Восемь или девять мудрых слов о том, как писать письма". О, какое удовольствие я получил от прочтения этой небольшой, но очень интересной статьи!.. :)

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

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

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

Я советую всем, кто еще не знаком с этим текстом, обязательно прочитать. Хотя бы как художественное произведение :)

Искусство интервью от gamedeff

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

Читать статью на blog.gamedeff.com

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