1C - Добро и зло. Распоред на точки во холивари околу 1C

Пријатели и колеги, неодамна имаше сè почести написи за Habré со омраза кон 1C како развојна платформа и говори на неговите бранители. Овие написи идентификуваа еден сериозен проблем: најчесто, критичарите на 1C го критикуваат од позиција на „не го совладаат“, карајќи проблеми што де факто лесно се решаваат и, напротив, не допираат проблеми што се навистина важни, вредат. дискутираат и не се решени од продавачот . Верувам дека има смисла да се спроведе трезен и избалансиран преглед на платформата 1C. Што може да направи, што не може, што треба да прави, но не прави и, за десерт, што прави со тресок, а вашите програмери во %technology_name% ќе направат сто години, фрлајќи го повеќе од еден годишен буџет.

Како резултат на тоа, вие, како менаџер или архитект, ќе можете да добиете јасно разбирање за тоа каква задача ќе ви биде корисно да користите 1C и каде треба да се изгори со жешко железо. Како развивач во светот „не-1C“, ќе можете да видите што има во 1C што предизвикува гужва. И како развивач на 1C, ќе можете да го споредите вашиот систем со екосистемите на други јазици и да ја разберете вашата локација во координатниот систем за развој на софтвер.

Под резот има многу дебели напади на 1C, на критичари на 1C, на Java, .NET и воопшто... Навивачот е полн, добредојде!

Изјава

Запознаен сум со темата на разговор од околу 2004 година. Програмирам веројатно од 6-годишна возраст, од самиот момент кога добив книга за професорот Фортран со стрипови за мачка, врапче и гасеница. Ги анализирав програмите што ги напиша мачката од сликите во книгата и дознав што направиле. И да, немав вистински компјутер во тоа време, но имаше цртеж на ширењето на книгата и искрено ги притиснав копчињата за хартија, внесувајќи ги командите што ги шпионирав за мачката Х.

Потоа имаше BK0011 и BASIC на училиште, C++ и асемблери на универзитет, потоа 1C, а потоа и многу други работи што ми е премногу мрзливо да ги паметам. Во последните 15 години, главно се занимавам со 1C, не само во однос на кодирањето, туку и во 1C воопшто. Поставување задачи, администрација и развој овде. Во последните 5 години бев ангажиран во општествено корисни активности во смисла на развој на алатки за развој и автоматизација за други корисници на 1C, пишување написи и книги.

Ајде да одлучиме за темата на дискусија

Прво, да дефинираме за што ќе зборуваме, бидејќи буквите „1C“ можат да значат многу работи. Во овој случај, под буквите „1C“ ќе мислиме исклучиво на развојната рамка „1C: Enterprise“ на модерната, осма верзија. Нема да зборуваме многу за производителот и неговите политики (но ќе треба малку да направиме Ние нема да разговараме за конкретни апликации напишани со оваа рамка). Технологијата е посебна, апликациите ака конфигурации се посебни.

Архитектура на високо ниво 1C: Enterprise

Не за џабе го спомнувам зборот „рамка“. Од гледна точка на развивачот, платформата 1C е токму рамка. И треба да го третирате токму како рамка. Размислете за тоа како Spring или ASP.NET, извршени од одредено време на траење (JVM или CLR соодветно). Се случува во светот на конвенционалното програмирање („не 1C“), поделбата на рамки, виртуелни машини и специфични апликации е природна, поради фактот што овие компоненти обично се развиваат од различни производители. Во светот на 1C, не е вообичаено експлицитно да се разликува рамката за развој и самото време на работа. Како резултат на тоа, се појавува одредена конфузија. Затоа, во рамките на статијата, ќе треба да го разгледаме 1C од неколку страни одеднаш и да го класифицираме по неколку координатни оски. И во секоја координатна оска ќе ставиме лопата од кафеава супстанција и ќе ги разгледаме карактеристиките, предностите и недостатоците на постојното решение.

Погледни точки на 1C

1C за купувачот

Купувачот купува систем за автоматизација со кој може брзо да ги реши проблемите со автоматизирање на сопствениот бизнис. Бизнисот може да биде мал тезга, или може да биде голем холдинг. Јасно е дека потребите на овие бизниси се различни, но и двете се поддржани од една база на кодови на платформата.

За купувачот на 1C ова е брзо време за пазар. Брзо. Побрзо од Java, C# или JS. Просечна. Околу болницата. Јасно е дека веб-локацијата за визит-картичка која користи React ќе излезе подобра, но задниот дел на системот WMS ќе се стартува побрзо на 1C.

1C како алатка

Секое технолошко решение има граници на применливост. 1C не е јазик за општа намена, тој не живее одвоено од неговата рамка. Препорачливо е да користите 1C кога ви треба:

• серверска апликација
• апликација каде се појавуваат финансиите
• со готов UI, ORM, известување, XML/JSON/COM/PDF/YourDataTransferingFormat
• со поддршка за заднински процеси и работни места
• со безбедност заснована на улоги
• со скриптабилна деловна логика
• со можност за брзо креирање на прототип и ниско време за продажба

Не ви треба 1C ако сакате:

• машинско учење
• Пресметки на графичкиот процесор
• компјутерска графика
• математички пресметки
• CAD систем
• обработка на сигнал (звук, видео)
• вчитајте http повици со стотици илјади вртежи во секунда

1C како производствена компанија

Вреди да се разбере каков е бизнисот на 1C како производител на софтвер. Компанијата 1C продава решенија за деловни проблеми преку автоматизација. Различни бизниси, големи или мали, но тоа е она што таа го продава. Средствата за постигнување на оваа цел се деловните апликации. За сметководство, сметководство за плати итн. За пишување на овие апликации, компанијата користи сопствена платформа за развој на деловни апликации. Специјално приспособени за заеднички задачи на истите овие деловни апликации:

• финансиско сметководство
• лесно прилагодување на деловната логика
• широки можности за интеграција во хетерогени ИТ пејзажи

Како производител, 1C верува дека ова е стратегијата што ви овозможува да работите со партнери и клиенти во режим на победа-победа. Може да се расправате со ова, но отприлика вака се промовира компанијата: готови решенија за деловни проблеми кои можат брзо да се приспособат од партнерите и да се интегрираат во секој ИТ пејзаж.

Сите тврдења или желби за 1C како рамка треба да се разгледуваат исклучиво низ оваа призма. „Сакаме OOP во 1C“, велат програмерите. „Колку ќе не чини поддршката на OOP во платформата, дали ова ќе ни помогне да ја зголемиме продажбата на кутии?“ вели 1C. Ја отвора својата „призма“ на продажба на решенија за деловните проблеми:

- Еј, бизнис, дали сакаш OOP во твојот 1C?
- Дали ова ќе ми помогне да ги решам моите проблеми?
- Кој знае...
- Тогаш нема потреба

Овој пристап може да биде добар или лош во зависност од тоа кој го гледа, но тоа е само така. Зборувајќи за фактот дека нема карактеристика X во 1C, треба да разберете дека таа не е таму со причина, туку во контекст на изборот „трошок за имплементација наспроти износ на профит“.

Технолошка класификација

„Всушност, Odinesniks даваат се од себе за да ги користат најдобрите модели, внимателно избрани од грижливи методолози и развивачи на платформата 1C.
Кога го пишувате вашиот глупав код за едноставна управувана форма, во реалноста ја користите модел-поглед-контролер с двонасочно врзување на податоци в трислоен-податоци-апликација-мотор, со вкус мапирање објект-релации на високо ниво на основата декларативен опис на метаподатоциимајќи свој Јазик за барање независен од платформата, Ц Декларативен кориснички интерфејс управуван од податоци, целосна транспарентна серијализација и програмски јазик ориентиран кон домен.

Она што програмерите на 1C се разликуваат од нивните западни колеги е во ПР. Тие сакаат на секое срање да му дадат големо име и да трчаат со него како валкана торба“.
А.Орефков

Платформата 1C има класична архитектура со 3 нивоа, во чиј центар е серверот за апликации (или негова емулација за малку пари за малите пазарџии). Или MS SQL или Postgres се користат како DBMS. Има и поддршка за Oracle и IBM DB2, но ова е прилично езотерично, никој не знае што ќе се случи ако имплементирате 1C на овие бази на податоци под средно и високо оптоварување. Верувам дека самиот 1C не го знае ова.

Клиентскиот дел е или тенок клиент инсталиран на машината на корисникот или веб-клиент. Клучната карактеристика е што програмерите не пишуваат 2 различни кодови, тие пишуваат една апликација, на еден јазик, а можете да ја прикажете во прелистувачот доколку има желба или потреба. Кој таму сакаше вистински целосен стек и единствен јазик за предниот и задниот дел, node.js? Никогаш до крајот не успеаја да го направат истото. Постои вистински полн стек, но ќе мора да го напишете во 1C. Иронијата на судбината, вакви работи :)

Облакот SaaS решението 1C:Fresh работи и во режим на прелистувач, во кој не можете да купите 1C, туку да изнајмите мала база на податоци и да ја следите продажбата на шаварма таму. Само во прелистувачот, без да инсталирате или конфигурирате ништо.

Покрај тоа, постои наследен клиент, кој во 1C се нарекува „редовна апликација“. Наследството е наследство, добредојдовте во светот на апликациите во 2002 година, но сè уште зборуваме за моменталната состојба на екосистемот.

Делот од серверот 1C поддржува кластерирање и скали со додавање на нови машини во кластерот. Овде се скршени доста копии и ќе има посебен дел во статијата за ова. Накратко, ова не е сосема исто како додавањето на неколку точно исти примероци зад HAProxy.

Рамката за развој на апликации користи сопствен програмски јазик, кој приближно наликува на малку подобрен VB6 преведен на руски. За луѓето кои мразат сè што е руско, кои не веруваат дека „ако“ е преведено како „ако“, се нуди втората синтаксичка опција. Оние. Ако сакате, можете да го напишете во 1C на таков начин што не се разликува од VB.

Токму овој програмски јазик е главната причина за омразата на прекарите на 1C кон нивната платформа. Да се ​​разбереме, не без причина. Јазикот беше замислен колку што е можно поедноставен, дизајниран да ја исполни мантрата „ПРОВИЖНИЦИ, РАЗВИВАЧИ“ на размери барем во ЗНД. Комерцијалната суштина на таквото решение, според мое мислење, е јасно видлива: повеќе програмери, поголема покриеност на пазарот. Ова се оствари, според различни проценки од 45% до 95%. Веднаш ќе кажам дека пишувањето на јазикот што мислите е навистина полесно. И јас знам доста програмски јазици.

Да почнеме со јазикот.

1C програмски јазик

Во исто време јаката и слабата точка на системот. Обезбедува лесен влез и читливост. Од друга страна, тој не е ажуриран од објавувањето на верзијата 8 во 2002 година и е морално застарен. Некој ќе рече „главниот недостаток е што нема ООП“ и ќе згреши. Прво, ПЛО не го сака не само Нуралиев, туку и Торвалдс. И второ, ООП сè уште постои.

Од гледна точка на развивачот, тој има на располагање рамка со основни класи прикажани на DBMS. Програмерот може да ја земе основната класа „Директориум“ и да го наследи директориумот „Клиенти“ од него. Може да додаде нови полиња за класа на него, на пример, INN и Address, а исто така, доколку е потребно, може да ги отфрли (замени) методите на основната класа, на пример, методот OnWrite/AtRecord.

Рамката е дизајнирана на таков начин што ретко е потребно подлабоко наследство, а ограничувањето во OOP, според мое мислење, има смисла. 1C се фокусира на развој управуван од домен и ве тера да размислувате, пред сè, за предметната област на решението што се развива, и ова е добро. Не само што нема искушение, туку и нема потреба да се пишуваат 10 различни DTO и ViewModels само за да се прикажат некаде некои податоци од доменот. Развивачот на 1C секогаш работи со еден ентитет, без да го натрупува контекстот на перцепција со десетина класи со слични имиња, кои го претставуваат истиот ентитет, но од друга страна. Секоја .NET апликација, на пример, нужно ќе содржи пет или два ViewModels и DTO за серијализација во JSON и пренос на податоци од клиент на сервер. И приближно 10-15% од кодот на вашата апликација ќе биде потрошен за пренос на податоци од една класа во друга користејќи пенкала или патерици како AutoMapper. Овој код мора да биде напишан и на програмерите мора да им се плати за да го креираат и одржуваат.

Излегува дека јазикот 1C е тешко да се развие без да се комплицира на ниво на мејнстрим јазици, со што се губи предноста на едноставноста. Која е задачата на продавачот во суштина што се решава: да издаде стандардно решение што секој ученик фатен на улица може да го приспособи со потребното ниво на квалитет (т.е., комплетот што покрива од тезга до голема фабрика е завршен). Ако сте тезга, земете студент ако сте фабрика, земете гуру од вашиот партнер за спроведување; Фактот што партнерите за имплементација ги продаваат студентите по цена на гуру не е проблем со рамката. Архитектонски, рамката мора да ги реши проблемите на двете, кодот на стандардните конфигурации (кој го продадовме на бизнисите со ветување за прилагодување) треба да може да биде разбран од студентот, а гуруто треба да може да разбере што сакате.

Она што, според мене, навистина недостасува на јазикот, она што ве принудува да пишувате повеќе отколку што можете, е она што го губи времето платено од клиентот.

• Можност за пишување на ниво, на пример, TypeScript (како резултат на тоа, поразвиени алатки за анализа на код во IDE, рефакторирање, помалку навредливи заглавувања)
  Достапност на функции како објекти од прва класа. Малку покомплексен концепт, но количината на типичен код за котли може значително да се намали. Разбирањето на кодот на ученикот, IMHO, дури би се зголемило поради намалувањето на волуменот
• Универзална колекција буквали, иницијализатори. Истото - намалување на количината на код што треба да се напише и/или да се погледне со очи. Пополнувањето на колекциите зазема над 9000% од времето за програмирање 1C. Да се ​​напише ова без синтаксички шеќер е долго, скапо и склоно кон грешки. Општо земено, количината на LOC во решенијата 1C ги надминува сите замисливи граници во споредба со достапните отворени рамки и, генерално, со сите ваши претпријатија Javas заедно. Јазикот е говорен, а тоа дегенерира во количина на податоци, меморија, IDE кочници, време, пари...
• конечно конструкции Имам хипотеза дека оваа конструкција ја нема поради фактот што не најдоа успешен превод на руски :)
• Сопствени типови на податоци (без OOP), аналози на Тип од VB6. Тоа ќе ви овозможи да не пишувате структури користејќи коментари во BSP и магични методи кои ги конструираат овие структури. Добиваме: помалку код, навестување преку точка, побрзо решение на проблемот, помалку грешки поради печатни грешки и исчезнати својства на структурите. Сега пишувањето на корисничките структури целосно му припаѓа на тимот за развој на Стандардната библиотека на потсистемите, кој, по своја заслуга, внимателно пишува коментари за очекуваните својства на положените структури на параметри.
• Без шеќер кога работите со асинхрони повици на веб-клиентот. повратен повик во форма на ProcessingNotifications е привремена патерица предизвикана од ненадејна промена на API-то на главните прелистувачи, но не можете да живеете вака постојано повеќе и повеќе. Не додавајте поддршка за оваа парадигма во главниот IDE и работите ќе станат уште полоши.

Ова е еден од горливите проблеми, јасно е дека списокот може да биде многу поголем, но не смееме да заборавиме дека ова сè уште не е јазик за општа намена, не бара повеќенишки, ламбда функции, пристап до графичкиот процесор и брз пресметки со подвижна запирка. Ова е јазик за скриптирање со деловна логика.

Програмер кој веќе има работено многу со овој јазик, гледа во js или c#, станува досадно во рамките на овој јазик. Тоа е факт. Му треба развој. Од другата страна на скалата за продавачот се трошоците за имплементација на наведените карактеристики наспроти зголемувањето на приходите по нивното спроведување. Овде немам никакви информации за тоа што е моментално претерано во очите на компанијата.

Развојна средина

И овде работите не одат мазно. Постојат две развојни средини. Првиот е Конфигураторот вклучен во испораката. Втората е околината Enterprise Development Tools, или скратено EDT, развиена врз основа на Eclipse.

Конфигураторот обезбедува целосен опсег на развојни задачи, ги поддржува сите функции и е главната средина на пазарот. Тој е исто така морално застарен, не се развива, според гласините - поради висината на техничкиот долг во себе. Ситуацијата може да се подобри со отворање на внатрешен API (во форма на пријателство со Снешко А.Орефкова или на самостојна основа), но тоа не е така. Практиката покажа дека заедницата ќе запише свои карактеристики во IDE, се додека продавачот не се меша. Но, ние го имаме тоа што го имаме. Конфигураторот беше одличен во 2004-2005 година, многу потсетуваше на Visual Studio од тие времиња, на некои места беше и поладен, но беше заглавен во тие времиња.

Покрај тоа, обемот на просечното стандардно решение оттогаш порасна неколку пати, а денес IDE едноставно не може да се справи со количината на код со кој се храни. Употребливоста и можностите за рефакторирање не се ни нула, тие се во минус. Сето ова не додава ентузијазам кај програмерите и тие сонуваат да се преселат во други екосистеми и да продолжат да кодираат срања таму, но во пријатна средина која не ви плука во лице со своето однесување.

Како алтернатива, се нуди IDE напишана од нула, изградена на Eclipse. Таму, изворите, како и во секој друг софтвер, живеат во форма на текстуални датотеки, се чуваат во GIT, гранки за повлекување барања, сето ова. Негативно, не остави статус на бета веќе многу години, иако се подобрува со секое издание. Нема да пишувам за недостатоците на EDT, денес е минус, утре е фиксна карактеристика. Релевантноста на таков опис брзо ќе исчезне. Денес е можно да се развие во EDT, но необично е да се подготвите за одреден број на грешки во IDE.

Ако ја погледнете ситуацијата низ гореспоменатата „1C призма“, ќе добиете нешто вака: објавувањето на новиот IDE не ја зголемува продажбата на кутии, но одливот на ДЕВИЛОПЕРИ може да се намали. Тешко е да се каже што го чека екосистемот во однос на удобноста на програмерите, но Мајкрософт веќе ги зафркна мобилните програмери нудејќи им ги своите услуги предоцна.

Управување со развојот

Овде сè е значително подобро отколку во пишувањето код, особено неодамна, кога напорите на заедницата ги извадија на виделина проблемите со автоматизацијата на администрацијата, лансираа прототипови кои повикуваат на фрлање на складиштето 1C во корпата за отпадоци и користење git, брзо обвинување, преглед на кодот , статичка анализа, автоматско распоредување и сл. На платформата се додадени многу функции кои го зголемуваат нивото на автоматизација на развојните задачи. Сепак, сите овие карактеристики беа додадени само и исклучиво за развој на нашите сопствени големи производи, кога стана очигледно дека не можеме без автоматизација. Имаше автоматско спојување, тринасочна споредба со KDiff и сето тоа. Лансиран на Github гитконвертер, кој, искрено, идеолошки беше одвлечен од проектот gitsync, но изменета за да одговара на процесите на компанијата продавач. Благодарение на тврдоглавите момци од софтвер со отворен код, развојната автоматизација во 1C започна. Отвореното API за конфигураторот, IMHO, исто така би ја префрлило моралната заостанатост на главниот IDE.

Денес, складирање на извори 1C во git со обврски поврзани со проблеми во Jira, прегледи во Crucible, притискање на копчето од Jenkins и Allure извештаи за тестирање на код во 1C, па дури и статичка анализа во SonarQube - ова е далеку од новост, туку е мејнстрим во компаниите каде што има многу развој на 1C.

Администрација

Има многу да се каже овде. Прво, ова е, се разбира, сервер (кластер на сервери 1C). Прекрасно нешто, но поради фактот што се работи за целосно црна кутија, документирана со доволно детали, но на специфичен начин - совладувањето на започнувањето на непречено работење во режим на високо оптоварување на неколку сервери е многу од неколкумина избрани кои носат медал со натпис „Експерт за технолошки прашања“. Вреди да се напомене дека, во принцип, администрирањето на серверот 1C не се разликува од администрирањето на кој било друг сервер. Тоа е мрежна апликација со повеќе нишки која троши меморија, процесор и ресурси на дискот. Обезбедува многу можности за телеметриско собирање и дијагностика.

Проблемот овде е што продавачот не нуди ништо посебно во однос на готови решенија за оваа дијагностика. Да, има 1C: Инструментација и контролен центар, дури се доста добри, но се многу скапи и не ги имаат сите. Има голем број на случувања во заедницата за поврзување на Grafana, Zabbix, ELK и други работи од стандардниот админ сет, но не постои единствено решение кое ќе одговара на мнозинството. Задачата го чека својот херој. И ако сте бизнис што планира да започне со кластер 1C, потребен ви е експерт. Свое внатре или однадвор, но ти треба. Нормално е дека има посебна улога со компетенции за работа на серверот, не секој корисник на 1C треба да го знае ова, само треба да разберете дека е потребна таква улога. Да го земеме SAP на пример. Таму, програмер, најверојатно, нема ни да стане од столот ако од него се побара да конфигурира нешто на серверот за апликации. Можеби е само глупав и нема да се срами. Во методологијата SAP постои посебна улога на вработениот за ова. Поради некоја причина, во индустријата 1C се верува дека ова треба да се комбинира кај еден вработен за иста плата. Тоа е заблуда.

Недостатоци на серверот 1C

Има точно еден минус - сигурност. Или, ако сакате, непредвидливост. Ненадејното чудно однесување на серверот веќе стана збор на градот. Универзален лек - запирање на серверот и чистење на сите кешови - е дури опишан во прирачникот на експертот, па дури и се препорачува сериска книга што го прави тоа. Ако вашиот систем 1C почне да прави нешто што ни теоретски не би требало да го прави, време е да го исчистите кешот на податоците за сесијата. Според моја проценка, во целата земја има само тројца луѓе кои знаат да управуваат со сервер 1C без оваа процедура и не споделуваат тајни, бидејќи ... тие живеат од ова. Можеби нивната тајна е во тоа што ги чистат податоците од сесиите, но никому не кажуваат за тоа, пријателе.

Инаку, серверот 1C е иста апликација како и секој друг и се администрира на ист начин, со читање на документацијата и чукање на тамбурата.

пристанишен работник

Корисноста од користење на контејнеризиран сервер 1C во производството сè уште не е докажана. Серверот не е групиран со едноставно додавање јазли зад балансерот, што ги намалува придобивките од контејнеризацијата на производството на минимум, а практиката на успешно работење во контејнерите во режим на високо оптоварување не е воспоставена. Како резултат на тоа, само програмерите користат Docker+1C за да постават околини за тестирање. Таму е многу корисно, применето, ви овозможува да играте со современи технологии и да се одморите од очајот на конфигураторот.

Комерцијална компонента

Од инвестициска гледна точка, 1C ви овозможува да го решите проблемот со брзо лансирање деловни идеи поради широките можности на класите на апликации. 1C надвор од кутијата дава многу пристојно известување, интеграција со било што, веб-клиент, мобилен клиент, мобилна апликација, поддршка за различни DBMS, вкл. бесплатни, меѓуплатформски и серверски и инсталирани делови од клиентот. Да, интерфејсот на апликациите ќе биде жолт, понекогаш ова е минус, но не секогаш.
Со избирање на 1C, бизнисот добива збир на софтверски решенија кои им овозможуваат да изградат многу широк опсег на апликации, како и многу програмери на пазарот кои сакаат помалку пари од јаваистите и во исто време даваат резултати побрзо.

На пример, задачата за испраќање PDF-фактура до клиент може да се реши за еден час студентска работа. Истиот проблем во .NET може да се реши со купување на сопствена библиотека или неколку дена или недели кодирање од строг, брадест развивач. Понекогаш, и двете одеднаш. И да, зборував само за генерирање PDF. Не кажавме од каде воопшто ќе дојде оваа сметка. Веб-фронтендерот мора да создаде формулар каде што операторот ќе ги внесува податоците, бекендерот ќе треба да креира dto модели за пренос на JSON, модели за складирање во базата на податоци, структурата на самата база на податоци, миграција во неа, формирање на графички приказ на оваа сметка, и само тогаш - PDF. На 1C, целата задача, од нула, се завршува за точно еден час.

Целосен сметководствен систем за мала тезга со еден купен/продаден деловен процес се прави за 3 часа Со известување за продажба, сметководство на стоки по купопродажни цени, поделено по складиште, контрола на правата за пристап, веб-клиент и мобилна апликација. . Добро, заборавив на апликацијата, со апликацијата не за 3 часа, за шест.

Колку време ќе му треба на оваа задача на развивачот на .NET од инсталирање на визуелно студио на чист компјутер до демонстрација на клиентот? Што е со трошоците за развој? Исто нешто.

Јаки страни на 1C како платформа

1C е силен не затоа што има нешто специфично во него што е најдоброто во светот. Напротив, во секој поединечен потсистем можете да најдете поинтересен аналог во светскиот софтвер. Сепак, врз основа на комбинација на фактори, не гледам платформа слична на 1C. Тука лежи комерцијалниот успех. Предностите на платформата се расфрлани низ неа и најјасно се видливи кога ќе видите како тоа се прави на други платформи. Во основа, тоа НЕ се ни карактеристики, туку напротив - отфрлање на карактеристиките во корист на една специфична парадигма. Неколку примери:

1. Уникод. Што по ѓаволите може да биде поедноставно? Нема потреба да се користат шифрирања од еден бајт ASCII во 2019 година (освен за интеграција со старите наследени). Никогаш. Но не. Како и да е, некој во некоја табела користи варчар од еден бајт и апликацијата ќе има проблеми со шифрирањето. Во 2015 година, овластувањето за LDAP на gitlab не успеа поради неправилна работа со кодирање JetBrains сè уште не работи со кирилица во имињата на датотеките насекаде; 1C обезбедува висококвалитетна изолација на кодот на апликацијата од слојот на базата на податоци. Таму е невозможно да се пишуваат табели на ниско ниво и таму се невозможни заглавувања на некомпетентни јуниори на ниво на база на податоци. Да, може да има други проблеми со некомпетентните јуниори, но разновидноста на проблемите е многу помала. Сега ќе ми кажете дека вашата апликација е правилно дизајнирана и слојот за пристап до базата е изолиран како што треба. Погледнете уште еднаш на вашата корпоративна приспособена Java апликација. Тесно и искрено. Дали ве мачи совеста? Тогаш јас сум среќен за тебе.
2. Нумерирање на документи/референтни книги. Во 1C дефинитивно не е најфлексибилно и не е најдобро. Но, она што го прават во банкарскиот софтвер и во самите сметководствени системи - добро, тоа е само темнина. Или ќе се заглави идентитетот (а потоа „а, зошто имаме дупки“), или напротив, ќе направат генератор кој работи со заклучување на ниво на DBMS (и ќе стане тесно грло). Всушност, доста е тешко да се направи оваа навидум едноставна задача - попишувач од крај до крај на ентитети, со дел за уникатност базиран на одреден сет на клучеви, префиксација, за да не ја блокира базата на податоци при паралелно внесување податоци .
3. Идентификатори на записи во базата на податоци. 1C донесе одлука со силна волја - сите идентификатори на врски се апсолутно синтетички и тоа е тоа. И нема проблеми со дистрибуирани бази на податоци и размена. Програмерите на други системи тврдоглаво создаваат нешто како идентитет (тоа е пократко!), влечете ги во GUI додека не дојде време да се создадат неколку поврзани примероци (и потоа тие ќе бидат откриени). Го немаш ова? Искрено?
4. Списоци. 1C има доста успешни механизми за страничење низ (големи) списоци и навигација низ нив. Веднаш да направам резервација - со правилна употреба на механизмот! Општо земено, темата е прилично непријатна, не може да се реши идеално: таа е или интуитивна и едноставна (но ризикот од огромни збирки записи на клиентот), или страничењето е од една или друга кривина. Оние кои прават страничење често го прават тоа криво. Оние кои прават искрена лизгачка лента додаваат база на податоци, канал и клиент.
5. Управувани форми. Без сомнение, во веб-клиентот интерфејсот не работи совршено. Но, тоа функционира. Но, за многу други сметководствени и банкарски системи, создавањето оддалечено работно место е проект на ниво на претпријатие. Одрекување: за среќа за оние кои првично го направија на интернет, тоа нема да влијае.
6. Мобилна апликација. Неодамна, можете да пишувате и мобилни апликации додека сте во истиот екосистем. Овде е малку покомплицирано отколку кај веб-клиент, спецификите на уредите ве принудуваат да пишувате специјално за нив, но, сепак, не ангажирате посебен тим на мобилни програмери. Ако ви треба апликација за внатрешните потреби на една компанија (кога мобилното решение за корпоративен проблем е поважно од жолт дизајн на UI), едноставно ја користите истата платформа надвор од кутијата.
7. Известување. Со овој збор не мислам на БИ систем со големи податоци и задоцнување на процесот на ETL. Ова се однесува на извештаите на оперативниот персонал што ви овозможуваат да ја процените состојбата на сметководството овде и сега. Биланси, меѓусебни порамнувања, преоценување и сл. 1C излегува од кутијата со систем за известување со флексибилни поставки за групирања, филтри и визуелизација на корисничката страна. Да, на пазарот има поладни аналози. Но, не во рамките на се-во-едно решение и по цена понекогаш повисока од решението се-во-едно. И почесто е дури и обратно: само известување, но поскапо од целата платформа и полошо по квалитет.
8. Форми за печатење. Па, користете .NET за да го решите проблемот со испраќање уплатници за плата во PDF до вработените преку е-пошта. И сега задачата за печатење фактури. Што е со зачувувањето на нивните копии во истиот PDF? За прекарот 1C, излегувањето на кој било распоред во PDF е +1 линија код. Ова значи + 40 секунди работно време, наместо денови или недели на друг јазик. Распоредот на печатените форми во 1C се неверојатно лесни за развој и доволно моќни за да се натпреваруваат со платените колеги. Да, веројатно нема многу интерактивни можности во документите со табеларни пресметки 1C, не можете брзо да добиете 3D дијаграм со скалирање користејќи OpenGL. Но, дали е навистина потребно?

Ова се само неколку примери каде ограничувањето на функционалноста или спроведувањето компромиси се покажува како важна архитектонска придобивка во иднина. Дури и компромис или не најефективната опција - таа е веќе во кутијата и се зема здраво за готово. Неговата самостојна имплементација или ќе биде невозможна (бидејќи таквите одлуки мора да се носат на почетокот на проектот, а за тоа нема време, а архитект воопшто нема), или неколку скапи повторувања. Во секоја од наведените точки (а ова не е комплетна листа на архитектонски решенија), можете да зафркате и да воведете ограничувања што го блокираат скалирањето. Во секој случај, вие, како бизнисмен, треба да бидете сигурни дека вашите програмери, кога прават „систем од нула“, имаат прави раце и веднаш добро ќе ги решат суптилните системски проблеми.

Да, како и во секој друг сложен систем, самиот 1C исто така има решенија што го блокираат скалирањето во одредени аспекти. Сепак, повторувам, врз основа на комбинација на фактори, трошоците за сопственост и бројот на веќе решени однапред однапред решени проблеми, не гледам достоен конкурент на пазарот. За иста цена добивате рамка за финансиска апликација, кластериран балансиран сервер, со UI и веб интерфејс, со мобилна апликација, со известување, интеграција и еден куп други работи. Во светот на Јава, најмувате тим од предниот и заден дел, дебагирате ниско ниво од домашно напишан код на серверот и плаќате одделно за 2 мобилни апликации за 2 мобилни оперативни системи.

Не велам дека 1C ќе ги реши сите случаи, но за внатрешна корпоративна апликација, кога нема потреба да се брендира UI - што друго е потребно?

Летај во маст

Веројатно сте добиле впечаток дека 1C ќе го спаси светот и дека сите други начини на пишување корпоративни системи се погрешни. Воопшто не е така. Од гледна точка на бизнисменот, ако изберете 1C, тогаш покрај брзото време до пазар, мора да ги земете предвид и следните недостатоци:

• Доверливост на серверот. Потребни се навистина висококвалитетни специјалисти кои можат да обезбедат негово непречено функционирање. Не сум запознаен со подготвена програма за обука за такви специјалисти од продавачот. Има курсеви за подготовка за Стручниот испит, но ова, според мене, не е доволно.
• Поддршка. Видете го претходниот став. За да имате поддршка од продавачот, треба да го купите. Поради некоја причина ова не е прифатено во индустријата 1C. И со SAP, тоа е речиси задолжително купување и никому не му пречи. Без корпоративна поддршка и без експерт за персонал, можете да останете сами со грешки од 1C.
• Сепак, не можете да направите апсолутно сè со 1C. Ова е алатка и како и секоја алатка има граници на применливост. Во пејзажот 1C, многу е пожелно да се има системски архитект „не-1C“.
• Добрите прекари 1C не се поевтини од добрите програмери на други јазици. Иако, лошите програмери се скапи за вработување, без разлика на јазикот на кој пишуваат.

Ајде да ги означиме точките

• 1C е рамка за брз развој на апликации (RAD) за бизнис и е прилагодена за ова.
• Врска од три нивоа со поддршка за главните DBMS, кориснички интерфејс, многу добар ORM и известување
• Широки можности за интеграција со системи кои можат да го направат она што 1C не може. Ако сакате машинско учење, земете го Python и испратете го резултатот до 1C преку http или RabbitMQ
• Нема потреба да се трудите да правите сè користејќи 1C, треба да ги разберете неговите силни страни и да ги користите за свои цели
• На програмерите кои гравитираат кон продлабочување на гаџетите со технолошка рамка и редизајнирање на секои N години до нов мотор, им е здодевно со 1C. Таму сè е многу конзервативно.
• На програмерите им е исто така досадно затоа што има многу мала грижа за нив од производителот. Досаден јазик, слаб IDE. Тие бараат модернизација.
• Од друга страна, програмерите кои не можат да најдат забава преку користење и учење друга технологија во која уживаат се лоши програмери. Ќе кукаат и ќе се преселат во друг екосистем.
• Работодавците кои не дозволуваат нивните прекари 1C да напишат нешто во Python се лоши работодавци. Ќе изгубат вработени со испитувачки ум, а на нивно место ќе дојдат мајмуни кодери кои иако се согласуваат со се, ќе го влечат корпоративниот софтвер во мочуриштето. Допрва ќе треба да се препише, па можеби би било подобро да се инвестира малку во Python малку порано?
• 1C е комерцијална компанија и имплементира карактеристики исклучиво врз основа на сопствените интереси и целисходност. Не можете да ја обвинувате за ова, бизнисот мора да размислува за профит, тоа е животот
• 1C заработува со продавање решенија за деловни проблеми, а не за проблеми со програмерите на Васија. Овие два концепта се во корелација, но приоритетот е токму она што го кажав. Кога инвеститорот Васија е подготвен да плати за лична лиценца за 1C: Resharper, тоа ќе се појави доста брзо, „Resharper“ од А. Орефкова е доказ за тоа. Доколку продавачот го поддржеше, а не се бореше против него, ќе се појави пазар за софтвер за програмери. Сега има еден и пол играч на овој пазар со сомнителни резултати, и сето тоа затоа што интеграцијата со IDE е негативна и се се прави на патерици.
• Практиката на оператор со повеќе машини ќе исчезне во заборав. Современите апликации се премногу големи за да се запомнат и од страната на кодот и од страната на деловната употреба. Серверот 1C, исто така, станува покомплексен, ќе биде невозможно да се одржат сите видови експертиза во еден вработен. Ова треба да повлече побарувачка за специјалисти, што значи атрактивност на професијата 1C и зголемување на платите. Ако претходно Васија работеше три во еден за една плата, сега треба да ангажирате два Васија и конкуренцијата меѓу Васија може да го поттикне севкупниот раст на нивното ниво.

Заклучок

1C е многу достоен производ. Во мојот опсег на цени, воопшто не знам аналози, пишете во коментарите ако ги има. Сепак, одливот на програмери од екосистемот станува се позабележителен и ова е „одлив на мозоци“, без разлика како гледате на тоа. Индустријата е гладна за модернизација.
Ако сте програмер, не се закачувајте на 1C и немојте да мислите дека сè е магично на други јазици. Додека си јуниор, можеби. Штом треба да се реши нешто поголемо, готовите решенија ќе треба да се бараат подолго и поинтензивно да се довршуваат. Во однос на квалитетот на „блоковите“ од кои може да се изгради решение, 1C е многу, многу добар.

И уште една работа - ако ви дојде прекар 1C за да вработите, тогаш прекарот 1C може безбедно да се назначи на позицијата водечки аналитичари. Нивното разбирање на задачата, предметната област и вештините за распаѓање е одлично. Сигурен сум дека ова се должи токму на присилната употреба на DDD во развојот на 1C. Едно лице е обучено да размислува за значењето на задачата пред сè, за врските помеѓу предметите од предметната област, а во исто време има техничка позадина во технологиите за интеграција и форматите за размена на податоци.

Бидете свесни дека идеалната рамка не постои и грижете се за себе.
Се добро!

PS: Ви благодарам многу спешуричен за помош при подготовката на статијата.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Дали имате 1C во вашето претпријатие?

• 13,3%Воопшто не.71

• 30,3%Има, ама само во сметководство некаде. Основни системи на други платформи162

• 41,4%Да, главните деловни процеси работат на тоа221

• 15,0%1C мора да умре, иднината му припаѓа на %technology_name%80

Гласале 534 корисници. 99 корисници беа воздржани.

Извор: www.habr.com