вторник, 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 июня – Как свести к минимуму возможные «отклонения от курса». Что делать с несбывшимися надеждами. Как на отдыхе помочь себе отдохнуть.
Мне кажется, должно быть интересно. Особенно нам, програмерам (ничего не делал и устал, ага).

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


суббота, 28 мая 2011 г.

Введение в SCRUM

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

пятница, 27 мая 2011 г.

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

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

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

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

вторник, 24 мая 2011 г.

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

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

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

пятница, 20 мая 2011 г.

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

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

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

среда, 11 мая 2011 г.

понедельник, 18 апреля 2011 г.

Инстанцирование

xxx: хочу класс ватрушки
yyy: может, объект?
xxx: нет
xxx: класс и наделать кучу объектов
xxx: а деструктор уже готов ...

(c) bash.org.ru

четверг, 14 апреля 2011 г.

Сортировка массива на картах

Не можешь объяснить - покажи это в танце.
Народная мудрость.

Не получается в танце - объясни на пальцах. Или на картах.
Еще одна не менее народная мудрость.

В продолжение к предыдущему посту о сортировке в танце там же на youtube-е нашлось не менее забавное видео о quick sort, правда уже на картах:


Кстати, остальные способы сортировки смотрите на канале Shishberg.

P.S.: Я утомился ждать пока он пузырьком отсортирует. Не даром один из самых медленных алгоритмов.

Сортировка массива в танце

Не можешь объяснить - покажи это в танце.
Народная мудрость.
Очень наглядное танцевальное пособие по простым алгоритмам сортировки. Сортировка выбором, вставкой, сортировка Шелла и, конечно же, пузырек:


Жаль, что нет быстрой сортировки, но наверное это было бы сложно. С другой стороны - следите за каналом, может будет?..

понедельник, 11 апреля 2011 г.

Школа ИТ рекрутера

Практически одновременно с забавным видео о тестировщиках в ленту принесло рекламу о "школе ИТ рекрутера":

Это программа повышения квалификации ИТ рекрутеров, нацеленная, прежде всего, на повышение эффективности их работы в компании.

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

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

Кто такие тестировщики?

Уважаемый w_bf выложил забавное видео о тестировщиках.



P.S.: Я обещал себе не высказываться публично о тестировщиках, потому никак комментировать не буду, но видео и комментарии в блоге w_bf наводят на мысль о том, что следует сесть и написать большой пост о сабже, чем "феерически расставить точки".