AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.06.2015, 14:51   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Миф о документации
Миф о документации
http://gaperton.livejournal.com/60632.html
Старый 29.06.2015, 08:08   #2  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
хорошая статья.
Есть, правда, в консалтинге еще один вид документов. Под названием "проектная документация". Это такой огромный ворох шуршашей оберточной бумаги, в который заворачивают механизм, дабы клиент не вымазался в мазуте и не зашиб колено об выступающие детали. Бумагу принято украшать цветными диаграммами, абстрактными скрин-шотами и загадочными таблицами. Инжинер-моторист должен, презрев эстетику, бумагу сорвать, скомкать и отбросить. И после этого совершить тщательный осмотр изделия, чтобы понять чтоже собственно ему предстоит обслуживать.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: mazzy (2), Шрэк (1), Logger (1), kingozzavr (2).
Старый 29.06.2015, 11:01   #3  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Статья действительно интересная, чувствуется, что "выстраданная" Но утверждения на счет противопоставления договора и справочника, мне кажется, - не бесспорны. Выделение полужирным далее - моё.
Цитата:
Итак, мы выяснили, что:
  • по решаемым проблемам «документы» можно условно разделить на «договор», «справочник», и «учебник», и хоть это и не полный список, но вполне достаточный для наших целей.
  • Документ типа «договор» пишут и читают добровольно все, или многие, ибо иначе придет <censored>.
  • «Договор» нет нужны «поддерживать в актуальном состоянии», ибо это лежит за рамками проблемы, решаемой «договором».
  • Основная фишка «справочника» в том, что ему точно можно доверять, и он всегда актуален.
  • «Справочники» очень дороги в создании и содержании, и нужна действительно веская причина, чтобы его создавать. Меняется справочник редко.
«Справочником» в нашем случае является исходный текст программы, с комментариями в тексте, и с комментариями к коммитам в системе контроля версий. Для тех, кто не умеет читать код – для практически всех современных языков есть автоматические генераторы «справочников» из кода, вроде JavaDoc, волшебным образом решающие проблему актуальности.
Тексты типа «договор», которые в нашем случае отражают требования, иногда результат проектирования, и пр. – не надо пытаться превращать в документы типа «справочник», и поддерживать актуальными. Они решают совсем другую проблему. Эта идиотская затея провалится просто потому, что это <censored> никому не нужно.
Вспомнилась в связи с этим чудесная книга Балдеющие от адреналина и зомбированные шаблонами Тома Демарко, Тимоти Листера & Co, в частности, шаблон №43 "Эти чертовы интерфейсы"
Цитата:
Члены проектной команды неотступно концентрируются на интерфейсах – как автоматизированных, так и человеческих.
Чтобы спроектировать систему, нам следует понять, какие интерфейсы должны быть между этой системой и ее окружением. Нам нужно знать, какие данные поступают на вход и что система производит на выходе. Пока у нас нет такого перечня входов и выходов, мы остаемся на стадии предварительного анализа: мы не ограничили задачу. Получив полный набор интерфейсных характеристик, мы можем заняться определением функциональности системы.
Что происходит в проектировании после того, как достигнуто согласие по поводу функциональности? Мы разбиваем большую и сложную систему на подсистемы, а подсистемы делим на компоненты. И снова, для того чтобы ограничить эти подсистемы и компоненты, необходимо в каждом случае определить все уникальные входы и выходы.
Как мы фрагментируем деятельность по реализации? По подсистемам и/или компонентам. Команда может взяться за работу над подсистемой, при этом отдельные люди будут создавать и тестировать
компоненты. Границы подсистемы и компонента задают фронт работ, определяя конкретную область ответственности каждого разработчика. Интерфейсы играют роль контрактов между компонентами; один компонент говорит другому: «Ты передаешь мне именно такие данные и только при таких условиях, а я создам именно такой результат, который будет храниться точно в указанном месте».
Знакомые с этим паттерном команды начинают штурмовать интерфейсы как можно раньше. Они создают фрагменты кода для работы интерфейсов еще до того, как начнут писать код компонентов. Они рано начинают интеграцию кода отдельных разработчиков и часто проводят тестирование.
Мы как-то имели дело с проектом, который вели три рабочие группы – одна в Канаде, другая в США, а третья в Израиле. Руководитель держал в интранет-сети проекта документ с названием «Библия интерфейсов». Этот справочный документ служил единственным источником информации по всем интерфейсам системы, и только включенные в него особенности интерфейсов имели право на существование. Он клялся на этой библии, и поэтому ему не приходилось проклинать интерфейсы.
Тут приводится пример того, как один документ может играть роли договора (контракта) и справочника в классификации автора статьи, при этом он
  • не является исходным текстом программы
  • не пишется раз и навсегда, а развивается и уточняется со временем
  • от поддержания его в актуальном состоянии (чтобы ему "можно было доверять") во многом зависит успех реализации проекта
В общем, мне лично кажется, что выводы автора во многом сформировались в условиях недостаточной работы по анализу и проектированию до начала написания кода.
За это сообщение автора поблагодарили: mazzy (2).
Старый 29.06.2015, 14:26   #4  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Мне приходилось встречать такое определение договора - это "документ, который достаётся тогда, когда проект заходит в тупик"
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 22.07.2015, 22:26   #5  
MARKZeon is offline
MARKZeon
Участник
 
5 / 10 (1) +
Регистрация: 09.07.2015
Договор в основном пишут юристы для юристов для борьбы со странными заказчиками и поставщиками, ведь им потом расхлебывать
Старый 23.07.2015, 03:09   #6  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от MARKZeon Посмотреть сообщение
Договор в основном пишут юристы для юристов для борьбы со странными заказчиками и поставщиками, ведь им потом расхлебывать
Подпускать юристов к составлению договоров уже становится дурным тоном. Точно так же как подпускать бухгалтеров к принятию бизнес-решений.
Ибо у юристов интерес один, увернуться от ответственности в случае судебного разбирательства. А бизнесу судебные разбирательства обычно совсем не интересны. Ибо для бизнеса даже выигрыш в суде часто оборачивается убытками, а для юристов и адвокатов даже проигрыш это прибыль.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: mazzy (2).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
О документации, утрате технологий и прочих печальностях komar Курилка 4 22.04.2015 17:29
Как не надо переводить мануалы к технической документации a33ik Курилка 8 17.09.2010 15:38
Миф о модифицируемости Аксапта, или техническая эстетика. stavteam Курилка 110 29.12.2004 14:28
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 21:57.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.