Наверное, уже нет человека, который бы не слышал о программе 1С. И тем более нет ни одного директора, который бы не понимал всех прелестей J автоматизации учета и отчетности.

Наверное, уже нет человека, который бы не слышал о программе 1С. И тем более нет ни одного директора, который бы не понимал всех прелестей J автоматизации учета и отчетности.

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

 Итак, технологическая платформа «1С:Предприятие» представляет собой программную оболочку над базой данных (СУБД). Проще говоря, 1С формирует запросы к СУБД (к примеру Microsoft SQL Server) и либо что-то там пишет, либо читает. Собственно говоря, практически любой сайт делает то же самое, только с той разницей, что функцию 1С выполняет, к примеру, PHP движок.

 Технологическая платформа, в свою очередь, использует конфигурацию, в которой описаны все данные, которые необходимо хранить, их характеристики, а также набор процедур и функций (это то, что происходит после нажатия «кнопочки»J). Конфигурации бывают разные, например, «Управление производственным предприятием», их можно изменять, а можно создавать новые.

 А теперь мы подошли к основной части вопроса, о котором слышали или сами сталкивались практически все: Почему база тормозит? Нет, не так – ПОЧЕМУ ОНА БЕЗУМНО ТУПИТ???

 1-я причина - слабое железо сервера, на котором крутится 1С. Если у Вас 2-5 пользователей, то идеальным вариантом может оказаться не очень мощный компьютер с 8 гигами памяти, двумя венчестерами (на одном стоит windows server, на втором sql), установленным серверным ПО, сервером терминалов или без (если Вы хотите использовать клиент-серверный вариант), установленным SQL (тот же Microsoft SQL Server или аналогичный вариант от IBM, PostgreSQL, и даже Oracle). Но если у Вас 30 одновременно работающих пользователей, в день создается около тысячи первичных документов, Вам может потребоваться уже несколько серверов терминалов (обычно один пользователь использует около полугигабайта памяти), а SQL необходимо выносить на отдельный сервер (а еще лучше иметь зеркальный сервер с SQL), про рейды и модель восстановления тоже не забываем.

 2-я причина - излишек хранимой, но не используемой информации, а также ошибки кодирования. Дело в том, что любая из типовых конфигураций пытается описать практически все возможные бизнес-процессы, которые, возможно, у Вас и не используются. А дополнительное описание – это дополнительные объекты метаданных (справочники, документы, регистры и т.д.), соответственно дополнительные таблицы в SQL, что само по себе не добавит скорости в работе  базы. Кроме того в самих объектах метаданных масса неиспользуемых Вами реквизитов, которые сохраняются, но в них ничего не заносится. Также, обычно изменения в любом из документов подразумевает движение по регистрам, а регистров этих много, и зачастую половина из них, а то и больше, никогда не будет использоваться в Вашем бизнесе, но информация туда пишется и база пухнет как на дрожжах, кроме того такая запись занимает определенное время (представьте, прописать информацию в 2-3 регистра или в 10?). Кстати, я как-то общался с одним программистом и тот рассказывал что в его базе, фактически, процентов 30% базы занимал всего лишь один регистр сведений, к которому никто никогда не обращался и зачем хранили в нем информацию в весьма специфическом разрезе – не понятноJ. Ну а ошибки кодирования – это даже не ошибки, а выбор неправильных алгоритмов выполнение которых создает дополнительную нагрузку. Например, ну не знает программист, что такое левое соединение, а массивы (таблицы) большие – вот он и пытается подставить костылиJ.

 3-я причина очень оригинальна, но не потому что редко встречается, а потому что на нее не обращают внимание. Это ошибки проектирования базы на уровне SQL. Как правило это и непонимание принципов работы SQL в целом и непонимание отдельных тонких мест в SQL. Например, индексирование. Стоит индексировать те записи (реквизиты), которые часто читаются, а не пишутся, т.к. излишний индекс занимает место (и не мало!), кроме того запись информации в индексируемый реквизит вызывает перестройку индекса, а это уже дополнительное время.

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