Прочел последний топик про Singleton в этой группе «Совершенный код» и вспомнилось мне недавнее сообщение в группе Google comp.lang.c++.moderated про совершенную реализацию thread safe Singleton.
Советую всем любителям C++ прочитать это сообщение и вникнуть в код в нем.

По-моему это своего рода шедевр про то, как можно стремлением к совершенству убить красоту и понятность кода и превратить его в совершенный и нечитаемый фарш.
Мое мнение, что thread safe для Singleton не нужен, т.к. проблему одновременной инициализации static переменной в Meyers Singleton можно решить более простыми способами.

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

Есть возражения или мысли на этот счет?

В этой статье я хочу затронуть тему одного из наиболее распространенных паттернов объектно-ориентированного программирования – Singleton. Но в данном случае я не буду описывать преимущества/недостатки и области применения этого паттерна, а попытаюсь изложить свой взгляд на его имплементацию в JAVA.

Общие сведения
Паттерн Singleton гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.

Нашествие многоядерных процессоров и повсеместный параллелизм наступили как-то неожиданно для софтверной индустрии (компания Intel довольно резко переметнулась на многоядерные проекты в 2004 году). В результате, современные средства разработки программного обеспечения оказались совершенно не приспособлены к параллельной архитектуре ПК. А ведь практически все современные процессоры являются многоядерными, и количество этих ядер растёт у них в геометрической прогрессии: 4, 8, 16 и т.д. Если программы не научатся в самое ближайшее время эффективно использовать параллелизм, то весь технический прогресс в процессоростроении пойдёт насмарку.

Фактически, это новая чаша Грааля для компаний-разработчиков: кто первым сможет разработать компиляторы для эффективного распараллеливания программ? Здесь начинается настоящая золотая лихорадка, пишет NY Times.

Месяц назад Intel и Microsoft объявили о программе исследований в этом направлении. Они финансируют работу группы в Университете Калифорнии в Беркли. Над той же проблемой бьются исследователи из Университета Иллинойса. Сейчас стало известно, что ещё один — третий — альянс «золотоискателей» при Стенфорде (Pervasive Parallelism Lab) сформировали корпорации Sun Microsystems, AMD, Nvidia, IBM, HP и та же Intel.

Боритесь со сложностью

Как известно, мозг человека может одновременно рассматривать 7±2 элемента. Поэтому очень важно стремиться к снижению сложности ПО. Вот некоторые конкретные рекомендации:

• Разделите систему на подсистемы на уровне архитектуры, чтобы концентрироваться в каждый конкретный момент времени на меньшей части системы.
• Тщательно определяйте интерфейсы классов, чтобы можно было игнорировать
  внутреннее устройство классов.
• Поддерживайте абстракцию, формируемую интерфейсом класса, чтобы не
  запоминать ненужных деталей.
• Избегайте глобальных данных, потому что их использование значительно увеличивает процент кода, который нужно удерживать в уме в любой момент
  времени.
• Избегайте глубоких иерархий наследования, потому что они предъявляют
  высокие требования к интеллекту.

«Чтобы стать экспертом в практической или научной области, нужны огромный труд и долгое время. Если человек добросовестно трудится каждый час рабочего дня, когда-нибудь он проснется одним из самых компетенткых специалистов своего поколения.»
Ульям Джеймс

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

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

В этой статье попытаемся ответить на вопрос, какими же качествами должен обладать человек для того, чтобы писать совершенный код.

«Ясно, что на некотором уровне комментарии должны быть полезны. Думать иначе означало бы полагать, что понятность программы не зависит от того, сколько информации о ней уже известно читающему программу человеку. Б. Шейл.»
Действующие лица:
ФРАСИМАХ Неопытный пурист теории, который верит всему, что читает.
КАЛЛИКЛ Закаленный в боях представитель старой школы — «настоящий»
программист.
ГЛАВКОН Молодой, самоуверенный, энергичный программист.
ИСМЕНА Опытная разработчица, уставшая от громких обещаний и просто
желающая найти несколько работающих методик.
СОКРАТ Мудрый опытный программист.

Мизансцена:
Завершение ежедневного собрания группы
— Желает ли кто-то обсудить еще что-нибудь, прежде чем мы вернемся к работе? — спрашивает Сократ.
— Я хочу предложить стандарт комментирования для наших проектов, — говорит расимах. — Некоторые наши программисты почти не комментируют свой код, а всем известно, что код без комментариев нечитаем.
— Ты, должно быть, еще менее опытен, чем я думал, — отвечает Калликл. — Комментарии — это академическая панацея, и любому, кто писал реальные программы, известно, что комментарии затрудняют чтение кода, а не облегчают. Естественный язык менее точен, чем Java или Visual Basic, и страдает от избыточности, тогда как операторы языков программирования лаконичны и попадают в самое яблочко. Если кто-то не может написать ясный код, разве ему удастся написать ясные комментарии? Кроме того, комментарии устаревают при изменениях кода.
Доверяя устаревшим комментариям, ты сам себе роешь яму.

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

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

Конструирование ПО

Что такое конструирование ПО?

Разработка ПО — непростой процесс, который может включать множество компонентов. Вот какие составляющие разработки ПО определили ученые за последние 25 лет:
— определение проблемы;
— выработка требований;
— создание плана конструирования;
— разработка архитектуры ПО, или высокоуровневое проектирование;
— детальное проектирование;
— кодирование и отладка;
— блочное тестирование;
— интеграционное тестирование;
— интеграция;
— тестирование системы;
— корректирующее сопровождение.

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

Создал блог после опроса, готовлю статьи-конспекты «Совершенного кода» Макконнелла.

В блоге приветствуются любые статьи, которые так или иначе связаны с тематикой, затрагиваемой в книге.

Присоединяйтесь, читайте, пишите!