Владимир Харин - Просто Pro 1С

2023-04-06 15:29:37 Хороший код: о чем не знают пользователи и чего стоит лень программиста (часть 1)

Всегда пишите код так, будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете. (с) Джон Вудс, геймдев-программист

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

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

Залез я внутрь программных модулей — и ахнул. Вы когда-нибудь видели адовый код? Этот был раз в десять хуже. Смотрел и думал — как можно написать такое? В общем, прошел через все мытарства, пока пытался понять, как все устроено. Параллельно матерился про себя, в красках представляя, как отрываю руки безграмотному джуну (на всякий случай поясню: джун (junior) — начинающий разработчик), что писал этот код.

Но, знаете, странное чувство не покидало меня. Казалось: где-то я эту разработку уже видел... И тут я натыкаюсь на авторский комментарий в коде: «// Харин В.» Занавес.

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

Это вам так, для разогрева. Скоро расскажу, какие конкретно проблемы создает «некрасивый» код, и что делать, чтобы их избежать. Небольшой спойлер — стоимость поддержки ваших информационных систем напрямую зависит от качества кода.

Ставьте , если вы перфекционист, и считаете, что красота спасет мир программиста! Или , если вы прагматик, и убеждены, что людям нужен результат (а программисты пусть сами о себе заботятся). Открыть/Комментировать

2023-04-03 14:13:02 Какой должна быть зарплата, чтобы цифры не влезали в расчетный лист?

Этот вопрос мы обсудим в комментариях. Но пост немножко о другом: иногда большая зарплата руководства становится проблемой для программиста. Вот вам мой кейс на эту тему.

В 2007 году внедрял 1С в крупном холдинге. Это был мой первый большой проект, все было в новинку. А особенно конфигурация «Зарплата и управление персоналом» (ЗУП), с которой я не работал, но должен был ее аккуратно дорабатывать и исправлять.

Однажды поступил запрос: «Владимир, у нас есть очень срочная задача (а разве другие бывают? ). Нужно доработать отчет «Расчетный листок». Мы сегодня должны всем разослать расчетки, а у генерального директора в графу «К выплате» не помещается сумма».

Я, конечно, много немного прифигел (это ж какую зарплату надо иметь, чтобы она в расчетный листок не влезла!), но собрался с силами, сделал покер фейс и ответил: «Не вопрос, исправим!»

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

Несколько часов мы крутили разные варианты:

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

Тогда я осознал, что программист – это немного дизайнер. А еще понял, как тяжело бывает дизайнерам со сложными заказчиками.

Что в итоге? Мы сделали то, что я и планировал изначально: увеличили ширину проблемной колонки, уменьшив при этом ширину другой, где нет сумм. Бинго! Все довольны. И гендир, думаю, тоже был доволен. Нет, не моими доработками, а размером своей зарплаты.

Ну а теперь давайте попробуем угадать порядок «проблемной» (пишу и сам смеюсь) суммы. Пишите предположения в комментариях. А еще вопрос со звездочкой — для настоящих знатоков. Какая версия ЗУП внедрялась?

У всех, кто поставит , зарплата вырастет в этот году. Гарантирую! В крайнем случае, нет. Открыть/Комментировать

2023-03-31 08:21:01 Успешных вам проектов, друзья!

И... не обижайте разработчиков Открыть/Комментировать

2023-03-30 13:18:11 Это не баг, это — фича! Или все-таки баг?

Неработающая программа обычно приносит меньше вреда, чем та, что работает плохо. (с) Дейв Томас, автор книг о программировании и тестировании ПО

В предыдущем посте затронул тему ошибок в пользовательском интерфейсе. А сегодня разберемся, какие еще факапы возникают при разработке программ, и что с ними делать. В частности, речь пойдет об 1С. Пост без сложных терминов — для тех, кто не очень в теме.

Забавное наблюдение в стиле «спасибо, Кэп»: если программа работает корректно, никто не акцентирует на этом внимание. А зачем? Она ведь так и должна работать. Другое дело, если возникают ошибки! Это сразу всех расстраивает выводит из себя.

Ошибки можно разделить на явные и неявные.

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

С неявными все сложнее. Программа, на первый взгляд, работает четко, но делает не то, что нужно. Еще хуже, если она иногда делает не то, что нужно, а чаще работает нормально. То есть, обычно 2+2 = 4, а потом раз — и внезапно 5! Это так называемые «плавающие» ошибки. Очень неприятные, поверьте. Стоит только ослабить контроль...

Древняя мудрость гласит: не бывает программ без ошибок, бывает мало тестирования. Что надо делать?
Тестировать программисту при разработке.
Тестировать при приемке (это должен сделать постановщик задач).
Тестировать тестировщику (хотя во вселенной 1С тестировщики — это экзотика).
Выполнять автоматическое тестирование. Это целая отрасль знаний, но во вселенной 1С применяется редко (знаю, тут есть несколько мнений: если не согласны с моим, приглашаю в комментарии).
Бонусом — совет пользователям, которые начинают работать с новым функционалом: относитесь к нему с подозрением.

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

Как такое получается?
– Постановщик задачи берет на себя роль архитектора, хотя не обладает компетенциями. Об этом писал здесь.
– Участники проекта не коммуницируют. Постановщик описал задачу, а разработчик что-то неправильно понял. Или постановщик о чем-то не сказал, а разработчик, вместо того чтобы уточнить, додумал сам (и сделал неправильно).

Что делать?
– Больше общаться в команде. Есть новое ТЗ? Пусть тот, кто его написал, и тот, кто будет по нему работать, обсудят все детали.
– Устраивать демонстрации промежуточных результатов. Так можно заметить, что программист делает что-то не то, прежде чем станет слишком поздно.

А у вас есть уникальные методы создания софта без багов? Поделитесь в комментариях! И не забывайте о реакциях: так я пойму, что контент интересен. Открыть/Комментировать

2023-03-27 09:19:36 Даже программисты этого не замечают: частая ошибка в интерфейсе

Все хорошие интерфейсы похожи друг на друга, а каждый плохой плох по-своему. Узнали, чьи слова я перефразировал? Лев Николаевич бы удивился .

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

Платформа 1С сильно упрощает жизнь в разработке пользовательского интерфейса. Кто программировал на олдскульных языках и платформах, понимает, о чем речь. И многие 1С-ники относятся к интерфейсу своих разработок, что называется, «с ленцой» (признаюсь, и я этим грешу ). Раскидали поля/таблицы по форме — и ладно, сойдет. Но сегодня, набив шишек, скажу: не сойдет — посмотрите на форму внимательно.

Как-то разрабатывал документ, в котором была табличная часть с полями:
— Плановая сумма доставки
— Плановая сумма упаковки
(… и еще несколько плановых показателей)
— Фактическая сумма доставки
— Фактическая сумма упаковки
(… и еще столько же фактических показателей)

При запуске 1С и открытии формы документа платформа вставила наименования (синонимы) полей в заголовки колонок таблицы. И выглядело это вот так:

| План… | План… | План… | Факт… | Факт… | Факт… |

Названия полей длинные, и текст срезался. Ну и что такого, думалось мне. Если интересно, что там за «план» в колонке, наведи на заголовок указатель мыши — появится подсказка с полным текстом. Если не появится — наведи еще раз. Подвигайся немного, офисный работник, тебе полезно. Тренируй память и внимательность, а иначе тебя скоро заменит нейросеть! Если что, я просто шучу: ничего такого я не подумал, а на недостаток в интерфейсе просто не обратил внимания.

Но шутки в стороны: что в итоге? Люди путали колонки таблицы, вбивали в поля не те данные. Заказчик негодовал, а виноват оказался — какая несправедливость! — я…

Заголовки переработали: сделали сначала такими:

| Доставка (план) | Упаковка (план)| …

Уже лучше, но и это оказалось так себе: иногда в заголовках срезалось слово «план». На узких мониторах все выглядело так:

| Доставка (… | Упаковка (… | … | Доставка (… | Упаковка (… |

Пришлось подумать еще. В итоге пришли к такому варианту:

| План | Факт
| Доставка | Упаковка | … | Доставка | Упаковка | …

Ошибок больше не было. Зато заказчик понял, что у него невнимательные работники. А я понял, что интерфейс — штука тонкая: некоторые элементы нужно продумывать, прорабатывать и отлаживать. Иногда это занимает больше времени, чем возня с кодом.

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

А у вас были курьезы с пользовательским интерфейсом? Приглашаю в комментарии, обсудим, посмеемся.

Судя по прошлому посту, вам понравилось играть. Поэтому предлагаю вопрос на эрудицию. Поняли, из какого романа Толстого первая фраза, которую я переиначил? Открыть/Комментировать

2023-03-24 19:11:35 Почему увольняются сотрудники: кейс и игра на интуицию

Полезные кейсы в 1С не всегда сложные. Иногда очень даже простые: к гадалке программисту не ходи. Решил поделиться с вами одним из них.

Несколько лет назад я внедрял конфигурацию «Зарплата и управление персоналом» (ЗУП) в холдинге, где основная часть сотрудников – менеджеры по продажам. В компании была большая текучка: проблема для кадровиков и hr-ов, согласны? Те, кто занимался персоналом, хотели выяснить причины. И, как следствие, понять, что с этим делать. Мнение у них уже было, но одно дело — предполагать, а другое – располагать точными данными. Если любите цифры и статистику — . А я продолжу.

На мой взгляд, ЗУП – самая бесполезная для бизнеса конфигурация 1С. Только не говорите, что не согласны . Ладно, говорите — жду в комментариях. Но в ней, как и в любой конфе, есть механизм дополнительных реквизитов и сведений. Можно самостоятельно добавить что-то полезное. Вот мы и добавили в документ «Увольнение» два поля:

«Причина увольнения», с выбором из классификатора.
«Причина увольнения (подробно)», где можно вписать свой текст.

Классификатор причин сделали таким:

Семейные обстоятельства
Размер зарплаты
Офис далеко от дома, много времени уходит на дорогу
Отсутствие карьерного роста
Отсутствие перспектив, профессионального развития и повышения квалификации
Неудовлетворенность условиями труда (график, интенсивность, состояние рабочего места)
Плохая атмосфера в коллективе
Не сработался(лась) с руководителем
Неверно выбрал(а) специальность, профессию, понял, что не мое
Иное (указать подробнее)

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

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

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

Примерьте ситуацию на себя: кадровик оформляет документы до окончательного расчета, поэтому сотрудник, на всякий случай, может быть неискренним. В беседе с руководителем тоже не все гладко: вариант причины №8, скорее всего, выпадет.

Что решили?

Придумали, что все-таки будем программировать, и немного расширили техническую часть. Через несколько дней после увольнения сотрудник получает письмо с благодарностью за работу в компании и вклад в ее развитие. И там же — просьба заполнить небольшой опросник. Ответ уходил в кадровую службу, спецы вносили данные в 1С. Profit!

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

А теперь поиграем. Как думаете, какая главная причина увольнения в этой компании? Испытайте свою интуицию в комментариях, а я поделюсь правильным вариантом. Открыть/Комментировать

2023-03-21 16:16:28 Желания VS Потребности: клиент (не) всегда прав

Знаете, какие заказчики мне нравились, когда я был «молодым и зеленым» 1С-ником? Те, которые максимально точно ставят задачу. Чуть ли не до запятой! Что и куда добавить, на чем сделать акцент... Ну не замечательно ли? Думать не надо: работай на автомате, да и все. Получил задачу – садись и делай. Оформил красиво – молодец. Идиллия, подумаете вы. Катастрофа, воскликну я!

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

Какое-то время спустя появились проблемы:
– мало кто из пользователей 1С обращал внимание на наши доработки. Во-первых, функционал неудобный. Во-вторых, людям никто толком не объяснил, зачем нужны бесконечные новации.
– директор стал путаться в своей же 1С. Частенько спрашивал у меня: «А ты не помнишь, зачем мы с тобой это сделали?» (как думаете, я помнил? )
– код конфигурации все больше напоминал минное поле. Починил в одном месте, сломал в трех других.

Что мы решили? Сейчас бы рассказать душещипательную историю, как я боролся за адекватность, а директор настаивал на своем. Но нет! Мы не только провели полную ревизию доработок, но и узнали, какие вообще потребности учета в компании. В течение нескольких недель проводили совещания, смотрели 1С, думали, обсуждали...

Каков результат?
– 70% доработок просто выкинули: решить задачи можно было с помощью типового функционала конфигурации.
– 25% функционала полностью переделали – так, чтобы пользоваться им было удобно.
– написали инструкции пользователям, чтобы у них было четкое понимание: что делать, какая польза.
– договорились (да, и так бывает), что директор больше не будет говорить спецам, что конкретно хочет увидеть в 1С.

К чему я это рассказал? Чтобы каждый понял, что начинать работу лучше с вопроса: «Какую проблему мы решаем?» К тому же этот кейс полезен руководителям: оставьте проектирование решения тому, кто в теме. Поверьте, это сильно сэкономит время, нервы и... деньги.

Сегодня разговаривал с потенциальным заказчиком. Он мне говорит: «Владимир, я и сам знаю, что нужно сделать. Прислала же вам таблицу, где все подробно расписано». Я чуть было не купился! Но вместо дежурного «ок», ответил четко: «У вас отличная таблица, но давайте сначала обсудим, какие конкретно проблемы возникают в учете?»

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

По теме этого поста есть хорошая фраза Стива Джобса: «Не имеет смысла нанимать толковых людей, а затем рассказать им, что делать; мы нанимаем умных людей, чтобы они могли рассказать нам, что делать».

А у вас были заказчики-«эксперты»? Может, кто-то узнал себя? Не стесняйтесь, признавать свои ошибки не стыдно! Открыть/Комментировать

2023-03-19 22:45:47 До сих пор думаете, что 1С создана для бухучета? Этот стереотип я разрушу прямо сейчас

Пост для тех, кто еще не очень в теме. Чем платформа 1С хороша и почему так популярна? Выделил для себя топ причин — делюсь с вами.

На 1С много решений под самые разные нужды. До сих пор встречаются люди, которые убеждены: 1С — это что-то для бухучета. Возможно, давно, когда компьютеры были большими, а программы маленькими, так оно и было. Но сегодня на 1С автоматизируют что только можно. А иногда и то, что нельзя . Кроме «типовых конфигураций» от самой 1С (а их больше десятка), есть огромное количество решений от сторонних разработчиков. Любая организация сможет подобрать себе что-то подходящее. Как для точечной автоматизации отделов и подразделений, так и сквозной — то есть для всего предприятия. Что нужно именно вам? Расскажу в блоге позже.

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

У 1С широкая сеть партнеров. Есть множество организаций, которые готовы вам продавать, внедрять, дорабатывать и поддерживать решения на этой платформе. Это так называемые 1С-Франчайзи или просто франчи. По информации фирмы 1С, их сейчас порядка 8 тысяч. В крупном городе вы легко найдете несколько десятков. В этом поможет сайт 1С. Причем по каждому франчу можно посмотреть следующее: какие у него компетенции, сколько аттестованных специалистов, отзывы о внедрениях и т.д. Заходи, смотри, выбирай. Или может объявить тендер и франчи придут к вам сами.

На рынке много специалистов по 1С. Можно набрать в компанию целый отдел, чтобы непрерывно причинять страшную боль пользу своему бизнесу. Не могу сказать, что хороших очень много и найти их легко. Но ведь такая проблема есть в любой отрасли. Как выделить самых крутых? Будут в блоге мысли и на этот счет.

Кстати, есть и 1С-ники фрилансеры. Их тоже много, работать с ними дешевле, чем с франчами, их не нужно брать в штат. Но в работе с фрилансерами есть свои нюансы. Вы ведь любите приключения?

1С — один из самых известных брендов в России. Говорит ли это о том, что система очень хорошая? Скорее, нет. Но как минимум она популярна. Не думаю, что плохую платформу юзали бы так часто. Конкуренты, конечно, есть. Но на фоне 1С они либо смотрятся блекло, либо с Россией (уже/пока) не работают.

Если коротко, во вселенной 1С есть:
— из чего выбрать решение для автоматизации.
— спецы, в том числе очень компетентные.
— возможность слепить решение под себя.

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

2023-03-15 20:20:04 Привет! Я Владимир, бывалый 1С-ник, занимаюсь внедрением и доработкой 1С с 2003 года.

Что подтверждает мой опыт?
— работал со многими 1С-Франчайзи
— участвовал в проектах автоматизации как небольших торговых компаний, так и крупных производственных холдингов.
— согласовывал требования, писал ТЗ, копался в коде сам и заставлял копаться в нем коллег.
— обучал пользователей, оказывал им техническую и моральную поддержку (и та и другая очень нужны в процессе внедрения 1С ).

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

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

Уверен, мои заметки помогут обойти многие грабли стороной и сделают ваш путь с 1С эффективным и комфортным.

Буду благодарен за комментарии и обратную связь! Открыть/Комментировать