Каталог решений - Хороший, плохой, злой 1С-ник

Исходная задача

Чтобы не водить вилами по воде — начнем сразу с конкретной задачи, которая имела место быть в моем личном опыте.

Итак заказчик ставит задачу: Добавить галочку "Согласовано" в документ поступление товаров.

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

Акт 1

Программист №1: Добавляет реквизит в документ и выносит эту галочку на форму. Тратит на это 30 мин.

Программист №2: Создает документ "Согласование" + табличную часть "Товары", делает регистр накоплений "Согласование" и описывает логику заполнения табличной части. Тратит на это 10 часов.

Заказчик: Думает, что №1 — очень хороший и очень быстрый и готов ему уже сейчас платить в 2-3 раза больше, чем №2. А этот долгий №2 еще и денег просит больше.

Акт №2 

Бухгалтерия закрывает период редактирования.

Программист №1: Находит тот код, который запрещает изменять документы в закрытом периоде, и переделает его так, чтобы можно было согласовать. Тут придется ему повозиться. Задача-то нетривиальная. И потратит 4 часа.

Программист №2: Ничего не делает

Заказчик: Думает, что №1 работает и хочет ему помочь, а №2 не желает помогать.

Акт №3

Проблема: Двое согласующих не хотят признавать, что это они согласовали, и валят друг на друга.

Программист №1: Добавляет реквизит "Согласовал" с типом "Справочник.Пользователи", который заполняется в его хитром алгоритме обхода закрытого периода. Тратит еще 1 час.

Программист №2: Еще а первом акте добавил реквизит "Ответственный" в свой документ и опять ничего не делает.

Заказчик: Думает, что №1 делает как удобно заказчику. Все просто и понятно и даже в списке документов можно видеть, согласовано или нет. А №2 сделал какого-то монстра и озадачивает понапрасну людей создавать еще документов.

Акт №4

Заказчик говорит: Хочу, чтобы люди, которые согласовывают, видели новые документы, которые им надо согласовать.

Программист №1: Делает обработку, форма которой раз в n секунд делает запрос по документам, у которых нет галки. Ну или ко всем документам, а потом в цикле сравнивает ТекущийПользователь и Согласовал. И обработка эта открывается ПриНачалеРаботыСистемы. Тратит на это 3 часа.

Программист №2: Делает отчет, который показывает остатки регистра накоплений из первого акта. Тратит на это 30 мин.

Заказчик: Думает, что №2 совсем не понимает, что нужно делать. А №1 молодец. Все просто и понятно.

Акт №5. Заключительный 

Проблема: Часть товаров может быть согласована, а часть нет.

Программист №1: Переносит реквизиты "Согласовано" и "Согласовал" в табличную часть, в списке документов обрабатывает событие "ПриВыводеСтроки", чтобы определить согласован документ целиком или нет, переделывает алгоритм обхода даты запрета, переделывает обработку, которая открывается "ПриНачалеРаботыСистемы". Тратит на это 6 часов.

Программист №2: Ничего не делает, потому что все готово было в первом акте.

Заказчик: Начинает понимать, что №2 все предусмотрел заранее. Но реальную работу он видит у №1. Поэтому со счетом 4:1 побеждает №1

Итого

Программист №1 тратит 14,5 часов.

Программист №2 тратит 10,5 часов

Заказчик получает, казалось бы, одинаковый результат, но с №1 ему работать выгоднее, т.к. он делает "красивее" и ставка у него ниже. И заказчик еще не знает, что доработки №1 будут добавлять 15 мин. к каждому следующему обновлению конфигурации. Заказчик еще не знает, что эти доработки приведут к серьезным проблемам производительности в будущем и к блокировкам, с которыми не сможет разобраться программист №1 и опять напишет кучу подобного. И вот после всей этой кучи доработанного заказчик начнет получать ответы от программиста №1 по типу "Мы не можем вести учет в разрезе двух складов, а если доработаем — вся компания может встать, т.к. предусмотреть все места, где написано

Если Склад.Наименование = "Склад №1" Тогда
....

НЕВОЗМОЖНО!"

Вот и получается, что в глазах заказчика программист №1 — хороший, а программист №2 — плохой, а по факту получается совсем иначе.

Технический долг

Это еще один интересный момент, который не видят заказчики/работодатели.

Если коротко — технический долг это непродуманное решение, которое может приводить к негативным последствиям (как в примере выше — галочка "Согласовано")

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

Представим ситуацию: Работало 2 программиста с низкой квалификацией, но им досталась типовая конфигурация, которую они дорабатывали на протяжении нескольких лет.

Потом на их место пришли программисты с высокой квалификацией и з/п им нужна в 2 раза больше.

50% своего времени напрямую или косвенно новые специалисты тратят на закрытие технического долга.

И тут работодатель опять попадает в эту ситуацию: Плачу больше, делают дольше.

Может получиться еще одно интересное развитие событий: с этими двумя расстанутся и возьмут опять с меньшими зарплатными ожиданиями и более низкой квалификации. Технического долга будет естественно меньше, да и не факт, что он их будет волновать. Сказали галочку — вот вам галочка. И руководство опять радо — опять видно работу программистов. А то, что в штате через несколько лет уже 10 плохих программистов, а не 2 хороших, работодателя не особо тревожит. Ведь люди работают, ставят галочки в отчетах. Все хорошо.

Злой программист

Какой он? Хороший или плохой? На самом деле он может быть как хорошим, так и плохим.

Это именно тот, который ставит галочки в отчетах и работает только в том случае, если можно галочку поставить в отчете и получить премию за это. Что происходит в коде его не волнует.

Увидел такой код:

Если ТекущаяДата() > Дата("20200101") Тогда
.....

 Поменял на Дата("20210101") и знает, что в следующем году он будет востребован.

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

Но писать хороший код они не хотят, потому что боятся падения своей ценности.

Конечно его можно заменить на хорошего программиста, но процесс этот долгий и проще оставить как есть.

Выводы

Определить, хороший программист, плохой или злой, очень сложно людям, которые далеки от программирования. Если программист быстро делает Ваши хотелки и при этом стоит недорого — еще не означает, что он хороший.

И даже то, что он делает долго и стоит дорого — не означает, что он хороший.

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

Как максимально точно определить, кто перед Вами на собеседовании? Попробуйте составить задачу из нескольких актов (как я описал выше) и обсудите с кандидатом каждый акт отдельно, не говоря ему о том, что впереди еще задачи. Будет ли он задавать вопросы или тупо делать — вот что важно! Хотя и это не панацея.