Рассуждения на тему code reuse возникают в любом более-менее большом проекте, начинающем разваливаться под собственной тяжестью. Вдруг неожиданно выясняется, что в программе есть десять мест, работающие практически идентично, но не оформленные в одну нормальную функцию/класс, потому что сначала по-быстрому скопипастили, потом сделать нормально было некогда, потом все забыли об этом фронте работ как о страшном сне и так далее. Все эти отмазки и так хорошо всем известны, лишний раз их перечислять не требуется. Проблемы начинаются в момент внесения изменений в дублирующиеся участки кода. Десять раз опрометчиво нажали ctrl-v, значит нужно менять в десяти разных местах. В двух местах из десяти забыли/не доглядели/накосячили. В итоге получили два возврата от тестировщиков (дай бог от тестировщиков, а не от клиентов, или, ещё хуже, принимающей организации). Как правило в ваших программах будет таких мест гораздо больше. Помнится рефакторил одну подсистему в некой программе. После рефакторинга количество кода уменьшилось в 100 раз. Для тех кто не понял с первого раза — на два порядка. Матёрый копипастер прогу ваял.

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

    Решений два — одно простое, другое правильное.

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

    Как только проблема плохого code reuse становится очевидна даже топ-менеджерам, сразу начинаются поиски решений. Он традиционно ведётся в ключе «чтобы такого сделать, чтобы ничего не делать, но всё само собой разрешилось». У особо пытливых граждан даже появляется иллюзия, что такая изначально порочная цель достижима. Достигать её предлагается различными модными шаманствами. Типа тимбилдинга, частыми совещаниями и вебдванольными тулзами вроде вики или прочего. Всё это имеет кратковременный эффект, который как правило заключается в том что несколько недоумков сцепятся во время кофедрейка, выясняя чья реализация вектора лучше. Потом всё возвращается на круги своя, пока высокое начальство не начнёт опять кровь сворачивать.

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

    После двух альф вышла первая бэта Джумлы 1.6 Из приятных отличий стоит отметить облагороженный код Видов. Раньше это была мешанина из PHP кода, HTML'я и SQL запросов, теперь всё гораздо лучше. Хотя от пэхэпэшного кода в шаблонах они так и не ушли. Видимо не особо и хотели. Также продолжает развиваться MVC фреймворк. Это тоже хорошо. Однако, в версии 1.6 наличествует обновлённая система доступов. Судя по беглому обзору, корявое убожество из 1.5 к версии 1.6 стало ещё корявее и ещё более убогим. В новой системе доступов всё настолько непросто, что разработчики в своём блоге рисуют какие-то картинки с зелёными шариками, рассуждают о наследовании доступов. Но от этого становится совсем грустно. Ну и под занавес - раз обновился MVC фреймворк, значит могут быть проблемы с совместимостью. Прощайте старые наработки.
    У хостинга опенсорсных приложений sourceforge.net есть одна интересная особенность – глобальный рейтинг всех проектов обновляется раз в месяц аккурат в ночь на первое число. Это приводит к тому, что толпа девелоперов ломится первого числа на данный сайт посмотреть, на каком месте оказался их проект, кто из аутсайдеров вырвался вперёд, а кто наоборот оказался за бортом. Это, ясное дело, приводит к существенному всплеску закачек. Как правило, активность первого числа по закачкам примерно равна среднестатистическому релизу. Но не в этот раз. Первое число прошло вполне себе тихо, даже наблюдалось некоторое снижение количества закачек десять-двенадцать, но второго числа закачек набралось аж 159. Это значит, что за один день закачек было в два раза больше чем за самый удачный релиз за всю историю этого проекта. Это значит, что за один день было скачано в полтора раза больше чем полгода назад выкачивали за целый месяц. All hail Megatron!!!

    Непонятным остался только один факт, почему этого всплеска не было первого числа? Неужели народ по всему миру был настолько занят днём дурака?

    В своё время случилась одна любопытная дискуссия с моим сотрудником. Подходит он ко мне и говорит, что типа наша БД не в первой нормальной форме. Не в какой-нибудь хитрой четвёртой или в пятой, которая практически нафиг никому не нужна. А именно первой. Т.е. подобное заявление равнозначно наезду, что, мол, структура БД полное говно, а вы, Алексей, криворукий идиот. «Нифига себе» - подумал, я. Как это такое может быть? Почти полтора десятка лет в программировании, плюс здравым смыслом, вроде, не обделён, и тут вот такое. Можно было конечно завершить недоразумение фразой «я – начальник, ты – дурак», но как-то самому стало интересно, в чём же дело. Поэтому деликатно так поинтересовался, а на чем основано данное утверждение? Сотрудник бодро открыл определение в Википедии и походу уже приготовился праздновать победу. Я, признаться, никогда не мог по памяти назвать ни одну из нормальных форм, а «рисовал» структуру БД просто на основании здравого смысла. Потом постфактум выяснялось, что базы спроектированы в полном соответствии с этими самыми формами. Так и жил. А тут, стало быть, по определению выходило совсем не так как подсказывало программерское чутьё. Поэтому с любопытством начал изучать определение. Каково же было моё удивление, что как раз по этому определению выходило, что с базой полный порядок! Я, конечно, и раньше находил формулировки отечественного сегмента Википедии чрезмерно заумными, и поэтому допускал, что со средним умом лучше их не читать. Но тут произошло что-то совсем вопиющее – мой сотрудник, прочитав определение, сделал какой-то абсолютно нелогичный вывод и даже не удосужился проверить свои выводы. А наоборот взял свою свежепридуманную глупость и решил с её помощью поучить народ. Я говорил, что опенсорс до добра не доведёт, да и другие умные люди тоже говорили. Но я не знал, что армегедец наступит так скоро. Ну да бог с этой Википедией, можно ведь и самому определения нормальных форм набросать.

    Ключ - поле записи, чьё значение уникально для всего набора записей, имеет значение отличное от NULL и неизменно на протяжении всей жизни записи.

    Первая нормальная форма – любое поле любой записи хранит только одно значение.

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

    Вторая нормальная форма – БД находится в первой нормальной форме и любое неключевое поле полностью зависит от ключа.

    Например, у нас есть запись с полями (Идентификатор, Название CD-Диска, Название группы), где ключом является поле «Идентификатор». При этом, очевидно, что поле «Название группы» зависит не только от «Идентификатора» но и от поля «Название CD-Диска». Поэтому такая БД не находится во второй нормальной форме.

    Третья нормальная форма – БД находится во второй нормальной форме и нет неключевых полей зависящих от значения других неключевых полей.

    Например, у нас в записи хранятся код региона и его название (помимо самих полей с информацией о CD-диске). Понятно, что название региона зависит от кода, и наоборот, поэтому такая БД не будет находиться в третьей нормальной фоме.

    PS Ссылки по теме:
    Нормальные формы баз данных ч.2

    Сергей Белоусов, исполнительный директор компании Parallels, в своем недавнем интервью немецкому журналу «t3n» в прямом смысле смешал Open Source не с самыми лучшими материями сего мира.

    Отвечая на вопрос издания о Linux и Open Source, Сергей заявил, что «Open Source — это большая куча дерьма», и засмеялся, после чего добавил: «Я ненавижу Open Source». Раскрывая свою позицию, глава Parallels сослался на детство, которое прошло во времена коммунизма и оставило не самые приятные ощущения от общественных работ, которые схожи по своей сути с развитием Open Source-продуктов энтузиастами, производящими изменения в соответствии со своими личными предпочтениями.

    Утащено отсюда. Надо ли говорить что я подобными откровениями блистал аж в 2008 году в статье Open Source убьёт мир. А тут вот и представители бизнеса подтянулись. Смело срывают покровы. Осталось дождаться, когда Red Hat откроет всем страшную правду.

    Недавно с любопытством заметил, что 2007 офис, в котором есть дохрена всего, работает быстрее чем 3.0.1 опенофис, в котором нихрена нету. Есть мнение, что Майкрософту надо раскрыть исходники своего офиса, тогда с производительностью будет полный порядок и он сразу же станет прекрасен аки Линукс )).