GK
Второй вариант, да
Size: a a a
2020 July 09
RT
тогда и документация не поможет, архитектура останется только на бумаге, а в реализации всё равно все будет как обычно
DK
Пока документация не будет явно указана как один из обязательных результатов работы сотрудника наравне с кодом, он не будет относиться к ней как к чему-то важному, за редким исключением.
GK
тогда и документация не поможет, архитектура останется только на бумаге, а в реализации всё равно все будет как обычно
так и есть
AL
С4 удобен, жаль только отсутствует в грамматике формальное определения интерфейса интеграции
А для этого есть Архимейт с его контрактами и интерфейсами
GK
Когда есть документация, есть возможность сделать ревью произведений инженерного искусства. Когда она неактуальна, есть возможность выяснить, что она не актуальна и приблизиться к актуализации.
Но часто архитектора сажают на бочку с порохом. Документация - это ящик Пандоры.
Но часто архитектора сажают на бочку с порохом. Документация - это ящик Пандоры.
GK
Пока документация не будет явно указана как один из обязательных результатов работы сотрудника наравне с кодом, он не будет относиться к ней как к чему-то важному, за редким исключением.
Именно. И важно - на документирование явным образом должно выделяться время. Так же как и на ритуалы Скрам, например.
RT
Мой опыт подсказывает что документация работает тогда, когда пишется ДО реализации.
Например языком требований.
Например языком требований.
GK
Мой опыт подсказывает что документация работает тогда, когда пишется ДО реализации.
Например языком требований.
Например языком требований.
Стоит это обсудить
RT
описывать что-то, что уже реализовано дело гиблое:
результат уже получен, тратить время на бумажки никому не хочется, нет никакой мотивации.
документация всегда будет отставать от реальности
результат уже получен, тратить время на бумажки никому не хочется, нет никакой мотивации.
документация всегда будет отставать от реальности
GK
конечно, но можно сделать автогенерацию, если описывать в коде
RT
не вижу особого смысла, если и так можно увидеть в коде.
документация из реализации лишь фиксирует фвкт того как это сделано,
но ни разу не объяснет ЧТО должно быть сделано, ПОЧЕМУ это сделано так
документация из реализации лишь фиксирует фвкт того как это сделано,
но ни разу не объяснет ЧТО должно быть сделано, ПОЧЕМУ это сделано так
DK
описывать что-то, что уже реализовано дело гиблое:
результат уже получен, тратить время на бумажки никому не хочется, нет никакой мотивации.
документация всегда будет отставать от реальности
результат уже получен, тратить время на бумажки никому не хочется, нет никакой мотивации.
документация всегда будет отставать от реальности
Если нет понимания, куда оно дальше пойдет, кто это будет использовать - нет четкого конечного потребителя - да. Потому что никто не придет по твою душу))
GK
Я пришёл к тому, что можно вести карточки сервисов и из них генерировать C4.
Карточки должны содержать в сжатом и чётко структурированном виде (понятном и удобном для навигации и поиска) всю важную сводную информацию о сервисе. Их вполне реально актуализировать.
У Ричардса шаблоны карточек слишком простые, не учитывают многого и не пригодны для генерации C4
Карточки должны содержать в сжатом и чётко структурированном виде (понятном и удобном для навигации и поиска) всю важную сводную информацию о сервисе. Их вполне реально актуализировать.
У Ричардса шаблоны карточек слишком простые, не учитывают многого и не пригодны для генерации C4
DK
не вижу особого смысла, если и так можно увидеть в коде.
документация из реализации лишь фиксирует фвкт того как это сделано,
но ни разу не объяснет ЧТО должно быть сделано, ПОЧЕМУ это сделано так
документация из реализации лишь фиксирует фвкт того как это сделано,
но ни разу не объяснет ЧТО должно быть сделано, ПОЧЕМУ это сделано так
разрабу можно. всем остальным - низзя. или очень долго.
GK
В карточках должны быть ссылки и на требования, и на трекер, и на версионное хралище.
Доведу до ума и поделюсь, можно будет подискутировать.
Доведу до ума и поделюсь, можно будет подискутировать.
GK
Основна проблема с которой я встретился - разработчики не могут заполнить карточки, потому что дизайна никакого нет, они просто не думали над дизайном и поэтому ничего толком описать и не могут. То есть перед тем как заполнить карточки нужно ещё и редизайн сделать, потому что по факту дизайн оказывается так себе.
GK
Нет документации, нет вопросов. Утилизация высокая, всё в порядке. Ну а постоянный срач и пожары - часть героического пути.
RT
Нет документации, нет вопросов. Утилизация высокая, всё в порядке. Ну а постоянный срач и пожары - часть героического пути.
я сталкивался с ситуацией когда руководитель сознательно такое организовывал
GK
я сталкивался с ситуацией когда руководитель сознательно такое организовывал
Да, разработчиков в конечном итоге можно просто обязать. Не разработчики на бочку с порохом архитекторов сажают.