Бонус #3. Ошибки, за которые увольняют
Некоторые ошибки лучше не допускать, поскольку они могут привести к финансовым потерям Вашего заказчика.
Приведем наиболее распространенные ошибки, которые представлены в 40 видео-уроках.
Ошибка 1.
Часто возникает необходимость перехода с файлового варианта работы ИБ на клиент-серверный. Причин может быть несколько:
• Достаточно большой объем БД (в файловом варианте существует ограничение в 4 Гб на размер таблицы ИБ);
• Неудовлетворительная производительность информационной системы при многопользовательской работе;
• Требования к безопасности информации.
Как осуществить переход? Как два пальца об асфальт! Помните, вас учили на курсах (читали в книжках):
• Из файловой базы нужно сделать выгрузку в файл dt;
• В клиент-серверной базе загрузить данные из dt.
Но есть ряд подводных камней, о которых умалчивает документация. О них мы и поговорим сегодня…
Ошибка 2.
Представьте ситуацию. Вы находитесь у клиента, выполняете очень срочную и важную работу: потребовалось разработать небольшой отчет. И вот он уже готов. Вы с чувством гордости демонстрируете работу начальнику отдела продаж, он удовлетворен. Вам без проблем подписывают акты (платят наличкой).
Через 2 часа вы, прорвавшись через пробку, подъезжаете к другому клиенту. И тут на ваш мобильный поступает звонок: оказывается, отчет прекрасно работал под руководителем отдела продаж, но не работает под обычным линейным менеджером! Бывает ситуация и еще хуже: под разными пользователями отчет выдает разные данные! Знакомая ситуация!? Хорошо, если нет…
Хотя на самом деле вы сделали отчет правильно. Там и ошибиться было негде: запрос обращается за данными к двум таблицам БД. Но кто же тогда виноват? В чем проблема? Об этих вечных вопросах мы поговорим в сегодняшнем выпуске.
Ошибка 3.
Вы работаете с типовыми конфигурациями. Периодически выходят обновления от любимой нами фирмы «1С». Болела ли у вас голова после бессонной ночи, когда была попытка накатить новый «навороченный» релиз? Бывало!
Самое неприятное, что тот функционал который стабильно работал некоторое количество релизов может вдруг измениться, либо его просто «вырежут», либо пересортируют функции по различным общим модулям. Разумеется, никто об этом предупреждать не будет! Иначе наша работа была бы неинтересной :)
Сегодня мы поговорим о грустном: стабильности функционала типовых решений.
Ошибка 4.
Вы идеально знаете «7-ку». После некоторого напора со стороны своих клиентов, пришлось начать изучать новую версию платформы. Что ж там сложного? Открываем документацию – и вперед. Только вот поначалу время на решение задач уходило сильно больше, чем на «7-ке».
Но сегодня речь пойдет немного о другом. Как и в «7-ке» для получения небольших выборок данных вы по привычке используете метод Выбрать( ). И вроде бы ваш программный код работает. Но, может случиться, что этот код перестанет работать просто так… Почему? На этот вопрос мы ответим сегодня.
Ошибка 5.
Платформа 8.2 вышла более года назад. Пора бы уже переходить. Однако в некоторых моментах поведение системы изменилось по сравнению с предшествующими версиями. Поэтому нужно учитывать особенности и возможности новой платформы при разработке.
Сегодня мы поговорим об одном интересном «эффекте» платформы 8.2. Речь будет идти о контроле остатков. При проведении остатки могут контролироваться то правильно, то неправильно. Причем сами алгоритмы разработаны абсолютно корректно. И это даже не ошибка платформы, а именно новое ее свойство, которое нужно обязательно учитывать при разработке…
Ошибка 6.
Серия магических эффектов 8.2 продолжается.
Представим, что есть некоторый документ с одной строкой. Проводим его из формы списка несколько раз, проводится корректно: в регистрах появляется одна строка. Проводим тот же документ из формы объекта. При каждом перепроведении движения дублируются. И при этом алгоритмы написаны абсолютно правильно. Не бывает? Бывает! Разумеется, если у вас платформа 8.2.
Об этом интересном эффекте мы поговорим сегодня.
Ошибка 7.
Если при разработке документов на платформе «1С:Предприятие 8» не учесть один нюанс, то можно получить списание остатка «в минус» при параллельной работе пользователей.
Разве платформа не должна сама следить за этим (как, например, в 7.7)? И да, и нет. В «8-ке» существует режим, где разработчик должен сам учитывать возможность параллельной работы пользователей. И если он забудет это сделать, то последствия могут быть разной степени тяжести. Например, вначале отрицательного остатка никто не заметит, потом будут идти долгие разборки, почему же они появились и кто виноват. И с каждым новым случаем доверие к системе и ее разработчикам будет сильно снижаться.
Как этого не допустить? Об этом мы поговорим сегодня.
Ошибка 8.
Еще один сюрприз готовит платформа 8.2. И опять же это не ошибка, а новое свойство новой платформы. Часто количество регистров, по которым делаются движения документа, зависит от некоторых свойств самого документа (например, флаги отражения документа в разных видах учета: УУ, БУ, НУ).
При неаккуратной разработке может возникнуть ситуация, что документ хранит движения своего прошлого состояния. Например, изначально документ был проведен по БУ, далее в нем поставили флаг УУ, а БУ сняли. При этом проводки по БУ все же остались. Ошибка? Конечно! Возможна ли она? Да, если вы перешли на 8.2.
Сегодня поговорим о том, как не допустить описанной ситуации.
Ошибка 9.
Если разработчик написал правильный программный код, где нет ошибок, будет ли он выполняться всегда? Бывают ситуации, когда некоторое время программный код работает на «ура», а потом начинает иногда «сбоить». Разумеется, пользователи будут твердить свое любимое: «Ваша программа не работает, верните наши деньги!».
На самом деле это нормальная ситуация, просто нужно уметь ее предвидеть. О чем мы и поговорим сегодня.
Ошибка 10.
Очень часто разработчики подходят к решению любой задачи «в лоб». Пользователь сказал, что нужно сделать документ с 30-ью табличными частями, где будет по 1000 строк в каждой, а разработчик садиться и делает. В итоге получаем эффект бутылочного горлышка: неработающую систему, и конечно же, от пользователей – «ваша программа не работает». Это неправильный подход. Нужно оценивать, какие последствия может повлечь то или иное проектное решение. Пользователь не знает всех технических нюансов системы, он и не должен их знать. А разработчику нужно взвешивать все возможные последствия той или иной реализации.
Сегодня мы поговорим о вполне конкретных вещах. При любой модификации данных нужно учитывать, что с этими же данными могут работать другие пользователи. Если на это не обратить внимание, то в лучшем случае мы получим ошибку во время исполнения программного кода, в худшем – несогласованные изменения.
Ошибка 11.
Часто требования к информационной системе меняются в процессе внедрения. Аппетит растет во время еды. Соответственно требуется менять структуру регистров. Но такие эксперименты на «живой» базе (где есть пользовательские данные) проводить опасно.
О том, как правильно и не правильно менять структуру регистров, о возможных последствиях мы поговорим сегодня.
Ошибка 12.
Сегодня мы рассмотрим, пожалуй, самую частую ошибку, совершаемую начинающими разработчиками. Особенно любят допускать такую ошибку разработчики на платформе 7.7.
Итак, нужно разработать простой отчет, который получает долги клиентов на выбранную дату. Где здесь можно ошибиться? На самом деле, есть целых два капкана, в которые часто попадаются разработчики.
Ошибка 13.
Сегодня мы рассмотрим нюанс, который относится напрямую не к платформе, а скорее к программированию вообще. Однако последствия невнимательной работы с коллекциями значений может быть печальны. Например, это неправильная обработка чеков на оплату, и как следствие неверное закрытие кассовой смены.
О том как, не нужно обрабатывать элементы коллекций мы расскажем в видео-уроках.
Ошибка 13+1.
Мы рассмотрели наиболее часто встречающиеся ошибки у разработчиков «1С:Предприятие 8».
Разумеется, это далеко не полный список возможных коллизий. Бывают ошибки, которые достаточно сложно поймать. Бывают ошибки, поведение которых проявляется не всегда, а только пики нагрузок на ИС. Об одной из таких ошибок мы поговорим сегодня.