Ընկերներ և գործընկերներ, վերջերս Habré-ի մասին ավելի հաճախակի են եղել հոդվածներ ատելությամբ 1C-ի նկատմամբ որպես զարգացման հարթակ, և ելույթներ նրա պաշտպանների կողմից: Այս հոդվածները բացահայտեցին մեկ լուրջ խնդիր. ամենից հաճախ 1C-ի քննադատները քննադատում են այն «չտիրապետելու» դիրքից, կշտամբում են այն խնդիրները, որոնք դե ֆակտո հեշտությամբ լուծվում են և, ընդհակառակը, չշոշափում են իսկապես կարևոր, արժանի խնդիրներ։ քննարկվում են և չեն լուծվում վաճառողի կողմից: Կարծում եմ, որ իմաստ ունի անցկացնել 1C հարթակի սթափ և հավասարակշռված վերանայում: Ինչ կարող է նա անել, ինչ չի կարող անել, ինչ պետք է անի, բայց չի անում, և, որպես դեսերտ, ինչ է նա անում պայթյունով, և %technology_name%-ի ձեր մշակողները կանեն հարյուր տարի՝ դեն նետելով այն: մեկից ավելի տարեկան բյուջե.
Արդյունքում, դուք, որպես մենեջեր կամ ճարտարապետ, կկարողանաք հստակ պատկերացում կազմել, թե ինչ խնդիր է ձեզ համար ձեռնտու օգտագործել 1C, և որտեղ այն պետք է այրվի տաք արդուկով: Որպես «ոչ 1C» աշխարհում ծրագրավորող՝ դուք կկարողանաք տեսնել, թե ինչ կա 1C-ում, որը աղմուկ է բարձրացնում: Եվ որպես 1C ծրագրավորող, դուք կկարողանաք համեմատել ձեր համակարգը այլ լեզուների էկոհամակարգերի հետ և հասկանալ ձեր գտնվելու վայրը ծրագրային ապահովման մշակման կոորդինատային համակարգում:
Կտրվածքի տակ շատ հաստ հարձակումներ կան 1C-ի վրա, 1C-ի քննադատների վրա, Java-ի, .NET-ի և ընդհանրապես... Երկրպագուը լիքն է, բարի գալուստ:
About Me
Խոսակցության թեմային ծանոթ եմ մոտավորապես 2004 թվականից։ Ես ծրագրավորել եմ երևի 6 տարեկանից, հենց այն պահից, երբ ես գիրք ստացա պրոֆեսոր Ֆորտրանի մասին՝ կատվի, ճնճղուկի և թրթուրի մասին կոմիքսներով։ Գրքի նկարներից վերլուծեցի կատուն գրած հաղորդումները և պարզեցի, թե ինչ են արել։ Եվ այո, ես այն ժամանակ իսկական համակարգիչ չունեի, բայց գրքի տարածության վրա նկար կար, և ես անկեղծորեն սեղմեցի թղթե կոճակները՝ մուտքագրելով X կատվին լրտեսածս հրամանները։
Հետո եղան BK0011-ը և BASIC-ը դպրոցում, C++-ը և assemblers-ը համալսարանում, այնուհետև 1C-ն, և հետո շատ այլ բաներ, որոնք ես չափազանց ծույլ եմ հիշել: Վերջին 15 տարիներին ես հիմնականում զբաղվում եմ 1C-ով, ոչ միայն կոդավորման, այլ ընդհանրապես 1C-ով։ Առաջադրանքներ, վարչարարություն և զարգացում այստեղ: Վերջին 5 տարիների ընթացքում ես զբաղվել եմ սոցիալապես օգտակար գործունեությամբ 1C-ի այլ օգտվողների համար մշակման և ավտոմատացման գործիքների մշակման, հոդվածներ և գրքեր գրելու առումով:
Եկեք որոշենք քննարկման առարկան
Նախ, եկեք սահմանենք, թե ինչի մասին ենք խոսելու, քանի որ «1C» տառերը կարող են շատ բան նշանակել: Այս դեպքում «1C» տառերով նկատի կունենանք բացառապես ժամանակակից, ութերորդ տարբերակի «1C: Enterprise» զարգացման շրջանակը։ Մենք շատ չենք խոսի արտադրողի և նրա քաղաքականության մասին (բայց մենք ստիպված կլինենք մի փոքր անել, մենք չենք քննարկի այս շրջանակի օգտագործմամբ գրված հատուկ ծրագրերը): Տեխնոլոգիան առանձին է, հավելվածները՝ այլ կոնֆիգուրացիաները՝ առանձին:
Բարձր մակարդակի ճարտարապետություն 1C: Ձեռնարկություն
Իզուր չէ, որ ես նշում եմ «շրջանակ» բառը։ Մշակողի տեսանկյունից 1C հարթակը հենց շրջանակ է: Եվ դուք պետք է դրան վերաբերվեք ճիշտ այնպես, ինչպես շրջանակի: Մտածեք դրա մասին որպես Spring կամ ASP.NET, որոնք իրականացվում են որոշակի գործարկման ժամանակով (համապատասխանաբար JVM կամ CLR): Դա տեղի է ունենում, որ սովորական ծրագրավորման աշխարհում («ոչ 1C») բաժանումը շրջանակների, վիրտուալ մեքենաների և հատուկ հավելվածների բնական է, քանի որ այդ բաղադրիչները սովորաբար մշակվում են տարբեր արտադրողների կողմից: 1C աշխարհում ընդունված չէ հստակորեն տարբերակել զարգացման շրջանակը և գործարկման ժամանակը, բացի այդ, շրջանակի օգտագործմամբ գրված հատուկ հավելվածները նույնպես հիմնականում մշակվում են հենց 1C-ի կողմից. Արդյունքում որոշակի շփոթություն է առաջանում։ Հետևաբար, հոդվածի շրջանակներում մենք ստիպված կլինենք դիտարկել 1C-ը միանգամից մի քանի կողմից և դասակարգել այն մի քանի կոորդինատային առանցքներով: Եվ յուրաքանչյուր կոորդինատային առանցքում մենք կդնենք շագանակագույն նյութի թիակ և կդիտարկենք առկա լուծման առանձնահատկությունները, առավելություններն ու թերությունները:
Տեսակետներ 1C-ի վրա
1C գնորդի համար
Գնորդը գնում է ավտոմատացման համակարգ, որով կարող է արագ լուծել սեփական բիզնեսի ավտոմատացման խնդիրները։ Բիզնեսը կարող է լինել փոքր կրպակ, կամ կարող է լինել խոշոր հոլդինգ: Հասկանալի է, որ այս բիզնեսների կարիքները տարբեր են, բայց երկուսն էլ ապահովված են մեկ հարթակի կոդային բազայով:
1C գնորդի համար սա շուկա դուրս գալու արագ ժամանակ է: Արագ. Ավելի արագ, քան Java, C# կամ JS: Միջին. Հիվանդանոցի շուրջը. Հասկանալի է, որ React օգտագործող այցեքարտի վեբկայքը ավելի լավ կստացվի, բայց WMS համակարգի հետնամասն ավելի արագ կգործարկվի 1C-ում:
1C որպես գործիք
Յուրաքանչյուր տեխնոլոգիական լուծում ունի կիրառելիության սահմաններ: 1C-ն ընդհանուր նշանակության լեզու չէ, այն չի ապրում իր շրջանակից առանձին: Ցանկալի է օգտագործել 1C, երբ ձեզ անհրաժեշտ է.
- սերվերային հավելված
- դիմում, որտեղ հայտնվում են ֆինանսները
- պատրաստի UI, ORM, Հաշվետվություն, XML/JSON/COM/PDF/YourDataTransferingFormat-ով
- ֆոնային գործընթացների և աշխատատեղերի աջակցությամբ
- դերերի վրա հիմնված անվտանգությամբ
- սցենարային բիզնես տրամաբանությամբ
- նախատիպի արագ ստեղծման ունակությամբ և շուկա դուրս գալու քիչ ժամանակով
Ձեզ հարկավոր չէ 1C, եթե ցանկանում եք.
- մեքենայի ուսուցում
- GPU-ի հաշվարկներ
- համակարգչային գրաֆիկա
- մաթեմատիկական հաշվարկներ
- CAD համակարգ
- ազդանշանի մշակում (ձայն, վիդեո)
- վերբեռնեք http զանգերը հարյուր հազարավոր rps-ով
1C որպես արտադրական ընկերություն
Արժե հասկանալ, թե որն է 1C-ի բիզնեսը որպես ծրագրակազմ արտադրող: 1C ընկերությունը ավտոմատացման միջոցով վաճառում է բիզնեսի խնդիրների լուծումներ։ Տարբեր բիզնեսներ, մեծ թե փոքր, բայց դա այն է, ինչ նա վաճառում է: Այս նպատակին հասնելու միջոցները բիզնես հավելվածներն են։ Հաշվապահական հաշվառման, աշխատավարձի հաշվառման և այլնի համար: Այս հավելվածները գրելու համար ընկերությունն օգտագործում է սեփական բիզնես հավելվածների մշակման հարթակը: Հատուկ հարմարեցված է այս նույն բիզնես հավելվածների ընդհանուր առաջադրանքների համար.
- ֆինանսական հաշվառում
- բիզնեսի տրամաբանության հեշտ հարմարեցում
- ինտեգրման լայն հնարավորություններ տարասեռ ՏՏ լանդշաֆտներում
Որպես արտադրող, 1C-ն կարծում է, որ սա այն ռազմավարությունն է, որը թույլ է տալիս աշխատել գործընկերների և հաճախորդների հետ շահած-շահող ռեժիմով: Դուք կարող եք վիճել դրա հետ, բայց մոտավորապես այսպես է ընկերությունն ինքն իրեն գովազդում.
1C-ի բոլոր պահանջները կամ ցանկությունները որպես շրջանակ պետք է դիտարկվեն բացառապես այս պրիզմայով: «Մենք ուզում ենք OOP 1C-ում», - ասում են մշակողները: «Որքա՞ն կարժենա մեզ պլատֆորմում OOP-ի աջակցությունը, արդյո՞ք դա կօգնի մեզ ավելացնել արկղերի վաճառքը»: Բացում է բիզնես խնդիրների լուծումներ վաճառելու իր «պրիզմա».
- Հեյ, բիզնես, ուզու՞մ ես OOP քո 1C-ում:
-Սա ինձ կօգնի՞ լուծել իմ խնդիրները:
- Ով գիտի...
-Ուրեմն կարիք չկա
Այս մոտեցումը կարող է լինել լավ կամ վատ՝ կախված նրանից, թե ով է նայում դրան, բայց դա հենց այդպես է: Խոսելով այն մասին, որ 1C-ում X հատկանիշ չկա, դուք պետք է հասկանաք, որ այն չկա որևէ պատճառով, այլ «իրականացման արժեքը ընդդեմ շահույթի չափի» ընտրության համատեքստում:
Տեխնոլոգիական դասակարգում
«Իրականում, Օդինեսնիկներն անում են ամեն ինչ, որպեսզի օգտագործեն լավագույն նախշերը, որոնք խնամքով ընտրված են հոգատար մեթոդոլոգների և 1C հարթակի մշակողների կողմից:
Երբ գրում եք ձեր հիմար կոդը պարզ կառավարվող ձևի համար, իրականում դուք օգտագործում եք մոդել-դիտում-վերահսկիչ с երկկողմանի տվյալների կապում в եռաշերտ տվյալների հավելված-շարժիչ, համով բարձր մակարդակի օբյեկտ-հարաբերությունների քարտեզագրում հիմքի վրա դեկլարատիվ մետատվյալների նկարագրությունունենալով իր սեփականը հարթակից անկախ հարցման լեզու, C դեկլարատիվ տվյալների վրա հիմնված օգտատիրոջ միջերես, ամբողջական թափանցիկ սերիալացում և տիրույթի վրա հիմնված ծրագրային լեզու.Այն, որտեղ 1C մշակողները տարբերվում են իրենց արևմտյան գործընկերներից, PR-ում է: Նրանք սիրում են ցանկացած հիմարության մեծ անուն տալ և կեղտոտ պայուսակի պես վազվզել դրանով»։
Ա.Օրեֆկով
1C հարթակն ունի դասական 3-աստիճան ճարտարապետություն, որի կենտրոնում կիրառական սերվերն է (կամ դրա նմանակումը փոքր խանութպանների համար փոքր գումարի դիմաց): Կամ MS SQL կամ Postgres օգտագործվում է որպես DBMS: Աջակցություն կա նաև Oracle-ի և IBM DB2-ի համար, բայց դա բավականին էզոտերիկ է, ոչ ոք չգիտի, թե ինչ կլինի, եթե 1C-ն ներդնեք այս տվյալների բազաներում միջին և բարձր ծանրաբեռնվածության ներքո: Ես կարծում եմ, որ 1C-ն ինքն էլ չգիտի դա:
Հաճախորդի մասը կա՛մ օգտագործողի մեքենայի վրա տեղադրված բարակ հաճախորդ է, կա՛մ վեբ-հաճախորդ: Հիմնական առանձնահատկությունն այն է, որ ծրագրավորողները չեն գրում 2 տարբեր կոդ, նրանք գրում են մեկ հավելված, մեկ լեզվով, իսկ ցանկության կամ անհրաժեշտության դեպքում այն կարող եք ցուցադրել բրաուզերում։ Ո՞վ էր այնտեղ ուզում իրական ամբողջական փաթեթ և մեկ լեզու առջևի և հետևի, node.js-ի համար: Նրանք երբեք չեն կարողացել ճիշտ նույն բանն անել մինչև վերջ։ Իրական ամբողջական փաթեթ գոյություն ունի, բայց դուք պետք է այն գրեք 1C-ով: Ճակատագրի հեգնանք, նման բաներ :)
Cloud SaaS լուծումը 1C:Fresh աշխատում է նաև բրաուզերի ռեժիմում, որում դուք չեք կարող գնել 1C, այլ վարձել փոքր տվյալների բազա և հետևել այնտեղ շաուրմայի վաճառքին: Պարզապես բրաուզերում, առանց որևէ բան տեղադրելու կամ կազմաձևելու:
Բացի այդ, կա ժառանգական հաճախորդ, որը 1C-ում կոչվում է «սովորական հավելված»: Legacy-ը ժառանգություն է, բարի գալուստ 2002 թվականին հավելվածների աշխարհ, բայց մենք դեռ խոսում ենք էկոհամակարգի ներկայիս վիճակի մասին:
1C սերվերի մասն աջակցում է կլաստերավորմանը և մասշտաբներին՝ նոր մեքենաներ ավելացնելով կլաստերին: Այստեղ բավականին շատ օրինակներ են կոտրվել, և այս մասին հոդվածում առանձին բաժին կլինի։ Մի խոսքով, սա այնքան էլ նույնը չէ, ինչ HAProxy-ի հետևում մի քանի ճիշտ նույն օրինակ ավելացնելը:
Հավելվածի մշակման շրջանակն օգտագործում է իր ծրագրավորման լեզուն, որը մոտավորապես նման է մի փոքր բարելավված VB6-ի՝ թարգմանված ռուսերեն: Մարդկանց համար, ովքեր ատում են ամեն ինչ ռուսերենը, ովքեր չեն հավատում, որ «եթե»-ն թարգմանվում է որպես «եթե», առաջարկվում է երկրորդ շարահյուսական տարբերակը: Նրանք. Ցանկության դեպքում կարող եք գրել 1C-ով այնպես, որ VB-ից չտարբերվի։
Հենց այս ծրագրավորման լեզուն է 1C մականունների ատելության հիմնական պատճառը իրենց հարթակի նկատմամբ։ Եկեք ընդունենք, ոչ առանց պատճառի: Լեզուն ստեղծվել է հնարավորինս պարզ, որը նախատեսված է «ՄՇԱԿԱՐԱՐՆԵՐ, ՄՇԱԿԱՐԱՐՆԵՐ» մանտրան գոնե ԱՊՀ-ում իրականացնելու համար: Նման լուծման կոմերցիոն էությունը, իմ կարծիքով, հստակ երևում է՝ ավելի շատ մշակողներ, շուկայի ավելի մեծ ծածկույթ։ Սա իրականություն դարձավ, տարբեր գնահատականներով՝ 45%-ից մինչև 95%: Ես անմիջապես կասեմ, որ ձեր կարծիքով ձեր լեզվով գրելն իսկապես ավելի հեշտ է: Իսկ ես բավականին շատ ծրագրավորման լեզուներ գիտեմ։
Սկսենք լեզվից։
1C ծրագրավորման լեզու
Միևնույն ժամանակ համակարգի ուժեղ և թույլ կողմը. Ապահովում է հեշտ մուտք և ընթեռնելիություն: Մյուս կողմից, այն չի թարմացվել 8 թվականին 2002-րդ տարբերակի թողարկումից հետո և բարոյապես հնացած է: Ինչ-որ մեկը կասի «հիմնական թերությունն այն է, որ OOP չկա», և նրանք սխալ կլինեն: Նախ, PLO-ն չի սիրում ոչ միայն Նուրալիևին, այլև Տորվալդսին։ Եվ երկրորդը, OOP-ը դեռ գոյություն ունի:
Մշակողի տեսանկյունից նա իր տրամադրության տակ ունի DBMS-ում ցուցադրվող բազային դասերով շրջանակ: Մշակողը կարող է վերցնել «Directory» բազային դասը և դրանից ժառանգել «Clients» գրացուցակը: Այն կարող է դրան ավելացնել դասի նոր դաշտեր, օրինակ՝ INN և Address, ինչպես նաև, անհրաժեշտության դեպքում, կարող է փոխարինել (վերագրանցել) բազային դասի մեթոդները, օրինակ՝ OnWrite/AtRecord մեթոդը։
Շրջանակը նախագծված է այնպես, որ ավելի խորը ժառանգություն հազվադեպ է անհրաժեշտ, իսկ OOP-ում սահմանափակումը, իմ կարծիքով, իմաստ ունի: 1C-ն կենտրոնանում է տիրույթի վրա հիմնված զարգացման վրա և ստիպում է ձեզ մտածել, առաջին հերթին, մշակվող լուծման թեմայի շուրջ, և դա լավ է: Չկա ոչ միայն գայթակղություն, այլև կարիք չկա գրել 10 տարբեր DTO-ներ և ViewModels՝ պարզապես ինչ-որ տեղ տիրույթից որոշ տվյալներ ցուցադրելու համար։ 1C ծրագրավորողը միշտ գործում է մեկ սուբյեկտի հետ՝ առանց ընկալման ենթատեքստը խառնելու նմանատիպ անուններով տասնյակ դասերի, որոնք ներկայացնում են նույն էությունը, բայց այլ կողմից: Ցանկացած .NET հավելված, օրինակ, անպայման պետք է պարունակի հինգ կամ երկու ViewModels և DTO-ներ՝ JSON-ում սերիալիզացիայի և հաճախորդից սերվեր տվյալների փոխանցման համար: Եվ ձեր դիմումի կոդի մոտավորապես 10-15%-ը կծախսվի տվյալներ մի դասից մյուսը փոխանցելու վրա՝ օգտագործելով AutoMapper-ի նման գրիչներ կամ հենակներ: Այս կոդը պետք է գրվի, և ծրագրավորողները պետք է վճարվեն այն ստեղծելու և պահպանելու համար:
Պարզվում է, որ 1C լեզուն դժվար է զարգանալ՝ առանց այն բարդացնելու հիմնական լեզուների մակարդակին՝ այդպիսով կորցնելով պարզության առավելությունը։ Ո՞րն է վաճառողի խնդիրը, ըստ էության, լուծվում է. թողարկել ստանդարտ լուծում, որը փողոցում բռնված ցանկացած ուսանող կարող է հարմարեցնել որակի պահանջվող մակարդակին (այսինքն՝ ավարտված է կրպակից մինչև մեծ գործարան ծածկող գործը): Եթե դուք կրպակ եք, վերցրեք ուսանող, եթե գործարան եք, վերցրեք գուրու ձեր իրականացնող գործընկերոջից: Այն, որ իրականացնող գործընկերները ուսանողներին վաճառում են գուրուի գնով, շրջանակի խնդիր չէ: Ճարտարապետական առումով շրջանակը պետք է լուծի երկուսի խնդիրները, ստանդարտ կոնֆիգուրացիաների ծածկագիրը (որը մենք վաճառեցինք բիզնեսին հարմարեցման խոստումով) պետք է հասկանալի լինի ուսանողի համար, և գուրուն պետք է կարողանա հասկանալ այն, ինչ ուզում եք:
Այն, ինչ, իմ կարծիքով, իսկապես բացակայում է լեզվում, ինչը ստիպում է քեզ գրել ավելին, քան կարող էիր, դա այն է, ինչ վատնում է հաճախորդի վճարած ժամանակը։
- Մակարդակում մուտքագրելու հնարավորություն, օրինակ՝ TypeScript (արդյունքում՝ IDE-ում կոդերի վերլուծության ավելի զարգացած գործիքներ, վերաֆակտորինգ, ավելի քիչ վիրավորական խցանումներ)
Գործառույթների առկայությունը որպես առաջին կարգի օբյեկտներ: Մի փոքր ավելի բարդ հայեցակարգ, բայց սովորական կաթսայատան ծածկագրի քանակը կարող է զգալիորեն կրճատվել: Ուսանողի ըմբռնումը կոդը՝ IMHO, նույնիսկ կմեծանա ծավալի նվազման պատճառով - Ունիվերսալ հավաքածուի բառացիներ, սկզբնավորիչներ: Նույնը՝ նվազեցնելով կոդի քանակությունը, որը պետք է գրել և/կամ նայել աչքերով: Հավաքածուների լրացումը խլում է 9000C ծրագրավորման ժամանակի ավելի քան 1%-ը: Առանց շարահյուսական շաքարի սա գրելը երկար է, թանկ և սխալ: Ընդհանուր առմամբ, 1C լուծումներում LOC-ի քանակը գերազանցում է բոլոր հնարավոր սահմանները՝ համեմատած հասանելի բաց շրջանակների և, ընդհանուր առմամբ, ձեր ձեռնարկության բոլոր Java-ների հետ միասին: Լեզուն խոսուն է, և դա վերածվում է տվյալների, հիշողության, IDE արգելակների, ժամանակի, փողի...
- վերջապես կոնստրուկցիաներ Ես ունեմ վարկած, որ այս կոնստրուկցիան բացակայում է այն պատճառով, որ ռուսերեն հաջող թարգմանություն չեն գտել :)
- Սեփական տվյալների տեսակներ (առանց OOP), Type-ի անալոգներ VB6-ից: Այն թույլ կտա չտպել կառույցներ՝ օգտագործելով BSP-ի մեկնաբանությունները և այդ կառույցները կառուցող մոգական մեթոդները: Մենք ստանում ենք՝ ավելի քիչ կոդ, ակնարկ կետի միջոցով, խնդրի ավելի արագ լուծում, ավելի քիչ սխալներ՝ տառասխալների և կառուցվածքների բացակայող հատկությունների պատճառով: Այժմ օգտատերերի կառուցվածքների մուտքագրումն ամբողջությամբ պատկանում է Ստանդարտ ենթահամակարգի գրադարանի մշակող թիմին, որը, ի պատիվ իրեն, զգուշորեն գրում է մեկնաբանություններ անցած պարամետրային կառուցվածքների ակնկալվող հատկությունների վերաբերյալ:
- Վեբ հաճախորդի վրա ասինխրոն զանգերի հետ աշխատելիս շաքար չկա: «Callback-hell»՝ ProcessingNotifications-ի տեսքով, ժամանակավոր հենակ է, որն առաջացել է հիմնական բրաուզերների API-ի հանկարծակի փոփոխության հետևանքով, բայց դուք չեք կարող անընդհատ այսպես ապրել ավելի ու ավելի. Հիմնական IDE-ում այս պարադիգմային աջակցություն չավելացնեք, և ամեն ինչ ավելի վատթարանա:
Սա հրատապ խնդիրներից մեկն է, պարզ է, որ ցանկը կարող է շատ ավելի մեծ լինել, բայց չպետք է մոռանալ, որ սա դեռևս ընդհանուր նշանակության լեզու չէ, այն չի պահանջում բազմաթելային, լամբդա գործառույթներ, մուտք դեպի GPU և արագ: լողացող կետի հաշվարկներ. Սա բիզնես տրամաբանության սկրիպտավորման լեզու է:
Ծրագրավորողը, ով արդեն շատ է աշխատել այս լեզվով, նայում է js կամ c#, ձանձրանում է այս լեզվի շրջանակներում։ Դա փաստ է։ Նա զարգացման կարիք ունի։ Վաճառողի համար սանդղակի մյուս կողմում նշված հատկանիշների իրականացման ծախսերն են՝ ընդդեմ դրանց ներդրումից հետո եկամտի ավելացման: Այստեղ ես որևէ տեղեկություն չունեմ այն մասին, թե ինչն է ներկայումս գերակշռում ընկերության աչքում։
Զարգացման միջավայր
Այստեղ նույնպես գործերը հարթ չեն ընթանում։ Կան երկու զարգացման միջավայր. Առաջինը առաքման մեջ ներառված կոնֆիգուրատորն է: Երկրորդը Enterprise Development Tools միջավայրն է, կամ կարճ՝ EDT, որը մշակվել է Eclipse-ի հիման վրա։
Կազմաձևիչը ապահովում է զարգացման առաջադրանքների ամբողջական շրջանակ, աջակցում է բոլոր հնարավորություններին և հանդիսանում է շուկայի հիմնական միջավայրը: Այն նաև բարոյապես հնացած է, չի զարգանում, ըստ լուրերի, իր ներսում տեխնիկական պարտքի մեծության պատճառով։ Իրավիճակը կարող է բարելավվել՝ բացելով ներքին API (ընկերության տեսքով Ա.Օրեֆկովա կամ անկախ հիմունքներով), բայց դա այդպես չէ։ Պրակտիկան ցույց է տվել, որ համայնքը կգրի իր սեփական հնարավորությունները IDE-ում, քանի դեռ վաճառողը չի խանգարում: Բայց մենք ունենք այն, ինչ ունենք։ Կոնֆիգուրատորը հիանալի էր 2004-2005 թվականներին, շատ հիշեցնում էր այն ժամանակների Visual Studio-ն, որոշ տեղերում նույնիսկ ավելի սառն էր, բայց այն ժամանակներում խրված էր:
Բացի այդ, այդ ժամանակից ի վեր միջին ստանդարտ լուծույթի ծավալն աճել է մի քանի անգամ, և այսօր IDE-ն պարզապես չի կարողանում հաղթահարել կոդերի քանակությունը, որով սնվում է: Օգտագործելիությունը և վերամշակման հնարավորությունները նույնիսկ զրոյական չեն, դրանք կարմիր են: Այս ամենը մշակողների մոտ խանդավառություն չի ավելացնում և նրանք երազում են տեղափոխվել այլ էկոհամակարգեր և շարունակել կոդավորել այնտեղ, բայց հաճելի միջավայրում, որն իր պահվածքով չի թքում քո երեսին։
Որպես այլընտրանք՝ առաջարկվում է զրոյից գրված IDE՝ կառուցված Eclipse-ի վրա։ Այնտեղ աղբյուրները, ինչպես ցանկացած այլ ծրագրաշարում, ապրում են տեքստային ֆայլերի տեսքով, պահվում են GIT-ում, քաշեք հարցումների ճյուղերը, այս ամենը։ Բացասական կողմն այն է, որ այն երկար տարիներ չի թողել բետա կարգավիճակը, չնայած յուրաքանչյուր թողարկումով այն ավելի լավ է դառնում: Ես չեմ գրի EDT-ի թերությունների մասին, այսօր դա մինուս է, վաղը դա ֆիքսված հատկություն է: Նման նկարագրության արդիականությունը արագ կվերանա: Այսօր հնարավոր է զարգանալ EDT-ում, բայց դա անսովոր է, որ դուք պետք է պատրաստ լինեք որոշակի թվով IDE սխալների:
Եթե նայեք իրավիճակին վերոհիշյալ «1C պրիզմայով», ապա կստանաք այսպիսի բան. նոր IDE-ի թողարկումը չի ավելացնում տուփերի վաճառքը, սակայն DEVELOPERS-ի արտահոսքը կարող է կրճատվել: Դժվար է ասել, թե ինչ է սպասվում էկոհամակարգին ծրագրավորողների հարմարավետության առումով, սակայն Microsoft-ն արդեն խաբել է բջջային ծրագրավորողներին՝ նրանց շատ ուշ առաջարկելով իր ծառայությունները:
Զարգացման կառավարում
Այստեղ ամեն ինչ զգալիորեն ավելի լավ է, քան կոդ գրելը, հատկապես վերջերս, երբ համայնքի ջանքերը ի հայտ բերեցին վարչարարության ավտոմատացման խնդիրները, գործարկվեցին նախատիպեր, որոնք կոչ էին անում նետել 1C պահեստը աղբակույտ և օգտագործել git, արագ մեղադրում, կոդի վերանայում: , ստատիկ վերլուծություն, ավտոմատ տեղակայում և այլն: Պլատֆորմին ավելացվել են բազմաթիվ գործառույթներ, որոնք բարձրացնում են զարգացման առաջադրանքների ավտոմատացման մակարդակը։ Այնուամենայնիվ, այս բոլոր հնարավորությունները ավելացվել են միայն և բացառապես մեր սեփական խոշոր արտադրանքի զարգացման համար, երբ ակնհայտ դարձավ, որ մենք չենք կարող անել առանց ավտոմատացման: Կային ավտոմատ միաձուլումներ, եռակողմ համեմատություն KDiff-ի հետ և այդ ամենը։ Գործարկվել է Github-ում , ով, անկեղծ ասած, գաղափարապես քաշվեց նախագծից , բայց փոփոխվել է վաճառող ընկերության գործընթացներին համապատասխանելու համար: Բաց կոդով աշխատող համառ տղաների շնորհիվ 1C-ում զարգացման ավտոմատացումը իջավ: Կազմաձևողի՝ IMHO-ի բաց API-ն նույնպես կփոխի հիմնական IDE-ի բարոյական հետամնացությունը:
Այսօր 1C աղբյուրները git-ում պահելով՝ Jira-ի խնդիրների հետ կապված պարտավորություններ, Crucible-ի ակնարկներ, Jenkins-ի կոճակը և Allure-ը հաղորդում են կոդի փորձարկման մասին 1C-ում և նույնիսկ: - սա հեռու է նորություններից, այլ ավելի շուտ հիմնական է այն ընկերություններում, որտեղ 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 գեներացիայի մասին։ Մենք չենք ասել, թե նույնիսկ որտեղից է այս օրինագիծը։ Web frontender-ը պետք է ստեղծի մի ձև, որտեղ օպերատորը կմտցնի տվյալները, backender-ը պետք է ստեղծի dto մոդելներ JSON-ի փոխանցման համար, տվյալների բազայում պահելու մոդելներ, տվյալների բազայի կառուցվածքը, միգրացիան դեպի այն, գրաֆիկական ձևավորում: ցուցադրել հենց այս հաշիվը, և միայն դրանից հետո՝ PDF: 1C-ում ամբողջ առաջադրանքը զրոյից ավարտվում է ուղիղ մեկ ժամում։
Փոքր տաղավարի լիարժեք հաշվառման համակարգ՝ մեկ գնված/վաճառված բիզնես գործընթացով, կատարվում է 3 ժամվա ընթացքում վաճառքի հաշվետվություններով, ապրանքների հաշվառում առք ու վաճառքի գներով՝ բաժանված ըստ պահեստի, մուտքի իրավունքների վերահսկման, վեբ հաճախորդի և բջջային հավելվածի: . Լավ, ես մոռացել էի դիմումի մասին, դիմումով ոչ թե 3 ժամից, այլ վեցից:
Որքա՞ն ժամանակ կպահանջվի այս առաջադրանքը .NET մշակողից մաքուր համակարգչի վրա տեսողական ստուդիա տեղադրելուց մինչև այն հաճախորդին ցուցադրելը: Ինչ վերաբերում է զարգացման ծախսերին: Նույն բանը.
1C-ի ուժեղ կողմերը որպես հարթակ
1C-ն ուժեղ է ոչ այն պատճառով, որ դրա մեջ ինչ-որ կոնկրետ բան կա, որը լավագույնն է աշխարհում: Ընդհակառակը, յուրաքանչյուր առանձին ենթահամակարգում դուք կարող եք գտնել ավելի հետաքրքիր անալոգային աշխարհի ծրագրային ապահովման մեջ: Այնուամենայնիվ, գործոնների համակցության հիման վրա ես չեմ տեսնում 1C-ի նման հարթակ: Այստեղ է կոմերցիոն հաջողությունը: Պլատֆորմի առավելությունները սփռված են ամբողջում և առավել հստակ տեսանելի են, երբ տեսնում եք, թե ինչպես է դա արվում այլ հարթակներում: Հիմնականում դրանք նույնիսկ հատկանիշներ ՉԵՆ, այլ ընդհակառակը` հատկանիշների մերժում` հօգուտ մեկ կոնկրետ պարադիգմայի: Մի քանի օրինակ.
- Յունիկոդ. Ինչ դժոխք կարող է լինել ավելի պարզ: 2019 թվականին մեկ բայթ ASCII կոդավորումներ օգտագործելու կարիք չկա (բացառությամբ հնագույն ժառանգականների հետ ինտեգրման): Երբեք: Բայց ոչ. Ինչևէ, ինչ-որ աղյուսակում ինչ-որ մեկը օգտագործում է մեկ բայթանոց varchar, և հավելվածը խնդիրներ կունենա կոդավորման հետ: 2015 թվականին gitlab-ի LDAP թույլտվությունը ձախողվեց կոդավորման հետ սխալ աշխատանքի պատճառով JetBrains IDE-ը դեռևս ամենուր չի աշխատում կիրիլիցայի հետ: 1C-ն ապահովում է կիրառական կոդի բարձրորակ մեկուսացում տվյալների բազայի շերտից: Այնտեղ անհնար է ցածր մակարդակով աղյուսակներ մուտքագրել, իսկ տվյալների բազայի մակարդակով ոչ կոմպետենտ կրտսերների խցանումները այնտեղ անհնար են։ Այո, կարող են լինել այլ խնդիրներ ոչ կոմպետենտ կրտսերների հետ կապված, բայց խնդիրների բազմազանությունը շատ ավելի փոքր է։ Այժմ դուք ինձ կասեք, որ ձեր հավելվածը ճիշտ է նախագծված, և տվյալների բազայի մուտքի շերտը մեկուսացված է այնպես, ինչպես հարկն է: Մեկ այլ հայացք գցեք ձեր կորպորատիվ մաքսային Java հավելվածին: Սերտորեն և անկեղծորեն: Ձեր խիղճը ձեզ խանգարու՞մ է։ Այդ դեպքում ես ուրախ եմ քեզ համար:
- Փաստաթղթերի/տեղեկատուների համարակալում. 1C-ում այն հաստատ ամենաճկունը չէ և լավագույնը չէ։ Բայց այն, ինչ նրանք անում են բանկային ծրագրերում և ինքնուրույն գրավոր հաշվապահական համակարգերում, դա պարզապես խավար է: Կամ ինքնությունը կխրվի մեջ (և հետո «օհ, ինչու մենք ունենք անցքեր»), կամ ընդհակառակը, նրանք կստեղծեն գեներատոր, որը կաշխատի DBMS մակարդակով կողպման միջոցով (և կդառնա խցան): Իրականում, բավականին դժվար է անել այս թվացյալ պարզ առաջադրանքը՝ սուբյեկտների վերջից մինչև վերջ հաշվարար, եզակիության բաժինով, որը հիմնված է որոշակի ստեղների վրա, նախածանցը, որպեսզի այն չարգելափակի տվյալների բազան զուգահեռ տվյալների մուտքագրման ժամանակ: .
- Տվյալների բազայի գրառումների նույնացուցիչները: 1C-ն ուժեղ կամքով որոշում կայացրեց՝ բոլոր հղումների նույնացուցիչները բացարձակապես սինթետիկ են, և վերջ: Եվ բաշխված տվյալների բազաների և փոխանակումների հետ կապված խնդիրներ չկան: Այլ համակարգերի մշակողները համառորեն ստեղծում են նույնականության նման մի բան (դա ավելի կարճ է), քաշեք դրանք GUI-ի մեջ, մինչև հասնի մի քանի հարակից օրինակներ ստեղծելու ժամանակը (և հետո դրանք կհայտնաբերվեն): Դուք չունե՞ք սա: Ազնվորեն?
- Ցուցակներ. 1C-ն ունի բավականին հաջող մեխանիզմներ՝ (մեծ) ցուցակներով էջեր անելու և դրանց միջով նավարկելու համար։ Թույլ տվեք անմիջապես վերապահում կատարել՝ մեխանիզմի ճիշտ օգտագործմամբ։ Ընդհանուր առմամբ, թեման բավականին տհաճ է, այն չի կարող լուծվել իդեալականորեն. այն կա՛մ ինտուիտիվ է և պարզ (բայց հաճախորդի վրա հսկայական գրառումների վտանգ է սպառնում), կա՛մ էջավորումն այս կամ այն ծուռ է: Փեյջինգ անողները հաճախ դա անում են ծուռումուռ։ Նրանք, ովքեր ստեղծում են ազնիվ ոլորման տող, ավելացնում են տվյալների բազա, ալիք և հաճախորդ:
- Կառավարվող ձևեր. Անկասկած, վեբ հաճախորդում ինտերֆեյսը կատարյալ չի աշխատում: Բայց դա աշխատում է: Բայց շատ այլ հաշվապահական և բանկային համակարգերի համար հեռավոր աշխատավայրի ստեղծումը ձեռնարկության մակարդակի նախագիծ է: Հրաժարում պատասխանատվությունից. բարեբախտաբար նրանց համար, ովքեր ի սկզբանե այն ստեղծել են համացանցում, դա չի ազդի:
- Բջջային հավելված. Վերջերս դուք կարող եք նաև բջջային հավելվածներ գրել նույն էկոհամակարգում գտնվելու ժամանակ: Այստեղ մի փոքր ավելի բարդ է, քան վեբ հաճախորդի դեպքում, սարքերի առանձնահատկությունները ստիպում են ձեզ գրել հատուկ նրանց համար, բայց, այնուամենայնիվ, դուք չեք վարձում բջջային ծրագրավորողների առանձին թիմ. Եթե Ձեզ անհրաժեշտ է հավելված՝ ընկերության ներքին կարիքների համար (երբ կորպորատիվ խնդրի բջջային լուծումն ավելի կարևոր է, քան դեղին միջերեսային դիզայնը), դուք պարզապես օգտագործում եք նույն հարթակը առանց տուփի:
- Հաշվետվություն. Այս բառով ես նկատի չունեմ BI համակարգ մեծ տվյալներով և ETL գործընթացի հետաձգմամբ: Խոսքը վերաբերում է գործառնական անձնակազմի հաշվետվություններին, որոնք թույլ են տալիս գնահատել հաշվապահական հաշվառման վիճակը այստեղ և հիմա: Մնացորդներ, փոխադարձ հաշվարկներ, վերագնահատումներ և այլն: 1C-ը տուփից դուրս է գալիս հաշվետվական համակարգով՝ խմբավորումների, ֆիլտրերի և օգտագործողի կողմից արտացոլման ճկուն պարամետրերով: Այո, շուկայում կան ավելի սառը անալոգներ: Բայց ոչ համընդհանուր լուծման շրջանակներում և երբեմն ավելի բարձր գնով, քան համընդհանուր լուծումը: Եվ ավելի հաճախ դա նույնիսկ հակառակն է՝ միայն հաշվետվություն, բայց ավելի թանկ, քան ամբողջ հարթակը և որակով ավելի վատ:
- Տպագրելի ձևեր. Դե, օգտագործեք .NET-ը, որպեսզի լուծեք աշխատողներին էլ. Իսկ հիմա հաշիվ-ապրանքագրեր տպելու խնդիրը։ Ի՞նչ կասեք դրանց պատճենները նույն PDF-ում պահելու մասին: 1C մականվան համար PDF-ի ցանկացած դասավորություն դուրս բերելը կոդ է +1 տող: Սա նշանակում է + 40 վայրկյան աշխատանքային ժամանակ՝ այլ լեզվով օրերի կամ շաբաթների փոխարեն: Տպագիր ձևերի դասավորությունները 1C-ում աներևակայելի հեշտ է մշակվում և բավականաչափ հզոր՝ վճարովի գործընկերների հետ մրցելու համար: Այո, հավանաբար, 1C աղյուսակային փաստաթղթերում շատ ինտերակտիվ հնարավորություններ չկան, դուք չեք կարող արագորեն ստանալ 3D դիագրամ մասշտաբով, օգտագործելով OpenGL: Բայց արդյո՞ք դա իսկապես անհրաժեշտ է:
Սրանք ընդամենը մի քանի օրինակ են, որտեղ ֆունկցիոնալությունը սահմանափակելը կամ փոխզիջումների իրականացումը պարզվում է, որ ապագայում կարևոր ճարտարապետական առավելություն է: Անգամ փոխզիջումային կամ ոչ ամենաարդյունավետ տարբերակը՝ այն արդեն տուփի մեջ է և ընկալվում է որպես ինքնին: Դրա ինքնուրույն իրականացումը կամ անհնար կլինի (որովհետև նման որոշումներ պետք է կայացվեն նախագծի սկզբում, և դրա համար ժամանակ չկա, և ընդհանրապես ճարտարապետ չկա), կամ մի քանի թանկարժեք կրկնություններ։ Թվարկված կետերից յուրաքանչյուրում (և սա ճարտարապետական լուծումների ամբողջական ցանկը չէ), կարող եք խեղաթյուրել և սահմանել սահմանափակումներ, որոնք արգելափակում են մասշտաբը: Ամեն դեպքում, դուք, որպես գործարար, պետք է համոզվեք, որ ձեր ծրագրավորողները, «զրոյից համակարգ» ստեղծելիս, ուղիղ ձեռքեր ունենան և անմիջապես լավ կլուծեն համակարգի նուրբ խնդիրները:
Այո, ինչպես ցանկացած այլ բարդ համակարգում, 1C-ն ինքնին նույնպես ունի լուծումներ, որոնք արգելափակում են մասշտաբը որոշակի առումներով: Սակայն, կրկնում եմ, ելնելով գործոնների համակցումից, սեփականության արժեքից և նախապես արդեն լուծված խնդիրների քանակից, ես շուկայում արժանի մրցակից չեմ տեսնում։ Նույն գնով դուք ստանում եք ֆինանսական հավելվածի շրջանակ, կլաստերային հավասարակշռված սերվեր, UI և վեբ ինտերֆեյսով, բջջային հավելվածով, հաշվետվություններով, ինտեգրմամբ և մի շարք այլ բաներով: Java-ի աշխարհում դուք վարձում եք առաջնային և հետևի թիմեր, վրիպազերծում եք տնային գրված սերվերի կոդի ցածր մակարդակի վրա և վճարում եք առանձին 2 բջջային հավելվածի համար 2 բջջային ՕՀ-ի համար:
Ես չեմ ասում, որ 1C-ն կլուծի բոլոր գործերը, բայց ներքին կորպորատիվ հավելվածի համար, երբ կարիք չկա բրենդավորելու UI-ն, էլ ի՞նչ է պետք:
Fly է քսուք
Հավանաբար ձեզ մոտ տպավորություն է ստեղծվել, որ 1C-ը կփրկի աշխարհը, և որ կորպորատիվ համակարգեր գրելու մյուս բոլոր եղանակները սխալ են: Դա ամենևին էլ այդպես չէ։ Գործարարի տեսանկյունից, եթե դուք ընտրում եք 1C, ապա ի լրումն արագ շուկայավարման ժամանակի, դուք պետք է հաշվի առնեք հետևյալ թերությունները.
- Սերվերի հուսալիություն. Պահանջվում են իսկապես բարձրակարգ մասնագետներ, ովքեր կարող են ապահովել դրա անխափան շահագործումը։ Ես տեղյակ չեմ վաճառողի կողմից նման մասնագետների վերապատրաստման պատրաստի ծրագրի մասին: Փորձագիտական քննությանը պատրաստվելու դասընթացներ կան, բայց դա, իմ կարծիքով, բավարար չէ։
- Աջակցություն. Տես նախորդ կետը: Վաճառողի կողմից աջակցություն ունենալու համար դուք պետք է գնեք այն: Ինչ-ինչ պատճառներով դա ընդունված չէ 1C արդյունաբերության մեջ: Իսկ SAP-ի դեպքում դա գրեթե պարտադիր գնում է, և դա ոչ մեկին չի անհանգստացնում: Առանց կորպորատիվ աջակցության և առանց անձնակազմի փորձագետի, դուք կարող եք մենակ մնալ 1C խափանումների հետ:
- Այնուամենայնիվ, դուք չեք կարող բացարձակապես ամեն ինչ անել 1C-ով: Սա գործիք է և ինչպես յուրաքանչյուր գործիք, այն ունի կիրառելիության սահմաններ: 1C լանդշաֆտում շատ ցանկալի է ունենալ «ոչ 1C» համակարգի ճարտարապետ։
- Լավ 1C մականուններն ավելի էժան չեն, քան այլ լեզուներով լավ ծրագրավորողները: Չնայած վատ ծրագրավորողներին վարձելը թանկ արժե՝ անկախ նրանից, թե ինչ լեզվով են գրում:
Եկեք կետավորենք կետերը
- 1C-ը բիզնեսի համար կիրառման արագ մշակման (RAD) շրջանակ է և նախատեսված է դրա համար:
- Եռաստիճան հղում՝ հիմնական DBMS-ների, հաճախորդի UI-ի, շատ լավ 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 մականունը կարող է ապահով նշանակվել առաջատար վերլուծաբանների պաշտոնում: Առաջադրանքի, առարկայի տարածքի և տարրալուծման հմտությունների նրանց ըմբռնումը գերազանց է: Համոզված եմ, որ դա հենց պայմանավորված է 1C մշակման մեջ DDD-ի հարկադիր կիրառմամբ։ Մարդը վարժված է մտածելու առաջադրանքի իմաստի մասին առաջին հերթին, առարկայական ոլորտի օբյեկտների միջև կապերի մասին, և միևնույն ժամանակ ունի տեխնիկական նախապատմություն ինտեգրացիոն տեխնոլոգիաների և տվյալների փոխանակման ձևաչափերում:
Տեղյակ եղեք, որ իդեալական շրջանակ գոյություն չունի և հոգ տանեք ձեր մասին:
Լավ բոլորի համար:
Հ.Գ.: Շատ շնորհակալ եմ հոդվածի պատրաստման հարցում օգնության համար։
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Ձեր ձեռնարկությունում ունե՞ք 1C:
-
13,3%Ամենևին.71
-
30,3%Կա, բայց միայն հաշվապահությունում ինչ-որ տեղ։ Հիմնական համակարգեր այլ հարթակներում162
-
41,4%Այո, դրա վրա աշխատում են հիմնական բիզնես գործընթացները221
-
15,0%1C-ը պետք է մեռնի, ապագան պատկանում է %technology_name%80-ին
Քվեարկել է 534 օգտատեր։ 99 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com