Головна

Про нас

Наша Команда

Наша історія

Замовникам

Рекрутинг

Ціни

Шукачам

Вакансії

Запитання

Статті

Координати

Русский

English

 

 

Андрій Андренко : Як оцінити програміста 1С: погляд дилетанта.


 

Напевно, вже немає людини, яка б не чула про програму 1С. І тим більше немає жодного директора, який би не розумів усіх принад :) автоматизації обліку та звітності.

Але перед тим, як почати питання про те, як оцінити програміста 1С, давайте спочатку простою і зрозумілою мовою визначимо, що взагалі таке 1С:Підприємство і як це все працює.

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

Технологічна платформа, у свою чергу, використовує конфігурацію, в якій описані всі дані, які необхідно зберігати, їх характеристики, а також набір процедур та функцій (це те, що відбувається після натискання кнопки)). Зміни бувають різні, наприклад, «Управління виробничим підприємством», їх можна змінювати, а можна створювати нові.

А тепер ми підійшли до основної частини питання, про яке чули чи самі стикалися практично всі: Чому база гальмує? Ні, не так - ЧОМУ ВОНА БЕЗУМНО ТУПИТЬ???

1-я причина – слабке залізо сервера, на якому крутиться 1С. Якщо у Вас 2-5 користувачів, то ідеальним варіантом може виявитися не дуже потужний комп'ютер з 8 гігами пам'яті, двома вінчестерами (на одному стоїть windows server, на другому SQL), встановленим серверним ПЗ, сервером терміналів або без (якщо Ви хочете використовувати клієнт -Серверний варіант), встановленим SQL (той же Microsoft SQL Server або аналогічний варіант від IBM, PostgreSQL, і навіть Oracle). Але якщо у Вас 30 одночасно працюючих користувачів, щодня створюється близько тисячі первинних документів, Вам може знадобитися вже кілька серверів терміналів (зазвичай один користувач використовує близько півгігабайта пам'яті), а SQL необхідно виносити на окремий сервер (а ще краще мати дзеркальний сервер із SQL ), про рейди та модель відновлення теж не забуваємо.

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

3-я причина дуже оригінальна, але не тому, що рідко зустрічається, а тому що на неї не звертають уваги. Це помилки проектування бази на рівні SQL. Як правило це і нерозуміння принципів роботи SQL загалом і нерозуміння окремих тонких місць у SQL . Наприклад, індексування. Варто індексувати записи (реквізити), які часто читаються, а чи не пишуться, т.к. зайвий індекс займає місце (і не мало!), Крім того запис інформації в реквізит, що індексується викликає перебудову індексу, а це вже додатковий час.

Як оцінити програміста? Насамперед він чітко повинен спілкуватися на вищезгадані теми, висловлювати та обґрунтовувати свою думку, він повинен знати типові конфігурації (ті які у Вас використовуються), бажано мати досвід створення баз з нуля (цілком можливо, що Ви з цим зіткнетеся), добре знати мова 1С, мати досвід автоматизації, досвід вирішення нетривіальних завдань (обов'язково їх описати та розповісти як він їх вирішував з обґрунтування правильності рішень). Ну і по дрібниці: можливості технологічної платформи, план рахунків, запити, робота з «нерідними» SQL, використання СКД, підключення обладнання (ваги, каси, сканери). І взагалі, робити так, як потрібно, а не як простіше:).

P.S. Чомусь усі думають, що 1С – це суто бухгалтерська програма. Насправді це не так, на її основі можна поставити не лише бухгалтерію як таку, а й створити повноцінну систему управлінського обліку та звітності безпосередньо під вимоги Вашого підприємства. І у ній буде все, абсолютно все.

 

 

Тел: (057) 7595481,

Тел./Viber/Telegram: (067) 5787707