Коллеги, кто из вас проектирует программный интерфейс будущего объекта? Имеется ввиду, перед тем как нырнуть в модуль и начать писать код, проектируете ли будущий состав этого модуля? Например, список методов (процедур/функций), с описанием действий и входных параметров?
Постоянно замечаю, что сложные задачи очень чувствительны к проектированию их решения. Чем тщательнее продумаешь и спроектируешь, тем легче потом кажется решение задачи ("разложить по-полочкам").
Так вот, остро ощущается нехватка какой-то методики, позволяющей проектировать код (метаданные, интерфейс) системно. "Разобрать на мелкие составные" это понятно, но хотелось бы найти хороший и грамотный инструмент. Вроде SWOT-анализа в стратегическом планировании. Такого, чтобы сел, что-то там пораскладывал, порисовал, и вот родилась стройная структура программного интерфейса, в который осталось только код вписать.

Что можете посоветовать? К системе стандартов и методик фирмы 1С не отсылать. К книгам навроде "Совершенный код" С.Макконела тоже. Это я всё прокурил, но инструмента там не нашел.

Я о таком не слышал(

Есть конечно в EDT https://wonderland.v8.1c.ru/blog/skhema-dannykh/ но это как я понимаю не то, что Вам нужно

(0) http://v8.1c.ru/model/

(3) не совсем то. СППР предназначена для функционального проектирования конфигурации. А я спрашиваю о более частном - проектировании кода на встроенном языке. В СППР нет возможностей проектировать программный интерфейс.

так эджайл же.
проектирование кода - это в прошлом веке осталось

(0) http://macode.ru/

(6)+ http://factorized.tumblr.com/post/4180288873/programming-motherfucker

"Поэтому вот вам пошаговая инструкция для внедрения нашей замечательной методологии:

Выпишите список всей той хрени, которая должна входить в ваш продукт
Реализуйте всю эту хрень путем блять написания кода
Протестируйте написанное
Если что-то работает неправильно — то напишите блять правильный код!"

(3) она денег стоит(((

Попробую пояснить.

"Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (Dijkstra, 1972), поэтому нам — разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании." (с) С. Макконел, "Совершенный код"

так вот, не хватает такого инструмента, который позволил бы не "жонглировать" множеством информации одновременно, когда пишешь код. При разработке постоянно приходится держать в голове кучу всякой дряни: какие поля возвращает запрос1, 2, 3... N; какие поля в таблице, куда нужно складировать результат запроса; какие параметры в том "универсальном" БСПшном методе, куда нужно подать две структуры с определенными ключами, чтобы он вернул один массив... и много-много чего ещё.
Заметил по себе, что когда не держишь в голове множество информации, а сосредоточен на чем-то одном, код пишется легко и быстро, количество ошибок минимально. Хотелось бы найти подходящую методику. Самому придумать тямы не хватает

(0) Ты еще скажи, что и тесты писать надо. Да еще и раньше основного кода.

(9) Велосипед уже изобретен, называется https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)

Но у одинесовцев своё видение мира, поэтому в типовых и на БСП ты будешь писать так, как описал.

(10) раньше основного кода скорее всего нет

(12) TDD, BDD не слышали о таком? А мне вот приходилось и в 1С-сочке таким образом разрабатывать ;)

(12) Всякие адепты xDD учат, что таки да.

(13) Ну и как? Пришел к просветлению?

(7) Шикарно :)))

(13) ТДД - хрень собачья

(0) Интересно, а Rational Rose и 1С пытался кто-нить подружить?

(11) так вот откуда появилось деление модулей на ПрограммныйИнтерфейс, СлужебныйПрограммныйИнтерфейс и СлужебныеПроцедурыИФункции

(15) (17) Больше на BDD было. Непривычно, иногда больше времени уходило на написание теста чем на программу в разы. С другой стороны несколько прочищает мозги в плане того, что именно собрался делать. Ну и гораздо меньше потом было "не так сделал, надо было так". Счас не использую, проще по старинке

(18) что-то мне кажется, что UML с 1С вряд ли подружить

Вот тут люди что-то пытались делать http://www.uml2.ru/forum/index.php?topic=220.0

(21) Ну почему же? Если рассматривать объекты конфигурации как недоделанные классы со своими методами. Мне кажется можно что извлечь из этого

(22) Пасиб. Интересно, почитаю

(19) А что с этим делением не так? Логично же

(18) Нахер RR и UML. У нас есть свой православный Дракон https://catalog.mista.ru/public/504530/

(25) я не говорю, что что-то не так. Деление как раз правильное

(26) а вот это уже интересно. Спасибо.

(28) Посмотрите другие публикации автора, там есть практические примеры.

(26) дайте две! Шикарно! )

в совершенном коде много хороших рекомендаций. рисуешь в майнд мапе и не выeбываешься... не?

Mindjet MindManager 2017

(31) в СК да, но далеко не все из них подходят к славяноязычной разработке.
(32) попробуем

(0) https://life-prog.ru/2_6249_urovni-i-metodi-proektirovaniya-programm.html

Все реально просто, в уме разбиваешь задачу не некие "блоки".
Формулируешь что будет на входе в каждый блок и что на выходе и делаешь кучу https://ru.wikipedia.org/wiki/Функция-заглушка


Процедура РешениеВсейЗадачи()
РешениеПодзадачи1("ВходныеПараметры");
КонецПроцедуры;

Функция РешениеПодзадачи1(ВходныеПараметры)
Возврат "ВыходныеПараметры";
КонецФункции;


А потом постепенно наполняешь пустые процедуры/функции кодом...

(34) спасибо

(34) А я в дополнение к этому использую комментарии.
Начинаешь работу, почти все зеленое.
Когда вся "зелень" исчезла, работа готова.
Очень удобно. И эстетически приятно. Напоминает созревание урожая.

Ещё кто-нибудь поделится опытом?

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

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

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

тем самым сильно упрощается общее понимание модуля и упрощается программирование. Кстати в БСП именно так и делается...

(34) (38) аналогично, прикидываешь что должно быть, функции с возврат НЕОПРЕДЕЛЕНО, а дальше реализация

(34)(38)(41) ИМХО, пустые процедуры/функции это хорошо, позволяет продумать структуру модуля. Но между проектированием структуры модуля и написанием кода нужен ещё один процесс - проектирование самой процедуры/функции. А вот тут уже помогает объявление переменных внутри процедуры/функции

Процедура МояПроцедура(Параметр1, Параметр2)

    Перем Запрос;
    Перем Выборка;
    Перем ТаблицаНоменклатуры;
    Перем МассивПодразделений;

    // Описание действий, которые будут выполняться в процедуре

КонецПроцедуры

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

Кстати, заметил одну интересную штуковину. Когда внутри метода объявляешь переменные, код получается стройнее, исключаются переменные с размашистыми именами, типа ТаблицаВыбраннойНоменклатурыТекущегоПодразделенияДляЗагрузкиИмениДвадцатогоСъездаВсесоюзнойКоммунистическойПартии

(42) Переменные имеет смысл объявлять только самые важные и повторно используемые внутри процедуры/функции.

Временные/одноразовые же нет смысла никакого.

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

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

http://imglink.ru/show-image.php?id=2020bb6c41617b8556b9bfd6f39fe7da
http://imglink.ru/show-image.php?id=da3651fe005bc63bf82ab27f3786fb82

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

(11) А тут в тележке некто из ЖК утверждает, что БСП круто покрыто тестами...

(10) Иногда да, раньше основного кода, например, задача реализовать некий интерфейс/класс, зачастую тесты существуют раньше основного кода, да, тесты валятся, т.к. кода еще нет.
Это если с нуля разрабатывать и требовния размыты, тогда, да, пишется основной код и покрывается тестами.

(40) Это потому, что когда на форму выносится доп логика и кодовая база растет, легко запутаться.

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

   Структура - поля адреса:
        * Представление    - Строка - текстовое представление адреса по административно-территориальному делению.
        * МуниципальноеПредставление - Строка - текстовое представление адреса по муниципальному делению.
        * ТипАдреса        - Строка - основной тип адреса (только для адресов РФ).
                                      Варианты: "Муниципальный", "Административно-территориальный".
        * Страна           - Строка - текстовое представление страны.
        * КодСтраны        - Строка - код страны по ОКСМ.
        * Индекс           - Строка - почтовый индекс.
        * КодРегиона       - Строка - код региона РФ.
        * Регион           - Строка - текстовое представление региона РФ.
        * РегионСокращение - Строка - сокращение региона.
        * Округ            - Строка - текстовое представление округа (устарело).
        * ОкругСокращение  - Строка - сокращение округа (устарело).
        * Район            - Строка - текстовое представление района у адресов по административно-территориальному делению.
        * РайонСокращение  - Строка - сокращение района у адресов по административно-территориальному делению.
        * МуниципальныйРайон - Строка - текстовое представление муниципального района у адресов по муниципальному делению.
        * МуниципальныйРайонСокращение - Строка - сокращение муниципального района у адресов по муниципальному делению.
        * Город            - Строка - текстовое представление города у адресов по административно-территориальному делению.
        * ГородСокращение  - Строка - сокращение города  у адресов по административно-территориальному делению.
        * Поселение            - Строка - текстовое представление поселения у адресов по муниципальному делению.
        * ПоселениеСокращение  - Строка - сокращение поселения у адресов по муниципальному делению.
        * ВнутригородскойРайон - Строка - текстовое представление внутригородского района.
        * ВнутригородскойРайонСокращение  - Строка - сокращение внутригородского района.
        * НаселенныйПункт  - Строка - текстовое представление населенного пункта.
        * НаселенныйПунктСокращение - Строка - сокращение населенного пункта.
        * Территория            - Строка - текстовое представление территории.
        * ТерриторияСокращение  - Строка - сокращение территории.
        * Улица            - Строка - текстовое представление улицы.
        * УлицаСокращение  - Строка - сокращение улицы.
        * ДополнительнаяТерритория - Строка - текстовое представление дополнительной территории (устарело).
        * ДополнительнаяТерриторияСокращение - Строка - сокращение дополнительной территории (устарело).
        * ЭлементДополнительнойТерритории - Строка - текстовое представление элемента дополнительной территории (устарело).
        * ЭлементДополнительнойТерриторииСокращение - Строка - сокращение элемента дополнительной территории (устарело).
        * Здание - Структура - структура с информацией о здании адреса.
            ** ТипЗдания - Строка  - тип объекта адресации адреса РФ согласно приказу Минфина России от 5.11.2015 г. N
                                     171н.
            ** Номер - Строка  - текстовое представление номера дома (только для адресов РФ).
        * Корпуса - Массив - содержит структуры(поля структуры: ТипКорпуса, Номер) с перечнем корпусов адреса.
        * Помещения - Массив - содержит структуры(поля структуры: ТипПомещения, Номер) с перечнем помещений адреса.
        * ИдентификаторАдресногоОбъекта - УникальныйИдентификатор - Идентификационный код последнего адресного объекта
                                        в иерархи адреса. Например, для адреса: Москва г., Дмитровское ш., д.9 это
                                        будет идентификатор улицы.
        * ИдентификаторДома - УникальныйИдентификатор - Идентификационный код дома(строения) адресного объекта.
        * Идентификаторы - Структура - Идентификаторы адресных объектов адреса.
            ** РегионИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор региона.
            ** РайонИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор района.
            ** МуниципальныйРайонИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор муниципального района.
            ** ГородИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор города.
            ** ПоселениеИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор поселения.
            ** ВнутригородскойРайонИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор
                                                                                           внутригородского района.
            ** НаселенныйПунктИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор населенного пункта.
            ** ТерриторияИдентификатор - УникальныйИдентификатор, Неопределено - идентификатор территории.
            ** УлицаИдентификатор      - УникальныйИдентификатор, Неопределено - идентификатор улица.
        * КодыКЛАДР           - Структура - Коды КЛАДР, если установлен параметр КодыКЛАДР.
           ** Регион          - Строка    - Код КЛАДР региона.
           ** Район           - Строка    - Код КЛАДР район.
           ** Город           - Строка    - Код КЛАДР города.
           ** НаселенныйПункт - Строка    - Код КЛАДР населенного пункта.
           ** Улица           - Строка    - Код КЛАДР улица.
        * ДополнительныеКоды  - Структура - Коды ОКТМО, ОКТМО, ОКАТО, КодИФНСФЛ, КодИФНСЮЛ, КодУчасткаИФНСФЛ, КодУчасткаИФНСЮЛ.
        * Комментарий - Строка - комментарий к адресу.

(48) Нормальный ахтунг, посмотри структуру адресов Яндекса, Гугла, опенстритмап... Там похоже, а у Яндекса еще перегруженней.

три дня и три ночи будешь заполнять такую структуру, и потом неделю плохо спать

(50) Структуру адреса яндекса посмотри.

(50) Заполняют такие структуры и ничего страшного в том нет.

(52) страшного-то ничего нет, но тут налицо проблема из (9)

(53) Это не проблема как раз.

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

(54) как раз проблема. Я прямо чувствую, как падает производительность и качество работы, когда приходится держать в голове много всего. А типовые и БСП всячески способствуют захламлению мозга 1сника "переменными". Открываешь документ в типовой конфе, а там шисят реквизитов, пять ТЧ с двадцатью реквизитами каждая... А тебе нужно всё это дело программно заполнить, учтя триста нюансов для отдельных реквизитов. Универсальность, мать её за ногу

(56) как интересно замыкается развитие...
было черти что-велосипеды, тут пять реквизитов, там десять ничего несовместимо
придумали ООП, все растащили по классам, наследование красота... довели в java до абсурда...сплошные абстракции, километры вложенностей классов...
и теперь опять пишут черти что копипастом одно и тоже, потому что "падает производительность программиста чтобы это все заполминать"

чую в 9 версии будет ООП, а в 10 его начнут выпиливать

(57) сейчас в тренде функциональное программирование

(58) функциональная поддержка кода походу не в тренде

(57) постоянно случаются перегибы в ту или иную сторону. Доходит до точки неудобства и... уходит в другом направлении. Вот взять мобильные телефоны, у них лет двадцать развитие шло в сторону уменьшения и компактности, в двухтыщных уже было дело подошли к совсем компактным и легким моделям. Но в тред начали врываться смартфоны, и размеры снова пошли в сторону увеличения. Ща дойдут лопатофоны до килограмма весом и 10" диагональю, начнут из рук вываливаться, и двинут в новом направлении, скорее всего обратно в сторону уменьшения.
Также и с разработкой ПО. Придёт время, и ПО двинет в сторону простоты и компактности. Возможно.
ИМХО, универсальность универсальностью, но разработчик должен быть жадным до количества полей в таблицах и количества кода.

Берём товарный чек (типовой бланк). У него в шапке три реквизита (фирма, дата, номер) и одна табличка из четырех реквизитов (наименование товара, количество, цена, сумма). А в 1С что? А в 1С электронный брат этого чека имеет, внимание!
31 реквизит в шапке
12 табличных частей
81 реквизит в ТЧ суммарно
всю эту красоту можно наблюдать в 1С:Рознице 2

и ведь по большому счету это тот же самый товарный чек, суть которого отражать факт продажи товара покупателю

(61) Это не повод ныть.
..Не нравиться? Переделывай и продавай. ...Если сможешь

(53) Хорошо, как вы выкрутитесь в случае с адресом? Предложите альтернативу. Я лично ничего страшного в структурах не вижу, если они документированы. Многоэтажные структуры были еще в функциях WinAPI, которым по 20 годков. Реальной альтернативы этому нет, потому что объекты действительно вот такие, достаточно много полей в них.

(61) Проблема не в кол-ве параметров, а в их документировании, что там важное а что можно опустить по дефолту.
И вот чтоб это понять сча приходится ползти и разбирать код.

(61) Это красота присвистала из УТ.  В рознице все заглушками облеплено. Учет товаров - это не продажа.

(62) никто и не ноет. Просто обращаю внимание на непомерно разросшуюся структуру БД.

(66) Так и пиши об этом в техподдержку. На этом форуме нет спецов, которые оптимизируют код в типовых.

(67) воу-воу, полехче. Чувствую как топик переходит на личности и прочие "сам дурак"

(0) Enterprise Architect подойдет? Там UML.

(69) только дракон, только порно!

(69) спасибо, глянем

(68) Я тебя уважаю, если что.))
Но по сути всё просто. Либо пишешь своё решение и продвигаешь, либо обращаешься к разработчикам. Остальное-пустое сотрясание.