Добрый день.

Написал решение, позволяющее сохранять качество конфигурации при командной разработке.

Предполагается, что вы уже используете хранилище конфигурации (лучше два: одно текущее и одно релизное) при разработке. В таком случае мое решение позволяет подключаться к хранилищам, загружать из них историю изменений и строить по ним отчеты в 1С. В частности, видеть динамику изменений за период.

Для себя я так мониторю изменения конфигурации за неделю: смотрю, какие обьекты были добавлены, изменены либо удалены и кем.

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

Решение доступно в патреоне http://www.patreon.com/andrew_chuprina . Стоит 3.99$. Около 250 руб - стоимость электронной книги. При подписке вы получаете доступ к постам, в которых есть ссылки на скачивание. Отписаться можно в любое время. Но решение будет еженедельно развиваться.

Создаю инструмент, призванный превратить программиста в архитектора 1С.

Короткое демо-видео: https://youtu.be/0PdsP4gU-Ak

Видео? Скрины?

(1) Сначала надо заплатить )

Свое EDT?
С увеселительными играми и приятными дамами?

(0) "Для себя я так мониторю изменения конфигурации за неделю: смотрю, какие обьекты были добавлены, изменены либо удалены и кем. " А, GIT чем плох?

(1) + 1. Где посмотреть?

Видосы покажи.

(1) Скрин отчета: https://imageshack.com/a/img921/3114/w4qCeu.png

(5), (6), (1) Точно, забыл про самое главное. Видео будет вечером, как до домашнего компа доберусь.

(3) Вроде того :-)

(4) GIT заместо типового хранилища разработки? Месье знает толк в извращениях...

(7) На извращение больше похоже, то что в (0)

(8) Каждому свое

(9) А, как это сказывается на "Поддержание качества конфигурации"?

(10) + как список изменений влияет на качество кода или алгоритма? Или, что вы имеете введу по качеством?

(11) *виду

Выложи фрагмент .

(13) Фрагмент чего?

(14) А ответить на вопрос в (11) ?

Ограничения (платформы, релизы, ОФ-УФ)? Штатные ли средства работы с хранилищем, или (не поминаем всуе) забанит и проклянёт инструмент?

Что-то я не вижу контроля качества...  

"В таком случае мое решение позволяет подключаться к хранилищам, загружать из них историю изменений и строить по ним отчеты в 1С." - какую информацию можно проанализировать в отчете?  Выложил два раза один и тот же объект в хранилище - косяк? Это неявный признак качества.

Где описаны способы контроля качества?

(14) Зачем отвечать, если человек задает очевидные вопросы?
Мониторинг изменений конфигурации напрямую влияет на ее качество.

(16) Реализовано штатными средствами: параметрически запускается конфигуратор (поэтому релиз и ОФ-УФ любые), на выходе выдавая mxl-файл изменений. Этот файл распарсивается из загружается в мою конфу. Конфа на УФ Такси. В конфе по загруженной инфе строятся отчеты.

(17) Пока речь о мониторинге изменений больше. Знать, что творится в конфигурации за неделю например. Не спамят ли ее объектами. Плюс, привязка объектов к задачам.

Контроль качества кода сложно сделать. Есть типовая конфа которая это делает -  Автоматизированая проверка конфигураций. Чтоб она нормально работало ее нужно знать и много ее пилить.

(18) "Мониторинг изменений конфигурации напрямую влияет на ее качество. " каким образом?

(20) Ну, увидел ты, что Вася три раза изменил справочник Номенклатура и что? Причем тут качество?

(20), (21) Не плодятся новые справочники, перечисления, константы и формы, а используются уже существующие.

как отчет по хранилищу может увеличить качество?
Качество - это тесты + код ревью.
Но для этого никакое решение за 3.99 не нужно

По сабжу:"Поддержание качества..".
А по сути-Отчет об изменениях конфигурации. Так бы задал тему и конфигурацию.

(22) Странно, а если они нужны? Как отчет поможет это определить?
И что за выражение "Не спамят ли ее объектами"? У тебя там кто-то сидит и плодит просто так новые объекты?
Бред какой-то или я чего-то не понимаю.

Зря деньги потратил на тему. Ни продукта, ничего.
Фигня какая (цы) не мое

(25) У него "группа разработчиков"...)

Ох уже эти 1Сники... Не умеют делать коммерческие проекты.
Продукт нужно подготовить! раскрыть. презентации...

а тут фигня какая то.. отчетики по конфигурации и автор называет это качеством.

(24) Это разный взгляд на одно и то же.

Вот я сейчас вроде как паяю датчик на ардуину. А в дневном отчёте напишу, что интегрировал RFID в УТ 10. В КП уже будет про "созданная учётная система исключает возможность ошибочных действий пользователя".

(0) Ты тут не первый день, поэтому на критику смотри не всерьёз. Дерзай!

(23) Чтобы написать тесты, надо знать, что тестировать. Чтобы знать, что тестировать, нужны изменения за неделю например.

(25) Когда в подчинении будет от 5-ти разработчиков, поймешь.

(28) По отсутствию вменяемой презентации согласен. Исправлюсь.

(29) Благодарю! Со временем прикручу функциональности в конфу. Но очень хотелось с чего-то начать, отправную точку получить. Поэтому опубликовал сегодня.

(30) как я понимаю ты совсем далек от темы тестирования, да?

(31) Куда уж мне. За 13 лет в 1С ни разу не тестировал.

(18) Не вижу в отчете практического применения. Посмотреть изменения можно и в хранилище.

Показывать кому-то извне тоже смысла нет. Потому как то, что хранится в хранилище - это внутренняя кухня ИТ-отдела.

Получается отчет ради отчета.

Расходимся, с качеством сабж никак не связан.

Кому не жалко, заплатите 250 р и выложите в общий доступ.

(30) Стесняюсь спросить. У тебя в подчинение больше 5 разработчиков? Есть среди них архитектор 1С?

(36) Стесняются в бане. Мы не в бане. Не стесняйся.

(32) На какой технологии тесты писал?

(37) Ответь

(38) Хочется поговорить о тестах - заводи свою рекламную ветку. Здесь о (0) речь.

(39) 1 штатный и 4 внештатных. За последними нужен глаз да глаз. Архитектора нет. Я за него.

(40) Это рекламная оплаченная ветка?
Тогда молчу

(30) "Чтобы знать, что тестировать, нужны изменения за неделю например." Отчет по изменениям ни как тебе не покажет, что тестировать. Это просто отчет.
Раз ты рекламируешь свой продукт, так будь добр объясни зачем всё это?

(42) Обычно те кто разрабатывает новый функционал - отлично знают что нужно тестировать

(43) Ну, так ТС не разработчик, он смотрит отчет по изменениям.

(0) Изменения в коде можно увидеть или только изменённые объекты?

(45) Только измененные объекты

Зачем изобретать велосипед, когда наше светлое будущее - EDT+GIT?

(46) Всё равно не понимаю, ну увидел ты измененный справочник Пользователи и что? Как тебе это поможет?

(0) Как мне этого не хватало, когда я работал начальником отдела программистов!

А есть привязка к проекту? Может хэштеги прикрутить?

(48) пошел и "поговорил по душам" с разработчиком

В общем так и неясно, чем сабж отличается от встроенного в платформу отчета по истории хранилища.
Может там отчет мега-красивый/удобный - так хоть бы скриншотов накидал.

>> сохранять качество конфигурации при командной разработке
Каким боком тут качество? Как оно измеряется до и после внесения изменения? Сохранение означает не улучшение?
Простенький отчет по журналу регистрации на предмет ошибок для качества будет на порядок полезней.
Что уж про смоук-тест говорить.

>> превратить программиста в архитектора 1С.
Чувак вообще в курсе, чем архитектор занимается?

(7) так ведь история хранилища с отбором по разработчику прекрасно покажет, что изменял тот самый разработчик. Какой смысл?

(52) Просто внешняя приблуда надсмотрщика для централизованного наблюдения без необходимости подключаться к каким-то там хранилищам и всему такому

(47) как-то грустненько с этими EDT. Фирма 1С развивает EDT как среду разработки, а на родной конфигуратор почему-то подзабивает. Хотя изначально писали, что EDT это для заманивания сторонних разработчиков, кодящих на англоязычных ЯП, чтобы те в 1ске пользовались привычными инструментами.

(54) На партнерке в открытую пишут на фич-реквесты, что такая-то фича будет реализована в следующей версии ЕДТ, а в пофигураторе - крайне маловероятно (даже не говорят, что "пожелание записали") :)

(49) Спасибо за поддержку!

Привязка задачи к проекту / подсистеме и поддержка хештегов будут в течение месяца.

(52) Ну выдаст она под сотню изменений и что, в каждое заходить за перечнем объектов? Единого перечня объектов за период она не даст.

(56) как ты потом работаешь с перечнем объектов?

(7) а в чем извращение? Был опыт использования GIT вместо хранилища?

(58) ну далек человек от промышелнной разарботки, может дойдет когда-нибудь

(59) ну я так и подумал. GIT по сравнению с обычным хранилищем конечно огонь. Мозг надо просто перенастроить немного

(57) Пока только смотрю, чтобы не надобавляли лишнего и не трогали, что не надо.

На перспективу буду связывать с задачами, подсистемами и проектами. Чтобы и через полгода при необходимости вспомнить, какой объект зачем менялся и что послужило первопричиной создания того или иного объекта. И чтобы не тратить время на объяснение этого новым коллегам. Чтобы они могли при необходимости по объекту отобрать все задачи, завязанные на него.

(58) Есть опыт использования GitHub на не 1С-программировании. Хранилище многое упрощает. А Git - лишний геморой при соизмеримой пользе. Зачем оно надо?

(59) Ага-ага. Только не путайте цель и средство. Промышленная разработка хороша с умом, а не когда модные инструменты превращаются в самоцель и технологический невроз.

(60) Какие выгоды дает Git? Необходимые в 1С-разработке

(56)
https://d.radikal.ru/d19/1902/74/d1de7ec93c47.png

(63) Так покажите сформированный результат.

(62) 1. полноценная распределенная система хранения версий
2. практически  моментальное выяснение, кто, когда и зачем добавил или изменил ту или иную строку кода
3. ветки!
4. хранение внешних отчетов и обработок

(65) 1. Общие слова. Можно конкретику?
2. (0) это решает
3. Сдались вам эти ветки?
4. Внешние отчеты и обработки = хаос в конфигурации и требованиях

(65) + и это еще без всяких разных CI/CD

(66) не рашает. Что конкретно изменено не увидишь, нужно версии сравнивать - а это ппц как долго

(66) а как вы рабочую обновляете? а если в хранилище незаконченные задачи?

(69)+ Да, интересно, зачем 2 хранилища? Что за релизное хранилище?

(66) 1. Не зависит от сервера, который хранит исходники

а про ветки вы это зря. они не нужны до тех пор пока не попробовал.

(71) + и кстати да, вы сами предлагаете некое подобие веток, когда говорите про два хранилища

Зачем изобретать велосипеды, если в мире это все уже проходили 10 лет назад?

(71) Это как с наркотой: не нужна до тех пор, пока не попробовал )

(69), (70)
Хранилище разработки - Единая свалка всех разработок, в том числе находящихся на стадии разработки / тестирования.

Релизное хранилище - Сюда попадает только оттестированная функциональность для обновления рабочей базы. К этому хранилищу подключена рабочая база.

(72) Верно. Достаточно двух веток. Зачем остальные в _прикладном_ программировании - мне не понятно.

(74) Тестируете вы конфигурацию из разработки или релиза?

(75) Тестируем из разработки
Для релизной - только автотесты (в планах правда)

(74) ну например работаете вы над документом над каким то, например РТиУ. Захватили его в хранилище и дорабатываете. Потом прилетает срочная задача по изменению этого же документа и вам по хорошему надо сохранить конфигурацию в файл, отменить захват в хранилище, захватить снова, сделать срочную задачу, поместить в хранилище, объединить с сохраненной конфигурацией, продолжить работу над первой задачей. В Git все это разруливается одни действом по созданию новой ветки.

(76) получается проблема с тем, что пока вы тестируете и исправляете разработку, туда попадут новые доработки

(76) Тут методика описана от 1С
https://its.1c.ru/db/metod8dev#content:5811:hdoc

(79) Пардон, https://its.1c.ru/db/metod8dev#content:5905:hdoc

(78) Все верно, но первопричина не в инструменте.

Первопричина в нежданчиках - прилетающих срочных задачах. И пока они будут прилетать, коммунизма не наступит. Срочно прилететь может только критический баг, но это не проблема, т.к. лечится оперативно захватом и исправлением в рабочей конфигурации (хранилище которой всегда свободно).

А если срочно прилетают задачи на разработку, надо наводить порядок в приоритизации работы отдела разработки 1С, а не идти на поводу.

(80) Что конкретно из этой методики вы видите отсутствующим / противоречащим (76)?

(81) ну не привязывайтесь к срочности. подумайте о кейсе, когда вы правите 5 модулей неделю, а второму разработчику надо поправить один из этих модулей тоже, но сегодня.

(81) либо у вас в отделе людей не так много, либо задачи неглобальные.
Использование 3х контуров (+хранилищ) рекомендовано 1С, а также личным опытом коллег:
http://catalog.mista.ru/public/646867/

(61) "На перспективу буду связывать с задачами, подсистемами и проектами. Чтобы и через полгода при необходимости вспомнить, какой объект зачем менялся и что послужило первопричиной создания того или иного объекта."

Для этого принято заполнять комментарий при помещении в хранилище

(66) "Внешние отчеты и обработки = хаос в конфигурации и требованиях" это еще что за бред?

(82) Тогда проблема архитектуры / постановки задач. Не ставьте задачи двум разработчикам на доработку одного и того же объекта либо архитектурно разбейте его на два, если возникает такая необходимость.

Не самом деле проблема не в том, что инструмент чего-то не позволяет, а в том, что это не надо.

(83) У нас задача еще глобальнее, чем в вашем примере: обеспечить стабильность контура разработки. Чтобы контур разработки был уже работоспособен. А не только на этапе контура тестирования была работоспособность. Система с двумя контурами выигрышнее за счет снижения издержек на администрирование.

(84) Как вы получите группировку по задаче стандартными средствами?

(85) Оставайтесь при своем компетентном мнении.

(83) о, у нас примерно как в статье

с несколькими хранилищами не удобно cherry pick делать.
То бишь исправил ошибку на рабочей - ручками перенеси в хранилище разработки

(86) "Как вы получите группировку по задаче стандартными средствами?"

Очень легко. Нужно просто поместить объекты, изменяемые в рамках одной задачи, за одно помещение
Конфигурация -> Хранилище  -> Хранилище
Разработчик делает отбор по своему пользователю. Выделяет несколько объектов, измененных в рамках одной задачи, и помещает их, заполнив комментарий ссылкой на задачу. Далее в истории хранилища всё наглядно отображается. Видно, например, что Вася Пупкин одним махом поместил:
Роль.Кладовщик
Справочник.Склады
Документ.ПриходнаяНакладная
Документ.РасходнаяНакладная
а в комментарии красуется номер задачи, по которой Вася внёс эти изменения

(88) и в чём тут сложность?

(89) Это ты типа ноу-хау делишься? ))

(91) нет, это типа как многие работают подсказываю

(89) Как заносить в хранилище понятно.

Как группировку в отчете стандартными средствами получить?

Когда у вас по задаче от 10+ изменений и надо получить единый список объектов.

(93) ну так помещаем за раз единым списком, потом в истории хранилища этот единый список будет виден

http://www.picshare.ru/view/9873650/

Изменения то чем помогут?
где поставленная задача разбитая на этапы?
изменения то не с потолка берутся

(34) по ходу

(94) Это хорошо на абстрактных примерах получается единым списком. На практике по задаче (не особо сложной) в разное время может быть от 5-ти помещений в хранилище. По моим задачам - от 10-ти. Да и держать объекты только затем, чтобы потом поместить их единым списком не есть хорошо.

(95) Поставленная задача пока во внешней учетной системе. А в хранилище - только гиперссылка на нее. У себя мы используем Redmine

(96) Да ладно. Даже общение по теме с умными людьми развивает. Мы же здесь умные люди, да?

(43) если бы так было, то ошибок и проблем было бы минимум. а мне кажется - что такого нет...

(99) Тоже склоняюсь к мнению, что тестировать следует тем, кто не ведет разработку. Оптимально - не программистам

(100) тут продуктивнее - разрабатывать через тестирование.
я пробовал тестить сложную систему 1Сную. бесполезняк. настрйоки столь многоварианты, что тестирование по одной ветке сценария практически ничего не дает. а чтобы покрыть все возможные ветки - это капец, я слабо представляю. вдобавок когда поведение системы во многом определяется действиями юзера.
- проверить, что будет если отсканирован нормальный ШК (пойдет дальше по 10-12 возможным вариантам или свалиться - зависит от последующего кода реализации)
- проверить что будет если остканирован совершенно левый код
- проверить если отсканирован правильный шк, но который не ожидается в данном месте
- проверить который ожидается в данном месте, но которого нет в системе
- проверить что будет если на один ШК возможны два разных объекта (поведение рулится отдельной галкой).
- проверить что будет если сканируется ШК а фокус стоит в поле ввода количества...
итд... итд..
что тестировать? как тестировать? если не в теме всех этих тестирований (что такое дымовые тесты?) и все это тестирование не вшито в процесс разработки изначально и нкогда тестирование неотделимо от процесса разработки - если этого нет - то все это тестирование очень проблематично... притом что некоторые траблы выявляются только на вполне определенном наборе исходных данных/ситуации (ну вот так вот получилось.. по како йпричрне - хз)...

(101) Я предпочитаю исходить из некоего красного контура. Вариантов использования / операций / функций, которые система должна гарантированно поддерживать. И опираясь на эту основу строить тесты.

Другое дело, что в процессе разработки сами функции как правило теряются. И в конце ты уже не помнишь в голове весь скоуп (перечень) функций, а только то, что делал в последний момент. В итоге в тесты попадает только разработанная в последний момент функциональность.

Моя конфигурация - первый шаг к решению проблемы гиперзабывчивости. По крайней мере иметь хотя бы перечень задач / объектов с настраиваемыми в СКД отборами.

Постепенно буду наращивать функциональность, добавляя привязку к функциям, операциям, вариантам использования. Чтобы можно было связать метаданные, ТЗ и ожидаемое поведение системы воедино и на основании него строить тесты.

(0) Короткое демо-видео: https://youtu.be/0PdsP4gU-Ak

(101) тут просто все в финансирование упирается. Нет денег - нет тестов. Есть деньги - пофиг сколько вариантов надо обработать.

(104) Тогда это уже не тестирование, а освоение бюджета

(105) Тестирование всегда освоение бюджета. Или ты готов бесплатно писать код?

(106) Я про "пофиг сколько вариантов надо обработать." разумная целесообразность нужна. Никто не говорит работать за бесплатно. Но и "пофиг сколько вариантов" - другая крайность

(102) мне кажется что ты куда-то не в ту степь идешь.
если строить тестирование - то и юзать всякие ванесссы, тдд и прочее - народ-то достаточно много наваля по этой теме. и вообщем болееменее складно все.
тем более на ИС сейчас как раз идет серия больших публикаций по тестированию как это сделано со всеми этими упомянутыми мно a феньками

(102) "Я предпочитаю исходить из некоего красного контура. Вариантов использования / операций / функций, которые система должна гарантированно поддерживать. И опираясь на эту основу строить тесты. "
- фу, бяка.
простой вопрос: (хрен с ним что я тупой).
есть функция.
есть входные параметры.
внимание вопрос: надо ли покрывать тестами поведение функции при некорректных параметрах?
мы же рассчитываем что функция будет вызываться ПРАВИЛЬНО? или не будем на это рассчитывать?

А что, в платформенном меню этого ничего нет?? Вроде и историю вижу, и кто чего изменил тоже. Ну единственно, что не в форме отчетов 1с.

(97) видимо у вас не всё гладко с организацией разработки, поэтому ваша практика и не позволяет помещать все объекты по одной задаче за раз. У нас с этим никаких проблем нет (over 10 человек пыхтят в одном хранилище)

(103) Фигня какя-то, ну опять - видишь ты, что объект изменился и что? А что было изменено? Трех минутное видео ни о чем. И за это хотят 250р? Зачем?

(108) Ванесса отобьётся только для больших проектных команд или у тех, кто пилит свою коробку. Более простые альтернативы тоже нужны.

(109) Пока не понял, к чему ты клонишь.

>надо ли покрывать тестами поведение функции при некорректных параметрах?

Конечно, надо. В разумных пределах.

(109) какие ещё тесты? у чувака качество простым отчетом по истории хранилища поддерживается)

(115) +100)

(30) Неправильно. Чтобы знать что тестировать - надо иметь документацию на продукт, где описано его поведение во всех предусмотренных ситуациях. Что там поменяли - вообще пофиг, главное чтобы ТЗ соответствовало.

(115) Ой, чувак, расскажи, как ты поддерживаешь качество )

Бред какой-то. Я может нихрена не понимаю,  но ещеив 80-ых меня учили что единственным реальным тестом является прогон алгоритма на всем возможном наборе исходных данных. То бишь только это можно назвать "все предусмотренные ситуации".

(119) если я правильно помню, то тестировать надо 3 варианта входящих данных: верхняя и нижняя границы + что-то посередине.

(114) нифига не понял. Основа, на которую опираемся - как сам писал - чтоифункция работает в подобающем окружении - мы ведь её для этого написали, не правда ли? Зачем тестировать на кривых входных параметрах?

(121) Потому, что вызывающий эту функцию код мог "сломаться", и в этом случае поведение функции не должно быть неопределённым.

(118) Да, что такое качество в твоем понимании? Качество чего?

Зачем? Если вызывающий код "сломался", то пофиг. Даже во вред будут попытки поддерживать работоспособность неправильного кода, мы ведь должны обеспечивать правильную работу?

(124) Не работоспособность поддерживать, а не допускать неопределённого поведения, чтобы проблема не пошла дальше этой функции.

(123) Я всю ветку распинаюсь. Расскажи сначала и ты что-нибудь про качество.

(126) Ты про качество в твоем понимании еще не слова не сказал.

(126) Мне зачем рассказывать, не я слона продаю.

(127) качество - это когда никто лишних объектов не клепает

(109) конечно нужно.
В этом случае может быть ошибка, но программа недолжна падать

(129) Это был сарказм?

(131) Это краткий пересказ ветки

(132) Краткость сестра таланта)

Предлагаю уже переименовать ветку в "Контроль изменения объектов в хранилище" и разойтись.

Управлением качеством здесь и не пахнет.

(134) Контроль — одна из функций управления. Есть ещё планирование, учёт и план-фактный анализ. Так что это шаг в правильном направлении.

(135) Кто ж спорит. Вопрос лишь в формулировке.

Контроль изменения объектов в хранилище - это шаг в правильном направлении. Но этого недостаточно для контроля качества.

(135) учёт и план-фактный анализ это скорее подфункции управления. Основные функции управления - планирование, организация, мотивация и контроль

(136) вот что пишет С.Макконел про качество ПО:

ВНЕШНИЕ характеристика качества ПО:  
*Корректность — отсутствие/наличие дефектов в спецификации, проекте и реализации системы.
*Практичность — легкость изучения и использования системы.
*Эффективность — степень использования системных ресурсов. Эта характеристика учитывает такие факторы, как быстродействие приложения и требуемый им объем памяти.  
*Надежность — способность системы выполнять необходимые функции в предопределенных условиях; средний интервал между отказами.  
*Целостность — способность системы предотвращать неавторизованный или некорректный доступ к своим программам и данным. Идея целостности подразумевает ограничение доступа к системе для неавторизованных пользователей, а также обеспечение правильности доступа к данным, т. е. одновременное изменение взаимосвязанных данных, хранение только допустимых значений и т. д.  
*Адаптируемость — возможность использования системы без ее изменения в тех областях или средах, на которые она не была ориентирована непосредственно.  
*Правильность — степень безошибочности системы, особенно в отношении вывода количественных данных. Правильность характеризует выполнение системой ее функций, а не то, создана ли она корректно. Этим правильность отличается от корректности.  
*Живучесть — способность системы продолжать работу при вводе недопустимых данных или в напряженных условиях.

ВНУТРЕННИЕ характеристики качества ПО:
*Удобство сопровождения — легкость изменения программной системы с целью реализации дополнительных возможностей, повышения быстродействия, исправления дефектов и т. д.  
*Гибкость — возможный масштаб изменения системы с целью использования ее в тех областях или средах, на которые она не была непосредственно ориентирована.  
*Портируемость — легкость изменения системы с целью использования в средах, на которые она не была ориентирована непосредственно.  
*Возможность повторного использования — масштабность и легкость использования частей системы в других системах.  
Удобочитаемость — легкость чтения и понимания исходного кода системы, особенно на детальном уровне отдельных операторов.  
*Тестируемость — возможная степень выполнения блочного и системного тестирования программы и проверки ее соответствия требованиям.

(134) Ветка названа на вырост, с запасом по формулировке.

(138) Портянка из вики это прекрасно. Был бы пример практической реализации этого потока сознания - вообще бы цены не было.

(140) это не из вики, а из книги
https://www.ozon.ru/context/detail/id/138437220/

"Был бы пример практической реализации этого потока сознания - вообще бы цены не было."

Есть пример
https://ru.wikipedia.org/wiki/ITIL

туда же
https://ru.wikipedia.org/wiki/ITSM

(140) Молодой человек, если ты не читал Макконела, и даже не знаешь кто это и называешь это потоком сознания, то зачем ты вообще полез в эту сферу, сначала бы подучиться хоть чуть чуть, а потом пытаться умничать.

(143) Я уже понял, что ты записал себя в мои "учителя". Так вот, молодой человек, сначала сам чего-нибудь достигни. Потом в учителя набивайся.

(144) Нужен ты мне... просто ты чушь с умным видом несешь. Ну и конечно если достижением считать отчет по изменениям в хранилище, тогда ой.

Тебе умные люди дело говорят и подсказывают, а ты вместо спасибо выступаешь.

(141) Я читал "Code Complete" в оригинале. Говоря о книгах, на меня больше произвела впечатление "Мифический человеко-месяц". Она более жизненная и более практичная.

(141), (142) Вы меня не до конца поняли. Я в (140) про то, что теоретические измышления - это, конечно, замечательно. Но пока их реализации нет в конкретном инструменте - они просто теоретические выкладки из разряда "Космические корабли бороздят просторы большого театра". Что конкретных ITIL-инструментов реализовано много мне также известно. Но лучше, если мы в разговоре от теории перейдем к конкретным практикам, применяемым в инструментах.

(145), (146) Тебя порядком стриггерило на меня. Ты это, таблеток попей что ли.

(145) И да, твое высокомерное поверхностное суждение о людях и вещах удручает. От недалекого ума впрочем.

(147) Ну, вот начал исправляться, хотя конечно про чтение тем более в оригинале ты лукавишь имхо.

(149)
"И да, твое высокомерное поверхностное суждение о людях и вещах удручает."

"От недалекого ума впрочем."

ты вошел в рекурсию

(151) Да. Не стоит повторять чужих ошибок.

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

и еще,одна очень печальная тема-вспомогательные функции,которые нужно размещать в отдельных модулях,чтобы не писать в каждом,а также иметь возможность быстрой синхронизации между разработчиками,чтобы не было дублирование кода и изобретения велосипедов.

(154)
"В БСП всё есть" (с) :)

(153) А ведь технические комментарии к коду для описания его алгоритма - хорошая идея! Особенно, если по коду пробежится парсер и составит сводный алгоритм функции.

(154) Синтакс-помощник по собственному коду?

(156)да,технические комментарии,которые в продакшен не пойдут,а также описание функций в этих комментариях с возможностью поиска.

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

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

отдельно где то складывать описание экспортных методов для обьектов,хотя,если все грамотно во внешние модули разнести,то экспортные методы нужны только чтобы избавится от проверки типа.

(158) Внешние модули - это общие модули или внешние файлы?
Если внешние файлы, то тогда мы так к семерке возвращаемся. Там можно было в модуле вставить директиву включения внешнего файла.

(109)В оригинале лежит идея покрытия тестами не кода, а функциональности. Процент закрытия кода тестами это уже симптом по которому можно судить о качестве и количестве написанных тестов. Кто-то написал же этот функционал который в (101) так вот идея состоит в том, что ты сначала для этого функционала написал тесты, а потом уже написал сам функционал. Вопрос когда этого функционала написаны километры кода и тесты написать целая история. Я думаю надо начинать с момента когда, что-то упало в результате твоих правок. И ты написал тест. Запуск которого в следующий раз не допустит повторения подобной ситуации.