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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Вопрос комментировать или не комментировать код для меня вполне понятен, стараюсь придерживаться правил:

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

А вот вопрос на каком языке комментировать мне не совсем ясен.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Damian Conway, co-designer of Perl 6

Хороший программный код определяется как минимум тремя признаками: однозначность, эффективность и сопровождаемость.

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

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

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

Не так давно потребовалось решать задачу массового обновления конфигурации устройств. Стандартная задача системного администрирования, если у вас в обслуживании больше одного устройства выполняющего однотипные функции. Для решения существуют как универсальные продукты, например из доступных redmine.nocproject.org, так и множество скриптов широко представленных на тематических форумах и порталах. Как раз на этот случай под рукой и должен был оказаться собственный написанный скрипт, но не оказался, поэтому учитывая что время для манёвров было, скрипт был написан заново, выполнен и положен на полочку, чтобы там в очередной раз затеряться.
Для написания был использован expect — expect.sourceforge.net, надстройка над TCL позволяющая обрабатывать и реагировать на ответы различных интерактивных консольных утилит, в частности, telnet. Учитывая что для TCL раньше писать не приходилось, код нуждался в повторном осмыслении. Ключевой момент скрипта это генератор списка IPv4 адресов для обработки, после внимательной оценки данный кусок программы удалось значительно, на мой взгляд, оптимизировать, по крайней мере сократить количество строк на треть и безболезненно добавить новый функционал. Причём все эти сокращения мало относились к специфики TCL, а касались принципиальных подходов к построению алгоритма в целом.
Я выделил этот код в отдельную утилиту, которую попытаюсь очень подробно разобрать далее по тексту — как было «до» и что стало «после», и почему не получилось написать сразу так как «после». Мне не всё в ней нравится до сих пор: смущают как алгоритмические проблемы так и проблемы TCL, например использование списков вместо массивов (что быстрее?, безопаснее?, идеологически вернее?), все сомнения тоже присутствуют в тексте, с надеждой на конструктивные комментарии.

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

Пустяк

Три дня и три ночи мастер не появлялся из своей кельи. На четвертый день монахи отправили послушника проведать его.

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

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

Привет, хабражители!

Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.

Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше…

С чего все началось

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

Задание и первая версия программы

Программа должна была использовать структуру из 5-ти полей:
Поле №1: номер записи;
Поле №2: название трека;
Поле №3: имя исполнителя;
Поле №4: время звучания;
Поле №5: год записи.
Это должна была быть консольная программа, все данные в которую вводятся с клавиатуры или с текстового файла (по желанию писавшего). Вводимые данные сохраняются в память компьютера или в файл соответственно. Также программа должна исполнять такие команды:
Поиск: по номеру, названию, исполнителю, времени и году записи а также вывод всех записей на экран;
Изменение данных: удаление, редактирование и добавление новых записей;
Редактирование: возможность изменения всех полей кроме номера записи.

После очередного спора внутри нашей компании решили вынести холивар на хабр.

Собственно, какой из вариантов форматирования кода предпочитаете использовать?

Выравниваю код

foo       = 'bar'
habrahabr = 'Hello, world!'

Не выравниваю код

foo = 'bar'
habrahabr = 'Hello, world!'

В примере фигурирует присваивание значений, но тоже самое относится к ассоциативным массивам, словарям и т.п.

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

— Вася, так может ты сам поработаешь? Уже десять человек уволили… Понимаю, специалистов в наше время не сыскать, понимаю, одному работать трудно, но может всё-таки попробуешь, а?
— Иваныч, я бы с радостью, но кто тогда мелкими делами будет заниматься? Я пишу важнейшие вещи, а отвлекаться на пустяки всегда очень трудно. Найди мне хорошего человека, Иваныч! Я верю, однажды попадётся тот самый, который сможет работать как я, а то и лучше!
— Да что ты, Вася, я уже убедился — лучше тебя никого мне не найти. Я постараюсь, Вась, постараюсь!
Директор похлопал его по плечу и вышел из кабинета. А Вася нажал Alt+Tab и продолжил читать ленту.

Доброго времени суток. Вот и пришло время для публикации второй части так понравившегося многим хабровчанам перевода стайл гайда для языка Python от компании Google, (первая часть бережно хранится хабром). Теперь мы коснемся напрямую форматирования исходного кода на языке программирования Python. Как известно, чистота — залог здоровья, а чистота программного кода — залог уважения коллег и (в идеале) поощрения от кого-нибудь свыше. Вообще, Python сам по себе является хорошо читаемым языком, и даже синтаксис данного языка призывает к порядку в коде (и, как следствие — в голове). Но каждый из нас сам себе документатор и сам себе творец оформления. А как уже говорилось однажды — ко мнению авторитетных товарищей нельзя не прислушиваться. Итак, вторая часть Google Python Style Guide — Python Style Rules ждет Вас под катом. И pdf тут как тут.

По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
Дядюшка Боб

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

• С. Макконнелл, «Совершенный код. Мастер-класс»
• Р. Мартин, «Чистый код. Создание, анализ и рефакторинг»
• Д. Босуэлл, Т. Фаучер, «Читаемый код, или Программирование как искусство»

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

Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно. После чтения различных холиваров на тему правильных подходов к написанию кода мне в глаза бросилась одна тенденция: каждый пытается применить означенные подходы не в целом к программированию, а только к своему опыту разработки, к своим проектам. Многие не осознают, что хорошие практики — это не абсолютные правила, которые должны строго соблюдаться в 100% сценариев, это лишь советы о том, как следовало бы поступать в большинстве ситуаций. На каждую хорошую практику всегда можно придумать несколько дюжин примеров, в которых она работать не будет. Но это вовсе не означает, что хорошая практика не такая уж и хорошая, просто её применили не к месту.

В качестве реакции на мой предыдущий пост о защитном программировании, один из моих читателей прислал мне такой вопрос:

[Один] очень известный сценарий защитного программирования встречается, когда входным параметром является

IEnumerable




public class Publisher
{
    public Publisher(IEnumerable<Subscriber> subscribers)
    {
        // defensive copy -> good or bad?
        this.subscribers = subscribers.ToArray();
    }
    //  …
}

Хороший код или плохой? Лично для меня хороший код обладает следующими качествами:

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

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

Почему именно эти критерии? Сразу оговорюсь, речь сейчас идет о разработке ПО для бизнеса (enterprise application). Критерии оценки кода для систем реального времени, самолетов, систем жизнеобеспечения и МКС отличаются.

Зачастую, создавая less-файлы (что, впрочем, касается и других препроцессоров css), мы гонимся за красотой и элегантностью less-кода, когда как частенько забываем про скомпилированный css-код. Иногда это влечет за собой критичные последствия, когда объем конечного css возрастает в раз, а код становится совершенно нечитаемым.