Пусть программирует Сережа
У каждого клиента – свои предпочтения. Не только в выборе автомобиля, блюда на обед или корпоративной информационной системы. Клиенты любят выбирать программистов.
Ну, что программисты разные – ежу понятно. Считается, что клиенты предпочитают профессионалов. Мы тоже так думали, и искренне стремились сделать каждого своего программиста этим самым профессионалом.
Однако, несколько клиентов, ставя нам задачи, упорно твердили: пусть программирует Серёжа. Хотя Серёжа – лютейший говнокодер, объект всеобщей жалости и главный поставщик материалов для конференций на тему «Как не надо программировать».
Кто такой Серёжа?
Я буду называть Серёжу Серёжей, потому что он просит называть себя именно так. Не знаю, почему.
Ничего особенного. Отучился в ПТУ (колледже) на программиста, пришёл работать. Попал в отдел сопровождения – где надо «а-а-а-а-быстрее-быстрее-клиент-ждёт». Такой старт во многом и определил стиль программирования Серёжи.
Стратегия Серёжи: «быстро и точно». Кратчайшим путём дойти до решения, максимально точно попадающего в исходную постановку задачи. Особенно важна точность интерфейса, включая цвета, шрифты, названия и порядок колонок и т.д.
Сами понимаете, такая стратегия – чрезвычайно сложна. Реализовать её можно либо будучи бешеным профи, либо – оставляя за собой лютейший говнокод. Серёже, конечно, был доступен только второй сценарий.
Клиенты Серёжу полюбили. Руководитель отдела сопровождения – тоже. Но, тем не менее, через три года Серёжа ушёл – в отдел разработки. Туда, где сидят «настоящие программисты».
Переход
Вообще, переходы были нормальной практикой. Человек осваивает какие-то навыки в сопровождении, и идёт к сурьёзным ребятам, задачам и клиентам. Некоторые так и оставались, правда, в сопровождении.
Но Серёжа, будучи почти звездой в сопровождении, нужен был в программировании. Это было не его решение – начальство так постановило.
И началась дичь. И для Серёжи, и для программистов. Закатывали глаза, заламывали руки, брызгали слюной, бились головой о стену. Но ничего не помогало – говнокод стал частью ДНК Серёжи.
Несчастный очень быстро скатился вниз по показателям. Какую бы задачу ему не дали – ни фига не получалось. Точнее, программирование шло с противнейшим скрипом и затратами колоссального времени остальных сотрудников – приходилось объяснять, ещё раз объяснять, тыкать носом, заставлять переделывать и, в конце концов, забирать задачу и, матерясь, переделывать самим.
Начали проседать показатели всего отдела – не сильно, но всё-таки. Ну и атмосфера, конечно, стала гнетущей. Надо было что-то решать.
Позвали начальство.
Решение
Начальство было мудрое. С одной стороны, виден полный провал Серёжи во всём «сурьёзном». С другой – бывшие клиенты Серёжи изнывали без него. Ну а чё, подумало начальство.
Пусть Серёжа сидит с программистами, но решает задачи своих бывших клиентов. Случился лёгкий спор с начальником отдела сопровождения – ведь «забрали клиента». Но, как выяснилось, забирать-то особо нечего, с уходом Серёжи его клиенты почти перестали приносить деньги.
Ну а остальные программисты будут Серёже помогать в развитии навыков, только уже на его задачах и клиентах. На том и порешили.
Пошло хорошо. Первый месяц Серёжа, к великой радости клиентов и начальства, просто херачил весь накопленный пул задач. Быстро и точно, как умел и любил. Но сработал закон Вселенной – чем больше задач клиента ты решаешь, тем больше их становится.
Серёжа перестал справляться с возрастающим потоком. Выход был очевиден – пусть задачи решают и остальные программисты. Те оказались не против. Парней, если честно, немного завидки брали – пусть и говнокодом, но Серёжа зарабатывал больше. А тут – возможность победить засранца на его же поле.
Но начался жесточайший кризис.
Кризис
Программисты полезли в сокровищницу Серёжи и ахнули… Не, говнокод-то они уже видали, но чтобы столько, да в одном месте, и как-то это всё взаимосвязано! И, самое поганое – работает!
Ситуация получалась весьма странная. Раньше Серёжа решал хорошую задачу и огребал за гокновод, который пытался встроить в нормальный, чёткий, лаконичный и выверенный контекст. Теперь – ровно наоборот. Нужно было понять записки сумасшедшего, и хоть как-то вклинить в них что-нибудь изящное и не позорное.
Для программистов это было в новинку. И бесило жутко. Начались скандалы. Брал программист задачу, смотрел, матерился, звал Серёжу и пытался тыкать его носом. Серёжа к тому моменту уже стал чуть смелее, и отвечал просто: «не хочешь – не делай, сам подшаманю». Раз сказал, два сказал – перестали пытаться воззвать к чувству вины.
Ну ладно, сказали программисты. Щас мы покажем – и Серёже, и его клиентам, как надо программировать. И стали молча делать решения так, как положено. Но тут, совершенно неожиданно, взвыли клиенты.
Во-первых, им не нравились решения программистов – они были не точны. Программист ведь почти Бог, и лучше знает, что надо клиенту. Поэтому делает близко к требованиям, но с обязательным внесением своей лепты в постановку задачи.
Во-вторых, не понравились суммы, которые программисты выставляли за свою работу. Они были в разы больше серёжиных. Оно и понятно – быстрый говнокод дёшев, нормальный – существенно дороже.
Фраза «Пусть программирует Серёжа» звучала всё чаще и настойчивее.
Но программисты не сдавались – решили объяснить клиентам, как надо на самом деле. Организовали несколько встреч, собрались, поговорили. Рассказали про архитектуру, стоимость поддержки кода, правильное проектирование, сценарии использования, масштабируемость и т.д. Короче, изложили, что есть «правильно».
Клиенты послушали, головой покивали, но честно признались – всё понятно, но ничего не понятно. Давайте на примерах. Программисты взялись объяснить на текущих задачах.
Под руку попался инструмент планирования загрузки оборудования имени Серёжи – клиент попросил добавить в него новую функциональность. Программисты сказали, что на анализ всего инструмента придётся потратить 10 чел/часов. Но раз такое дело, сделают это бесплатно. Клиент, правда, цифру услышал и запомнил.
После анализа программисты сказали, что весь инструмент надо переделать. От макушки и до пят. И анализ сделать ещё раз – только не кода, а требований, процессов и сценариев. С людьми поговорить, короче. А тут уже не обойтись без привлечения бизнес-аналитика.
Насчитали, в итоге, предварительную стоимость в 120-160 чел/часов. Клиент был в шоке – нахера отдавать столько денег за создание с нуля инструмента, который уже давно работает? Программисты пытались объяснить, что это будет правильно. Говнокод обязательно сломается когда-нибудь, не будет масштабироваться, не натянется на него очередное функциональное требование.
Но всё было тщетно. Клиент перестал слушать программистов. Твердил, как заведённый: «Пусть программирует Серёжа». Особенно с учётом того, что Серёжа оценил текущую доработку в 4 чел/часа.
Но программисты не сдавались. Они пошли к начальству.
Финал
Программисты знали, что начальство, конечно, уважает всякие там «технические подробности», но любит деньги. Поэтому решили надавить именно на доход – сравнить суммы от «хорошего» и «плохого» программирования.
За основу взяли тот самый инструмент планирования, который оценивали для клиента. На вторую чашу весов положили свою фантазию на тему «за сколько Серёжа это говнокодище сделал», и добавили известную им стоимость доработок инструмента за последние месяцы.
Итак, хороший код принёс бы компании 160 чел/часов. Плохой, по оценкам программистов – 50 чел/часов. Отправили цифры начальству, попросили о встрече.
Начальство, напомню, было мудрое. Решило выслушать и вторую сторону – попросило Серёжу посчитать, сколько компания заработала на создании и доработках этого конкретного инструмента. Ну и назначило встречу на всех.
Серёжа насчитал 300 чел/часов. И не просто насчитал – принёс документы, которые подтверждали цифры. Чаша весов резко качнулась. Но Серёжа, кроме денег, докинул на неё свои говнокодерские аргументы.
Во-первых, инструмент работал уже через месяц после начала создания. Да, через задницу, но задачи клиента решал. Во-вторых, инструмент продолжал развиваться и выполнять своё предназначение в течение двух лет. Ну да, не развиваться, а «развиваться». В-третьих, ни разу, ни единого разочка, с клиентом не было проблем – ни с инструментом планирования, ни с другими задачами.
Четвёртое добавило начальство – неистовая, слепая лояльность клиента. К Серёже, конечно, но через него – ко всей компании.
Программисты с выводами не согласились, но уже исчерпали все аргументы. Раз такое дело – пусть и правда программирует Серёжа.
P.S.
Развитие истории получилось неожиданным. Чутка поостыв, программисты подумали, поговорили, поспорили и… Признали право Серёжи и его говнокода на существование. Решили к нему даже присмотреться. И, по возможности, поучаствовать – очень, почему-то, захотелось и к себе неистовой лояльности.
Правда, отношения с клиентами Серёжи уже успели испортить. Поэтому решили так: пусть клиент думает, что программирует Серёжа. А задачи будут решать программисты. Не все подряд, разумеется, и не только их – свои клиенты никуда не делись. Никто не собирался менять веру и уходить в говнокод с головой.
Стали просто разбавлять. Один день красиво программируешь, другой – пускаешься во все тяжкие. Сравнивали дни говнокодерства с мероприятиями вроде Ла Томатины. И, как ни странно, остались довольны.
Во-первых, чутка больше зарабатывали – доработки говнокода требовались часто. Во-вторых, нашли в говнокодерстве профессиональную ценность – лучше понимали, как надо писать код. В-третьих, обнаружили, что и своим клиентам иногда полезно сделать «быстро и точно» - лояльность повышается, а следом – и поток объём задач. В-четвертых, клиенты Серёжи, наконец, сдались и разрешили другим программистам официально решать их задачи.
Теперь можно услышать не только про Серёжу. Пусть программирует Коля, Петя, Вася. Жить стало интереснее и проще.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
С 1998 года я писал код в 1С сам, руками, от первой строки до последней. В марте 2026 я рассказывал, как проект на пять месяцев ИИ воспроизвёл за час. Прошло полгода, и теперь я не пишу код совсем, я даже не проверяю его и при этом закрываю 30-40 задач в месяц. Это история о том, что осталось от программиста, когда из его работы ушёл код, почему у одних коллег этот переход получается за месяц, а у других не получается вообще и почему ИИ без опыта за плечами это умножение на ноль.
20.10.2026 5437 GarriSoft 378
О жизни 1C:Бухгалтерия Бесплатно (free)
Как я считаю стоимость своего часа, почему не извиняюсь за цену и что отвечаю на «дорого». Без теории — только то, что работает в разговоре с заказчиком.
11.09.2026 4438 qwerty1414 73
О жизни Россия Бесплатно (free)
Расскажу, как это было у меня. Собеседования я не умею проходить от слова совсем, особенно когда начинают задавать вопросы типа: • Что такое структура? • Что такое соответствие? • Чем соответствие отличается от структуры? • Как обратиться к общему модулю из формы документа? • Как надо обновлять доработанную конфигурацию?
28.07.2026 6135 chuevsf 175
О жизни Россия Бесплатно (free)
Моё личное мнение о перспективах ИИ в среде 1С.
23.06.2026 5335 1c-intelligence 114
30 лет в 1С, 51 год, жёсткие требования к формату работы. За 1.5 месяца нашёл работу, используя DeepSeek как персонального HR-ассистента. Один раз настроил, отправил три своих резюме - дальше просто скидывал вакансии в чат и наговаривал ощущения через микрофон. ИИ анализировал, отсеивал фейки, писал сопроводительные письма, готовил к собеседованиям и разбирал ошибки. Результат: 127 откликов, 2 оффера, выход на работу 1 июня с достойной зарплатой (гибрид, к сожалению, мы с ним не нашли)
20.05.2026 9303 GarriSoft 227
О жизни Россия Бесплатно (free)
В далеком 2007 году я услышал впервые слово «Инфостарт» от своих коллег по работе и нашел этот сайт в Интернете, а 29.06.2007г. успешно зарегистрировался на нем. В течение долгих лет я был «молчуном»: не выкладывал никаких наработок и не писал статей. Просто читал, время от времени, и получал на сайте информацию.
14.05.2026 6108 chuevsf 207
О жизни Россия Бесплатно (free)
Еще совсем недавно у программистов 1С было всё хорошо. Задачи на выполнение сыпались, как из рога изобилия. Счетчик времени зашкаливало от быстроты их выполнения. Чуть ли не каждый месяц был новый рекорд. Новые идеи генерировались бизнесом одна за другой. Но общее состояние экономики в России в 2026 году уже давали о себе знать, и группу компаний также стало лихорадить.
17.04.2026 12052 chuevsf 244
Личные заметки о том, как 1С-разработка столкнулась с вызовом времени. От FoxPro до "гаражной инженерии" - тридцать лет по одним и тем же граблям.
02.04.2026 12992 GarriSoft 280
Но удивительно при этом - код работает и не сильно нагружает систему... Клиент сервер помощнее поставил - и даже не знает, что что-то там написано криво.
Это как история развития отчетов - вначале были примитивные формы (v77), написанные под пользователя, где он управляя 1-2 галочками или полями ввода настраивал что ему нужно на выходе. Порой, в таком отчете было 3-4 или даже больше кнопок "Сформировать" и под каждую - свой отдельный алгоритм написан и свой макет нарисован. И всем пользователям, кроме 1-2 бухгалтеров, было удобно.
Потом появился "Универсальный отчет" на построителе, с кучей настроек, который надо было ещё настроить под себя каждый раз и сохранить настройки. Неудобно, надо понимать что как устроено в БД.
И только потом, появилась СКД, внутри которой - варианты отчета (несколько предопределенных настроек отчета + того, какие поля настроек показывать в форме самого отчета). Получилось сделать почти как в v77.
Я знал двоих персонажей, которые разносили чужой код. Оба с мерзким характером, нелюдимы. Было ощущение, что они нашли для себя оружие, которым отбивались от внешнего мира - это желчь. Но стоит отдать должное, один из этих персонажей профессионал своего дела, который соблюдал собственные рекомендации, а у другого нет ничего, кроме мерзкого характера.
Мне в то время довелось поработать в проекте, который делался по это методологии, было круто. Ну и такой подход безусловно имеет право на жизнь при высоком уровне лояльности заказчика. Например для внутренней разработки, если на работе не много политики, он на мой взгляд является оптимальным.
А правильные, но не признанные клиентами "гении" и "академики" от программирования, пусть задумаются чего им в действительности не хватает для конкуренции с Серёжей...
Как и любой другой товар, программный код имеет показатель цена\качество... а любой продавец товаров Вам скажет, что большинство продаж это нижний ценовой сегмент... выбор большинства покупателей стремится к показателю цена, а не к качеству... поэтому, если заказное программирование это Ваш бизнес, то Вы не можете не учитывать психологию покупателя... говнокод был, есть и будет всегда, как и остальные говнотовары...
И если бы так ценились низкоквалифицированные программисты... Посмотрите на зарплаты. Все хотят высококвалифицированных. Так что статья расходится с реальностью.
Четвёртое добавило начальство – неистовая, слепая лояльность клиента. К Серёже, конечно, но через него – ко всей компании.
Ну и там совершенно не обязательно должен быть совсем злой говнокод. Что там 100% неизбежно должно быть, что должно было кодеров в этой сказочке выбешивать - изменения кода скорее всего были оформлены в виде патчей и оставлены "закоменченные" куски старого кода, чтобы можно было без усилий вернуть все в зад. Потому что так быстро и дешево, и вероятность того что придется это переделывать относительно низкая.
Это как в известном пирожке
Бог создал труд и обезьяну
Чтоб получился человек
А вот пингвина он не трогал
Тот сразу вышел хорошо
Так и тут, считаем что создаем пингвина и он выйдет хорошо сразу.
1) умение общаться с клиентом. Видимо у профи таких навыков нет.
2) делать MVP и потом его дорабатывать. Деньги размазываются по периодам и воспринимаются заказчиком лучше.
Да и польза от продукта появляется быстрее.
А в целом да, не дай бог работать после такого Сережи)
1. Кто умеет общаться
2. Кто хорошо делает работу
Общество очень часто выбирает первого, т.к. не могут оценить профессионализм зачастую.
Общение оценить легче
делать что-то он при этом и не должен, а делают - другие!
так и тут - говорить хорошо, а делать (и переделывать) за него - придётся другим!
не согласен - Люди и компании (которые ценят своё время и силы)
обычно предпочитают вариант 2) - чтобы работа была сделана, а не "пообщались хорошо"
а кто хорошо общается и плохо делает работу - называется "пустобрёх"
и это "мягкое" название, обычно говорят резче и нецензурнее
Но Заказчику надо было поскорее, поэтому мои красочные рассказы об "удобной форме с удобными кнопками и мульоном настроек под капотом" его не порадовали, а расстроили.
И услышал я от него фразу, которую теперь применяю постоянно:
"НЕ НАДО ГЛОБАЛИТЬ!!!"
И услышал я от него фразу, которую теперь применяю постоянно:
"НЕ НАДО ГЛОБАЛИТЬ!!!"
Хорошее выражение, мне понравилось.
Я стараюсь на этапе обсуждения с заказчиком расставить рамки, насколько все должно быть круто. Может быть два принципиально разных концептуальных подхода к разработке
Первый подход - пользователь думает головой, а если косячит, то исправляет косяк и налетает на штраф. И есть у пользователя начальник, который за ним приглядывает.
А второй подход - считается, что пользователь поросенок и будет творить что попало, а программа не будет ему давать косячить.
По деньгам, реализация второго подхода будет стоить раза в три дороже, чем первого. Хотя решение лежит не в области разработки, а на административном уровне.
и не очень долго...
а когда таких "Серёжей" не 1, а человек 5-6 и поработав полгода они уходят...
остальным - придётся разгребать за ними всё это барахло!
А когда это надо ещё и обновлять каждый раз...
с каждой итерацией это всё сложнее и сложнее...
И в один прекрасный момент - не очень-то хорошо получится
придётся бесплатно! переписывать "как надо", но уже другим!
и придётся переделывать ВСЁ с нуля !
для руководителей - надо ЭТОТ аргумент привести - что переписка займёт в 3-5 раз больше времени и сил более квалифицированных программистов - и оплачивать ЭТО будет руководитель из своего кармана!
Они незаменимы. Когда надо быстро сляпать прототип, и показать заказчику.
Потом, когда заказчик будет доволен как выглядит прототип, "индуса" пошлют на новый прорывной стартап, а вместо него уже за дело примется команда профессионалов.
Все на своем месте, все - довольны. Главное - осознать эти роли, и не перепутать!
Все вполне объяснимо. Многие сопровожденцы далеко не программисты и "что-то делать в конфигураторе" учатся на клиентах. Клиентам важно решение, которое их устроит и побыстрее, и еще подешевле. Обычно как: дешево и быстро? значит - некачественно. Так и есть с точки зрения дальнейшего сопровождения, оптимальности работы и прочего. Но клиента устраивает - оно работает и ладно. Клиенты не программисты и не знают (да и не хотят знать) всех тонкостей разработки и поддержки. Им важно быстрое и рабочее решение их проблемы. И за это они платят. Чаще всего их волнует результат "здесь и сейчас", а дальше будет дальше, как-нибудь обновится, поддержится.
"Рассказали про архитектуру, стоимость поддержки кода, правильное проектирование, сценарии использования, масштабируемость и т.д. Короче, изложили, что есть «правильно»." - вот это вообще было зря. У них уже есть Сережа, который им делает, оно работает и им выходит гораздо дешевле. Так что ваше "правильно" оно, может быть, качественно и дорого, но клиенты скорее подумают о том, что их разводят на деньги, потому что у них есть свое видение "правильного". Доводы "У Сережи говнокод!" вообще для клиентов пустой звук.
Клиенту небольшому хочется недорогой поддержки, лишь бы работало. Вот когда они вырастают и начинаются проблемы с производительностью - тогда и есть смысл приводить к ним настоящих программистов, экспертов и архитекторов, но это будут совсем другие деньги.
Похлопаем Сереже.
(33)
И вот в этот момент приходится все переписывать, т.к. код не читается вообще и выясняется, что проблема не в производительности в каком-то конкретном месте. А там все так написано.
И еще такое бывает, когда не клиент "вырос", а Сережа (с убытием в другой город, профессию, и т.д.)
Скупой платит дважды
Самое важное, подавать вовремя нужное решение, а не идеальное.
Мы это должны клиента спросить или за него сами решаем? Как ему это надо.
И почему качественно обязательно дольше?
Возьмем обычный запрос. Его можно написать правильно или неправильно. Банальное размещение отборов в правильном месте занимает ровно столько же времени как и в неправильном. И на выходе будут одинаковые данные.
И даже работать они будут одинаково быстро в первое время.
Спросить обязательно.
Качественно не обязательно дольше, но в большинстве случаев это все таки дольше.
С запросом согласен полностью. Неверное размещение отборов это не только говнокод, но и безграмотность программиста. А мы говорим не о безграмотности, а о говнокоде.
Возьмем пример, нужно сделать загрузку с сайта заказов, через xml.
Как правильно - изучим оформление заказов, какие есть особенности заполнения складов, подразделений и т.д. Опросим пользователей. Придумаем хорошую структуру xml. Напишем ТЗ, согласуем все это с разработчиками сайта и клиентом. Напишем сценарий тестирования и т.д.. Потом все это разработаем, оттестируем и подадим на блюдечке клиенту. На что уйдет черт знает сколько времени и соответственно денег клиента.
А есть быстрый вариант - когда не вникая особо в процесс оформления заказа, на "коленке" обсудим с разработчиками сайта структуру, приступаем к программированию. Данную обработку будем допиливать и допиливать десяток раз, отлавливая по ходу ошибки. Скорее всего код будет ужасен, хотя возможно изначально он был и не плох. Но множество заплаток, которые ложатся друг на друга сделают код не оптимальным. Тем более все заплатки нужно делать быстро, так как заказ оформлен, а в систему не грузиться и все ждут, когда программист допилит загрузку и можно двинуться дальше.
В результате получаем говнокод, но загрузка может начать работать уже через день-два после старта работ, криво косо, но работать и приносить пользу бизнесу. И после "тестирования" на реальных данных, обзаведясь кучей заплаток начнет работать вполне успешно.
Будет ли вариант два дешевле? Это неизвестно. Но если клиенту критична скорость, то вариант имеет право на жизнь. Если клиент готов потратиться на оптимизацию кода, то можно это сделать потом, когда все заработает. Хотя я таких клиентов встречал крайне редко.
Если я буду со стороны заказчика - вы мне не сдадите работу просто)
Сейчас есть проект, в котором я представляю другую сторону.
Началось в октябре 2021, когда меня попросили проверить сделанную интеграцию 1с с Битрикс24.
Смотрю, а там php-скрипт "посередине" (на сервере с 1С должен работать). Спрашиваю зачем, а они типа так все реальные пацаны делают. Это было только начало)))
Убрал за них завязку на скрипт. И дальше одно за другим. Короче цифры сделок до сих пор некорректные. Должны были все сдать в течении месяца))))).
Там работы было часов на 40. Люди умудрились развезти это на много месяцев. Я не знаю доплачивают ли им за исправления, но все это время интеграция не работает.
Был другой случай, когда был сделан обмен, и спустя полгода выяснилось, что сумма без НДС при передаче считается в другую сторону))))) Потом вылезали другие косяки, а потом еще. И через какой-то момент меня подключили к переговорам по согласованию этого же подрядчика на проект в другом месте. Я просто сказал, что их нельзя брать и просто расписал всю прелесть их подхода и перспективы гарантированных проблем.
Был еще случай, когда чел написал ПО (не на 1с) и через некоторое время предложил продать конторе сервер, т.к. тот что был не тянул. Ну как бы решение работало, сделано было быстро, но требовалось заменить сервер.
Позвали посмотреть. Выяснилось, что его продукт
Есть просто связь между подходом к делу и результатом.
Нужно развиваться как профессионал.
Клиент сейчас стал умнее. Даже здесь в тендерах можно найти запросы на проверку чужого кода. Придет время, к вам тоже придут)
Попробуйте кто-нибудь клиенту, у которого 1-2 точки прокинуть мысль о продукте стоимостью 10 месячных оборотов этих точек :) Может он закроет эти точки через полгода. Зачем сильно заморачивать продукт для такого клиента "всякими" архитектурами?
Подрастёт клиент, подрастут требования - поймет, что может освоить более серьёзный продукт и закажет новый, дорабатывая на старом. Это же эволюционный процесс как со стороны клиента, так и со стороны программиста.
У меня опыт работы более 15 лет и я многое видел :) Видел, как сделанный на коленке за месяц-полтора продукт зарабатывал в 10 раз больше своей стоимости, столько же сколько и другой - профессиональный. Видел как продукт, который разрабатывался на заре становления предприятия и дошедший до определенного уровня, остановился в развитии и его функционала хватает уже 5-7 лет без доработки... Потому что серьёзный продукт со свистелками и перделками стоит как боинг. Из-за наличия в каждом проекте аналитиков, программистов, тестеров и прочих специальностей продукт набирает денежный вес, а нужно всего то базовый функционал.
Подход "Сережи" безусловно плох и в конечном счете как и показано в рассказе стоит дороже всем - и клиенту и задействованным специалистам. Но идеалистичным перфекционизмом это не лечится. Это как лечить грибок ногтей ампутацией. Любое легаси, на то и называют легаси, что ты или отказываешься от него совсем или как-то пытаешься с ним жить: изолируешься, понемногу рефакторишь изолированные и декомпозированные фрагменты, если текущие задачи требуют модификации этих участков кода. Ну или в запущенных случаях просто параллельно делаешь своё решение "сбоку", которое постепенно будет перехватывать функциональный контроль.
Я привык решать задачу так, чтоб больше не слышать о ней до конца проекта. Точно наверно напишу как нить об этом статью с кучей примеров из практики.
Тем более что бизнесу ваше "качественно" неинтересно. Бизнесу нужно эффективно. Потому что задачи у бизнеса здесь и сейчас и решать их надо еще вчера, а не через неделю. Ну и затраты на них должны быть соразмерны проблемам.
Если у вас огород в 6 соток, то вам хватит садовой тачки чтобы отвезти урожай на ближайший базар. Надоело катать - приколхозим мотоблок. Да, будет неэстетично, зато дешево, надежно и практично.
Покупать для этого грузовик с манипулятором излишне. Хотя "по науке" все правильно и дважды платить не придется. Только вот никто не хочет думать, что огород может так и остаться на 6 сотках и этот грузовик нафиг не сдастся, разве что по праздникам девок по деревне катать.
Ессно когда такой материал готовится, то качество не связано с заказчиком. Я поделюсь своим пониманием качества, приведу аргументы...
Конечно же материал будет некоторым образом идеализирован. А дальше каждый сам принимает для себя решение - нужно ему так? полезно?
Кому-то не нужен грузовик, а нужна садовая тачка с моторчиком. Если бюджет заказчика предусматривает только быстрый и грязный код - то у него будет именно такой код. Но при этом он будет работать и будет приносить закачику ценность.
Делать иначе - это или бесполезно тратить свое время, или разводить заказчика на лишние деньги. Оба варианта плохие.
Вылизать код можно тогда, когда вы делаете тиражное решение, под какую-то типовую проблему, которое пойдет потом в широкие массы.
Вот вам реальная задача. Заказчику понадобилось чтобы кассир мог печать кассовую книгу, а там вылезло что не хватает прав, причем прав на кадровую подсистему.
Варианты:
а) сесть и разобраться с правами, долго, дорого.
б) УстановитьПривилегированныйРежим(Истина) - быстро, дешево и эффективно.
В описанной задаче разобраться в задаче этой - не долго и не дорого, а второй вариант - ошибочный, ибо даёт на это права всем, а не одной роли!
Именно на это и хочу нацелить статью, чтоб было меньше дефективных решений!
Потом нужно найти и дать нужные права роли. Это как раз самое простое.
А потом еще нужно проконтролировать, что после выдачи таких прав у него не окажется чего-то там лишнего, чего быть не должно. А это тоже вы сами не сделаете, ибо нужно понимать что именно по этому поводу думает заказчик.
В тоже время установить привилегированные права на печать формы, точнее на кусок кода, которые получает нужные данные, а потом их забрать никакой опасности в принципе не несет, хоть для одной роли, хоть для всех. Быстро и недорого решает проблему заказчика.
И опять таки смотрим в корень. Заказчик ставит вам проблему - у него не печатается форма у кассира. Вместо того, чтобы сделать так. чтобы она печаталась вы начинаете выносить ему мозг по набору прав, а потом выкатываете счет за несколько часов. Заказчик в афуе, мол нифига себе "напечатал". А еще через месяц выяснится, случайно, что кассир видит то, чего видеть не должен и будут очень и очень неприятные вопросы.
P.S. Был у меня один молодой коллега, который с первого дня решил все делать правильно, через три месяца его из конторы уволили с формулировкой "дурачок какой-то, нам тут работать надо, а не в его игрушки играть".
Дело в том, что я уже больше 10 лет занимаюсь разгребанием говнокода. И этот говнокод в длинную имеет космическую стоимость. То о чём я говорю не касается вот таких мелких задач. Сам не занимаюсь такими. Самая маленькая задача, которой я занимаюсь занимает обычно 2 недели. чаще месяц-два. А обычная для меня задача длится до полугода.
Поэтому мы мыслим разными масштабами, в каждом масштабе применимы разные подходы. Всё что мною написано относится к серьёзным задачам, а не к сопровождению торговых точек. Речь о внедрении.
ps: может зря уволили коллегу? Желание делать качественно очень полезно на проектах!
Но речь не об этом. При вашем подходе заказчик оплачивает то, чего он не просил и что ему может никогда не понадобиться. На маленьких примерах это как раз очень заметно.
А на крупных бывает так: сделали, внедрили, заплатили кучу денег, но уже в эксплуатации начинают выясняться разные интересные вещи, которые надо было сделать по другому. И начинается либо "говнокод", либо новые проекты на полгода.
Любая задача должна исходить из решения проблемы заказчика, на том уровне, на котором заказчик находится. А с позиции ваших сияющих высот: заказчик либо покупает совершенно не нужный ему грузовик, либо вы с ним даже разговаривать не будете.
С точки зрения клиента, если вдруг ему не надо... собственно я с такими не работаю! ибо считаю неадекватными.
Ко мне приходят те, где уже пару команд обосрались/наговнокодили (пардон за мой французский)... и там уже понимают, что решение должно быть продуманным и качественным.
А те кому не надо, пусть берут Серёжу и пусть он себе говнокодит на здоровье!
Именно поэтому у меня и есть желание написать материал, привести примеры, обосновать почему писать качественно - это ВЫГОДНО! Причём выгодно именно заказчику. Ярых говнокодеров не переубедить. От них можно только избавляться на проектах. Но очень много тех, кто просто не знает как делать качественно. Вот это как раз моя аудитория + ессно те кто является заказчиками и терпит большие убытки от говнокода..
Вариант с УстановитьПривилегированныйРежим в печ.форме как раз таки оптимальный, т.к. в этом случае не будут усложняться запросы на чтение фиксированных (необходимых для печ.формы) данных, особенно при пакетной печати. зы: Но можно эту доработку непосредственно в конфу внести, включив возможность изменений, а можно расширением или внешней печ.формой - первый способ быстрее, зато второй правильнее.
Есть тачка, заказчик хочет чтобы тачка ездила сама.
А грузовиков по цене тачки не бывает, должны прекрасно понимать, а если и бывают, то обходить их надо десятой дорогой, потому что утомитесь его ремонтировать. А тачка с моторчиком уже завтра ваше ведро картошки повезет на базар, вместе с вашей задницей. Одна беда - девок не покатаешь.
Под горку тачка прекрасно едет сама, демонстрация прошла успешно, немного рассыпавшийся урожай списали на погрешности ручного ввода оператором картошки в тачку. За минутную смазку и подкачку колес выставлен счет на пару часов, счет заказчиком оплачен - все довольны, задача решена)
Да и получить "техзадание" от заказчика - это еще постараться надо. Обычно описывают задачу или проблему, а как вы ее решите - дело ваше.
Будет расширяться огород - можно и грузовичок купить. А может и не будет завтра того огорода, выкопает заказчик пруд и будет там рыбу разводить. И не грузовик ему понадобится, а лодка.
Собственно по этому с "Сережами" и работают, потому что он дает недорогое решение именно насущных проблем. И эффект от них виден сразу.
Да, если компания начинает расти, то все это надо будет переделать и это будет стоить денег. Но там переделать надо будет не только программу, а вообще все. Начиная с учета и бизнес процессов.
Дополню, что ваше утверждение
(35)
не по букве, но по духу, и главное с экономическим базисом фигурирует и у меня в сообщении.
не понимаю, с чем не соглашаетесь? С тем что "оба хуже"?
Фишка в том, что "бизнес" нифига не одинэсник. И в 95% случаев он не в курсе надо оно ему или нет. И уж тем более бизнес не может просчитать последствия ошибок.
В общем я за качество)
Разверну мысль. Суть работы разработчика как инженера в широком смысле это воплощение "в железе" потребностей заказчика. Да, заказчик может многого не знать о будущих потребностях, но текущие нужды он может сформулировать. Задача же программиста/архитектора реализовать потребность в кратчайшие сроки, заложив, при этом задел на расширение и доработку решения, ести это потребуется в будущем.
При этом вполне очевидна мотивация сделать сразу "совсем хорошо", но повторюсь это следствие идеалистического восприятия нашей работы. Да, хорошее решение сразу займет в сумме меньше времени, так как не будет затрат времени на погружение в контекст. Но с другой стороны, что вы за программист, что не может сделать заготовку хорошего решения так, чтобы погружение в контекст не было долгим?
Но, в любом случае, когда речь идет не об астрактной разработке, как вещи в себе, а о части производственного процесса, то становится очевидной арифметика реального управления, когда 100 рублей нормального решения завтра больше чем 150 рублей хорошего решения через неделю/месяц/год, а в некоторых случаях даже плохое решение за рубль, но прямо сейчас будет оптимальным вариантом.
Правда, в случае с рублём это маркетинговая уловка "Сережи" или того, кто его имитирует. В итоге цена будет в районе тех же 100 рублей или уйдет в техдолг, оплата процентов по которому, обычно и топит проекты, что даёт козыри идеалистам.
Как думаешь думаешь налоги можно посчитать примерно? А зарплату коллективу? С разбегом +/- 2000 р.? Нет нельзя!
Вот поэтому я и есть идеалист. Если б работал с УТ или с бухнёй был бы меньшим идеалистом. Там пересортица это норм. Лишние затраты пару лямов размазать по всему производству - обычное дело и т.д.
Но когда приходит Серёжа и начинать говнокодить в ЗУПе - это вообще недопустимо ни при каких обстоятельствах. Эта конфа не прощает ошибок)))
И главная проблема в том, что в ЗУП решение задачи на 70% занимает меньше половины времени. А вот остальные 30% это и есть самое сложное, что при говнокодерстве обычно не решается. Ибо большинство таких задач в принципе говнокодом не решить! Приходится такие решения переделывать с нуля. Именно чтоб учесть 30% сценариев, иногда даже из-за меньшего количества сценариев это приходится делать.
Ещё раз повторюсь: для других предметных областей это не на столько актуально как для ЗУП.
Как найду время написать статью, потом ещё подискутируем предметно)
(114)
зы. По своей работе тоже иногда сталкиваюсь что в некоторых моментах начинают усложнять потому что "просто" это неправильно
Так вот, возвращаясь к искусству. Оно предназначено для потребителя (заказчика), а не для коллег-художников, которые не преминут в разговоре обязательно упомянуть, какая все-таки это мазня.
Те, кто работает по шаблонам, и есть ремесленники. А кто-то хочет творить. Можно, конечно, и такого натворить... Но это как повезет. :-)
Я сейчас работаю с "творческим" кодом. Знаете что вольный-художник натворил? из самого простого - он не знал, что есть Форма.Записать() и есть метод модуля объекта"ОбработкаЗаполнения", а в итоге "творческий порыв" закончился тем что у меня внутри ОДНОЙ формы документа есть 4(!) места с вызовом сервера, где создается один и тот же объект, но творческий порыв не терпит инкапсуляций и копипаста видимо была сильно густая. Как итог я имею 4 события об одном и том же, но написанное 2 разными способами с щепоктками ctrl-c без какого либо форматирования кода.
Именно в этом и кроется ремесло - уметь использовать стандарты и техники в реализации новых идей.
В начале нулевых работал с FoxPro, у меня был набор пргшных файлов со служебными процедурами, тоже печать, скролбары и т.д., по большей части интерфейсного порядка. В принципе, та же БСП. Практически окно готовой программы, наполняешь нужным функционалом, компилируешь в апп и все, получаешь программу.
Так же работал в компании где главный архитектор "Сережа" который проектирует по принципу все должно быть как в ТЗ. Количество вставок в типовой УТ зашкаливает. А количество реквизитов увеличивается с каждым ТЗ.
А есть ещё и случаи когда хочется написать на отвали. Какая ни будь очень важная вечная внешняя форма счет-фактуры.
Помнится Иван говорил что надо всегда быстрее в продакшн отправлять. Что бы эффект был быстрее. Без такого кода никак вообщем.
С уважением агент "Сережа" )
или мерило - стандарты 1с, если да то понятно.
А также что можно считать г.кодом
А="Г.Код";
Ответ = СРЕД(А,3,3);
Ответ2 = ПРАВ(А,3);
А пачему ты вместо СРЕД не использовал ПРАВ, это же ПРАВильнее
Иди на sponsr.ru и зарабатывай там бабки!!!!
Еще в студенчестве сестра одногруппника в германии начала программировать на JAVA и обязательными условиями были:
1) код ревью
2) наставник
3) и процент кода который уходил в конечный продукт (по моему 15%)
Подобные регламенты позволяют постепенно вливаться программистам уровня "Junior"
- у нас же обычно начальник с выпученными глазами сокрушается почему все плохо и нет дешевых высококвалифицированных спецов
В результате бедный Сережа выжил в агрессивных условиях, я его все равно пытаются за это прищучить... система
По поводу "лишних денег", то западные компании еще в конце 90-х тратили на ИТ не менее 10% прибыли, и с каждым годом суммы увеличивались. Потом произошло несколько кризисов, в которых выжили в основном те, кто тратил на ИТ куда больше - сравните гугл и яхуу, который окуклился в "портал". То же самое произошло с рамблером, а теперь они пытаются у автора NGinX отжать то, что он якобы в рабочее время напилил и свободно распространил, а когда он это все создавал, то рамблер это мало волновало. И сравните рамблер с яндексом, который и "ненужные" штуки от своих сотрудников активно пытается включить в свою экосистему, ища применение.
В общем те самые "ненужные" (сегодня) фичи - это задел для роста. Если не вкладывать в этот задел, то у корпорации не будет драйверов роста на постоянно меняющемся рынке, а рынок будет постоянно меняться. Уже сейчас запустилась перестройка очень многих сервисов как у нас, так и на западе. А те, кто считает, что и так сойдет, - они кончат, как рамблер и яхуу в самой радужной картине их будущего.
Заказчик 1 не самый последний банк в "загнивающей америке", IBM360/370, терминалы типа vt100, командная строка, учётная система на fortran и куча библиотек на чём угодно, не удивлюсь если там и на 1С есть :)
Заказчик 2 крупный химико-фарма, univac, терминалы от Adagio до графических станций HP QUADRO, куча софта от ассемблера до руби, основная база хим элементов codasyl fog. Каждый год идёт разговор о переезде на oracle, и понятно каждый год стоимость этого перехода растёт :)
Ну не было у меня проектов для ИТ компаний.
Вторая работа - бизнес-тревел. У них там много было интересных внутренних проектов, а фронт-офис вообще был на java. Так что контора в ИТ просто громадные деньги вкладывала. Серваки одни стоили просто нереально.
Третья работа - бутик. Они постоянно хакатоны проводили. Я их даже вел.
Четвертая - структура при банке. Тоже много всего, но это как стимпанк - после управляемых форм на обычные, но там как раз движуха с обычных форм на управляемые - старые-новые переживания )))
— Пойми, студент, сейчас к людям надо помягше... А на вопросы смотреть ширше.
Да, все правильно, надо писать как должно, не зря же существуют стандарты разработки.
И все же. Помню, в БП 2.0, когда обновлял, в форме поступления была ошибка масштабирования элементов формы, форма раскрывается, а элементы прежнего размера, в реализации все было нормально. Ощущение, что писали да разных человека. Подумал, забили, наверное, все внимание на 3.0. Так и в 3.0 сколько раз видел отступление от стандартов.
Были у нас во франче крутые ребята, сдавали по два, чуть ли не по три профессионала за день. Ездили на проекты. Потом через месяц звонит клиент, он так все красиво рассказал, чего-то делал, мы заплатили, но у нас ничего не работает.
Были и такие, съездит, сделает молчком, потом глбух звонит "А поговорить?".
А были и "простые" ребята, просто работали и приносили часы.
С людьми общаться надо, говорить на их языке, а как это реализовать их не должно касаться.
Все, конечно, понимают, что бесплатно ничего не делается. Для клиента важен результат, желательно в оговоренные сроки, как ты это будешь делать это другой вопрос.
На мой взгляд, у Серёжи талант именно в этой части, умение общаться с людьми.
Эта тема хорошо описана в книге Ли Якокки "Карьера менеджера".
Можно, конечно, воротить нос, как некоторые, мол мелкие проекты не беру, из мелкой посуды не пью и т.д. Но так недолго и вообще без заказов остаться. Да и заказчик сегодня по мелочи, завтра по мелочи, а там и что-то крупное предложит.
Поэтому надо соизмерять свою техническую позицию со значимостью проблемы для заказчика. Где-то костылем подпереть не только можно, но и нужно.
Средненькое предприятие-пекарня. 4 организации, на каждую организацию базы БП + ЗУП, плюсом база УПР, обмены везде файликами exel + txt.
Каждую базу Сережа дорабатывал говнокодом не парившись и первым делом снимая всю конфигурацию с замка. Но по разному, одну одним говнокодом, вторую другим, третью смесью 1-го и 2-го
Все работало долго и счастливо, глобальных задач Сережа не брал, мелкие - средние делал как оригинал от автора произведения.
Всех все устраивало.
Но пришла беда, весь этот пул баз не обновлялся года 3, главбух (женщина очень умная и грамотная в бухгалтерии, но в том как оно устроено в 1С - ни в зуб ногой) поставила задачу: все обновить. И Сережа не смог, полгода он всячески пудрил всем мозги пытаясь что-то сделать. Главбух поставила условие начальству - либо базы будут обновлены (как и кто сделает - ей по барабану), либо она уходит. Главбух была сильным профи, старой закалки. Начальство решило заменить Сережу.
Я тогда в 1С проработал всего года 3 как, время было свободное - искал подработку. Через очень опытного и авторитетного в наших кругах программиста вышла эта Пекарня на меня, он рекомендации дал.
Приехал я к ним посмотреть что да как, дня 4 все это изучал, дал решение: в таком виде я обновлять это не буду, не смогу физически. Сговорились на том, что я за фиксированную сумму (нормальная такая сумма в итоге вышла) переработаю Сережино наследие в что-то вменяемое. Очень повезло, что центральные механизмы Сережа трогал редко. Месяца 3 пахал как проклятый за аналитика, программиста и тестировщика. В итоге получилось сделать 2 пула однотипных баз, одна ПБ, вторая ЗУП. Обновил, все взлетело, ничего не поломалось.
И работал я с ними еще года 4 спокойно и счастливо. Очень повезло с глав.бухом, ей хватило печального опыта с Сережей. А потом глав.бух ушла на пенсию, пришла новая. Я немного поработал с новой и понял, что Сережа ей нужен гораздо больше чем я :)
Конец
С одной стороны, он делает быстро и недорого, что позволяет ему поднимать объемы мелких задач и быть (здесь и сейчас) выгодным для клиента, незаменимым (т.к. другие программеры с этим говнокодом работать не будут, или будут значительно дороже).
С другой - нескольким таким "Сережам" сложно ужиться в команде (совместимость подходов к говнокоду - как у разъемов зарядки телефонов до появления mini-USB), "Сережа" становится незаменимым и его не уволят, но и не повысят (кто-то тогда должен будет писать за него код, а это - дорого).
Ну и для клиента - в какой-то момент всё-же, при расставании с "Сережей" - придется вложиться в полный рефакторинг кода (погасить накопившийся технический долг). Если представить клиента, который понимает о чем речь, но при этом хорошо понимает финансовые траты и риски - то в ряде случаев он предпочтет "Сережу", т.к. стартовать быстро и недорого сейчас и платить много за переделку потом, бывает лучше.
Так что, быть "Сережей" - не выгоднее чаще всего именно для "Сережи".
А как "быстро-точно" делается без нормального ТЗ?
Про "быстро" рассказали - можно перейти (а для кого-то вернуться) на темную сторону и говноводить.
Из истории ясно, что "Сережа" лучше клиента знает как последний хочет. Тут "Сережа" познал джедайскую методику, либо решение задачи происходит в несколько итераций тестирования ключевым пользователем и оплатой (не жалко) Сереже часов за доработку.
Автор, нужна вторая часть про "точно".
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1678484
Создание 17.06.22 09:15
Обновление 17.06.22 09:15
Просмотры 13044
Загрузки 0
Рейтинг
71
Комментарии 119
Код открыт Да
Рубрики О жизни
Кому Для всех
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)