четверг, 30 июня 2011 г.

Процесс или результат?

Совсем недавно мы основательно препирались с шефом по поводу одной методологической мелочи. В ходе «горячей беседы» шеф спросил:
«...почему я должен потратить ДВА часа вместо часа?
что важнее – РЕЗУЛЬТАТ или ПРОЦЕСС?»
Казалось бы, ответ очевидный: конечно, результат! Кого волнует какой-то там процесс, если результат – вот он, перед тобой. Да и сам процесс, собственно, затевался именно ради результата, а не наоборот.

Но!

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

Есть мнение, что:
...качество продукта напрямую связано с качеством используемых для его создания процессов.
Так в десятой главе с сочным названием «Качество программного обеспечения» говорит нам SWEBOK. Во всяком случае все, кто согласен с этой формулировкой, ссылаются в первую очередь туда.
К тому же примерно о том говорят сверхпопулярные стандарты серии ISO 9000. Обратите внимание, что:
ISO 9000 – серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.
Или как объясняется чуть ниже:
Важно понимать, что соответствие стандарту ISO 9001 не гарантирует высокое качество продукции. Термин «quality management» здесь было бы правильнее переводить как «управление добротностью». Соответствие требованиям и рекомендациям этих стандартов говорит о способности предприятия:
  • делать всё максимально возможное для достижения поставленных перед собой целей;
  • улучшать результативность своей деятельности.
То есть, по сути, стандарты ISO 9000 выдвигают требования не к качеству конечного продукта, а к качеству ПРОЦЕССА его создания. Просто и со вкусом. И вряд ли найдется человек, который ни разу в жизни не встречал надписи «ISO 9001», например. А какие настолько же популярные стандарты на конечный продукт вы знаете? Кроме, конечно же, того самого пресловутого ГОСТа, слава которого тянется из советских времен?

Программисты, конечно же, знают обо всем этом и не устают повторять окружающим (см. «Страсти по качеству», раздел «Не плюй в колодец ISO 9000...»). Но, увы, не все верят.
Мне повезло. У меня перед глазами есть живой пример. Две команды разработчиков, у одной из которых нет процесса вообще, а вторая как-то пытается налаживать процесс. И знаете, кажется, у второй дела идут получше.

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

А я желаю вам хорошего дня и хорошего кода.

среда, 29 июня 2011 г.

Mercurial, Git, Baazar!

Очередная встреча клуба «Клуба анонимных разработчиков» будет посвящена использованию распределенных VCS.
Нужно сходить.

вторник, 28 июня 2011 г.

Agile-club

Буквально в последний момент решился пойти на Agile-club.
Заходите к нам на огонек!

Отзыв о "лучших практиках"

Недавно ходил на семинар "Лучшие практики инженерии создания ПО".

Это, несомненно, было прекрасно! Мы отлично пообщались в неформальной обстановке, уровень организации и прочее было на высоте, как и на любых мероприятиях компании Luxoft. (Да, можете считать это рекламой или как хотите, но только за "Luxoft training center" им нужно поставить памятник. Сеять разумное-доброе-вечное своими силами или силами приглашенных специалистов - это много стоит. И не говорите мне ничего о  GL-club, товарищи, это смешно). Замечательный докладчик Любовь Монсар, уважаемый специалист ("комсомолка, спортсменка и просто красавица!") хорошо владеет темой, увлекательно рассказывает, "держит аудиторию". Во общем - буря восторгов, и "абажаний" всему событию и отдельным моментам и людям.

Теперь о том, что можно было бы сделать лучше. Сразу скажу, что это будет критический взгляд scrum-инфицированного специалиста. Очень узконаправленный.
Во-первых для любого человека, который успел обзавестись небольшим ворохом бэйджиков, визиток и рекламок с логотипами AgileUkraine, ScrumGuides и прочим-таким, все, что рассказывалось на семинаре не представляется новым. Потому что RUP - это история agile. Именно оттуда было взято все лучшее, обрезано по-краям и выдано массам фанатичных аджайлистов. И любой новоявленный аджаил-коуч (шмоуч ;-) на первом же собственном "ивенте" рассказывает: "Сначала был waterfall, который придумала армия США (следует краткий обзор), потом IBM придумала RUP (следует краткий обзор), ну а затем уже появился agile".
Тем не менее в графе "Оправданы ли были ваши ожидания от семинара" я поставил твердую пятерку. Да, нового не было, но и ожидал я именно такого общего обзора. Очень хотелось бы попасть на семинар с названием "Лучшие практики №2 - Углубление в RUP", в котором более подробно рассматривались бы процессы, документы и прочие артефакты методологии. Или даже "Лучшие практики №3 - Внедряем RUP", где больше внимания можно было бы уделить тому, что же именно нужно, чтобы начать использовать RUP. А-то у скрама, например, все просто - есть доска и желание и вы уже скрам.А как с RUP-ом быть? С чего начинать? Что делать?
Во-вторых, мне кажется, что в самом докладе стоило бы уделить больше внимания именно agile. (Может быть, целый слайд!) Поскольку сейчас в мире разработки много аджайлнутых на голову, следовало бы доступно разъяснить, что RUP не хуже и не лучше того же scrum, а предназначен для других задач, для более строгих и формальных проектов. Рассказать про медицину и авиастроение (превед Максу Дорофееву!), может даже и с примерами. А-то это как-то всплыло только в обсуждении и то несколько абстрактно. Ну, и, конечно тут же можно было бы органично упомянуть про OpenUP. Конечно, я не специалист, но кажется, что методология любопытная, не знаю уж насколько жизнеспособная.

На этом, пожалуй и все. Все остальное на мой взгляд, как я уже и говорил, выше всяких похвал.
Теперь буду с нетерпением ждать следующих событий в luxoft traning center.

СКД и отбор на форме

Часто бывает нужно программно сформировать отчет на основании готового макета СКД и вывести его куда-нибудь в поле табличного документа на форме. Еще бывает полезно отобразить на форме настройки отбора или другие настройки СКД.

четверг, 23 июня 2011 г.

Рак формы

Забавно прокомментировал Лебедев форму какого-то приложения на бизнес-линче:
Это — рак формы, обычное заболевание программистов.
Часто проходит после знакомства с современной операционкой от Эппл и чтения документа «Эппл хьюман интерфейс гайдлайнc»
Хорошо, что он наших форм не видел. =)

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

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

воскресенье, 19 июня 2011 г.

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

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

Code review

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

четверг, 16 июня 2011 г.

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

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

среда, 15 июня 2011 г.

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

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

вторник, 14 июня 2011 г.

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

Учебный центр Luxoft проводит очередной интересный семинар - "Лучшие практики инженерии создания ПО".
Семинар является вводным в методологию RUP - Rational Unified Process.
Рассматриваются лучшие практики, используемые в проектах по разработке программного обеспечения.
Дается введение в итеративную разработку ПО как мощное средство снижения рисков проекта.
Про итеративную разработку мы и так в курсе, про практики интересно было бы послушать. Но самое главное, что будет рассматриваться RUP. Давно хотел познакомиться с этим зверем и даже читал про OpenUP, но все мельком и мимоходом. А тут такая возможность!

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

среда, 8 июня 2011 г.

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

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




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

вторник, 7 июня 2011 г.

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

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

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