Программные потроха

Моя категорическая неприязнь к тайм-менеджменту в этих вопросах никуда не делась, но считать программные тексты надо скорее в минутах чем в байтах или строках. Минуты у меня обобщённые, это и минуты (чаще, конечно, секунды) выполнения.
Программа это не тексты кода. Программа это инструмент, выполняющий какие-то действия. Лучше думать так потому что выполнять действия можно по-разному. Это будет иметь отношение к программированию, а не функционалу.
Можно считать программу набором экранов для ввода информации и отчётов по информации. Вообще-то там больше ничего нет.
Например программа для фирмы «Купи-продай» это две накладные (на приход и отгружу) и две платёжки (на приход и расход). Ещё там минимум три справочника (товар, организации -   контрагенты, единицы измерения).
Считаю экраны:
Справочники – 3 штуки
Платёжки – 2 штуки
Накладные – 4 штуки на два документа. Это потому что у накладной есть шапка, в которой дата, номер и организация (это один экран ввода информации) и список строк содержания накладной (второй экран).
Отчётов, печатных форм (т.е всяких бумажек, которые кому-то зачем-то нужны) пусть будет штук 10.
Тут может возникнуть сложное. Масса вариантов, на самом деле. Мало ли, кому-то потребуется статистический отчёт по отгрузкам или что-то другое, хитроумное, что сложно писать.
В формах для ввода информации тоже может быть не всё просто. При вводе платёжек, например, удобно если по умолчанию подставляется высчитанная сумма долга на данный момент. Как и в случае отчёта программа должна порыться в данных и выдать на экран нужную информацию.
В последние годы типовая экранно-отчётная схема начала немного размываться. Всё, что описано тут:
http://akostina76.ucoz.ru/blog/2018-07-20-5234

… но назначению больше всего похоже на отчёт. Только это не печатают, а смотрят с экрана обычно. Выводится это в специальные экранные формы больше похожие на формы ввода информации. Это всё можно считать отчётами, разве что не бумажными.
И понятие «программный расчёт», то самое потенциально длинное и тяжелое для машины изменилось. Точнее значительно чаще начал применяться внутренний инструментарий, позволяющий делать просто то, что раньше надо было делать длинно и сложно.
Пусть в той же программе для фирмы «Купи-продай» мне надо посчитать долги. Мне надо обработать (просуммировав) два документа. На самом деле, три документа, потому что возвраты тоже бывают. И будет у меня при таком методе довольно длинный текст, в котором последовательно обрабатывается информация всех документов. А если я додумаюсь завести список проводок и буду фиксировать в нём движение всех документов, то программа расчёта будет значительно короче, потому что при расчёте мне придётся обрабатывать только одну таблицу. Список проводок это «придуманный» объект. Настоящие тут документы. А этот список часть внутренней программной структуры, позволяющей ускорить и упростить некоторое действие.
С другой стороны в программе, в каком-то месте появилась запись информации документов в этот список. Чисто формально, то на то. А в текстах может и длиннее будет. С другой стороны, тексты бывают примитивные и сложные. Текст записи в список проводок обычно примитивен, а текст выборки информации без этого списка сложен. Т.е таким образом избавляются от сложных текстов, которые сложно читать, понимать и если надо исправлять. Перед тем как что-то менять (а в обычной жизни это требуется часто) надо в достаточной степени понять, что и как тут делается. Длинные функции больше времени хотя бы на чтение требуют.
Список проводок это то, что было сделано в «Кассе» в 2005 году:
http://akostina76.ucoz.ru/publ/5-1-0-8#kassa

На тот момент это было очень даже неплохо. Но лет через 5 даже мощная техника начала притормаживать потому что для вычисления остатков требовалось перекручивать базу за 5 лет. Не так часто базы ведутся подряд из года в год но это всё равно плохо. И это понятно в 2018 году. Потому я и рассказывают про регистры как инструмент:
http://akostina76.ucoz.ru/blog/2018-08-18-5306

… при том что не важно на чём реализовывать эту логическую придумку, такой же внутренний программный «фантом», который в отличие от документов не существует (также как список проводок). Программистская мысль не стоит на месте. Вначале такие придумки используют некоторые, потом это становится нормой. Такие вещи позволяют сократить и упростить код (сложный и плохо читаемый код). Если это не использовать, то код, естественно, будет длиннее и сложнее.
Есть другая причина, по которой могут начать разбухать тексты. Это «заплатки», которыми являются все изменения программы. То, что нельзя корректировать запаивается в железный ящик. Программы пишутся для гибкости, чтобы была возможность что-то поменять. Но делать это можно по-разному в разных условиях и ситуациях. Пусть это мой текст, который я почему-то хорошо помню. Тогда я дописываю только то, что нужно прекрасно зная что бывает, а чего не бывает. Пусть, например, мне захотелось сделать так, чтобы накладная на приход меняла какие-то остатки по поставщику. Я для себя точно знаю, что программа не ласт записать документ если забыли ввести этого поставщика (т.е в другой части программы есть лично мной написанный код, который блокирует запись такого документа). Тогда я не проверяю есть ли в накладной поставщик, я сразу делаю запись. А теперь пусть я этого не знаю и узнавать мне, например, лень.  Проще воткнуть проверку и выдать ошибку о том, что с документом что-то не так. В программе, работу которой я не очень знаю, у меня будут куча таких проверок и, соответственно, довольно длинный текст. Потому что если я в такое вклиниваюсь я стараюсь хотя бы ничего не напортить (и всё-таки написать то, что отработает при всех возможных ситуациях). Пусть потом следующий человек видит кучу проверок, решает что это не просто так и лучше тут ничего не трогать потому что непонятно почему так сделано. Так возникают какие-то загадочные ветки (переходы по if else), в которые ничто никогда не войдёт но пусть на всякий случай будет.
Организация, когда с одним текстом работают несколько человек это очень плохой вариант как раз потому что описанное выше возникает постоянно, захламляя тексты хорошо если хотя бы работающим (в итоге) кодом.  Следующая проблема, которая неизбежно раньше или позже возникнет это то, что заставить такое работать сложно. Это требует очень большого времени, при том что написание чего угодно (экрана, отчёта) с нуля при любой сложности это довольно быстрая операция.
Другой вариант захламления (и тоже несколькими программистами)  это использование разнообразных не типовых компонент. Компоненты это что-то вроде электродеталей. Их кто-то пишет, они разные, их можно использовать в разных частых программы. Проблема только в том, что информацию о том, как это работает обычно берут из Интернета. А информацию о том, что используется мало лет через 5 просто не найти. Если там что-то ломается то начинается «пинание ногами», т.е подбор типа «а если ему в этом свойстве написать минус 1 может заработает?». Внутри «черный ящик». Только автор знает, как оно работает и что ему надо. Так в текст появляется загадочный код потому что так надо и снабжённый комментарием «Не убирать!!!» с кучей восклицательных знаков. Я такое видела. У меня создалось ощущение, что там человек 10 отметилось со своими компонентами. Понято, как это работало. Очень мучительно для всех. По-моему от этого всего там даже внутри что-то перекашивало. Это был случай, когда просто переписывать с нуля надо было однозначно. Потому что загажено совсем. Написание с нуля - работа. В том случае это надо было 2-3 месяца писать. Но свеже-написанное во-первых, сразу проверяется, во-вторых, ещё долго лишено всех описанных недостатков. Так тоже бывает,  с какого-то момента захламления проще переписать. Может к этому моменту и более совершенный инструментарий уже придуман, позволяющий сделать это лучше и проще. Длинный текст может означать, что всех этих внутренних полезных вещей в структуре нет.