Вход | Регистрация
    1  2

Гугл-программисты (статья И. Белокаменцева)

Гугл-программисты (статья И. Белокаменцева)
Я
   mistеr
 
29.09.20 - 20:38
https://habr.com/ru/post/521104/

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

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

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

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

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

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

Получается, в экосистеме 1С усиливается "классовое расслоение". С одной стороны, матерые зубры со ставкой 3-4К (условно), которых на всех не хватит, с другой — гугл-программисты. А среднего класса все меньше и меньше. Не знаю, замечают ли это в 1С, но лучше бы заметили.
   Bigbro
 
101 - 30.09.20 - 12:44
(94) будет как только переписать станет выгоднее чем отмахиваться и терпеть.
я много говнокодил сам, и много разгребал и исправлял чужого говнокода.
но в целом да - если изначально более-менее адекватно оцениваешь задачу то обычно даже неоптимального решения хватает на долгие годы. и выигрыш от быстрой реализации перевешивает.
есть моменты где нельзя делать тяп ляп - это когда продумывается собственно основа, архитектура.
   Prog111
 
102 - 30.09.20 - 12:45
(95) У меня заказчик есть такой - он всегда разговор начинает со слов "Там всё просто"/"Там небольшая доделка".
   Mikeware
 
103 - 30.09.20 - 12:46
(97) Ну может он представляет архитектуру, а следовательно - объем доработки.
   Mikeware
 
104 - 30.09.20 - 12:56
(101) тонкая вещь. лучше архитектуру сделать сразу нормально, а вот код - уже вторично.
   Конструктор1С
 
105 - 30.09.20 - 12:58
(93) "потом всегда можно переписать"

Скорее всего это "потом" не наступит никогда. К тому же потом на этот код завяжется другой код, и выправлять его будет ещё сложнее и дольше. В этом-то вся и суть. Чем глубже в лес, тем больше дров. Чем дальше разработка, тем сложнее и дороже исправлять плохой код
   Bigbro
 
106 - 30.09.20 - 13:02
(105) никогда - так это же отлично. значит вы сэкономили время. и ваше "не очень" решение оказалось достаточным на весь срок жизни продукта.
или вы считаете что ваши решения должны работать вечно? не будет этого, не мечтайте.
все будет выброшено за ненадобностью, полностью переписано по причине изменения задачи, перенесено на другие языки и платформы намного быстрее чем качество кода станет критичным.
увы - но это так.
   Конструктор1С
 
107 - 30.09.20 - 13:14
(106) как раз не сэкономили, а потратили больше. С этим плохим кодом работать придётся, и не один раз, но выправлять его никто не будет.

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

Ты не поверишь, в сложных и важных участках системы только так и происходит. Уже через год весь код может поменяться чуть меньше, чем полностью. Но вот тут-то как раз хороший код выходит на передний план. С хорошим кодом работать легко и приятно: его легко понимать, легко дорабатывать. С плохим кодом всё ужасно: ты будешь часами сидеть и пытаться понять, под какими грибами был автор кода и что же этот код вообще делает, долго-долго будешь думать, как и куда вносить правки, а когда наконец-то внесёшь изменения, со всех сторон посыпятся ошибки, которых казалось быть не должно. Одна и та же задача будет решена на хорошем коде за 4 часа, на плохом за 40 часов. И это не преувеличение и не передёргивание, разрыв может быть колоссальным. Хороший код пишется не для того, чтобы им любовались. Хороший код пишется, чтобы в будушем с ним было удобно работать
   Конструктор1С
 
108 - 30.09.20 - 13:18
(104) плохой код утянет на дно не хуже плохой архитектуры
   Mikeware
 
109 - 30.09.20 - 13:28
(108) ага. Но гомнокод можно исправлять постепенно. а архитектуру практически невозможно исправить.
   Mikeware
 
110 - 30.09.20 - 13:32
   Mikeware
 
111 - 30.09.20 - 13:34
(106) "все будет выброшено за ненадобностью, полностью переписано по причине изменения задачи, перенесено на другие языки и платформы намного быстрее чем качество кода станет критичным." - не всегда. иногда затык на большем объеме данных становится существенным.
   Dzenn
 
112 - 30.09.20 - 14:06
Как же он за*бал, этот Белокаменцев... везде со своими графоманскими статьями лезет, нигде от него спасения нет
   Стаканов
 
113 - 30.09.20 - 14:08
(112) "Могёт, умеет, практикует" :))
   Mikeware
 
114 - 30.09.20 - 14:32
(112) а где еще?
зы. зато хоть курсы не ведет...
   Конструктор1С
 
115 - 30.09.20 - 14:32
(110) оно-то может и хорошо, только советы староваты. Сейчас тренд писать самодокументирующийся код, а не втыкать комментарии везде и всюду. Комментарии в коде тоже нужно сопровождать, но многие на это благополучно забивают. На качество кода кладут болт, на качество комментариев и подавно. Уже через несколько итераций изменения кода комментарии становятся не актуальными, а то и откровенно дезинформирующими. "На сарае написано "х#й", а там дрова!"
   Mikeware
 
116 - 30.09.20 - 14:59
(115) ну, книга 1985 года все-таки. (причем, если не ошибаюсь, уже второе издание).
Но основные принципы остались: делать код понимаемым для [стороннего] человека.
комментарии в коде: ну на уровне общего оглавления уже достаточно,  а если описаний типа описания функций в БСП - вообще прекрасно.
"используйте имена с подходящей мнемоникой" сейчас нужно читать как "давайте объектам осмысленные наименования", ибо уже не 8 символов в идентификаторах. про goto и говорить не стоит.
ну а в остальном - советы вполне актуальны. Хотя и против тренда (ХХП)
   novichok79
 
117 - 30.09.20 - 15:15
(112) +100500
   laby1
 
118 - 30.09.20 - 15:24
Среди гугл-программистов особое место занимают миста-программисты
   sikuda
 
119 - 30.09.20 - 15:34
Эх вспомним 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
   sr23
 
120 - 30.09.20 - 15:35
(112) в мире тренд на тупость, поэтому всем нравится)
   palsergeich
 
121 - 30.09.20 - 15:38
(100) Жесть, на Мисте начали Белокамецева обсуждать.
Остановите землю
   Стаканов
 
122 - 30.09.20 - 16:20
(121) Да чего, он же прикольный, в Первобите работает, народ троллит - кросавчег :)
   NorthWind
 
123 - 30.09.20 - 16:33
(119) ну одно другому не противоречит на самом деле. Можно сделать охрененно удобный для конечного пользователя механизм, который, тем не менее, будет работать ракообразно и не вполне рекомендуется к использованию.
   Злопчинский
 
124 - 30.09.20 - 16:48
все уже определено: главное для 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
   sikuda
 
125 - 30.09.20 - 16:51
(124)
Внедряй! Поддерживай! не ссы!
https://youtu.be/-uGdaKFboHo
   Bigbro
 
126 - 30.09.20 - 20:36
(107) вот именно что не поверю. я не вчера родился, и не в одном десятке организаций поработал.
есть требования бизнеса, и своё желание "сделать красиво" приходится засунуть себе куда поглубже и делать так, чтобы люди успели выполнить свои задачи. желательно не оставаясь на работе каждый день до 10 вечера включая выходные.
рабочее решение СЕЙЧАС всегда дороже для бизнеса, чем возможно более оптимальное но ПОТОМ.
да я переписывал здоровенные САПовские бух отчеты, ускорив формирование в 50+ раз. с нескольких часов до минут, НО если бы внедренцы взялись это делать сразу - сроки бы сорвали к хренам и бухам пришлось бы отчетность формировать вручную. - если такое у вас прокатывает, мне жаль вашего работодателя.
   Mikeware
 
127 - 30.09.20 - 20:41
(126) "рабочее решение СЕЙЧАС всегда дороже для бизнеса, чем возможно более оптимальное но ПОТОМ." - слово "дороже" в данном случае двусмысленно звучит. Лучше применить "ценнее". а "оптимальное, но завтра" может обойтись дороже, ибо если решение не работает сегодня, то завтра может уже и не наступить.
   Kongo2019
 
128 - 01.10.20 - 08:28
Классика
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
https://bash.im/quote/420672
  1  2

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.