Рекомендации по созданию оберток над процедурами из модуля Сервер в модуле ВызовСервера
Есть процедура в общем модуле, которая должна работать на сервере, но вызывать ее можно и с клиента, и с сервера.
Можно:
1) поместить ее в модуль ВызовСервера
2) поместить ее в модуль Сервер и добавить обертку в ВызовСервера
В первом случае нет дублирования, но серверный интерфейс расползается на 2 модуля и его становится нельзя быстро охватить глазом, чтобы понять, что доступно.
Во втором случае серверный интерфейс виден полностью, но есть лишний шаблонный код.
Сам шаблонный код не страшен, страшно, что также дублируется документация интерфейса в комментариях к процедурам -- благодатная почва для появления расхождений и устаревшей информации: когда исправил серверную процедуру, если сигнатура не поменялась, никогда не вспомнишь, что где-то там еще есть обертка над ней.
В БСП, судя по выборке наугад, используется второй подход: процедуры в ВызовСервера не являются обертками только если вызываются исключительно с клиента.
Есть ли какие-нибудь рекомендации со стороны 1С или других авторитетных специалистов на этот счет? Поиск не нашел ничего релевантного, в этот случай также не описан.
Можно:
1) поместить ее в модуль ВызовСервера
2) поместить ее в модуль Сервер и добавить обертку в ВызовСервера
В первом случае нет дублирования, но серверный интерфейс расползается на 2 модуля и его становится нельзя быстро охватить глазом, чтобы понять, что доступно.
Во втором случае серверный интерфейс виден полностью, но есть лишний шаблонный код.
Сам шаблонный код не страшен, страшно, что также дублируется документация интерфейса в комментариях к процедурам -- благодатная почва для появления расхождений и устаревшей информации: когда исправил серверную процедуру, если сигнатура не поменялась, никогда не вспомнишь, что где-то там еще есть обертка над ней.
В БСП, судя по выборке наугад, используется второй подход: процедуры в ВызовСервера не являются обертками только если вызываются исключительно с клиента.
Есть ли какие-нибудь рекомендации со стороны 1С или других авторитетных специалистов на этот счет? Поиск не нашел ничего релевантного, в этот случай также не описан.
Найденные решения
(1)
В БСП используется подход - описание процедуры только у основной процедуры, а у оберток добавляется комментарий с именем процедуры - в котором смотреть описание:
// См. ОтчетыКлиентПереопределяемый.ОбработкаРасшифровки
когда исправил серверную процедуру, если сигнатура не поменялась, никогда не вспомнишь, что где-то там еще есть обертка над ней.
В БСП используется подход - описание процедуры только у основной процедуры, а у оберток добавляется комментарий с именем процедуры - в котором смотреть описание:
// См. ОтчетыКлиентПереопределяемый.ОбработкаРасшифровки
Прикрепленные файлы:
(3) Показанное на скриншоте наблюдается не у оберток, а у обработчиков событий, вызываемых логикой БСП (тех, которые разработчику в комментариях предлагается добавлять в свои модули по шаблону).
У оберток в модулях БСП с ВызовСервера -- полноценные описания (см. вл.).
С другой стороны, никто не запрещает так поступать в своем коде.
Но тут все равно есть дублирование -- имени модуля в комментарии! Если при рефакторинге процедуру перенесут, имя в комментарии перестанет соответствовать действительности.
Можно, впрочем, вставлять что-то шаблонное без имен, вроде "см. описание обертываемого метода".
У оберток в модулях БСП с ВызовСервера -- полноценные описания (см. вл.).
С другой стороны, никто не запрещает так поступать в своем коде.
Но тут все равно есть дублирование -- имени модуля в комментарии! Если при рефакторинге процедуру перенесут, имя в комментарии перестанет соответствовать действительности.
Можно, впрочем, вставлять что-то шаблонное без имен, вроде "см. описание обертываемого метода".
Прикрепленные файлы:
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
В БСП используется подход - описание процедуры только у основной процедуры, а у оберток добавляется комментарий с именем процедуры - в котором смотреть описание:
// См. ОтчетыКлиентПереопределяемый.ОбработкаРасшифровки
когда исправил серверную процедуру, если сигнатура не поменялась, никогда не вспомнишь, что где-то там еще есть обертка над ней.
В БСП используется подход - описание процедуры только у основной процедуры, а у оберток добавляется комментарий с именем процедуры - в котором смотреть описание:
// См. ОтчетыКлиентПереопределяемый.ОбработкаРасшифровки
Прикрепленные файлы:
(3) Показанное на скриншоте наблюдается не у оберток, а у обработчиков событий, вызываемых логикой БСП (тех, которые разработчику в комментариях предлагается добавлять в свои модули по шаблону).
У оберток в модулях БСП с ВызовСервера -- полноценные описания (см. вл.).
С другой стороны, никто не запрещает так поступать в своем коде.
Но тут все равно есть дублирование -- имени модуля в комментарии! Если при рефакторинге процедуру перенесут, имя в комментарии перестанет соответствовать действительности.
Можно, впрочем, вставлять что-то шаблонное без имен, вроде "см. описание обертываемого метода".
У оберток в модулях БСП с ВызовСервера -- полноценные описания (см. вл.).
С другой стороны, никто не запрещает так поступать в своем коде.
Но тут все равно есть дублирование -- имени модуля в комментарии! Если при рефакторинге процедуру перенесут, имя в комментарии перестанет соответствовать действительности.
Можно, впрочем, вставлять что-то шаблонное без имен, вроде "см. описание обертываемого метода".
Прикрепленные файлы:
(9)
Что? Мой код -- говно! Им нельзя пользоваться! Он либо не делает то, что говорит описание, либо вообще не документирован! И я же буду от этого страдать -- теряя время и совершая ошибки при дальнейшней работе с ним.
Именно для этого я и пытаюсь выяснить best practices -- лучшее, что придумано в индустрии по этому вопросу на данный момент. Т.е. то, что либо вообще устраняет указанные изъяны, либо минимизирует их насколько возможно разумными усилиями.
Да, иногда может устареть.
Да, иногда надо править.
Собственно, и что?
Да, иногда надо править.
Собственно, и что?
Что? Мой код -- говно! Им нельзя пользоваться! Он либо не делает то, что говорит описание, либо вообще не документирован! И я же буду от этого страдать -- теряя время и совершая ошибки при дальнейшней работе с ним.
Именно для этого я и пытаюсь выяснить best practices -- лучшее, что придумано в индустрии по этому вопросу на данный момент. Т.е. то, что либо вообще устраняет указанные изъяны, либо минимизирует их насколько возможно разумными усилиями.
Мнение авторитетного специалиста:
Перестать считать "ВызовСервера" оберткой. Он используется не только как обертка, но и как место для преобразования серверных типов в клиентские.
Например:
1. Серверный метод возвращает таблицу значений.
2. ВызовСервера преобразует её в массив структур.
3. На клиентский код всегда приходит массив структур через Вызов Сервера
4. На серверный код возвращается по выбору разработчика: хоть ТЗ через Сервер, хоть Массив через ВызовСервера.
И никакого "шаблонного кода".
Перестать считать "ВызовСервера" оберткой. Он используется не только как обертка, но и как место для преобразования серверных типов в клиентские.
Например:
1. Серверный метод возвращает таблицу значений.
2. ВызовСервера преобразует её в массив структур.
3. На клиентский код всегда приходит массив структур через Вызов Сервера
4. На серверный код возвращается по выбору разработчика: хоть ТЗ через Сервер, хоть Массив через ВызовСервера.
И никакого "шаблонного кода".
(5)
пример из СП:
Если методы возвращают разное, они будут и называться по-разному во избежание путаницы -- т.е. фактически это будет 2 разных метода.
пример из СП:
БезопасныйРежим (SafeMode)
Синтаксис:
БезопасныйРежим()
Возвращаемое значение:
Тип: Булево, Строка.
Строка, если установлен безопасный режим с указанием имени профиля безопасности.
Истина, если установлен безопасный режим.
Ложь, если безопасный режим не установлен.
Синтаксис:
БезопасныйРежим()
Возвращаемое значение:
Тип: Булево, Строка.
Строка, если установлен безопасный режим с указанием имени профиля безопасности.
Истина, если установлен безопасный режим.
Ложь, если безопасный режим не установлен.
(13) (7) Это один и тот же метод, который может возвращать разные типы.
В (2), если я правильно понял, мне предлагали сделать 2 метода: "МойМодуль.МойМетод()", возвращающий один тип, и "МойМодульВызовСервера.МойМетод()", возвращающий другой тип.
Т.к. в типовом коде, в частности, в БСП, такие методы всегда делают ровно одно и то же, такое поведение выглядит вводящим в заблуждение: если "МойМодульВызовСервера.МойМетод()" возвращает другое, его следует назвать по-другому или поместить в другой модуль.
В (2), если я правильно понял, мне предлагали сделать 2 метода: "МойМодуль.МойМетод()", возвращающий один тип, и "МойМодульВызовСервера.МойМетод()", возвращающий другой тип.
Т.к. в типовом коде, в частности, в БСП, такие методы всегда делают ровно одно и то же, такое поведение выглядит вводящим в заблуждение: если "МойМодульВызовСервера.МойМетод()" возвращает другое, его следует назвать по-другому или поместить в другой модуль.
(16) То есть по твоей логике выходит, что если оба этих метода разместить в одном модуле, то настанет путаница, ибо мы не сможем отличить метод МойМетод() из "МойМодуль" от метода МойМетод() из другого модуля "МойМодуль".
Так я вижу твою логику?
Это же ты утверждаешь, что методы с одинаковыми наименованиями надо разносить по разным модулям, чтобы не возникало путаницы. То есть ты на голубом глазу допускаешь, что путаница возникнет только тогда, кода оба метода с одинаковым наименованием разместить в одном модуле?
Так я вижу твою логику?
Это же ты утверждаешь, что методы с одинаковыми наименованиями надо разносить по разным модулям, чтобы не возникало путаницы. То есть ты на голубом глазу допускаешь, что путаница возникнет только тогда, кода оба метода с одинаковым наименованием разместить в одном модуле?
(18)
Добавим треша в ад кутежа:
нельзя создать ни 2 общих модуля с одинаковыми именами, ни 2 метода с одинаковыми именами в одном модуле.
Добавим треша в ад кутежа:
#Если Клиент Тогда
Функция МойМетод(Массив)
Возврат Число;
КонецФункции
#Иначе
Функция МойМетод(ТаблицаЗначений)
Возврат Строка;
КонецФункции
#КонецЕсли Показать
(17)
В предположении, что автор сообщения написал "МойМодуль<Суффикс>", который движок форума "съел".
Давайте посмотрим. Согласно , модули с одинаковой основной частью имени у нас могут быть следующие:
* Модуль (МодульСервер)
* МодульВызовСервера
* МодульКлиент
* МодульКлиентСервер
* К каждому из них может добавляться "Служебный" и "ПовтИсп"
* глобальные модули не рассматриваем, т.к. их имена не фигурируют в коде
Далее я использую терминологию "рабочие подпрограммы" (бизнес-логика приложения) и "сервисные подпрограммы" (вспомогательная логика, не специфичная для конкретной задачи), прочитанную в старой переводной книге "Осваиваем микрокомпьютер". Каких-либо официальных терминов для этих сущностей не встречал.
* В Модуль (МодульСервер) размещаются
* рабочие процедуры, предназначенные для вызова с сервера.
* сервисные процедуры, использующие типы, доступные только на сервере
* В МодульВызовСервера размещаются рабочие процедуры, предназначенные для вызова с клиента.
* хотя их можно вызывать и с сервера, в БСП так никогда не делается; более того, стандарт указывает не ставить у модулей ВызовСервера флажок "Внешнее соединение" (где есть только сервер) -- что явно указывает, что логика стандарта 1С не предполагает вызывать их с сервера
* В МодульКлиент размещаются
* рабочие процедуры, специфичные для клиента.
* , на клиенте должна размещаться только логика ввода/вывода, за исключением работы с оборудованием/ПО, расположенным на стороне клиента
* сервисные процедуры, использующие типы/сущности, доступные только на клиенте
* В МодульКлиентСервер размещаются сервисные процедуры, не использующие типы, доступные только в одном месте
Таким образом, при использовании модулей по назначению не может возникнуть путаницы между Клиент, Сервер и КлиентСервер -- т.к. они содержат разные типы логики.
А вот Сервер и ВызовСервера содержат один и тот же тип логики. Как и модули с суффиксами "Служебный" и "ПовтИсп" и соответствующие им модули без таковых. И если в них есть процедуры с одинаковыми названиями, т.е., заявляющие, что они делают одно и то же, будет неочевидно, какую из них вызывать (при написании кода) и правильно ли выбрана вызываемая (при чтении кода) -- т.е. будет нарушаться принцип "".
настанет путаница, ибо мы не сможем отличить метод МойМетод() из "МойМодуль" от метода МойМетод() из другого модуля "МойМодуль"
В предположении, что автор сообщения написал "МойМодуль<Суффикс>", который движок форума "съел".
Давайте посмотрим. Согласно , модули с одинаковой основной частью имени у нас могут быть следующие:
* Модуль (МодульСервер)
* МодульВызовСервера
* МодульКлиент
* МодульКлиентСервер
* К каждому из них может добавляться "Служебный" и "ПовтИсп"
* глобальные модули не рассматриваем, т.к. их имена не фигурируют в коде
Далее я использую терминологию "рабочие подпрограммы" (бизнес-логика приложения) и "сервисные подпрограммы" (вспомогательная логика, не специфичная для конкретной задачи), прочитанную в старой переводной книге "Осваиваем микрокомпьютер". Каких-либо официальных терминов для этих сущностей не встречал.
* В Модуль (МодульСервер) размещаются
* рабочие процедуры, предназначенные для вызова с сервера.
* сервисные процедуры, использующие типы, доступные только на сервере
* В МодульВызовСервера размещаются рабочие процедуры, предназначенные для вызова с клиента.
* хотя их можно вызывать и с сервера, в БСП так никогда не делается; более того, стандарт указывает не ставить у модулей ВызовСервера флажок "Внешнее соединение" (где есть только сервер) -- что явно указывает, что логика стандарта 1С не предполагает вызывать их с сервера
* В МодульКлиент размещаются
* рабочие процедуры, специфичные для клиента.
* , на клиенте должна размещаться только логика ввода/вывода, за исключением работы с оборудованием/ПО, расположенным на стороне клиента
* сервисные процедуры, использующие типы/сущности, доступные только на клиенте
* В МодульКлиентСервер размещаются сервисные процедуры, не использующие типы, доступные только в одном месте
Таким образом, при использовании модулей по назначению не может возникнуть путаницы между Клиент, Сервер и КлиентСервер -- т.к. они содержат разные типы логики.
А вот Сервер и ВызовСервера содержат один и тот же тип логики. Как и модули с суффиксами "Служебный" и "ПовтИсп" и соответствующие им модули без таковых. И если в них есть процедуры с одинаковыми названиями, т.е., заявляющие, что они делают одно и то же, будет неочевидно, какую из них вызывать (при написании кода) и правильно ли выбрана вызываемая (при чтении кода) -- т.е. будет нарушаться принцип "".
(8) В сообщениях описываются объективные недостатки, которые аукнутся при поддержке кода, а не какие-то несоответствия моим личным предпочтениям.
Тема создана, чтобы выяснить лучшее, что придумано в индустрии по данному вопросу на данный момент -- что их исключает или минимизирует насколько возможно.
"Не тот делает быстро, кто спешит, а тот скор, кто не переделывает однажды сделанного." -- Валентин Иванов - Повести древних лет
Тема создана, чтобы выяснить лучшее, что придумано в индустрии по данному вопросу на данный момент -- что их исключает или минимизирует насколько возможно.
"Не тот делает быстро, кто спешит, а тот скор, кто не переделывает однажды сделанного." -- Валентин Иванов - Повести древних лет
(12)
Хочешь выяснить локальную истину - собери все гипотезы и найди в каждой что-то рациональное, после чего присвой всем плюсам и минусам некий коэффициент, перемножь и получишь некую математическую оценку - бенчмарк (фирма Ксерокс придумала, чтобы показать, что именно ее девайсы лучше - это решается коэффициентами), который и покажет, какая гипотеза лучше. Скомбинируй лучшее - получишь идеальное. Всем вломы этим заниматься, поэтому я с нетерпением жду, когда очередной стандартизатор научит меня жить лучше, больше, веселее....
Тема создана, чтобы выяснить лучшее, что придумано в индустрии по данному вопросу на данный момент -- что их исключает или минимизирует насколько возможно.
Лучшее еще не придумано, т.к. завтра придет очередной Мартин и напишет очередную книгу "(Не)ГовноКод", в которой переосмыслит современную индустрию с учетом активного внедрения в ней кода, сгенерированного ИИ, который, поверь, от имеющихся стандартов точно может ни на йоту не отступить, при том код будет именно "(Не)КакойТоТамЧичтыйКод" во всем остальном.
Хочешь выяснить локальную истину - собери все гипотезы и найди в каждой что-то рациональное, после чего присвой всем плюсам и минусам некий коэффициент, перемножь и получишь некую математическую оценку - бенчмарк (фирма Ксерокс придумала, чтобы показать, что именно ее девайсы лучше - это решается коэффициентами), который и покажет, какая гипотеза лучше. Скомбинируй лучшее - получишь идеальное. Всем вломы этим заниматься, поэтому я с нетерпением жду, когда очередной стандартизатор научит меня жить лучше, больше, веселее....
(12)
кто не переделывает
Ну вот наса писало, что делаем так, как сто лет назад делали, ибо проверено. Потом пришел Маск, стал делать так, как никто до него не делал, и где сейчас наса без Маска? При том они постоянно переделывают, т.к. технологии уходят вперед. Времена, когда делали с первого отреза (после семи измерений) канули в лету, ибо цель, в которую "стреляешь", все быстрее двигается. И все, что делаешь на века, уже можно будет не делать совсем. Отсюда и основной принцип аджайла: работающий продукт с ошибками лучше самого идеального нереализованного концепта.
(22)
На самом деле принцип agile -- "release early, release often". И для этого применяются различные техники, минимизирующие количество вносимых багов и затраты на них: продукт считается работающим, если он соответствует спецификации; внесение изменений небольшими контролируемыми порциями уменьшает риск где-нибудь ошибиться. Продукт "с ошибками" -- не "работающий", из-за этих самых ошибок; но любые неполадки в случаях, не описанных в спецификации, считаются не "ошибками", а неопределенным поведением.
(22)
Еще одна техника, позволяющая достичь высокой скорости разаботки -- по максимуму использовать существующие наработки (в т.ч. библиотеки): не писать код с нуля, а использовать подходящий существующий, уже отлаженный, протестированный, учитывающий неочевидные случаи, с которыми столкнулись на практике. А чтобы существующий можно было использовать, не тоня в багах, придумали техники разработки, минимизирующие даже те вносимые баги, которые проявятся только потом, при адаптации, причем минимизирующие автоматически, просто следуя этим принципам при написании кода. В их числе: separation of concerns, DRY principle, YAGNI principle, loose coupling (русских устоявшихся терминов нет, поэтому оригинальные понятнее). Последний пункт реализуется за счет модульности и интерфейсов. В 1С с этим плохо из-за отсутствия модульности в платформе, но это лишь значит, что нам приходится брать дело в свои руки и обеспечивать модульность самостоятельно, без поддержки со стороны 1С.
(22)
Я не изучал принципы работы Маска, но уверен, что он взял за основу существующие технологии, в т.ч. разработанные НАСА, а не проходил заново весь прогресс космической отрасли с 50-х. И из процессов, скорее всего, заимствовал то, что еще актуально, выкинув ставшее ненужным из-за того, что технологии стали надежнее, и из-за того, что он частник и ему не надо согласовывать каждый чих с десятком инстанций.
Отсюда и основной принцип аджайла: работающий продукт с ошибками лучше самого идеального нереализованного концепта.
На самом деле принцип agile -- "release early, release often". И для этого применяются различные техники, минимизирующие количество вносимых багов и затраты на них: продукт считается работающим, если он соответствует спецификации; внесение изменений небольшими контролируемыми порциями уменьшает риск где-нибудь ошибиться. Продукт "с ошибками" -- не "работающий", из-за этих самых ошибок; но любые неполадки в случаях, не описанных в спецификации, считаются не "ошибками", а неопределенным поведением.
(22)
Времена, когда делали с первого отреза (после семи измерений) канули в лету, ибо цель, в которую "стреляешь", все быстрее двигается.
Еще одна техника, позволяющая достичь высокой скорости разаботки -- по максимуму использовать существующие наработки (в т.ч. библиотеки): не писать код с нуля, а использовать подходящий существующий, уже отлаженный, протестированный, учитывающий неочевидные случаи, с которыми столкнулись на практике. А чтобы существующий можно было использовать, не тоня в багах, придумали техники разработки, минимизирующие даже те вносимые баги, которые проявятся только потом, при адаптации, причем минимизирующие автоматически, просто следуя этим принципам при написании кода. В их числе: separation of concerns, DRY principle, YAGNI principle, loose coupling (русских устоявшихся терминов нет, поэтому оригинальные понятнее). Последний пункт реализуется за счет модульности и интерфейсов. В 1С с этим плохо из-за отсутствия модульности в платформе, но это лишь значит, что нам приходится брать дело в свои руки и обеспечивать модульность самостоятельно, без поддержки со стороны 1С.
(22)
Потом пришел Маск, стал делать так, как никто до него не делал, и где сейчас наса без Маска?
Я не изучал принципы работы Маска, но уверен, что он взял за основу существующие технологии, в т.ч. разработанные НАСА, а не проходил заново весь прогресс космической отрасли с 50-х. И из процессов, скорее всего, заимствовал то, что еще актуально, выкинув ставшее ненужным из-за того, что технологии стали надежнее, и из-за того, что он частник и ему не надо согласовывать каждый чих с десятком инстанций.
(23)
Вот нейрояндыкс сколько выдал:
И, что самое важное, - нет той самой серебряной пули. Ну, конечно, кроме экселя и иже с ними, в которых, как всем известно, все и ведут всю свою бухгалтерию. 1С-неги, рыдайте!
С другой стороны, ракетчики мне говорили не раз, что повторное использование - это зашквар, типа там все одноразовое, хотя вроде как технологии на века. С третьей стороны, никому не нужны на орбите телекомуникационные спутники на двадцать лет - они через три года устареют, ибо устаревают протоколы. Сегодня эдж, завтра 3Ж, послезавтра ЛТЕ, а на следующей неделе 5Ж, на котором никто не планирует останавливаться. Поэтому массовые запуски спутников раз в неделю - это то будущее, которое в 50-х годах еще кому-то снилось, а к 80-м стало скорее влажной мечтой. Потом пришел Маск, сделал многоразовость, что снизило стоимость запуска при двух запусках в неделю на порядок. А если раз в год запускать - да, смысла никакого.
И да, сравните с SLS. Они вместо того, чтобы сто раз запускать болваники из нержавейки, тестируя и меняя системы налету, запилили походу водопадом ракету за лярды, которая еле-еле с пятого раза полетела вся целиком, но по итогу полета ее нужно переделать чуть меньше, чем совсем.
На самом деле принцип agile
На самом деле принципов в аджайле сильно больше одного, но сильно меньше стольки, чтобы в них окончательно запутаться.
Вот нейрояндыкс сколько выдал:
Некоторые принципы Agile:
Люди и взаимодействие важнее процессов и инструментов. Этот принцип подчёркивает значимость коммуникации между участниками проекта. 14
Работающий продукт важнее исчерпывающей документации. Клиенту в первую очередь нужен рабочий продукт, а не красочные презентации. 14
Сотрудничество с заказчиком важнее согласования условий контракта. Работа по Agile предполагает активное вовлечение заказчика в процесс разработки. 14
Готовность к изменениям важнее следования плану. Метод Agile признаёт, что предвидеть все изменения и необходимые корректировки заранее невозможно. 14
Ещё несколько принципов Agile:
Приоритет — удовлетворить клиента. Цель команды — обеспечить его удовлетворение за счёт быстрого и непрерывного предоставления полезного продукта. 2
Изменять требования даже на поздних этапах — это нормально. Гибкость — ключевая черта Agile, поэтому гибкие методологии управления проектами разрешают и даже поощряют изменения требований по ходу работы. 2
Промежуточный результат нужно показывать клиенту как можно чаще. Agile предлагает делить работу на короткие итерации, в конце которых команда предоставляет заказчику работающий продукт или его часть. 2
Заказчик и разработчики совместно работают на протяжении всего проекта. Постоянное общение помогает точно понимать требования, уточнять детали и вносить изменения по ходу проекта. 2
Люди и взаимодействие важнее процессов и инструментов. Этот принцип подчёркивает значимость коммуникации между участниками проекта. 14
Работающий продукт важнее исчерпывающей документации. Клиенту в первую очередь нужен рабочий продукт, а не красочные презентации. 14
Сотрудничество с заказчиком важнее согласования условий контракта. Работа по Agile предполагает активное вовлечение заказчика в процесс разработки. 14
Готовность к изменениям важнее следования плану. Метод Agile признаёт, что предвидеть все изменения и необходимые корректировки заранее невозможно. 14
Ещё несколько принципов Agile:
Приоритет — удовлетворить клиента. Цель команды — обеспечить его удовлетворение за счёт быстрого и непрерывного предоставления полезного продукта. 2
Изменять требования даже на поздних этапах — это нормально. Гибкость — ключевая черта Agile, поэтому гибкие методологии управления проектами разрешают и даже поощряют изменения требований по ходу работы. 2
Промежуточный результат нужно показывать клиенту как можно чаще. Agile предлагает делить работу на короткие итерации, в конце которых команда предоставляет заказчику работающий продукт или его часть. 2
Заказчик и разработчики совместно работают на протяжении всего проекта. Постоянное общение помогает точно понимать требования, уточнять детали и вносить изменения по ходу проекта. 2
И, что самое важное, - нет той самой серебряной пули. Ну, конечно, кроме экселя и иже с ними, в которых, как всем известно, все и ведут всю свою бухгалтерию. 1С-неги, рыдайте!
Еще одна техника, позволяющая достичь высокой скорости разаботки -- по максимуму использовать существующие наработки
Хорошая техника. Особенное, если нет текучки кадров и все разрабы в курсе, как эти все уже сделанные фичи работают. А потом приходит новый разраб, старые уходят, и целые подсистемы идут в лес, даже не смотря на то, что написаны они были офигенно! Но, например, для ОФ, а сейчас УФ. Или для УФ, а сейчас новый интерфейс на подходе, в котором понефрили все, что только можно, а народ только-только к такси привык, да и то только в компактном режиме, ибо хочется впихнуть невпихуемое.
но уверен, что он взял за основу существующие технологии
Так с XIX века особо-то ничего прилично нового и не придумали, если не считать языков программирования, которые ну может быть предельно описали в середине XX века.
С другой стороны, ракетчики мне говорили не раз, что повторное использование - это зашквар, типа там все одноразовое, хотя вроде как технологии на века. С третьей стороны, никому не нужны на орбите телекомуникационные спутники на двадцать лет - они через три года устареют, ибо устаревают протоколы. Сегодня эдж, завтра 3Ж, послезавтра ЛТЕ, а на следующей неделе 5Ж, на котором никто не планирует останавливаться. Поэтому массовые запуски спутников раз в неделю - это то будущее, которое в 50-х годах еще кому-то снилось, а к 80-м стало скорее влажной мечтой. Потом пришел Маск, сделал многоразовость, что снизило стоимость запуска при двух запусках в неделю на порядок. А если раз в год запускать - да, смысла никакого.
И да, сравните с SLS. Они вместо того, чтобы сто раз запускать болваники из нержавейки, тестируя и меняя системы налету, запилили походу водопадом ракету за лярды, которая еле-еле с пятого раза полетела вся целиком, но по итогу полета ее нужно переделать чуть меньше, чем совсем.
(24)
Я написал главный принцип -- какой в нем ключевой прорыв по сравнению с водопадом.
Ориентированность на клиента, доверие команде разработчиков самим вырабатывать свои бизнес-процессы -- это независимые от технологии разработки, параллельно выработанные best practices.
(24)
Если новый разраб отправляет все на слом вместо того, чтобы изучить и взять логику, которая останется прежней, это говорит о его уровне компетентности. Со своим новым кодом он будет снова наступать на все грабли, на которые наступили его предшественники. См.
Если интерфейс меняется, поменяется только логика, непосредственно взаимодействующая с ним, а бизнес-логика останется той же, максимум перераспределится по процедурам, если новому интерфейсу требуются другие точки входа.
(24)
С XIX века техническая революция сменилась на научно-техническую. Теперь уже не проблема придумать что-то новое, требуется придумать что-то, что лучше, или, по крайней мере, не хуже того, что уже придумано. Так что акцент сместился на изучение, использование и обобщение существующих наработок, чтобы двигаться дальше, переводя количество в качество.
(24)
Так и было, т.к. технологии слишком плохо переносили повреждения от космоса. НАСА обожглась на шаттлах: они формально могли летать много раз, но фактически после каждого полета их приходилось тщательно перебирать по винтику, затраты, примерно равные постройке нового. Полагаю, Маск использует более простые конструкции, более высокотехнологичные материалы и более совершенные методы диагностики, которые позволяют намного дешевле продиагностировать все части на пригодность к дальнейшему использованию.
(24)
Сам спутник, может, и не нужен. А вот чертежи, по которым при смене стандарта связи можно сделать такой же, заменив один модуль, весьма полезны.
На самом деле принципов в аджайле сильно больше одного
Я написал главный принцип -- какой в нем ключевой прорыв по сравнению с водопадом.
Ориентированность на клиента, доверие команде разработчиков самим вырабатывать свои бизнес-процессы -- это независимые от технологии разработки, параллельно выработанные best practices.
(24)
А потом приходит новый разраб, старые уходят, и целые подсистемы идут в лес, даже не смотря на то, что написаны они были офигенно! Но, например, для ОФ, а сейчас УФ. Или для УФ, а сейчас новый интерфейс на подходе, в котором понефрили все
Если новый разраб отправляет все на слом вместо того, чтобы изучить и взять логику, которая останется прежней, это говорит о его уровне компетентности. Со своим новым кодом он будет снова наступать на все грабли, на которые наступили его предшественники. См.
Если интерфейс меняется, поменяется только логика, непосредственно взаимодействующая с ним, а бизнес-логика останется той же, максимум перераспределится по процедурам, если новому интерфейсу требуются другие точки входа.
(24)
Так с XIX века особо-то ничего прилично нового и не придумали, если не считать языков программирования
С XIX века техническая революция сменилась на научно-техническую. Теперь уже не проблема придумать что-то новое, требуется придумать что-то, что лучше, или, по крайней мере, не хуже того, что уже придумано. Так что акцент сместился на изучение, использование и обобщение существующих наработок, чтобы двигаться дальше, переводя количество в качество.
(24)
С другой стороны, ракетчики мне говорили не раз, что повторное использование - это зашквар, типа там все одноразовое, хотя вроде как технологии на века
Так и было, т.к. технологии слишком плохо переносили повреждения от космоса. НАСА обожглась на шаттлах: они формально могли летать много раз, но фактически после каждого полета их приходилось тщательно перебирать по винтику, затраты, примерно равные постройке нового. Полагаю, Маск использует более простые конструкции, более высокотехнологичные материалы и более совершенные методы диагностики, которые позволяют намного дешевле продиагностировать все части на пригодность к дальнейшему использованию.
(24)
С третьей стороны, никому не нужны на орбите телекомуникационные спутники на двадцать лет
Сам спутник, может, и не нужен. А вот чертежи, по которым при смене стандарта связи можно сделать такой же, заменив один модуль, весьма полезны.
(25)
Но... Умные люди в XIX веке думали, куда девать лошадиные какашки. Ну вы в курсе, да?
а бизнес-логика останется той же
Я под стол упал, сорри...
С XIX века техническая революция сменилась на научно-техническую.
Сейчас пятый техуклад уже, так что оно сменилось с XIX века точно больше одного раза. Сейчас его ломают, чтобы временно переехать на шестой, который уже на какое-то приличное время сменится на седьмой. Там и дальше есть вполне предсказуемые шаги.
Но... Умные люди в XIX веке думали, куда девать лошадиные какашки. Ну вы в курсе, да?
Сам спутник, может, и не нужен. А вот чертежи
А вам нужен чертеж zx спектрума сегодня? Чета сомневаюсь. Радио, которое Попов изобрел, оно не поменяло принцип за полтора века. Технология в сути не меняется - меняется реализация. Аналоговое превращается в цифровое, дальше увеличивается частота, потом добавляется широкополосные приемники/передатчики, заворачиваются все в более маленькие коробочки, потребляют все меньше энергии. Чертежи XIX века и современные совершенно ничего общего не имеют, ну кроме колебательного контура.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот