8.0 Размышления о путях освоения

Подход к внедрению

Если отбросить в сторону тех кто пишет, не используя вообще сторонние разработки и тех кто вообще не дорабатывает типовые, я думаю таких меньшинство то все остальное можно уложить в следующую структуру. Берется за основы одна из разработок, в основном типовая конфигурация от 1С. На ее основе пишется собственная и с течением времени развивается, используя по возможности все лучшее из типовых, а также общедоступные разработки и идеи из сети. Конфигурация (если это не адресное внедрение) развивается так, чтобы она устраивала 95 % пользователей. Таким путем идут в основном маленькие фирмы у которых сопровождать многочисленные конфигурации нет возможностей. В результате покупая ее (зачастую платя не только за внедрение но и за саму конфигурацию) маленькая фирма с одним бухгалтером имеет 50 % лишних для нее функций, которые конечно можно не использовать. Или торговая фирма получает мощный торговый блок, но производство то ей не нужно, а оно тоже неплохо реализовано в конфигурации. В конфигурации есть "простая" зарплата, но не используется, так как зарплату ведут в др. программе и отказываться от нее не хотят. Клиент, купивший такую конфигурацию, возможно обратится после покупки только при изменении законодательства, а может и нет. Так что, необходимо для них хранить проданную версию конфигурации. А если со времени внедрения до первого обращения прошло достаточно времени то придется еще и изучать, что же ему было поставлено и как это доработать.

Из этого следует, что большинство не работают, и не могу работать на типовых конфигурациях, но используют их в качестве основы для своих решений. Что позволяет им выдавать на рынок конкурентные решения в минимальные сроки. Встает вопрос как упростить механизм использования готовых решений и блоки других? Снизить затраты на изменения своих решений и, адаптации сторонних разработок при их использовании. На эти вопросы я и постараюсь ответить.

Принципы, которые при их правильном применении могут помочь

• Унификация необходима в любом решении, при серьезности подхода к нему и намерений его развивать. До начала реализации необходимо прорабатывать соглашения по унификации, чтоб избежать в дальнейшем проблем с обновлением, совместимости с другими разработками. Унификация позволяет сделать дешевле повторное использование кода. Вспомните какие проблемы вызывает переименование одного из реквизитов. Для того, чтобы переименовать "просто" необходимо и достаточно, чтобы конфигурация также была "простой". Как только конфигурация становится более-менее сложной (больше 40-50 документов), то все становится очень непросто.
• Модульность. Разделение готового решения на подсистемы или модули позволяет снизать затраты на обновление, сопровождение и комплектацию системы для конечного пользователя. Маленькую часть намного проще довести до логического завершения, чем нечто глобальное. Такой модуль должен разрабатываться изначально как подсистема. С описанием его интерфейса и используя соглашения по унификации. При этом с имплементацией не должно быть никаких проблем. Подключение внешней конфигурации (подсистемы), с незначительной доработкой придает гибкость системе. А в дальнейшем при изменении подсистемы позволяет заниматься проблемами этого модуля, а не плюс старой, работающей части. Я думаю многим набили оскомину переносы информации из одного в другое, а затем в третье. С внешним данными без этого не обойтись, но внутри системы проблему можно решить.
• Универсальность. Например, простой механизм подключения внешних форм, реализованный в Торговле 9.х. Закладка таких механизмов во время разработки, и совершенствуя их в ходе развития системы, помогает отбиваться от индивидуальных клиентов, не трогая основной функционал. И это только один пример из реализации универсального подхода ,а таких примеров десятки.
• Открытость. Развитие продукта как OpenSource дает постоянный приток идей и постоянное развитие функционала, обеспечивает самую широкую сеть бета тестирования. Большинство из нас любят показывать свои знания и в меру своих сил помогать другим. При объединении всех разработок, которые выложены на всеобщее обозрение, для использования в единой системе является большим потенциалом.
• Исследование рынка. Зачастую проще проанализировать, что реализовано лучше, и как это реализовать на нашей родной платформе, повысив ее конкурентоспособность, позволяет сократить время на блуждание в потемках и формулирование своих идей.

  Предложение

  Для применения этих принципов предлагаю организовать проект по разработке системы отвечающей этим требованиям. Создать инфраструктуру для успешного развития проекта. Платформой для реализации выбрать 1С: Предприятие 8.0. Одна из наиболее весомых причин - скучно и тесно в рамках 7.7.  На данной стадии разработчики v8 движок уже править не будут. На лицо существенный шаг вперед. В новой версии усилен механизмами поддержания ее целостности в файл-серверном варианте. Разработчики продумали механизм транзакций, блокировки объектов. А также появился механизм подсистем. Наше дело брать и использовать. Явные ляпы быстро будут выявлены и разработчики их подправят. В рамках проекта, наряду с изучением тонкостей новой платформы мы сформирует библиотеки повторно используемого кода. Проработки теоретической части проекта и создание под нее инфраструктуры хватит до официального выхода платформы. А ждать пока платформа получит распространение, я думаю, немеет смысла главное чтоб она удовлетворяла наши потребности.

  Что дает проект

  1. Эффективное использование языка новой платформы. Зачем каждому из нас делать тестовые конфигурации и проверять различные варианты решений.
  2. Создание библиотеки типовых строительных элементов.
  3. Модульное построение систем в рамках новой платформы. Как наилучшим образом построить конфигурации, чтобы их можно было разрабатывать и распространять по модульному, функциональному принципу.
  4. Выработка единых стандартов. Для легкого объединения подсистем.
  5. Инфраструктура для групповой разработки. Создание удобной среды, для развития.
  6. Когда проект координировано разрабатывает группа в 5-10 программистов, то 1 специалист проиграет этой команде в 95% случаев.
  7. Для тех, кто ориентируется на типовые разработки фирмы 1С или других организаций могут внести свой вклад проверкой различных синтаксических конструкций.
  8. Разработчики собственных программ смогут обменяться мнениями и выложить отдельные их фрагменты для общего пользования.
     
     

  Препятствия проекту

  • Открытость - то что было в общем доступе входит в платную версию даже без указания на первоисточник. Затрагивает только амбиции участников. Отчасти решается открытой лицензией.
    Конкуренция - Главное, что большинство профессиональных генераторов идей работает в франчайзинговых структурах. А франчайзи конкуренты друг другу. В последнее время очень жестокие конкуренты.
  Недоступность v8 – Основной потенциал разработчиков проект получит только лишь после того как большая часть получит восьмерку, попробует перевести все то нетиповое что было на V7.7 на V8.0 - посмотрит оценит, протестирует и плавно перейдет к ее освоению.
  Отсутствие времени - для того чтобы, заниматься новым, изучать и осваивать его, а тем более формулировать предложения нужно время. С другой стороны участие в проекте должно помогать и не противоречить основной работе.
  Отсутствие информации - наверняка сейчас даже внутри фирм происходит расслоение специалистов так было и при переходе с 6 на 7. Даже внутри одной фирмы, наверняка, допущенные к телу крайне неохотно делятся информацией (объяснения наверняка очень рациональные - времени нет, все еще поменяется и т.п.). Появление такого проекта скорее даже поможет.
  Внедрение по принципу доработки - большую часть людей скорее будет интересовать проект только в плане переделки и мелких доработок того, что разрабатывается внутри его.

  Перспективы

  Зачастую при обсуждении какой бы вопрос не подняли рано или поздно скатываемся на КИС. Видимо базовый пласт задач на платформе уже подняли. Что ж возможно КИС и есть то, к чему все мы стремимся. Но для создания КИС в любом случае нужны нешуточные инвестиции. А может нет? Возможно с ростом проекта систему собранную из подсистем можно будет назвать КИС? Именно для КИС и нужно объединение усилий.
  
  

  Обсуждение статьи на форуме: https://forum.klerk.ru/showthread.php?s=&threadid=12357