Что-то мысль возникла внезапная, интегральная...

Ведь любое программирование это по сути рефакторинг, который делает из говна конфетку.
Сначала пишется ХОТЬ КАКОЙ-ТО рабочий код, который потом преобразуется в более-менее оптимальный, причём не по скорости, а по КРАСОТЕ.
Я прав или нет?

Пишите, что такое КРАСОТА программного кода?

(0) приходи на "Жёлтую конфу" в октябре, я буду докладывать доклад на эту тему 😁

(1) круто! А выделишь мне 5 минут микрофона? я тоже добавлю от себя.

Хотя стоп, я тогда претендую на полноценный доклад

(0) Что мешает сразу делать красиво? Переписывать явно сложнее и результат будет хуже.
Или это про мечту, что джуны наговнокодят, а ИИ забесплатно из г..на конфетку сделают?

(4) Скорее наоборот. Сначала ИИ делает говнокод, из которого джун делает конфетку.

(4) ты ещё предложи сразу без ошибок писать

(0) это когда понятно что написано.
Это необязательно м.б. и прямо уж эффективно, но понятно что должен делать код и даже почему. Вполне можно отрефакторить позже в сторону большей оптимальности/эффективности.
.
По своим наблюдениям - если фейс у проги корявый то и код гунявый (про 1с говорю). Унификация интерфейса как это сейчас в 1с в части "описываемого интерфейса" отчасти не дает майстрячить адский шлак самописок/доработок (как это в 77), но в целом как-то так связь имхо наблюдается.
.
По своему опыту первая итерация кода - базовая, в целом стараюсь писать аккуратно, хотя бы чтобы смысл кода был понятен. Если есть возможность - то вторая итерация - рефакторинг и оптимизация. Третья итерация - чтобы было красиво. Чем более редко используется код - тем менее вероятность второй и третье итерации. Ну и чем костыльнее решение (нужно вчера!) - тем меньше вероятность что базовый вариант код будет рефакторен когда-нибудь... Как-то вот так у меня. Как обстоит дело у восьмерочников - не знаю. Хорошо писать получается когда пишешь от души и для души, но таковое, видимо, редко среди погромистов 1с...

(6) К этому надо стремиться)
Делать специально ошибки чтобы было что рефакторить, вот это стратегия)

(8) работу нужно беречь !

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


Напишу об этом в 1с - этого не хватает в конфигураторе!

(10) в Спортлото еще можно написать...

(11) вот ты и пиши

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

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

(0) ты открыл эволюцию

(1) сделай доклад на мисте. Зачем эти продователи курсов.

(14) нет, это другое. Это больше похоже на креационизм

(4) Когда тема новая и ты не уверен, что сработает.

Лучше сразу писать хорошо и не писать плохо
Но это очень редко получается

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

И да сразу сделать конфетку не выйдет
Но в тоже время рефакторинг может сделать хуже, более непонятный и непростой код
Который будет сложней поддерживать/допиливать

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

В (0) посыл изначально неверный.
Рефакторинг - это не про красоту, а красота - это следствие, побочный эффект.

Если я вообще понимаю, что такое рефакторинг...
К примеру. Есть какая-то задача. ТЗ поставлено, вроде как исчерпывающее. Вроде как и все по нему сделал, работает. Но в процессе отладки и первого периода эксплуатации вылезают "нюансы", которые на момент постановки задачи было сложно или даже невозможно предвидеть. Уже готовую задачу, вылизываешь, различными "ответвлениями чуть в сторону", по методу "латания дыр", по сути "на ходу", когда некогда красоту наводить, клиенту работать нужно. И вот, в один прекрасный момент, количество этих заплаток начинает зашкаливать, и сам в своем коде начинаешь путаться, поскольку он становится трудночитаемым... Вот тогда и наступает момент, когда часть задачи проще переписать заново, уже с учетом приобретенного опыта по конкретной задаче, в процессе отладки и "латания дыр".
Как правило, это бывает проще, чем навести порядок в имеющемся коде. И результат получается значительно красивее. Вот это, в моем понятии и есть классический пример рефакторинга...

(21) Это не тз было, а хрень. Если нюанс приводит к тому, что работать невозможно и надо костыль срочно лепить.

(0) Красота - она в глазах смотрящего.
Очень субъективное понятие красивости. Вот код ЗУП некрасивый, а код УТ красивый.
Я не могу понять и объяснить почему так.
Может  это зависит от лёгкости понимания и восприятия. В УПП код прекрасен, а в ЕРП просто красивый.

(23) [В УПП код прекрасен, а в ЕРП просто красивый] - странные у вас понятия о красоте

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

(24) Я воспитан на традиционных ценостях )))

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

(23) Про ЗУП соглашусь , код очень некрасивый , к сожалению

А еще для красивого кода , на мой взгляд, одно из самых важных условий - это грамотная архитектура.

Если грамотной архитектуры нет(как пример ERP) - и код становится некрасивым, очень сложно написать красивый код под плохую архитектуру

А под хорошую грамотную архитектуру и код словно по маслу идет красивый

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

Это касается не только кода, но и практически всего.

Именно поэтому физики столетиями бьются над "теорией всего" и пока в прострации, ибо упускают невероятные детали.

Примеров прекрасного в искусстве, науке, жизни масса.
Примеров ужасного в любых проявлениях мысли также масса,
потому что ...читай кратко.

Кратко:
Главный базис красоты - глубочайшая детализация.
При условии, что у творца есть талант, знания и время.

(30) проходит мимо физиков молодая девушка

физики задумчиво ей вслед - как интересно красиво сгруппировались атомы...

(0) >> что такое КРАСОТА программного кода?
Хороший код, это когда любой среднячок может его доработать с минимальными трудозатратами. Плохой код, это когда автор лично через год лезет его модернизировать и переписывает его с нуля. Я лично так классифицирую.
Про рефакторинг тоже есть свой подход - использую модульную систему разработки, что сильно минимизирует трудозатраты при изучении и модернизации чужого кода. Конечно это не всегда работает, но часто помогает хорошо

красота и понятность часто несовместимы

https://habr.com/ru/companies/ruvds/articles/510266/

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

(22) Это не тз было, а хрень.

Сереж, соглашусь, но лишь от части. Да, когда ты пилишь задачу в команде, когда есть грамотные аналитики, консультанты, постановщики задач - то да. А когда ты один, и задачу по сути ставит клиент в общих чертах, а в тонкостях тебе самому приходится "додумывать" - то о нормальном ТЗ говорить не приходится...
Есть не только крупные компании и крупные проекты, есть еще и мелочь, от которой тоже никуда не деться...
Вот я пилю ЭДО свое, в 7.7, так, как штатного там нет. Уже несколько лет. Универсальное. От загрузки файлов из ЛК, до ЭДО лайт и СБИС внутри конфы. Заработало оно почти сразу - но, в процессе, выяснилось - вроде есть формат УПД, официальный, утвержденный ФНС... Но, он допускает кучу вариаций - и сколько поставщиков, столько может быть и вариаций, одна извращенее другой :-)
Изначально было пара поставщиков, все вылизано, работает. Потом, появляется третий, у программистов которого свое видение формата... И начинается - у первых двух работает, а у третьего что-то пошло не так, и его накладные "ложатся в программу" не так, как хотелось-бы... Допиливаешь. И так дальше.
И кроме того, наши законотворцы, скучать не дают... Это в процессе эксплуатации, как правило код не упрощает, а только запутывает.
И как было на этапе постановки задачи, предугадать, кто из контрагентов как извратится? Или, что законотворцам в голову стукнет? Сделать "универсально", четко в границах формата? Но, тогда многие "удобняшки" не будут работать... Писатели типовых как раз и идут по этому принципу... Но, хочется как лучше! А получается как всегда :-(  И вот, периодически, приходится отдельные фрагменты переделывать заново. Вот и все ТЗ, какое бы оно не было...

(33) кто этот сумрачный гений, который для 1с7.7 склонение фио написал? может есть желающие, кто по красоте рефакторинг сделает?

// (c) Jurer Production Begin ( Start )
// http://superjur.narod.ru

цытата оттудова:

(35) ох флешбэки пошли, там еще рядом функция с склонением ФИО подобная была, в три раза страшнее этой)

а если ИИ скормить и пусть объяснит, как она работает?

есть у кого ИИ на подсосе?

вопрос в зал, красив ли код и если нет то почему

Функция СтранаПроисхождения(ЗаказКлиента)
    Возврат ЗаказКлиента.Контрагент.ГоловнойКонтрагент.ЮридическийАдрес.Страна;
КонецФункции

(38) уродлив

разврат из функции где?

ну хорошо, добавим возврат

ИИ не доверяю никак.
Иногда рефакторинг нужен, особенно после "некоторых.
Бывает аж тошно ковыряться в чужом коде, потом психуешь и пишешь заново всё, т.к. понимаешь что код говно.

(38) Код странный
Если не в цикле, то проще без функции, так прямо и писать в нужном месте

Если в цикле (или в разных местах юзать чтобы), то логичней через запросы, на вход один или несколько контрагентов (или других объектов)

(38) плохой и некрасивый код. если в функцию строку с номером заказа кто кинет - где отлуп, мол "чё ты тут суешь всяку хрень!!! урод блин...".

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

(44) Многовато точек это да
Причем каждая отдельный запрос порождает, который целиком объект дергает

Вот с точки зрения быстродействия лучше один запрос с кучей таблиц/соединений
Но код будет сильно больше места занимать это да

Хотя и работать более универсальней и быстрей/оптимальней конечно

Но в тоже самое время код с текстами запросов хуже поддается последующему рефакторингу
Там думать надо/приходится а не тупо заменять

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

(38)

Накладные  расходы по получению таб.частей , особенно если заказКлиента это ссылка, вас не тревожат ?

(46) Страна происхождения заказа клиента? ) Сам термин сомнительный немного.

(48) А представь на минуту такой код:
Объект.СП = ЗаказКлиента.Контрагент.ГоловнойКонтрагент.ЮридическийАдрес.Страна;
Можно много минут провести даря автору лучи добра.

(49) особенно если у контрагента нет головного контрагента.

(42) (47) (50) пусть будет запросом, даже с проверкой на пустой результат, такой код пройдёт Ваше ревью?

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|    ЗаказКлиента.Контрагент.ГоловнойКонтрагент.ЮридическийАдрес.Страна как Страна
|ИЗ
|    Документ.ЗаказКлиента КАК ЗаказКлиента
|ГДЕ
|    ЗаказКлиента.Ссылка = &ЗаказКлиента";
Запрос.УстановитьПараметр("ЗаказКлиента", ЗаказКлиента);
РезультатЗапроса = Запрос.Выполнить();
Если не РезультатЗапроса.Пустой() Тогда
    ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
    ВыборкаДетальныеЗаписи.Следующий();
    Возврат ВыборкаДетальныеЗаписи.Страна;
Иначе
    Возврат Справочники.КлассификаторСтранМира.ПустаяСсылка();
КонецЕсли;


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

(51)

Не пройдёт. В запросе есть  неявное ЛЕВОЕ СОЕДИНЕНИЕ, а ЕСТЬNULL нет

В догонку

Внимание вопрос.
Если поле Контрагент или ГоловнойКонтрагент не заполнено (пустая ссылка), то
вернет ли код

Возврат ВыборкаДетальныеЗаписи.Страна;

ожидаемую (вроде как)

Справочники.КлассификаторСтранМира.ПустаяСсылка();

Запрос для теста. &ЗаказКлиента -- любой заказ клиента с пустым "Контрагент"

ВЫБРАТЬ
	ЗаказКлиента.Контрагент,
	ЗаказКлиента.Контрагент.ГоловнойКонтрагент КАК КонтрагентГоловнойКонтрагент,
	ЗаказКлиента.Контрагент.СтранаРегистрации.Наименование КАК КонтрагентСтранаРегистрацииНаименование,
	ТипЗначения(ЗаказКлиента.Контрагент.ГоловнойКонтрагент),
	ТипЗначения(ЗаказКлиента.Контрагент.СтранаРегистрации.Наименование)
ИЗ
	Документ.ЗаказКлиента КАК ЗаказКлиента
ГДЕ
	ЗаказКлиента.Ссылка = &ЗаказКлиента

(52) это не УТ 11 (во всяком случае не из последних), там нет в контрагентах реквизита "ЮридическийАдрес" следовательно, мы не знаем какой тип в Юридическом адресе может принимать реквизит Страна. Может там составной тип данных, и могут быть справочники СтраныМира, КлассификаторСтранМира, Строка и еще черт в ступе. Эли так, то вернет Неопределено.

(52) вы не к тому цепляетесь. я просто обернул в запрос исходную строчку, чтобы показать что дело в не объектной модели.
Вы всё правильно пишете про пустых контрагентов в заказе, пустого Головного Контрагента итд, можете даже написать мега-запрос, который учтёт подобные случаи.
Но исходная ошибка глубже. подождём еще варианты

(4) Когда ты разрабатываешь "понятную" часть можно писать красиво. Обычно, сначала хоть как-то, а уже потом если это действительно используется можно переделать в красиво.

И такой подход действительно экономит кучу времени, выясняется, что фича которую ЛПР пропихивал так рьяно и она прям "нужна-нужна" используется раз в квартал. И подождать 15 минут вместо 5, раз в квартал не критично.

Спасибо за конструктивные ответы. Я всё записываю!

(38) Не очень очевидная функция, какой-то мелкий хелпер.
Название функции лучше переделать, например, СтранаЮрАдресаГоловногоКонтрагента(Заказ)
Функция в одну строку — это обычно моветон. Зачем она нужна, кроме своего имени и передачи контекста куда-то?

Что я могу сказать по некоторым наблюдениям, я очень долго слежу за развитием sqlite, больше 10 лет точно, слежу за всеми изменеиями в транке, слежу за описаниями. Бегло просматриватриваю но не все, но что-то просматриваю.

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

Плюс разработка через тестирование, а само тестирование занимает вроде уже больше кода, чем само ядро библиотеки.

У себя рефакторю, через какое-то время. Когда появился один костыль в одном месте, ладно, ладно, запихаем его как костыль, что бы по быстрому.
Потом в том же месте появляются 2,3,10 костылей.
Вот тогда и рефакторю на общий код костылей и отдельный для каждого костыля.
Без это код превращается в лапшу, где ничего понять невозможно.
Но и облегчается написание дальнейших костылей в том же стиле, пара строчек на ссылку для общего костыля, и он вызывает уже конкретные костыли, и сам костыль уже независим и логически понятен, т.к. он отделен от основного кода.

Ну и, конечно, если повторяемый код в 10-20 строк, а иногда и меньше, и встречается в 5-10 местах, то его рефакторю.
Тут главное баланс, если код после рефакторинга увеличивается, а такое постоянно встречается, то не понятно, стоит ли вообще это рефакторить, или стоит оставить как есть..

(54)
Архитектурная претензия?
В стандартах 1С это называется "Самодостаточность регистров".
Страну надо хранить в заказе, если она так важна.

(59) Это нарушение 2-й или 3-й нормальной формы БД

(60)
Нормальные формы - это не закон, можно и нарушать.
Следуя нормальным формам, во всех документах нужно удалить реквизит "Контрагент", ведь у договора всегда есть владелец.

(61) Категорически согласен! Более того, в движке миста форума нормальные формы осознанно нарушаются, чтобы в селектах не делать лишние соединения. Это ускоряет работу. МИСТА ФОРУМ просто летает!
С этим я согласен.

Но всё-таки. Тут речь про рефакторинг. Каждое нарушение нормальной формы БД будет оплачиваться. Это ж верно?

(57) Зачем она нужна, кроме своего имени и передачи контекста куда-то?
чем проще примеры тем лучше. юзер-стори вполне могло звучать примерно так: соседний отдел пилит логистическую систему и просит нас отдавать по апи, "страну контрагента заказа". они там дальше будут от нее или маршрут строить или на другой язык переводить итд от страны, неважно.
аналитик(или сам программист как у нас часто бывает) открыл карточку, увидел иерархию контрагентов, увидел юрадрес в нем страну, согласовал, бизнес это устроило, дали в разработку программисту. программист написал код и принёс его Вам на проверку, какие вопросы зададите вы программисту/аналитику и в каком направлении отправите их переделывать?
(59) претензия, конечно, архитектурная) допустим мы соблюдаем стандарты 1с, завели страну в заказе и будем ее сохранять перед записью. каким кодом туда её сохраните, исходным как в (38)?

(62)
Мне как-то было скучно, и я полистал книгу Дейта, где он null в запросах критикует.
Вот где жесть.

++++(58) Все именно так и есть.

"У себя рефакторю, через какое-то время. Когда появился один костыль в одном месте, ладно, ладно, запихаем его как костыль, что бы по быстрому.
Потом в том же месте появляются 2,3,10 костылей.
Вот тогда и рефакторю на общий код костылей и отдельный для каждого костыля.
Без это код превращается в лапшу, где ничего понять невозможно."

И это тоже, в точности:

"Ну и, конечно, если повторяемый код в 10-20 строк, а иногда и меньше, и встречается в 5-10 местах, то его рефакторю."

Антон, у нас с тобою, одинаковые видения процесса... Правда, у каждого в своей области, но общий принцип! :-)))

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

(66) Вот это очень интересная мысль: поменять структуру БД ради красивого кода. ИМХО, это и есть какой-то компромисс, который все ищут. Ну чтобы и строчек было мало, и чтобы база нормально себя чувствовала. Согласны?

Рефакторинг сразу после написания рабочего кода - признак того, что исходный код писал неопытный, без четкого плана и понимания как правильно пишется качественный код.
Лучше потратить немного (или много) времени на хороший план, и сделать сразу качественно, потому что на рефакторинг уйдет еще больше времени.
Если нужно просто исправить недочеты и сделать код более красивым, то это не рефакторинг, а "причесывание".
Обычно свежий код прогоняется через Prettier, Linter, а по-современному через ИИ, и делается более красивым и качественным без изменения алгоритмов, это все на автомате без существенных затрат времени.

(68) Обычно надо быстро показать результат, когда пофиг на качество кода, лишь бы было что-то рабочее.
Хотя я, например, уже выработал в себе привычку писать нормально сразу. Это уважение к самому себе и к коллегам, которые потом это читать будут.

(69) 👍

(0) стараюсь сразу писать конфетку (скромно потупя глаза)
начитался чистого кода и стараюсь его применять

(71) Покажите пример своего кода

(0)

Хороший код хорошо читаем.
Хороший код -  модифицируем, расширяем. Т.е. он написан не в стиле one time, write only
Хороший код не содержит  логических ям.
Хороший код оптимизирован не в вакууме, а в нужных местах. В остальных местах он читаем.
Хороший код, это когда он претерпевает минимальные изменения
-- для отладки
-- для тестирования
-- при внесении очевидных хотелок и доработок


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

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