Рак формы

Забавно прокомментировал Лебедев форму какого-то приложения на бизнес-линче:

Это — рак формы, обычное заболевание программистов.
Часто проходит после знакомства с современной операционкой от Эппл и чтения документа «Эппл хьюман интерфейс гайдлайнc»

Хорошо, что он наших форм не видел. =)

WordCloud: мы облачаем

Не удержался и поучаствовал в модном развлечении - WordCloud:

Вперед, товарищи!

Я рассказываю о преимуществах и перспективах scrum на второй ретроспективе.

Code review

Заметка: Статья о code review на хабре.
Кажется, нам есть чему поучиться.

Подзаголовок

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

Технический долг или Право на выбор

Интересная статья о техническом долге и рефакторинге.
Комментарии тоже интересные.

Лучшие практики инженерии создания ПО

Учебный центр Luxoft проводит очередной интересный семинар - "Лучшие практики инженерии создания ПО".

Семинар является вводным в методологию RUP - Rational Unified Process.
Рассматриваются лучшие практики, используемые в проектах по разработке программного обеспечения.
Дается введение в итеративную разработку ПО как мощное средство снижения рисков проекта.

Про итеративную разработку мы и так в курсе, про практики интересно было бы послушать. Но самое главное, что будет рассматриваться RUP. Давно хотел познакомиться с этим зверем и даже читал про OpenUP, но все мельком и мимоходом. А тут такая возможность!

Присоединяйтесь!

1C, ООП, DDD и дальше

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

Вот недавно я прочел (если честно, еще дочитываю) очень увлекательную книжку с умным названием "Приемы объектно-ориентированного проектирования" за авторством знаменитой "Gang of Four". В книге идет речь о шаблонах проектирования. Кстати, рекомендую от всей души, если кто еще не читал. Сложно представить себе, что ООП можно изучать без таких простых и наглядных примеров использования, какие приводятся в этой книге. Честное слово, я бы ввел ее в школьную программу, может, и не в школьную, но в университетскую точно. А пытливому уму везде найдется польза и применение. Хоть 1С и не поддерживает ООП в полной мере, но и нашему брату, 1С-нику, крупицу истины из нее почерпнуть не грех.

А теперь давайте про 1С и ООП. Когда-то (до 19 октября 2005) Википедия про язык 1С утверждала, что:

Данный язык является интерпретируемым объектно-ориентированным языком высокого уровня.

(На самом деле это, конечно же, не так, но об этом позже.)
И добавляла, что:

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

Если кто не понял, поясню: есть класс "Документы", от него можно создавать дочерние классы, вроде "Приходная накладная" или "Закрытие месяца", эти классы в свою очередь позволяют создавать конкретные экземпляры классов (объекты) - конкретные документы (ага, с номером и датой), которыми и управляет пользователь в режиме "Предприятие".
Не вполне ООП, но достаточно близко. Тут и один уровень наследования классов и разница между классом и экземпляром. Ну а про статические методы я уже недавно писал. Как говорили древние, "для умного достаточно", но недостаточно для программиста, у которого душа просится в полет, а руки тянутся к клавиатуре. Голова в этом всем никак не участвует, поэтому продолжаем мечтать.

А вот если бы!.. А вот если бы 1С была как Axapta или C++, например. Уж там-то наверняка полноценно поддерживается ООП, можно и шаблонов навертеть, объектную модель отгрохать - закачаешься. Только вот беда, у C++ порог вхождения выше. С 1С все просто: открыл конфигуратор - и ты уж программист. Сначала форму печатную поправил, потом расчет суммы подкорректировал, и пошло-поехало (ботинками не кидайтесь, пожалуйста, сам так начинал и еще кучу народа знаю такого же). А открой проект на C++ (сиплю-сиплю, а ничего не выходит) - чего-то не там переставил, и все - не компилируется в лучшем случае. Сложно и дорого. Потому-то 1С так мил сердцу мелкого бизнесмена, что не нужны заоблачные бюджеты на разработку, да и типовых конфигураций пруд пруди. Ну и нам, 1С-никам, заодно тепло и сухо. Но объектов хочется.

И вот недавно сама 1С подкинула интересную мысль. Помните релиз 8.2.14? Там, где общие реквизиты вернули. Так вот, что такое общие реквизиты с точки зрения ООП? Не что иное, как обычные свойства класса "Документы". Класс документы-то всеми подклассами наследуется, и свойства, стало быть, тоже. А что если разрешить не один уровень наследования от документов, а несколько? Вот это было бы здорово. Захожу я в конфигуратор (1Сv9, конечно же!), добавляю в документы группу "Товарные документы". Сразу в эту группу документов реквизиты добавляю, типа "Контрагент", "Опустил", "Принял" и ТЧ "Товары" с такими реквизитами - "Номенклатура", "Количество", "Цена". И тут же в модуле группы документов пишу код, что, мол, если количество поменялось - сумму пересчитать, если сумма - цену. Ну, вы все эти процедуры обработки реквизитов и сами по сто раз писали, чего я рассказываю. А потом уже в группе документов "Товарные документы" создаю "Приходную накладную", "Расходную накладную", ну и все, что положено. И у них все эти реквизиты и ТЧ уже есть - унаследовались от товарных документов. Просто волшебство и сплошной "ахалай-махалай" получается. Конечно, кое-где добавляю особенностей для каждого класса, реквизитов специфичных, но каркас работает общий. Удобно, черт возьми. Надо разрядность цены в товарных документах поменять - р-р-р-раз! - и поменял одним махом. Реквизит-то один. И код по обработке один. Так, по мелочи, потом пройтись останется. Ну, естественно, кроме группы "Товарные документы" делаю группу "Кассовые документы" из общего корня - "Документы". Там свои особенности, но общего тоже много. И так далее, и так далее.
Про то, что похожие фокусы со справочниками и другими объектами работают, говорить не буду: сами спокойно дофантазируете, если хотите.
Тут же, кстати, и общие модули немного разгрузятся. Есть модуль группы документов, там и обработки для этой группы документов можно разместить. Например, всякие поиски цен, обработки подборов и прочее. Оно ж все, по логике, к товарным документам относится, верно ведь? Вот пусть в модуле группы "Товарные документы" и лежит, чтобы долго не искать.
И подсистемы тоже как-то оборачиваются в новом свете. Теперь те же документы объединяются в группы с иерархией намного лучше, чем это делали подсистемы. Вот есть группа "Кассовые документы", и все, что относится к кассе, находится в ней. И это обоснованно с точки зрения наследования и структуры кода. Хотя с отношением к нескольким подсистемам проблема получается, но, наверное, и тут какое-то решение есть.
Конечно, это еще не полноценное ООП, но хороший шаг вперед. Или назад?

Давайте посмотрим, что Википедия сейчас пишет про 1С:

Данный язык является предварительно компилируемым предметно-ориентированным языком высокого уровня.

Ключевое слово тут "икра" предметно-ориентированным. На самом деле это очень важно. Именно предметно-ориентированность позволяет быть языку 1С "заумью с человеческим лицом". Когда такие понятия, как "документ" или "проводка", встроены в само ядро платформы, то всякие надуманные абстракции вроде классов и подклассов тихо бледнеют и не отсвечивают. В нормальных "больших" языках программирования тоже хотят так уметь. Даже целое направление придумали - DDD (русская Википедия, извините, об этом еще не в курсе). Так не испортим ли мы 1С, если начнем туда тянуть все эти наследования? Не знаю. Если бы я был разработчиком платформы (во куда хватил! но мы ж тут помечтать договорились, да?), я бы по-тихому все-таки протащил бы такую доменную сущность, как группы документов, не особо афишируя, что оно все торчит из ООП. В принципе, в рамках доменной модели (не путать с объектной) понятие "группа документов" вполне интуитивно понятно, ценно и достаточно функционально. Так что катастрофы тут не предвидится. Катастрофа предвидится, когда мы заговорим о множественном наследовании, но тут могу заметить, что это:

...концепция, поддерживаемая частью объектно-ориентированных языков программирования...

Частью! Так что нам тут бояться нечего, тут еще сами апологеты ООП до конца не определились.
Ну а не хочется вам с этими новомодными "группами документов" разбираться да все конфигурации переписывать - пожалуйста. Не наследуйте от групп, наследуйте от "Документы". И для вас как будто и ничего не поменялось. Вот вам, кстати, обратная совместимость.
Да... Много еще чего можно хорошего намечтать...

Оставляю вас за этим занятием и хочу пожелать вам хорошего дня и хорошего кода.

P.S.: Сильно не ругайте, если кто чем недоволен, о грубых ляпах пишите - буду исправляться.

Публикация на Infostart

Пиши код, блеать!

Манифест на http://пиши-код-блять.рф/

P.S.: В каждой шутке есть доля шутки, а остальное чистая правда.
Однако, слишком сильно увлекаться методологиями это вредно.

Как отдыхать?

Известно, что для того, чтобы создавать "продуктивный высококачественный код" (см. Галеры) очень важно быть в тонусе. А чтобы быть в тонусе нужно хорошо отдыхать. Собственно, цикл вебинаров о том как правильно отдыхать:

Семинар будет состоять из 4 бесплатных вебинаров. Программа семинара:
13 июня – Почему возникает усталость и что такое отдых. Как узнать от чего ты устал и от чего ты хочешь отдохнуть на самом деле.
14 июня – Как определить, что будет являться отдыхом в вашем случае. Как найти способ отдохнуть.
15 июня – Оценка вариантов. Всякий ли отдых полезен?
16 июня – Как свести к минимуму возможные «отклонения от курса». Что делать с несбывшимися надеждами. Как на отдыхе помочь себе отдохнуть.

Мне кажется, должно быть интересно. Особенно нам, програмерам (ничего не делал и устал, ага).

Подробности в ЖЖ и на сайте.

Введение в SCRUM

Алексей Кривицкий выложил неплохую презентацию "Введения в scrum". Если вы рассказываете новой команде о scrum, может пригодиться.

Redistributable intro To Scrum, Russian

View more presentations from krivitsky

Новые материалы по 1С УПП

Фарит Насипов выложил 14 часов видео:

• Концепция УПП (стартовый модуль нового курса)
• Achtung, 1С! (несколько видео-материалов о 'нелинейной' логике прикладных решений)
• Полный (пять с половиной часов видео) разбор решения аттестационного задания на 1С:Специалист по УПП от человека, который еще три месяца назад принимал эти самые аттестации :)

Подробности можно посмотреть у него на сайте.

На рабочем месте

w_bf предложил старинную офисную забаву по фотографированию своего рабочего места. Вот и я присоединяюсь:

Ну, и конечно же, мое "второе место" у доски. =)

Вторая scrum доска

Помните, я показывал вам свою первую доску? С того времени она немого подросла, вот она:

Что изменилось? Во-первых она стала больше и исчезла колонка "Выполненно". Оказалось, что она не нужна, задачи после разработки переходят сразу в тестирование.
Во-вторых есть легенда по стикерам: желтые - обычные истории, синие - не девелоперские задачи. Например, чистое написание манов не связанное с текущим кодированием (маны-то мы и так по каждому вопросу пишем), администрирование или research. Еще есть красные, но на этом фото их нет (что хорошо). Красные - срочные, не запланированные, авральные вопросы, которые нужно быстро решать и выпускать внеочередной bug-fix.
В третьих теперь задачи на доске действительно располагаются по-приоритету (и, кстати, то, чего вы не видите это реальный приоритет, установленный настоящим product owner-ом и сложность установленная planing poker-ом).
В четвертых есть календарик на итерацию с отметками сколько дней отработано, сколько еще осталось. Это зародыш burndown. Пока мы не эстимэйтим задачи в часах и у нас еще нет разделения на user story и tasks, так что толком burndown и не построить, но все еще впереди. А пока хватает и календарика.
Ну и удобный стикер прямо на самой доске с информацией о том во сколько проходит ежедневный daily scrum. =) Теперь никто не сможет сказать, что он не знал когда и где у нас scrum. Ответ перед глазами - у доски в 9:30.

Одиннадцать! (о системах распознавания голоса)

Метрика качества кода