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

Проект построен на связке tomcat,struts c java-сервером работающим с postgres. С веб-частью(tomcat) вроде все нормально. В самом сервере каша — где сам функционал по работе с БД.

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

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

уже есть(читал) по теме или близко:
— Рефакторинг. Фаулер
— Совершенный код. Стив Макконнелл
— Архитектура корпоративных программных приложений. Фаулер (хорошая книга)
— Еще какие-то одинаковые книги типа «Разработка корпор.приложений с помощью UML, J2EE» от
Гради Буча и пр.

Интересно не что-то общее из цикла типа RUP процессов разработки, а конкретно по архитектуре
и шаблонам развертывания, на примере конкретных коммерческих проектов.

Заранее спасибо за комментарии

Спешу поздравить сообщество с выходом полезного инструментария. Качаем с офсайта.
Из «нового»;) поддержка С#3 и LINQ.

Опыт «забавностей» становится всё больше и больше. Вот очередной случай маразма. Коротко суть:

Существует сайт, на котором нужно выводить одни и те же объекты с разными условиями выборки (по категории, по тегу, «захабареные» и т.п.) и разными отображениями (список, подробно и т.п.).

Некоторые индивиды, создают в каждом view замысловатую структуру из if-ов, и каждый раз она повторяется. Запомните:

1. Рефакторинг
2. Рефакторинг
3. Рефакторинг
4. view — это просто функция!

И так, по последнему пункту.

Навеяно топиком Каков должен быть, на Ваш взгляд, хороший framework?

Помнится, когда только начинал писать на PHP, устроился в молодую web-конторку. Там была своя простенькая CMS, которая отвечала только за обработку адреса (используя mod_rewrite), авторизацию и вызов модулей. Все было прекрасно, но стало надоедать постоянно копипастить модули. Через некоторое время добавил туда простенький хелпер для генерации форм, стало немного удобнее и понеслось…

На моей практике Ruby и Ruby on Rails оказались самым тяжелым в изучении сочетанием языка и фреймворка. Те люди, которые начинали программировать с C, C++ или Java, обнаружат в Ruby абсолютно другой (и более правильный!) подход к ОО-дизайну, а в Rails — много интересных решений, которые необходимо понять и осознать. И хотя изучение Ruby заняло у меня много времени (и я уверен, что еще очень многое предстоит узнать), я люблю эту технологию и не собираюсь возвращаться назад.

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

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

В этой статье мы пройдём с вами полный цикл от идеи, проектирования БД, написания PHP-Кода, и завершающей оптимизации. Постараюсь рассказать обо всем, как можно проще. Использовать для примеров буду PHP и Mysql. Заодно потренирую новичков :).

В этой статье я коснусь вопросов:
  1. Идея ACL
  2. Проектирование БД
  3. Нормализация БД
  4. Рефакторинг кода
  5. Оптимизация рабочего кода

Статья является ответом на Бинарное распределение прав доступа в CMS. Пока автором пишется практическая часть, я хочу предоставить мой вариант, который я использую довольно давно.
То, что я сейчас расскажу, похоже на ACL.

Предлагаю вниманию читателей перевод статьи "Programming Sucks! Or At Least, It Ought To", опубликованной в «The Daily WTF». Публикация рассказывает о том, как избыток профессионализма на практике мешает эффективности и предназначена скорее для опытных разработчиков, нежели для новичков.

За годы профессиональной деятельности у меня сложилось мнение, что по большей части программный код пишется «на коленке», «впопыхах», «под страхом дедлайна» и прочая, прочая. Рефакторится этот код не то чтобы даже не всегда — а практически никогда. Такой код впоследствии бывает тяжело воспринимать. Я не жалуюсь, я понимаю, что таково положение вещей и оно едва ли кардинальным образом поменяется.

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

+ JUG.ru
+ Рефакторинг

П.С. Как обычно можно скачать или подписаться на подкаст

Анти-паттерны — полная противоположность паттернам. Если паттерны проектирования —
это примеры практик хорошего программирования, то есть шаблоны решения определённых задач. То анти-паттерны — их полная противоположность, это — шаблоны ошибок, которые совершаются при решении различных задач. Частью практик хорошего программирования является именно избежание анти-паттернов. Не надо думать, что это такая непонятная теоретическая фигня — это конкретные проблемы, с которыми сталкивался практически каждый разработчик. Кто осведомлен, тот и вооружён! Рассмотрим же несколько расрпотранённых анти-паттернов в программировании.

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

А как делать этот самый рефакторинг, если даже неизвестно, с чего начать? Как осушить болото кода и не утонуть нем?

Конечно, идеальный вариант — считать рефакторинг одной из активности на проекте с самого его начала и выделять на него проектное время команды. В жизни, как ни странно, однако чаще всего оказывается, что предыдущий лид проекта не сильно озадачивался этим вопросом, предпочитая плыть по течению; возможно, он надеялся когда-нибудь сбагрить эту ношу менее удачливому лиду — пока проект еще не развалился; а может быть, просто не знал, что делать. Шеф, усё пропало!

Поюзал хабрапоиск и не нашёл упоминания о такой полезной штуке как DevExpress IDETools.

Что это такое и с чем это едят?

Это добротный набор плагинов для увеличения возможностей и интерактивности, а значит и потенциальной продуктивности работы в Visual Studio 2002/2003/2005/2008 (C#, VB, ASP, C++). Ни для кого не секрет, что среда разработки от Microsoft не является идеалом и часто уступает в удобстве продуктам других компаний и открытым проектам. Мне например до сих пор не понятно, почему куча проверенных и удобных фишечек известных мне из Java IDE таких как Jbuilder и IntelliJ до сих пор не появляются в Visual Studio.NET. Я погуглил. И нашёл сей замечательный коммерческий (об этом позже) продукт, который как раз и добавил то, чего мне не хватало для привычного удобства…

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

Один из примеров касается поддержки рефакторинга атрибутов.

Дочитал на днях сабжевую книжку. Вышла она еще в 2008 году (а предыдущее издание и того раньше), но мне она попалась только недавно. По идее, читать ее надо было бы после книги Фаулера «Рефакторинг. Улучшение существующего кода», на которую Кириевски постоянно ссылается, но до Фаулера я пока не добрался, хотя это и не особо затруднило чтение. Вторая книга, которую лучше всего прочитать заранее, это «Приемы объектно-ориентированного проектирования. Паттерны проектирования» банды четырех.

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

В продолжение или в поддержку поста Видео. Пример разработки приложения с помощью TDD. За основу мы взяли задачу — написать крестики-нолики с использованием TDD.

Отличие данного примера:
* больше теории про TDD
* немного отошли от стандартного цикла тест-код-рефакторинг
* пришлось ускорить сессию парного программирования в 5 раз (иначе получится двух часовая запись)
* запись в стерео, поэтому будет разговор в разных ушах

Все писалось налету, без подготовок. Чуть попозже была обнаружена одна значимая с точки зрения «клиента» ошибка. Её уже исправили в следующей записи про рефакторинг.

В данной статье я расскажу об одном из способов, позволяющих с наименьшими усилиями трансформировать программный код на C/C++ в код, написанный на C#. Впрочем, рассказанные принципы подойдут и для других пар языков. Хочу сразу оговориться, что способ не рассчитан на трансформацию кода, реализующего GUI.

Для чего это делать? К примеру, я таким образом портировал известную графическую библиотеку LibTiff (и LibJpeg заодно) на C#. Это позволило использовать наработки многих людей, создававших LibTiff, в моей программе вместе с библиотекой классов .NET Framework. Примеры кода в статье будут в основном из LibTiff и LibJpeg.

Обнаружил очень необычное тестовое задание, вот его текст:

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

Внимательно ознакомьтесь с кодом функции.

Какие потенциальные недочёты и неудобства вы в ней обнаружили?

Каким образом целесообразнее всего произвести рефакторинг или спроектировать код заново? (если это нужно, на ваш взгляд, сделайте это).»

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

Код проекта… В общем у меня осталось впечатление, что писал его недоученный студент… И это, немотря на то, что уже был сделан частичный рефакторинг другим программистом. Единственное, что радовало, то это то, что не использовался какой-либо фреймворк. Конечно, это вечно флеймовый вопрос: Иисус или Магомед? Быть или не Быть? Unix или Windows? Использовать или не Использовать? ИМХО, Моё мнение: фреймворки заточены под узкий круг типовых задач. Социальный проект — задача, как правило, не типовая… Но, в целом, мне проект показался интересным и я решил взяться за улучшение. На этом вступление можно закончить…

Наверно, про повышение производительности и тему highload не писал только ленивый WEB разработчик, знающий хоть что-то в этой области. Принципиально, что-то нового, в данной статье вы не найдёте. Основные идеи разработки highload проектов, были мною изложены в цикле статей HighLoad. Три кита.. Если вам интересно, как я увеличил производительность PHP проекта, используя NoSQL хранилище tarantool, то Добро пожаловать под кат.

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