https://habr.com/ru/post/521104/

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

В среде 1С развит культ good-enough решений. Сделал как умел, работает, заказчик доволен — всё, миссия выполнена, переходи к следующей задаче. На раздумья над красотой кода и оптимальностью запросов нет времени, т.к. время деньги. Когда (если) проблемы с этим кодом возникнут, тогда и будем решать.

Само по себе это не плохо, на мой взгляд. Это компромисс между скоростью/стоимостью разработки и стоимостью поддержки в пользу первого. Накладные расходы на overengineering не ложатся на заказчика. Это соответствует бизнес модели 1С, поддержка и доработка решений не должна быть слишком дорогой, иначе получится второй SAP.

Но есть проблема в том, что новички, приходящие в нашу сферу (не важно, с нуля или из других технологий) этот культ good-enough воспринимают по-своему. Как культ гугл-программирования. Гугл программирование воспринимается как норма. Почему? Потому, что нет перед глазами примеров, образцов для подражания. Никто не объясняет разницу между good-enough и рукопопым, никуда не годным решением. Все хорошие курсы платные (в отличие от других технологий). Методические материалы и лучшие практики от вендора тоже, отчасти. Хороших технических блогов по 1С разработке нет (мы же все деньги зарабатываем, а не альтруизмом занимаемся.)

Куда же податься условному нищему студенту? Конечно же, сюда. А здесь ему что? Правильно, сначала объяснят кто он такой, где его место в жизни и куда засунуть его г-код (и будут в общем-то правы). В конце скажут читать СП, гуглить, и может, кинут ссылку на книгу знаний или статью на ИС. Нянчится с ним, объяснять азы, наставлять никто не будет (время — деньги).

А потом, в один прекрасный день, мы начинаем набирать собственную команду, и опа — а толковых-то не найти, одни гугл-программисты кругом.

Получается, в экосистеме 1С усиливается "классовое расслоение". С одной стороны, матерые зубры со ставкой 3-4К (условно), которых на всех не хватит, с другой — гугл-программисты. А среднего класса все меньше и меньше. Не знаю, замечают ли это в 1С, но лучше бы заметили.

(0) 1С такая область, где один грамотный тимлид и десяток гуглопрограммистов смогут вполне себе сносно обслуживать пару-тройку десятков конторок средней руки.

(0) Среднего класса нет.

(1) keywords: "конторок средней руки."

(3) Именно. Понятно, что таким составом нормальный продукт не сделать, и Газпром не автоматизировать.

(0) "Когда (если) проблемы с этим кодом возникнут, тогда и будем решать"

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

(5)А я вот постепенно именно на такой метод поглядываю. С одной стороны всякие Agile именно его и исповедуют, уж если быть честным. С другой, наслушавшись такой мощной рекламы руководство часто хочет именно такой подход и сопротивляться все сложнее. С третьей стороны подталкивают сами вендоры. Какова длительность жизненного цикла распространенных продуктов? Лет 5-6? По личным ощущениям 1С, тоже движется в этом направлении. Если 3 года назад старался делать продукт, что называется на века, то теперь все больше задумываюсь а нафига? Ну вот сделали мы хорошую интеграцию с MS Project 2010, а через пару лет MS перестал его поддерживать. В свое время вложился сильно в консолидирующую базу еще не 7.7, и где эта 7.7? Просто вспомните какие ключевые изменения в платформе были за последние 6 лет. Да это же практически другая платформа. Код по другому писать надо. Вот и вопрос - стоит ли делать лучше?
(0) А разделение оно всегда было.

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

А вот если вы устраиваетесь на Java или на Php на должность Мидла, то на ваш код внимательно посмотрят прежде, чем взять на работу. И там код ревью это обязательно потому что от того как ты будеш говнокодить зависит сложность поддержки проекта в последующие годы.

(6) именно. у меня есть куча "костылей" в конфиге. работают уже кучу лет. и ничего.
отвалятся с переходом на следующую "платформу" (8-ка, или еще что-то). там где клинить- непринципиально (бывает редко),  бо критичные места - пусть даже с теми же костялями (условно) - вычищены и вылизаны и костыль уже не костыль, а "произведение искустсва".. ;-)
регулярно тянет типа "сесть и сделать по уму, все равно делать нехрен", но.. зачем..? -)

(6) Какова длительность жизненного цикла распространенных продуктов? Лет 5-6?
Вижу дофига контор, где на фронтенде всякие вещи от 7.7 до Розницы 1.х

С фактами нужно считаться. Как можно сравнивать 1с и Гугл. Одни делают поддерживаемый код и зарабатывают огромное кол-во денег, другие с 3-4 попытки отчёты выкатывают. 1с культура подразумевает делать и переделывать по мере того как вылазят баги или уже совсем ушатали Конфу доработками и ее только обновлять нужно больше месяца. Считаю что делать хорошо это в первую очередь развиваться, в итоге сможешь решать задачи которые не смогут решить тяп-ляп программисты и попадешь в следующую лигу

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

(10) Отдали меня в помощь соседнему отделу у которых дедлайн вчера. Так постановщик задач присылает уточнения по одной задаче каждые 2-5 минут в течение дня вплоть до 23 часов. Неужто я буду делать не тяп-ляп? Даже тестировать не знаешь как, все в одной куче. Ругаться не буду, сообщу своему руководителю, пускай он с ними разбирается финансово или словесно :)

А что за термин такой - гугл-программисты? Не слышал раньше

(12) Статью-то почитай.

(12) Ливингстары интернетов.

(13) Ясно :) я было подумал речь о программистах, работающих на Гугл.
(14) да, этот товарищ, пожалуй, самый яркий представитель :)

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

(0) Можно подумать, не в 1С используется какой-то другой подход. Работает, и ладно..

(12) очевидно, это те, кто любое решение вопроса подсматривают в гугле, не умея самостоятельно решать задачу и не владея в полной мере языком. Ну примерно как врачи, которые вбивают симптомы в гугл чтобы поставить диагноз. ЗЫ: статью пока не читал, так что это просто предположение.

(6) выигрыши от такого подхода сплошная иллюзия. Какие-то мелкие правки типовой ещё можно делать по методу "хуяк-хуяк и в продакшн", но чем сложнее разработка, тем губительнее такой подход. Чем больше говнокода, тем дороже обходится строчка такого кода. На написании кода его жизнь только начинается. После написания код будет много раз читаться. Да-да, программисты бОльшую часть времени тратят на чтение кода, своего или чужого. И если хороший код читается и понимается легко, то плохой превращается в ребусы. Приходится долно-долго продираться через его хитросплетения и скрытые ловушки. Чтобы изменить 10% из тысячи строк хорошего кода, ты потратишь час времени. Чтобы изменить 10% из тысячи строк плохого кода, ты потратишь 5-7 и более часов времени, в особо запущенных случаях счет может идти на недели. Тебе повезло, ты читаешь вполне читабельный код типовых. Но сам пишешь и призываешь писать код плохого качества. Это не есть хорошо

(14) Кто все эти люди?

(0) Неугомонный тип)

Язык 1с устарел просто. Приходится быдлокодить. В типовых полно такого

(21) В современном цэпепе без гугля ты вообще шага не сделаешь.

(22) почему? И причем тут c++?
Он давно уже не энтерпрайз

(0) прочитал. Нового тут ничего нет. Описанный паттерн поведения - очень давний, он в целом выгоден его носителю. Люди, которые "решают вопросы, как будто их нет" - в целом достаточно успешны в работе и личной жизни. Если чел привык все спрашивать у гугла, потому что это кратчайший путь к материальным ништякам - ну, значит, это имеет право на существование. О спасении души сейчас мало кто думает :)

(24) В "чел привык все спрашивать у гугла" путают причину со следствием.

Спрашивать у гугла это хорошо. Плохо не думать перед в процессе и после того как спросил.
И ничего не знать чтобы знать что спрашивать.

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

А не помню часто многое я в 1С потому что кроме 1С еще дофига чего знаю/умею, все помнить наизусть не получается.

Сам Белокаменцев в партнерке гуглит.
Вот беда-то нашлась.
Отлынил от проведения собеседования - получил гугл-падаванов.

(25) в статье речь не про поиск методов. Речь про то что находят готовые решения, в идеале рабочий код, и копипастят до тех пор, пока есть что копипастить. Когда становится нечего, то эффективность падает ввиду того что сами практически ничего не пишут

(0) Статья полное дерьмо. Автор статьи притворяется, что не знал о существовании гугла. Плато какое то выдумал. Прям дебилов понабрал по объявлению и за них гугл задачи решал, а потом перестал. Дерьмо полное.

Тут перепись высшего слоя гугл программистов ?

(28) Ну это тоже не исключено. Я с трудом понимаю, каким образом можно копипастить код, если ты вообще ни ухо ни рыло в вопросе. Все-таки досконально "свою" задачу в сети не найдешь, найдешь похожую. Чтобы адаптировать решение к "своим" потребностям, как ни крути, нужны определенные скиллы - переименовать переменные, организовать вызовы, предварительно разобравшись что они у предыдущего автора делали. Скиллы, которые в состянии помочь и при самостоятельном решении. То есть автор скорее всего по каким-то причинам не может мотивировать людей на работу. Может, ему ставят дурацкие планы, а может, сам не справляется с людьми, и в этой связи немножечко лукавит.

(30) Да блин. Даже если они всё копипастили из интернета, будет быстрее, чем самому заново писать. Потому и плато. А если бы были не гугл-программисты, то плато было бы с самого начала :) Радовался бы, что хоть что то сделали. Тру-программисты без гугла полгода курили бы на крыльце в задумчивости. Дерьмо.

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

(29) Плагиат с четырех научных работ - пятая научная работа.

(31) нет, это не дерьмо. Проблема действительно есть. Я тоже сталкивался с ситуацией, что если решение неочевидно, люди могут неделями ничего не делать, приходить к скандалу и даже увольняться.

(28) Но какое бурление говн в комментах на хабре, умеет чувак разворошить айтишнечгов.

(34) Но гугл тут точно не при чем. Может просто задолбало.

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

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

(37)
1. Антоним щедрые - жадные.
Богатые тоже бывают жадные, причем имхо чаще чем бедные ибо как они стали богатыми?

2. Треугольник выбора помним? Можно качество оплатить сроком а не деньгами.

Имхо автор статьи хотел получить быстро и дешево - получил некачественно. Чему тут удивляться?

(39)+ "Понятно, что простые задачи они решали легко. Я стал давать более сложные задачи – те, что раньше выдавались после года службы. Эти чуваки справлялись, без посторонней помощи, и с такими! Я был в шоке. Радовался – какое замечательное поколение растёт!"

а если гуглишь в типовой? это тоже гугл-программист?

(41) Ты код типовой в гугель залил? Силён...

(38) Богатство для щедрых, это минимально необходимое требование. Естественно, богатые могут быть и жадными. Будущее время в большинстве случае равносильно деньгам. Варианты с ограничением технологическим процессом (9 женщин за месяц) естественно не подпадают под данное утверждение.

(37) а это уже перекладывание ответственности на заказчика. Заказчик просто не знает, что в дальней перспективе ему придётся сильно переплатить за плохой код. В капиталистических странах смотрят не столько на стоимость покупки автомобиля, сколько на стоимость владения этим автомобилем (цена+страховка+ГСМ+техобслуживание+налоги), дешевый по цене автомобиль может на самом деле оказаться дорогим из-за накладных расходов. У кода тоже можно сказать есть стоимость приобретения и стоимость владения. Плохой код приобрести дешевле, а владеть им дороже. Но обычно заказчики об этом ничего не знают (если только у них самих нет опытных специалистов, знающих что к чему), поэтому идут на поводу у программистов-скорошлёпов, по-итогу переплачивая за разработку и кастомизацию

Разумеется, всё сильно зависит от задач. На каких-то мелких задачах говнокод легко уживается. Но всё в корне меняется, когда нужно разработать сложную систему. Посади быстрошлёпов писать ERP, и они не смогут написать её. Даже за 5 лет и 200 миллионов не напишут. Время и деньги тут бессильны, сложные системы впринципе невозможно создать быстрошлёпным местодом. Уже через год эта ERP превратится в страшного больного монстра, от работы с которым будут сбегать даже "отцы" сего творения. Дальше дорабатывать и развивать эту недоERP будет чрезвычайно сложно, местами вообще невозможно

(42) эээ... ок

(42) Это несложно, можно на гитхаб например

блин, посмотрел на хабр и понял кто автор.
этот тот спамер с ИС, который разводит резонерство. понятно, чо.

(46) А по шее не получишь?

(44) Ну вот и приходим к базовым моментам.
1. Заказчик должен разбираться в том, что заказывает. Либо верить экспертам (для ИТ именно этот момент ключевой, т.к. ИТ это доверительный товар).
2. Качественное всегда дороже некачественного.
3. Цена не всегда говорит о качестве.
Эти принципы подходят для любой отрасли и любого товара. И всегда есть вопрос - кому верить? Ответственность всегда лежит на заказчики, потому что он решает кому верить. Верить можно много кому, себе, эксперту, инструментальному анализу и т.д.

Блин как про меня прям.
Я вот как в статье прям гугл-программист.
Гуглю, практически всегда решение нахожу.
Редко когда сам придумываю.
И что мне теперь делать?

(50) Бери количеством. Рано или поздно оно перерастет в качество.

(50) Может тебе сложных задач не попадалось?

(51) Я фикси, откуда у меня количество.

(53) Ну так делай предложения по улучшению работы пользователей. Придумывай сам себе задачки и аргументируй что это жизненно важно для компании. Работы будут хоть задницей ешь.

(0) > В среде 1С развит культ good-enough решений
Вспомнилось - "мы твой позорный недуг в подвиг определим" (с)
Чаще всего в среде 1С радостно называют этим словом откровенный говнокод. А говнокодят вовсе не потому, что это реально экономит ресурсы (90% случаев - то на то и выходит). А просто из-за низкой квалификации.

(44) А придется ли? Либо жизненный цикл продукта закончится вообще (как произошло с 7.7), либо его "закончат" искусственно (все эти УФ/асинхронности) , либо исковеркают исходя из внутренних побуждений (поменяв названия функций, общие модули и т.п.), либо законодательно подвинут.

(51) мозги нужны еще.

(57) Ну не без этого.

(58) неправильно. Правильно будет: "без этого не"

(34) "решение неочевидно, могут неделями ничего не делать" - т.е. "если не смогли нагуглить, то просто на несколько недель забивают"?

нагуглить правильное решение - тоже надо соображать

(61) я вот заставляю себя гуглить...

(62) Хором: Здравствуйте, Михаил!
)

(49) не совсем

"2. Качественное всегда дороже некачественного."

В случае с разработкой ПО это не так. НЕкачественная разработка по-итогу оказывается дороже, чем качественная. Если в конце проекта "некачественной разработки" сесть и посчитать все-все расходы, то итоговая сумма будет выше (или даже намного выше), чем если бы велась качественная разработка. Сама разрабатываемая система может оказаться полумёртвой, а то и вообще мёртвой. Из-за плохого кода система буквально загнивает изнутри. С каждой новой итерацией разработки вносить изменения всё труднее и труднее. Т.е. производительность программистов падает просто катастрофически, каждая следующая кода обходится всё дороже и дороже. В конце-концов загнивание доходит до такого уровня, что дальше разрабатывать систему просто невозможно. Такого не происходит, если код изначально пишется нормально, покрывается тестами, проводится code review и пот это всё

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

(63) смех-смехом, но что остается делать?

(65) Попробуй перейти сначала на дакдак, потом на бинг, потом на яндекс... А с последнего уже соскочить просто...

(64) пока ты делаешь качественный прототип и релиз - тебя обойдут по методике ХХП.

(66) что я тебе плохого сделал, что ты меня на яндекс посылаешь?

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

(67) аббревиатура очень напоминает тот самый съезд

(64) Мы же говорим про стоимость приобретения? Стоимость владения и сопровождения не учитываем?
По поводу примера. Жаль не сохранил вэбинар. Главному маркетологу российского представительства Микрософт задали вопрос про глючный MS Project. Почему вы допускаете выпуск такого сырого продукта? Последовал ответ - если покупают, значит качество всех устраивает. Народу нужно дешево. Качество коту под хвост.
Посмотрите как продвигаются "эффективные менеджеры". Купил, а сказал что внедрил, новую ИС. Получил бонус за развитие ИТ. Сделал запись себе в резюме, и беги быстрее в следующую компанию, "внедряй" там "серебренную пулю". И ведь народ ведется. Почему? Потому что дешево.

Ну и Остап Бендер с его - "Вчера на улице ко мне подошла старуха и предложила купить вечную иглу для примуса. Вы знаете, Адам, я не купил. Мне не нужна вечная игла, я не хочу жить вечно". Никому не нужно качество. Никто не живет вечно.

(Надеюсь понимаете что это немного провокация. Иногда действительно нужно качество.)

(70) видимо, знак свыше...

(56) если ты на крупном динамичном проекте, то не получится отсидеться с плохим кодом. Гораздо раньше тебя настигнут проблемы с качеством ПО, чем сменится платформа, винда, наступит конец света

(67) в том-то и дело, что сначала наипашут по быстроляпным методикам, лишь бы на рынок выползти, а потом несут колоссальные расходы на развитие софтины. Хорошо если доходы от продаж покрывают все расходы. Но если ты пашешь на конкретного заказчика, то никакого скачка продаж у тебя просто не будет, чтобы им заткнуть резко возросшие расходы

Ещё процитирую того же Мартина
"когда создается правильный программный код, происходит что-то необычное: вам не требуются толпы программистов для поддержки его работоспособности. Вам не нужна объемная документация с требованиями и гигантские баг-трекеры. Вам не нужны огромные опенспейсы, работающие круглые сутки без выходных. Правильный программный код не требует больших трудозатрат на свое создание и сопровождение. Изменения вносятся легко и быстро. Ошибки немногочисленны. Трудозатраты минимальны, а функциональность и гибкость — максимальны"
в той же книге Мартин приводит реальный пример из жизни, как одна популярная коммерческая софтина становилась всё дороже и дороже с каждой новой версией. Если кратко, со временем производительность программистов упала в 40(!) раз по сравнению с производительностью тех же программистов на первой версии. К сожалению формат форума не позволяет вставлять картинки и спойлеры, так что скопипастить не могу

(71) Дешево? да конечно, вон сап или прочие ораклебизнес

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

(70)  перестройка началась с 27 го сьезда . Но похоже.

(73) <если ты на крупном динамичном проекте, то не получится отсидеться с плохим кодом.>
андройд вам в пример, они как минимум до 8 версии не могли качество вытянуть, да и то я сомневаюсь

(0) а чего все с 1с программистами меряются? никак лавры не могут получить такие же?

(68) Я тебя сначала на дак послал )))
А вообще, некоторые в этих ваших говорят, что яндекс в русском ищет лучше

(64) Всё так, да не всегда так. "Правильный подход" работает, когда заказчик платит за конечный результат, а исполнитель понимает, что проблемы, закладываемые с плохим кодом или архитектурой, придется решать ему же, за свой счет. Это работает на крупных проектах, с большим сроком поддержки. Это работает при разработке типвоых (отчасти :). Это работает при разработке платформы.

Но это не работает на фрилансе и во франчах, когда тебе платят за часы работы. Даже если ты все объяснишь заказчику, что можно сдежать по-быстрому, потом будут такие м такие проблемы, а можно качественно, но дороже. Даже если он тебя поймет. Он спросит: "И когда начнутся эти проблемы?" Ты честно ответишь: "Через год, может два". И что заказчик решит в итоге? Конечно же: "Давай быстрее! Хз что с моим бизнесом будет через год."

В итоге бабло побеждает и добро и зло.

(71) "Никто не живет вечно" - сильно увеличилась скорость изменений. Раньше можно было всю жизнь проработать "программистом на фортране". Лично знаю талантливого программиста, недавно ушедшего на пенсию, который фактически с 85 года кроме си,  да нескольких асмов ничего не использовал. Мы, начиная с начала 90-х, уже с полдюжины основных инструментов сменили. У молодежи уже слышал "это древнее 6-летнее дерьмо"...

(78) хуже этого - только в мизду

(75) на том моим родителям обещали, что будут при коммунизме жить. И тело ИС вынесли

(81) "Я бы вас послал, но вижу - вы там уже были..."

(83) "я в _этом_ весь..."

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

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

(85) Не в масштабе задачи дело. А в том, на кого ляжет стоимость поддержки. Если не на ту же команду, что решает задачу изначально, все — ХХП-аджайл выгоднее, а значит побеждает.

(86) на .....» диск итс» наверное . Первая команда скажет
Да дам все типовое ... обновляйтесь  с инета и норм.

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

на мисте конечно же

на самом деле нужен не "качественный" код, а система разработки, где тесты ревью, стат анализ и все такое
Но в 1с такого практически нигде нет.
А "качественный" код - он такой пока ты его сам сопровождаешь

(52) Откуда они у меня сложные задачи то. Да и честно если есть задача сложна ее же можно упростить и нагулить решение.

(54) А оно им не надо. Ну если кроме волшебной кнопки - сделай мне хорошо.

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

(93) можно переписать - значит никогда не будет переписано

(49) Еще одна беда в мозгах заказчика: вера в том, что "добавить кнопочку" - это очень просто и занимает 1 час, независимо от кнопочки, только жадные программисты деньги берут ни за что.

А как не гуглить? Фронт работ в 1С такой, что 5 лет надо минимум, чтобы текущие сферы изучить. А через 5 лет - смена парадигмы - и всё заново.
Сегодня я разбираюсь с подключением онлайн-кассы - изучаю драйвера, XML и прочее. Завтра понадобится выяснить, почему вычет по НДФЛ у беременной в командировке 5000, а не 6000. Послезавтра влезть в расчет себестоимости ERP...

+(95) Даже у нас. начальник одного из отделов, хороший айтишник(!), надавно выдал: "потребуется небольшая доработка 1С...."
Откуда ему знать, что она небольшая? Просто за голову хватаешься.

(94) Проект с говнокодом загибается когда прошлые проги уже убежали а новые проги как только понимают готовы убежать с проекта.

(97) Он начальник уже - если скажет большая ему по шапке

(88) Да везде. Вот, например, понадобилось на УФ раскрасить строки в таблице значений. На ОФ делается через "ПриВыводеСтроки", а на УФ этого в принципе нет. Погуглил - это вообще не кодом делается, а через Условное оформление.

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

(95) У меня заказчик есть такой - он всегда разговор начинает со слов "Там всё просто"/"Там небольшая доделка".

(97) Ну может он представляет архитектуру, а следовательно - объем доработки.

(101) тонкая вещь. лучше архитектуру сделать сразу нормально, а вот код - уже вторично.

(93) "потом всегда можно переписать"

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

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

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

"полностью переписано по причине изменения задачи"

Ты не поверишь, в сложных и важных участках системы только так и происходит. Уже через год весь код может поменяться чуть меньше, чем полностью. Но вот тут-то как раз хороший код выходит на передний план. С хорошим кодом работать легко и приятно: его легко понимать, легко дорабатывать. С плохим кодом всё ужасно: ты будешь часами сидеть и пытаться понять, под какими грибами был автор кода и что же этот код вообще делает, долго-долго будешь думать, как и куда вносить правки, а когда наконец-то внесёшь изменения, со всех сторон посыпятся ошибки, которых казалось быть не должно. Одна и та же задача будет решена на хорошем коде за 4 часа, на плохом за 40 часов. И это не преувеличение и не передёргивание, разрыв может быть колоссальным. Хороший код пишется не для того, чтобы им любовались. Хороший код пишется, чтобы в будушем с ним было удобно работать

(104) плохой код утянет на дно не хуже плохой архитектуры

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

(107) побаяню:
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=528

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

Как же он за*бал, этот Белокаменцев... везде со своими графоманскими статьями лезет, нигде от него спасения нет

(112) "Могёт, умеет, практикует" :))

(112) а где еще?
зы. зато хоть курсы не ведет...

(110) оно-то может и хорошо, только советы староваты. Сейчас тренд писать самодокументирующийся код, а не втыкать комментарии везде и всюду. Комментарии в коде тоже нужно сопровождать, но многие на это благополучно забивают. На качество кода кладут болт, на качество комментариев и подавно. Уже через несколько итераций изменения кода комментарии становятся не актуальными, а то и откровенно дезинформирующими. "На сарае написано "х#й", а там дрова!"

(115) ну, книга 1985 года все-таки. (причем, если не ошибаюсь, уже второе издание).
Но основные принципы остались: делать код понимаемым для [стороннего] человека.
комментарии в коде: ну на уровне общего оглавления уже достаточно,  а если описаний типа описания функций в БСП - вообще прекрасно.
"используйте имена с подходящей мнемоникой" сейчас нужно читать как "давайте объектам осмысленные наименования", ибо уже не 8 символов в идентификаторах. про goto и говорить не стоит.
ну а в остальном - советы вполне актуальны. Хотя и против тренда (ХХП)

(112) +100500

Среди гугл-программистов особое место занимают миста-программисты

Эх вспомним 2004 год: "Еще одним важным решением в части работы с данными в «1С:Предприятии» является поддержка в полях таблиц составных типов данных. Эта возможность, насколько нам известно, не имеет близких аналогов в других системах. При описании типа поля какого-либо объекта можно выбрать не только один из доступных типов, но и практически любую (с некоторыми ограничениями) их комбинацию." Сергей Нуралиев.
Оригинал: https://v8.1c.ru/metod/article/arkhitektura-1s-predpriyatiya-kak-produkt-inzhenernoy-mysli.htm";

И современный ИТС:
"Избегайте избыточности при создании полей составных ссылочных типов. Указывайте ровно столько возможных типов для данного поля, сколько необходимо. Не следует без необходимости использовать типы "любая ссылка" или "ссылка на любой документ" и т.п. Вместо этого следует более тщательно проанализировать прикладную логику и назначить для поля ровно те возможные типы ссылок, которые необходимы для решения задачи."
https://its.1c.ru/db/metod8dev/content/5842/hdoc

(112) в мире тренд на тупость, поэтому всем нравится)

(100) Жесть, на Мисте начали Белокамецева обсуждать.
Остановите землю

(121) Да чего, он же прикольный, в Первобите работает, народ троллит - кросавчег :)

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

все уже определено: главное для 1Сника-дятла - упорно долбить! Символ 1С - дает пример
https://yandex.ru/video/preview?filmId=10320792347708196743&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DHbdRitpyrZQ&text=Дятел%20террорист.%20%20Дятел%20падла&path=sharelink

(124)
Внедряй! Поддерживай! не ссы!
https://youtu.be/-uGdaKFboHo

(107) вот именно что не поверю. я не вчера родился, и не в одном десятке организаций поработал.
есть требования бизнеса, и своё желание "сделать красиво" приходится засунуть себе куда поглубже и делать так, чтобы люди успели выполнить свои задачи. желательно не оставаясь на работе каждый день до 10 вечера включая выходные.
рабочее решение СЕЙЧАС всегда дороже для бизнеса, чем возможно более оптимальное но ПОТОМ.
да я переписывал здоровенные САПовские бух отчеты, ускорив формирование в 50+ раз. с нескольких часов до минут, НО если бы внедренцы взялись это делать сразу - сроки бы сорвали к хренам и бухам пришлось бы отчетность формировать вручную. - если такое у вас прокатывает, мне жаль вашего работодателя.

(126) "рабочее решение СЕЙЧАС всегда дороже для бизнеса, чем возможно более оптимальное но ПОТОМ." - слово "дороже" в данном случае двусмысленно звучит. Лучше применить "ценнее". а "оптимальное, но завтра" может обойтись дороже, ибо если решение не работает сегодня, то завтра может уже и не наступить.

Классика
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
https://bash.im/quote/420672