1C - nzuri na mbaya. Mpangilio wa pointi katika holivars karibu 1C

Marafiki na wafanyakazi wenzetu, hivi majuzi kumekuwa na makala za mara kwa mara kuhusu Habré zenye chuki dhidi ya 1C kama jukwaa la maendeleo, na hotuba za watetezi wake. Nakala hizi ziligundua shida moja kubwa: mara nyingi, wakosoaji wa 1C wanaikosoa kutoka kwa msimamo wa "kutoijua", wakikemea shida ambazo zinatatuliwa kwa urahisi, na, kinyume chake, bila kugusa shida ambazo ni muhimu sana, zenye thamani. kujadili na si kutatuliwa na muuzaji. Ninaamini kuwa inaleta maana kufanya ukaguzi wa kina na sawia wa jukwaa la 1C. Kinachoweza kufanya, kisichoweza kufanya, kile kinachopaswa kufanya lakini hakifanyi, na, kwa dessert, kile kinachofanya na mshindo, na watengenezaji wako katika %technology_name% watafanya miaka mia moja, wakiitupa. zaidi ya bajeti moja ya mwaka.

Matokeo yake, wewe, kama meneja au mbunifu, utaweza kupata ufahamu wazi wa kazi gani itakuwa ya manufaa kwako kutumia 1C, na ambapo inahitaji kuchomwa na chuma cha moto. Kama msanidi programu katika ulimwengu wa "non-1C", utaweza kuona ni nini kilichopo katika 1C ambacho kinasababisha fujo. Na kama msanidi wa 1C, utaweza kulinganisha mfumo wako na mifumo ikolojia ya lugha zingine na kuelewa eneo lako katika mfumo wa kuratibu wa ukuzaji wa programu.

Chini ya kukata kuna mashambulizi mengi ya nene kwenye 1C, kwa wakosoaji wa 1C, kwenye Java, .NET na kwa ujumla ... Shabiki amejaa, karibu!

Kuhusu mimi mwenyewe

Nimekuwa nikifahamu mada ya mazungumzo tangu takriban 2004. Nimekuwa nikitayarisha programu labda tangu nilipokuwa na umri wa miaka 6, tangu wakati nilipopata kitabu kuhusu Profesa Fortran kilicho na vichekesho kuhusu paka, shomoro na kiwavi. Nilichambua programu ambazo paka iliandika kutoka kwa picha kwenye kitabu na kujua walichofanya. Na ndiyo, sikuwa na kompyuta halisi wakati huo, lakini kulikuwa na mchoro kwenye kuenea kwa kitabu na kwa uaminifu nilisisitiza vifungo vya karatasi, nikiingiza amri nilizozipeleleza kwenye paka X.

Kisha kulikuwa na BK0011 na BASIC shuleni, C ++ na wakusanyaji katika chuo kikuu, kisha 1C, na kisha mambo mengine mengi ambayo mimi ni mvivu sana kukumbuka. Kwa miaka 15 iliyopita, nimehusika hasa katika 1C, si tu kwa suala la kuandika, lakini kwa 1C kwa ujumla. Kuweka kazi, utawala na devops hapa. Kwa miaka 5 iliyopita nimekuwa nikijishughulisha na shughuli muhimu za kijamii katika suala la kukuza zana za ukuzaji na otomatiki kwa watumiaji wengine wa 1C, kuandika nakala na vitabu.

Wacha tuamue juu ya mada ya majadiliano

Kwanza, hebu tufafanue kile ambacho tutazungumzia, kwa kuwa barua "1C" zinaweza kumaanisha mambo mengi. Katika kesi hii, kwa herufi "1C" tutamaanisha mfumo wa maendeleo "1C: Enterprise" wa toleo la kisasa na la nane. Hatutazungumza sana juu ya mtengenezaji na sera zake (lakini tutalazimika kufanya kidogo). Teknolojia ni tofauti, maombi aka usanidi ni tofauti.

Usanifu wa hali ya juu 1C: Biashara

Sio bure kwamba ninataja neno "mfumo". Kwa mtazamo wa msanidi programu, jukwaa la 1C ni mfumo haswa. Na unahitaji kutibu kama mfumo. Ifikirie kama Spring au ASP.NET, iliyotekelezwa na wakati fulani wa kukimbia (JVM au CLR mtawalia). Inatokea kwamba katika ulimwengu wa programu za kawaida ("sio 1C"), mgawanyiko katika mifumo, mashine halisi na matumizi maalum ni ya asili, kwa sababu ya ukweli kwamba vipengele hivi kawaida hutengenezwa na wazalishaji tofauti. Katika ulimwengu wa 1C, sio kawaida kutofautisha kwa uwazi mfumo wa maendeleo na wakati wa kukimbia yenyewe, kwa kuongeza, maombi maalum yaliyoandikwa kwa kutumia mfumo pia yanatengenezwa hasa na 1C yenyewe. Matokeo yake, mkanganyiko fulani hutokea. Kwa hivyo, ndani ya mfumo wa kifungu, tutalazimika kuzingatia 1C kutoka pande kadhaa mara moja na kuainisha pamoja na axes kadhaa za kuratibu. Na katika kila mhimili wa kuratibu tutaweka koleo la dutu ya kahawia na kuangalia vipengele, faida na hasara za ufumbuzi uliopo.

Maoni juu ya 1C

1C kwa mnunuzi

Mnunuzi anunua mfumo wa otomatiki ambao anaweza kutatua haraka shida za otomatiki biashara yake mwenyewe. Biashara inaweza kuwa duka ndogo, au inaweza kuwa kampuni kubwa. Ni wazi kwamba mahitaji ya biashara hizi ni tofauti, lakini zote mbili zinaungwa mkono na msingi mmoja wa msimbo wa jukwaa.

Kwa mnunuzi wa 1C hii ni wakati wa haraka wa soko. Haraka. Haraka kuliko Java, C# au JS. Wastani. Karibu na hospitali. Ni wazi kwamba tovuti ya kadi ya biashara inayotumia React itakuwa bora zaidi, lakini mfumo wa nyuma wa WMS utazinduliwa kwa kasi zaidi kwenye 1C.

1C kama chombo

Kila suluhisho la kiteknolojia lina mipaka ya utumiaji. 1C sio lugha ya kusudi la jumla; haiishi tofauti na mfumo wake. Inashauriwa kutumia 1C wakati unahitaji:

• programu ya seva
• maombi ambapo fedha zinaonekana
• na UI iliyotengenezwa tayari, ORM, Kuripoti, XML/JSON/COM/PDF/YourDataTransferingFormat
• kwa usaidizi wa michakato ya nyuma na kazi
• na usalama wa msingi wa jukumu
• na mantiki ya biashara inayoweza kuandikwa
• na uwezo wa kuunda haraka mfano na wakati wa chini wa soko

Huhitaji 1C ikiwa unataka:

• kujifunza mashine
• Mahesabu ya GPU
• michoro za kompyuta
• mahesabu ya hisabati
• Mfumo wa CAD
• usindikaji wa ishara (sauti, video)
• pakia simu za http na mamia ya maelfu ya rps

1C kama kampuni ya utengenezaji

Inafaa kuelewa ni nini biashara ya 1C kama mtengenezaji wa programu ni. Kampuni ya 1C huuza suluhu za matatizo ya biashara kwa njia ya otomatiki. Biashara tofauti, kubwa au ndogo, lakini ndivyo anauza. Njia za kufikia lengo hili ni maombi ya biashara. Kwa uhasibu, uhasibu wa mishahara, n.k. Kuandika maombi haya, kampuni hutumia jukwaa lake la kukuza maombi ya biashara. Imeundwa mahsusi kwa kazi za kawaida za programu hizi hizi za biashara:

• uhasibu wa kifedha
• ubinafsishaji rahisi wa mantiki ya biashara
• uwezekano mpana wa ujumuishaji katika mandhari tofauti za IT

Kama mtengenezaji, 1C inaamini kuwa huu ndio mkakati unaokuruhusu kufanya kazi na washirika na wateja katika hali ya kushinda-kushinda. Unaweza kubishana na hili, lakini hii ni takriban jinsi kampuni inajitangaza yenyewe: suluhisho zilizotengenezwa tayari kwa shida za biashara ambazo zinaweza kubinafsishwa haraka na washirika na kuunganishwa katika mazingira yoyote ya IT.

Madai au matakwa yote ya 1C kama mfumo yanapaswa kutazamwa pekee kupitia prism hii. "Tunataka OOP katika 1C," watengenezaji wanasema. "Itatugharimu kiasi gani kusaidia OOP kwenye jukwaa, hii itatusaidia kuongeza mauzo ya masanduku?" inasema 1C. Hufungua "prism" yake ya kuuza suluhisho kwa shida za biashara:

- Hujambo, biashara, unataka OOP katika 1C yako?
- Je, hii itanisaidia kutatua matatizo yangu?
- Nani anajua...
- Kisha hakuna haja

Mbinu hii inaweza kuwa nzuri au mbaya kulingana na nani anayeitazama, lakini ndivyo ilivyo. Kuzungumza juu ya ukweli kwamba hakuna kipengele X katika 1C, unahitaji kuelewa kuwa haipo kwa sababu, lakini katika muktadha wa chaguo "gharama ya utekelezaji dhidi ya kiasi cha faida".

Uainishaji wa kiteknolojia

"Kwa kweli, Odinesniks hufanya kazi nzuri zaidi kutumia mifumo bora, iliyochaguliwa kwa uangalifu na wataalamu wa mbinu na watengenezaji wa jukwaa la 1C.
Unapoandika msimbo wako wa kijinga kwa fomu rahisi inayodhibitiwa, kwa kweli unatumia mfano-mtazamo-mtawala с kuunganisha data kwa njia mbili в Injini ya programu ya data ya tabaka tatu, yenye ladha kiwango cha juu cha ramani ya uhusiano wa kitu kwenye msingi maelezo ya metadata ya kutangazakuwa na yake lugha ya swali inayojitegemea, C kiolesura cha kutangaza kinachoendeshwa na data, uratibu kamili wa uwazi na lugha ya programu inayolenga kikoa.

Ambapo wasanidi wa 1C hutofautiana na wenzao wa Magharibi ni katika PR. Wanapenda kupeana ujinga wowote jina kubwa na kukimbia nalo kama mfuko mchafu.”
A. Orefkov

Jukwaa la 1C lina usanifu wa kiwango cha 3-tier, katikati ambayo ni seva ya maombi (au uigaji wake wa pesa kidogo kwa wauzaji wadogo). Aidha MS SQL au Postgres inatumika kama DBMS. Pia kuna msaada kwa Oracle na IBM DB2, lakini hii ni badala ya esoteric; Ninaamini kuwa 1C yenyewe haijui hili.

Sehemu ya mteja ama ni mteja mwembamba aliyesakinishwa kwenye mashine ya mtumiaji au mteja wa wavuti. Kipengele muhimu ni kwamba waandaaji wa programu hawaandiki nambari 2 tofauti, wanaandika programu moja, kwa lugha moja, na unaweza kuionyesha kwenye kivinjari ikiwa kuna tamaa au haja. Nani pale alitaka mrundikano kamili wa kweli na lugha moja ya mandhari ya mbele na ya nyuma, node.js? Hawakuweza kufanya kitu kile kile hadi mwisho. Rafu kamili ipo, lakini itabidi uandike katika 1C. Kejeli ya hatima, vitu kama hivyo :)

Suluhisho la SaaS la wingu 1C:Fresh pia hufanya kazi katika hali ya kivinjari, ambayo huwezi kununua 1C, lakini ukodisha hifadhidata ndogo na ufuatilie mauzo ya shawarma huko. Katika kivinjari tu, bila kusakinisha au kusanidi chochote.

Kwa kuongeza, kuna mteja wa urithi, ambayo katika 1C inaitwa "maombi ya kawaida". Urithi ni urithi, karibu kwa ulimwengu wa maombi mnamo 2002, lakini bado tunazungumza juu ya hali ya sasa ya mfumo ikolojia.

Sehemu ya seva ya 1C inasaidia kuunganisha na mizani kwa kuongeza mashine mpya kwenye nguzo. Nakala nyingi zimevunjwa hapa na kutakuwa na sehemu tofauti katika makala kuhusu hili. Kwa kifupi, hii si sawa na kuongeza matukio kadhaa sawa nyuma ya HAProxy.

Mfumo wa ukuzaji wa programu hutumia lugha yake ya programu, ambayo inafanana na VB6 iliyoboreshwa kidogo iliyotafsiriwa kwa Kirusi. Kwa watu wanaochukia kila kitu Kirusi, ambao hawaamini kwamba "ikiwa" inatafsiriwa kama "ikiwa," chaguo la pili la syntax hutolewa. Wale. Ukipenda, unaweza kuiandika katika 1C kwa njia ambayo haiwezi kutofautishwa na VB.

Lugha hii ya programu ndiyo sababu kuu ya chuki ya lakabu za 1C kuelekea jukwaa lao. Wacha tukabiliane nayo, sio bila sababu. Lugha ilichukuliwa kwa urahisi iwezekanavyo, iliyoundwa ili kutimiza mantra "WAENDELEZI, WAENDELEAJI" kwa kiwango angalau katika CIS. Kiini cha kibiashara cha suluhisho kama hilo, kwa maoni yangu, kinaonekana wazi: watengenezaji zaidi, chanjo kubwa zaidi ya soko. Hii ilitimia, kulingana na makadirio anuwai kutoka 45% hadi 95%. Nitasema mara moja kwamba kuandika kwa lugha unayofikiria ni rahisi sana. Na ninajua lugha nyingi za programu.

Hebu tuanze na lugha.

1C lugha ya programu

Wakati huo huo hatua kali na dhaifu ya mfumo. Hutoa kuingia kwa urahisi na kusomeka. Kwa upande mwingine, haijasasishwa tangu kutolewa kwa toleo la 8 mwaka wa 2002 na imepitwa na wakati kimaadili. Mtu atasema "kikwazo kuu ni kwamba hakuna OOP" na watakuwa na makosa. Kwanza, PLO haipendi tu Nuraliev, bali pia Torvalds. Na pili, OOP bado ipo.

Kwa mtazamo wa msanidi programu, ana mfumo wake na madarasa ya msingi yaliyoonyeshwa kwenye DBMS. Msanidi programu anaweza kuchukua "Saraka" ya darasa la msingi na kurithi saraka ya "Wateja" kutoka kwayo. Inaweza kuongeza sehemu za darasa mpya kwake, kwa mfano, INN na Anwani, na pia, ikiwa ni lazima, inaweza kubatilisha (kufuta) mbinu za darasa la msingi, kwa mfano njia ya OnWrite/AtRecord.

Mfumo umeundwa kwa njia ambayo urithi wa kina hauhitajiki sana, na kizuizi katika OOP, kwa maoni yangu, kina mantiki. 1C inazingatia Maendeleo ya Kikoa na inakufanya ufikirie, kwanza kabisa, juu ya eneo la somo la suluhisho linalotengenezwa, na hii ni nzuri. Hakuna tu majaribu, lakini pia hakuna haja ya kuandika DTO 10 tofauti na ViewModels ili tu kuonyesha data fulani kutoka kwa kikoa mahali fulani. Msanidi wa 1C daima hufanya kazi na chombo kimoja, bila kuunganisha muktadha wa mtazamo na madarasa kadhaa yenye majina sawa, yanayowakilisha huluki sawa, lakini kutoka upande tofauti. Programu yoyote ya .NET, kwa mfano, itakuwa lazima iwe na ViewModels tano au mbili na DTO kwa ufuataji katika JSON na uhamishaji wa data kutoka kwa mteja hadi seva. Na takriban 10-15% ya msimbo wako wa maombi itatumika kuhamisha data kutoka darasa moja hadi jingine kwa kutumia kalamu au mikongojo kama AutoMapper. Nambari hii lazima iandikwe na watayarishaji programu lazima walipwe ili kuunda na kudumisha.

Inabadilika kuwa lugha ya 1C ni ngumu kukuza bila kuifanya iwe ngumu kwa kiwango cha lugha za kawaida, na hivyo kupoteza faida ya unyenyekevu. Je, ni kazi gani ya muuzaji inasuluhishwa kimsingi: kutoa suluhu la kawaida ambalo mwanafunzi yeyote anayepatikana barabarani anaweza kubinafsisha kwa kiwango kinachohitajika cha ubora (yaani, kipochi kinachofunika kutoka kwa duka hadi kiwanda kikubwa kimekamilika). Ikiwa wewe ni duka, chukua mwanafunzi ikiwa wewe ni kiwanda, chukua guru kutoka kwa mshirika wako wa utekelezaji. Ukweli kwamba washirika wanaotekeleza huuza wanafunzi kwa bei ya guru sio tatizo na mfumo. Kwa usanifu, mfumo lazima utatue matatizo ya zote mbili, kanuni za usanidi wa kawaida (ambazo tuliuza kwa biashara kwa ahadi ya kubinafsisha) zinapaswa kueleweka na mwanafunzi, na guru anapaswa kuelewa chochote unachotaka.

Ni nini, kwa maoni yangu, kinachokosekana katika lugha, kinachokulazimisha kuandika zaidi ya vile unavyoweza, ndicho kinachopoteza wakati unaolipwa na mteja.

• Uwezekano wa kuchapa katika kiwango, kwa mfano, TypeScript (matokeo yake, zana zilizotengenezwa zaidi za uchanganuzi wa nambari katika IDE, kurekebisha tena, mikwaruzo machache ya kukera)
  Upatikanaji wa vitendaji kama vitu vya daraja la kwanza. Wazo changamano zaidi, lakini kiasi cha msimbo wa kawaida wa boilerplate kinaweza kupunguzwa sana. Uelewa wa mwanafunzi wa msimbo, IMHO, ungeongezeka hata kutokana na kupunguzwa kwa sauti
• Mkusanyiko wa maandishi halisi, vianzilishi. Jambo lile lile - kupunguza kiasi cha msimbo unaohitaji kuandikwa na/au kutazamwa kwa macho yako. Kujaza mikusanyiko huchukua zaidi ya 9000% ya muda wa utayarishaji wa 1C. Kuandika bila sukari ya kisintaksia ni ndefu, ghali na kuna makosa. Kwa ujumla, kiasi cha LOC katika suluhu za 1C huzidi mipaka yote inayowezekana ikilinganishwa na mifumo wazi inayopatikana na, kwa ujumla, Javas za biashara yako zote zikiwa pamoja. Lugha ni kitenzi, na hii hupungua hadi kiasi cha data, kumbukumbu, breki za IDE, wakati, pesa ...
• mwishowe ujenzi nina nadharia kwamba ujenzi huu haupo kwa sababu hawakupata tafsiri yake iliyofanikiwa kwa Kirusi :)
• Aina za data mwenyewe (bila OOP), analogi za Aina kutoka VB6. Itakuruhusu kutoandika miundo kwa kutumia maoni katika BSP na njia za uchawi zinazounda miundo hii. Tunapata: nambari ndogo, kidokezo kupitia nukta, suluhisho la haraka la shida, makosa machache kwa sababu ya makosa ya kuchapa na kukosa sifa za miundo. Sasa uchapaji wa miundo ya watumiaji hutegemea kabisa timu ya ukuzaji ya Maktaba ya Mfumo Ndogo wa Kawaida, ambayo, kwa deni lake, huandika kwa uangalifu maoni juu ya sifa zinazotarajiwa za miundo ya parameta iliyopitishwa.
• Hakuna sukari wakati wa kufanya kazi na simu za asynchronous kwenye mteja wa wavuti. callback-hell katika mfumo wa ProcessingNotifications ni njia ya muda inayosababishwa na mabadiliko ya ghafla katika API ya vivinjari vikuu, lakini huwezi kuishi hivi kila wakati; zaidi na zaidi. Usiunge mkono kwa dhana hii katika IDE kuu na mambo yanazidi kuwa mabaya zaidi.

Hili ni moja ya shida kubwa, ni wazi kuwa orodha inaweza kuwa kubwa zaidi, lakini hatupaswi kusahau kuwa hii bado sio lugha ya kusudi la jumla, hauitaji usomaji mwingi, kazi za lambda, ufikiaji wa GPU na haraka. mahesabu ya hatua ya kuelea. Hii ni lugha ya uandishi wa mantiki ya biashara.

Mpangaji programu ambaye tayari amefanya kazi nyingi na lugha hii, anaangalia js au c#, anachoshwa ndani ya mfumo wa lugha hii. Ni ukweli. Anahitaji maendeleo. Kwa upande mwingine wa kiwango cha muuzaji ni gharama ya kutekeleza vipengele vilivyoainishwa dhidi ya ongezeko la mapato baada ya utekelezaji wake. Hapa sina habari yoyote kuhusu kile ambacho kwa sasa kinazidi macho ya kampuni.

Mazingira ya maendeleo

Hapa pia mambo hayaendi sawa. Kuna mazingira mawili ya maendeleo. Ya kwanza ni Configurator iliyojumuishwa katika utoaji. Ya pili ni mazingira ya Zana za Maendeleo ya Biashara, au EDT kwa kifupi, iliyotengenezwa kwa msingi wa Eclipse.

Configurator hutoa aina kamili ya kazi za maendeleo, inasaidia vipengele vyote na ni mazingira kuu kwenye soko. Pia ni kizamani kimaadili, si kuendeleza, kulingana na uvumi - kutokana na kiasi cha madeni ya kiufundi ndani yake yenyewe. Hali inaweza kuboreshwa kwa kufungua API ya ndani (katika mfumo wa urafiki na Mtu wa theluji A. Orefkova au kwa misingi ya kujitegemea), lakini hii sivyo. Mazoezi yameonyesha kuwa jumuiya itaandika vipengele vyake katika IDE, mradi tu muuzaji asiingilie. Lakini tunacho tulichonacho. Configurator ilikuwa nzuri mnamo 2004-2005, ikikumbusha sana Visual Studio ya nyakati hizo, katika sehemu zingine ilikuwa baridi zaidi, lakini ilikuwa imekwama nyakati hizo.

Kwa kuongezea, kiasi cha suluhisho la wastani la kawaida limekua mara kadhaa tangu wakati huo, na leo IDE haiwezi kukabiliana na idadi ya nambari ambayo inalishwa. Usability na refactoring uwezo si hata sifuri, wao ni katika nyekundu. Yote hii haiongezi shauku kwa watengenezaji na wanaota ndoto ya kuhamia mifumo mingine ya ikolojia na kuendelea kuweka kificho huko, lakini katika mazingira mazuri ambayo hayatemei mate usoni mwako na tabia yake.

Kama mbadala, IDE iliyoandikwa kutoka mwanzo, iliyojengwa kwenye Eclipse, inatolewa. Huko, vyanzo, kama ilivyo katika programu nyingine yoyote, huishi katika mfumo wa faili za maandishi, zimehifadhiwa kwenye GIT, matawi ya ombi la kuvuta, yote haya. Kwa upande wa chini, haijaondoka kwenye hali ya beta kwa miaka mingi sasa, ingawa inazidi kuwa bora kwa kila toleo. Sitaandika juu ya ubaya wa EDT, leo ni minus, kesho ni kipengele kisichobadilika. Umuhimu wa maelezo kama haya utaisha haraka. Leo inawezekana kuendeleza katika EDT, lakini sio kawaida; unahitaji kuwa tayari kwa idadi fulani ya makosa ya IDE.

Ikiwa unatazama hali kupitia "1C prism" iliyotajwa hapo juu, unapata kitu kama hiki: kutolewa kwa IDE mpya hakuongeza mauzo ya masanduku, lakini outflow ya DEVELOPERS inaweza kupunguzwa. Ni vigumu kusema ni nini kinangoja mfumo wa ikolojia katika suala la faraja ya wasanidi programu, lakini Microsoft tayari imeharibu watengenezaji wa simu kwa kuwapa huduma zake kwa kuchelewa sana.

Usimamizi wa maendeleo

Kila kitu hapa ni bora zaidi kuliko msimbo wa uandishi, haswa hivi majuzi, wakati juhudi za jamii zilifunua shida za otomatiki za usimamizi, ilizindua prototypes zinazotaka kutupa hazina ya 1C kwenye lundo la takataka na kutumia git, lawama za haraka, hakiki ya nambari. , uchanganuzi tuli, uwekaji kiotomatiki na n.k. Vipengele vingi vimeongezwa kwenye jukwaa ambalo huongeza kiwango cha automatisering ya kazi za maendeleo. Hata hivyo, vipengele hivi vyote viliongezwa tu na kwa pekee kwa ajili ya maendeleo ya bidhaa zetu kubwa, wakati ikawa dhahiri kwamba hatuwezi kufanya bila automatisering. Kulikuwa na miunganisho otomatiki, ulinganisho wa njia tatu na KDiff na hayo yote. Imezinduliwa kwenye Github gitconverter, ambaye, kusema ukweli, alivutwa kiitikadi kutoka kwa mradi huo gitsync, lakini imerekebishwa ili kuendana na taratibu za kampuni ya mchuuzi. Shukrani kwa vijana wakaidi kutoka kwa chanzo huria, uundaji wa otomatiki katika 1C ulishuka. API wazi ya kisanidi, IMHO, pia ingebadilisha kurudi nyuma kwa maadili ya IDE kuu.

Leo, kuhifadhi vyanzo vya 1C kwenye git na ahadi zilizounganishwa na masuala katika Jira, hakiki katika Crucible, kitufe cha kubofya kutoka kwa Jenkins na ripoti za Allure kuhusu majaribio ya msimbo katika 1C na hata uchambuzi tuli katika SonarQube - hii ni mbali na habari, lakini badala ya kawaida katika makampuni ambayo kuna maendeleo mengi ya 1C.

Utawala

Kuna mengi ya kusema hapa. Kwanza, hii ni, kwa kweli, seva (nguzo ya seva ya 1C). Jambo la ajabu, lakini kutokana na ukweli kwamba ni sanduku nyeusi kabisa, iliyoandikwa kwa undani wa kutosha, lakini kwa njia maalum - kusimamia uzinduzi wa operesheni isiyoingiliwa katika hali ya juu ya upakiaji kwenye seva kadhaa ni kura ya wachache waliochaguliwa ambao huvaa. medali yenye maandishi "Mtaalamu wa Masuala ya Kiteknolojia". Ni muhimu kuzingatia kwamba, kimsingi, kusimamia seva ya 1C sio tofauti na kusimamia seva nyingine yoyote. Ni programu inayotegemea mtandao, yenye nyuzi nyingi ambayo hutumia kumbukumbu, CPU, na rasilimali za diski. Hutoa fursa nyingi za ukusanyaji wa telemetry na uchunguzi.

Shida hapa ni kwamba muuzaji haitoi chochote maalum katika suala la suluhisho zilizotengenezwa tayari kwa utambuzi huu. Ndiyo, kuna 1C: Kituo cha Ala na Udhibiti, hata ni nzuri kabisa, lakini ni ghali sana na si kila mtu anayo. Kuna idadi ya maendeleo katika jumuiya ya kuunganisha Grafana, Zabbix, ELK na mambo mengine kutoka kwa seti ya kawaida ya msimamizi, lakini hakuna suluhisho moja ambalo litafaa wengi. Kazi inangojea shujaa wake. Na kama wewe ni biashara inayopanga kuzindua kwenye nguzo ya 1C, unahitaji Mtaalamu. Yako mwenyewe ndani au kutoka nje, lakini unahitaji. Ni kawaida kwamba kuna jukumu tofauti na uwezo wa uendeshaji wa seva, sio kila mtumiaji wa 1C anapaswa kujua hili, unahitaji tu kuelewa kwamba jukumu kama hilo linahitajika. Hebu tuchukue SAP kwa mfano. Huko, mpangaji programu, uwezekano mkubwa, hatasimama kutoka kwa kiti chake ikiwa ataulizwa kusanidi kitu kwenye seva ya programu. Anaweza kuwa mjinga tu na hataona aibu. Katika mbinu ya SAP kuna jukumu tofauti la mfanyakazi kwa hili. Kwa sababu fulani, katika tasnia ya 1C inaaminika kuwa hii inapaswa kuunganishwa katika mfanyakazi mmoja kwa mshahara sawa. Ni udanganyifu.

Hasara za seva ya 1C

Kuna minus moja - kuegemea. Au, ukipenda, kutotabirika. Tabia ya kushangaza ya ghafla ya seva tayari imekuwa gumzo la jiji. Suluhisho la ulimwengu wote - kusimamisha seva na kufuta kashe zote - hata imeelezewa katika kitabu cha mtaalam, na hata kitabu cha batch kinapendekezwa kufanya hivi. Ikiwa mfumo wako wa 1C utaanza kufanya jambo ambalo haufai hata kinadharia kufanya, ni wakati wa kufuta akiba ya data ya kipindi. Kulingana na makadirio yangu, kuna watu watatu tu katika nchi nzima ambao wanajua jinsi ya kuendesha seva ya 1C bila utaratibu huu na hawashiriki siri, kwa sababu ... wanaishi kutokana na hili. Labda siri yao ni kwamba wao husafisha data ya kikao, lakini hawaambii mtu yeyote kuhusu hilo, jamani.

Vinginevyo, seva ya 1C ni programu sawa na nyingine yoyote na inasimamiwa kwa njia sawa, kwa kusoma nyaraka na kugonga tari.

Docker

Umuhimu wa kutumia seva ya 1C iliyo na kontena katika uzalishaji bado haujathibitishwa. Seva haijaunganishwa kwa kuongeza tu nodi nyuma ya sawazisha, ambayo inapunguza faida za uwekaji vyombo vya uzalishaji hadi kiwango cha chini, na mazoezi ya utendakazi mzuri katika vyombo katika hali ya juu haijaanzishwa. Kwa hivyo, ni wasanidi programu pekee wanaotumia Docker+1C kuweka mazingira ya majaribio. Huko ni muhimu sana, inatumika, hukuruhusu kucheza na teknolojia za kisasa na kuchukua mapumziko kutoka kwa kukata tamaa kwa kisanidi.

Kipengele cha kibiashara

Kutoka kwa mtazamo wa uwekezaji, 1C inakuwezesha kutatua tatizo la kuzindua haraka mawazo ya biashara kutokana na uwezo mkubwa wa madarasa ya maombi. 1C nje ya kisanduku inatoa Kuripoti kwa heshima sana, kuunganishwa na chochote, mteja wa wavuti, mteja wa rununu, programu ya rununu, usaidizi kwa DBMS anuwai, pamoja na. bure, jukwaa-msalaba zote mbili seva na sehemu za mteja zilizosakinishwa. Ndio, UI ya programu itakuwa ya manjano, wakati mwingine hii ni minus, lakini sio kila wakati.
Kwa kuchagua 1C, biashara hupata seti ya ufumbuzi wa programu ambayo inawawezesha kujenga aina mbalimbali za maombi, pamoja na watengenezaji wengi kwenye soko ambao wanataka pesa kidogo kuliko Javaists na wakati huo huo kuzalisha matokeo kwa kasi zaidi.

Kwa mfano, kazi ya kutuma ankara ya PDF kwa mteja inaweza kutatuliwa katika saa moja ya kazi ya mwanafunzi. Tatizo sawa katika .NET linaweza kutatuliwa kwa kununua maktaba ya wamiliki, au siku kadhaa au wiki za usimbaji na msanidi mkali, mwenye ndevu. Wakati mwingine, wote wawili mara moja. Na ndio, nilikuwa nikizungumza tu juu ya kizazi cha PDF. Hatujasema muswada huu utatoka wapi. Mtangulizi wa wavuti lazima atengeneze fomu ambapo opereta ataingiza data, anayerudisha nyuma atalazimika kuunda modeli za dto za kuhamisha JSON, modeli za kuhifadhi kwenye hifadhidata, muundo wa hifadhidata yenyewe, uhamishaji kwake, uundaji wa picha. onyesho la akaunti hii, na kisha tu - PDF. Kwenye 1C, kazi nzima, kutoka mwanzo, imekamilika kwa saa moja haswa.

Mfumo kamili wa uhasibu kwa duka dogo na mchakato mmoja wa biashara kununuliwa/kuuzwa hufanyika kwa saa 3 Kwa kuripoti mauzo, uhasibu wa bidhaa kwa bei ya ununuzi na uuzaji, iliyogawanywa na ghala, udhibiti wa haki za ufikiaji, mteja wa wavuti na programu ya rununu. . Sawa, nilisahau kuhusu maombi, na maombi si katika masaa 3, katika sita.

Je, kazi hii itachukua muda gani kwa msanidi wa .NET kutoka kusakinisha studio inayoonekana kwenye kompyuta safi hadi kuionyesha kwa mteja? Vipi kuhusu gharama ya maendeleo? Kitu sawa.

Nguvu za 1C kama jukwaa

1C ina nguvu sio kwa sababu kuna kitu maalum juu yake ambacho ni bora zaidi ulimwenguni. Kinyume chake, katika kila mfumo mdogo unaweza kupata analog ya kuvutia zaidi katika programu ya dunia. Walakini, kwa kuzingatia mchanganyiko wa sababu, sioni jukwaa sawa na 1C. Hapa ndipo mafanikio ya kibiashara yalipo. Faida za jukwaa zimetawanyika kote kote na zinaonekana wazi zaidi unapoona jinsi hii inafanywa katika mifumo mingine. Kimsingi, hizi sio sifa hata, lakini kinyume chake - kukataliwa kwa huduma kwa niaba ya dhana moja maalum. Mifano michache:

1. Unicode. Nini kuzimu inaweza kuwa rahisi zaidi? Hakuna haja ya kutumia usimbaji wa baiti moja ya ASCII mnamo 2019 (isipokuwa kwa kuunganishwa na zile za zamani). Kamwe. Lakini hapana. Kwa hivyo, mtu kwenye jedwali fulani hutumia varchar ya baiti moja na programu itakuwa na shida na usimbaji. Mnamo 2015, uidhinishaji wa LDAP wa gitlab haukufaulu kwa sababu ya kazi isiyo sahihi na usimbaji JetBrains IDE bado haifanyi kazi na Cyrillic katika majina ya faili kila mahali. 1C hutoa utengaji wa hali ya juu wa msimbo wa programu kutoka kwa safu ya hifadhidata. Huko haiwezekani kuandika meza kwa kiwango cha chini na jambs za vijana wasio na uwezo katika ngazi ya database haziwezekani huko. Ndiyo, kunaweza kuwa na matatizo mengine huko kutoka kwa vijana wasio na uwezo, lakini aina mbalimbali za matatizo ni ndogo zaidi. Sasa utaniambia kuwa programu yako imeundwa kwa usahihi na safu ya ufikiaji wa hifadhidata imetengwa kama inavyopaswa kuwa. Angalia tena programu yako maalum ya Java ya shirika. Kwa karibu na kwa uaminifu. Je! dhamiri yako inakusumbua? Kisha nina furaha kwa ajili yako.
2. Idadi ya hati/vitabu vya kumbukumbu. Katika 1C hakika sio rahisi zaidi na sio bora zaidi. Lakini wanachofanya katika programu za benki na katika mifumo ya uhasibu iliyoandikwa kibinafsi - vizuri, ni giza tu. Utambulisho wowote utakwama (na kisha "oh, kwa nini tuna mashimo"), au kinyume chake, watafanya jenereta ambayo inafanya kazi na kufunga kwa kiwango cha DBMS (na itakuwa kizuizi). Kwa kweli, ni ngumu sana kufanya kazi hii inayoonekana kuwa rahisi - hesabu ya mwisho hadi-mwisho ya vyombo, na sehemu ya kipekee kulingana na seti fulani ya funguo, kiambishi awali, ili isizuie hifadhidata wakati wa kuingiza data sambamba. .
3. Vitambulisho vya kumbukumbu katika hifadhidata. 1C ilifanya uamuzi wenye nia thabiti - vitambulishi vyote vya viungo vimeundwa na ndivyo hivyo. Na hakuna shida na hifadhidata zilizosambazwa na kubadilishana. Wasanidi wa mifumo mingine kwa ukaidi huunda kitu kama kitambulisho (ni kifupi zaidi!), Waburute kwenye GUI hadi wakati wa kuunda matukio kadhaa yanayohusiana (na kisha yatagunduliwa). Je, huna hii? Kwa uaminifu?
4. Orodha. 1C ina njia zilizofanikiwa za kurasa kupitia orodha (kubwa) na kuzipitia. Acha nihifadhi mara moja - kwa matumizi sahihi ya utaratibu! Kwa ujumla, mada haipendezi kabisa, haiwezi kutatuliwa kwa njia bora: ni angavu na rahisi (lakini hatari ya rekodi kubwa kwa mteja), au paging ni ya upotovu mmoja au mwingine. Wale wanaofanya paging mara nyingi hufanya hivyo kwa upotovu. Wale wanaotengeneza upau wa kusogeza kwa uaminifu huongeza hifadhidata, chaneli na mteja.
5. Fomu zinazosimamiwa. Bila shaka, katika mteja wa wavuti kiolesura haifanyi kazi kikamilifu. Lakini inafanya kazi. Lakini kwa mifumo mingine mingi ya uhasibu na benki, kuunda mahali pa kazi kwa mbali ni mradi wa kiwango cha biashara. Kanusho: kwa bahati nzuri kwa wale ambao waliifanya awali kwenye wavuti, hii haitaathiri.
6. Programu ya simu. Hivi majuzi, unaweza pia kuandika programu za rununu ukiwa katika mfumo ikolojia sawa. Ni ngumu zaidi hapa kuliko mteja wa wavuti; maalum ya vifaa hukulazimisha kuandika mahsusi kwao, lakini, hata hivyo, hauajiri timu tofauti ya watengenezaji wa rununu. Ikiwa unahitaji maombi ya mahitaji ya ndani ya kampuni (wakati suluhu ya simu ya mkononi kwa tatizo la shirika ni muhimu zaidi kuliko muundo wa kiolesura cha manjano), unatumia tu jukwaa moja nje ya boksi.
7. Kuripoti. Kwa neno hili simaanishi mfumo wa BI na data kubwa na bakia kwenye mchakato wa ETL. Hii inarejelea ripoti za wafanyikazi wanaofanya kazi ambazo hukuruhusu kutathmini hali ya uhasibu hapa na sasa. Mizani, makazi ya pande zote, kupanga upya daraja, nk. 1C inatoka kwenye kisanduku ikiwa na mfumo wa kuripoti wenye mipangilio rahisi ya kuweka vikundi, vichujio na taswira kwa upande wa mtumiaji. Ndiyo, kuna analogues baridi zaidi kwenye soko. Lakini si ndani ya mfumo wa suluhisho la yote kwa moja na kwa bei wakati mwingine juu kuliko suluhisho la yote kwa moja. Na mara nyingi zaidi ni hata njia nyingine kote: kuripoti tu, lakini ghali zaidi kuliko jukwaa zima, na mbaya zaidi katika ubora.
8. Fomu zinazoweza kuchapishwa. Naam, tumia .NET kutatua tatizo la kutuma hati za mishahara katika PDF kwa wafanyakazi kwa barua pepe. Na sasa kazi ya uchapishaji ankara. Vipi kuhusu kuhifadhi nakala zao kwa PDF sawa? Kwa jina la utani la 1C, kutoa mpangilio wowote kwa PDF ni +1 mstari wa msimbo. Hii ina maana + sekunde 40 za muda wa kufanya kazi, badala ya siku au wiki katika lugha nyingine. Mipangilio ya fomu zilizochapishwa katika 1C ni rahisi sana kukuza na ina nguvu ya kutosha kushindana na wenzao wanaolipwa. Ndiyo, pengine, hakuna fursa nyingi za mwingiliano katika hati za lahajedwali za 1C huwezi kupata mchoro wa 3D kwa kuongeza ukubwa kwa kutumia OpenGL. Lakini ni lazima kweli?

Hii ni mifano michache ambapo kupunguza utendakazi au utekelezaji wa maelewano hugeuka kuwa manufaa muhimu ya usanifu katika siku zijazo. Hata maelewano au sio chaguo la ufanisi zaidi - tayari iko kwenye sanduku na inachukuliwa kwa urahisi. Utekelezaji wake wa kujitegemea hautawezekana (kwa sababu maamuzi kama hayo lazima yafanywe mwanzoni mwa mradi, na hakuna wakati wa hiyo, na hakuna mbunifu kabisa), au marudio kadhaa ya gharama kubwa. Katika kila moja ya pointi zilizoorodheshwa (na hii sio orodha kamili ya ufumbuzi wa usanifu), unaweza kufuta na kuanzisha vikwazo vinavyozuia kuongeza. Kwa hali yoyote, wewe, kama mfanyabiashara, unahitaji kuhakikisha kuwa waandaaji programu wako, wakati wa kutengeneza "mfumo kutoka mwanzo," wana mikono moja kwa moja na watafanya maswala ya hila ya mfumo mara moja.

Ndio, kama ilivyo katika mfumo mwingine wowote changamano, 1C yenyewe pia ina suluhu zinazozuia kuongeza kiwango katika vipengele fulani. Hata hivyo, narudia, kwa kuzingatia mchanganyiko wa mambo, gharama ya umiliki, na idadi ya matatizo tayari kutatuliwa mapema, sioni mshindani anayestahili kwenye soko. Kwa bei sawa, unapata mfumo wa maombi ya kifedha, seva iliyounganishwa iliyosawazishwa, yenye kiolesura cha kiolesura cha wavuti, yenye programu ya simu ya mkononi, yenye kuripoti, kuunganishwa na kundi la mambo mengine. Katika ulimwengu wa Java, unaajiri timu ya mbele na nyuma, kutatua idadi ya chini ya msimbo wa seva iliyoandikwa nyumbani na kulipa kando kwa ajili ya maombi 2 ya simu kwa OS 2 za simu.

Sisemi kwamba 1C itasuluhisha kesi zote, lakini kwa maombi ya ndani ya kampuni, wakati hakuna haja ya kuweka alama ya UI - ni nini kingine kinachohitajika?

Kuruka kwenye marashi

Labda ulipata maoni kwamba 1C itaokoa ulimwengu na kwamba njia zingine zote za kuandika mifumo ya ushirika sio sawa. Sio hivyo hata kidogo. Kutoka kwa mtazamo wa mfanyabiashara, ukichagua 1C, basi pamoja na wakati wa haraka wa soko, lazima uzingatie hasara zifuatazo:

• Kuegemea kwa seva. Wataalamu wa hali ya juu wanahitajika ambao wanaweza kuhakikisha utendakazi wake bila kukatizwa. Sijui kuhusu mpango wa mafunzo uliotayarishwa tayari kwa wataalamu kama hao kutoka kwa muuzaji. Kuna kozi za kujiandaa kwa mtihani wa Mtaalam, lakini hii, kwa maoni yangu, haitoshi.
• Msaada. Tazama aya iliyotangulia. Ili kupata msaada kutoka kwa muuzaji, unahitaji kuinunua. Kwa sababu fulani hii haikubaliki katika tasnia ya 1C. Na kwa SAP, ni karibu ununuzi wa lazima na hausumbui mtu yeyote. Bila usaidizi wa kampuni na bila mtaalamu wa wafanyakazi, unaweza kuachwa peke yako na glitches 1C.
• Bado, huwezi kufanya kila kitu kabisa na 1C. Hii ni zana na kama kila zana ina mipaka ya utumiaji. Katika mazingira ya 1C, ni kuhitajika sana kuwa na mbunifu wa mfumo wa "non-1C".
• Majina mazuri ya utani ya 1C sio nafuu kuliko watengeneza programu wazuri katika lugha zingine. Ingawa, watengenezaji programu mbaya ni ghali kuajiri, bila kujali lugha wanayoandika.

Hebu tuangazie nukta

• 1C ni mfumo wa ukuzaji wa programu kwa haraka (RAD) wa biashara na umeundwa kwa ajili hii.
• Kiungo cha ngazi tatu na usaidizi wa DBMS kuu, UI ya mteja, ORM nzuri sana na kuripoti
• Uwezekano mpana wa kuunganishwa na mifumo inayoweza kufanya kile ambacho 1C haiwezi. Ikiwa unataka kujifunza kwa mashine, chukua Python na utume matokeo kwa 1C kupitia http au RabbitMQ
• Hakuna haja ya kujitahidi kufanya kila kitu kwa kutumia 1C, unahitaji kuelewa nguvu zake na kuzitumia kwa madhumuni yako mwenyewe.
• Wasanidi programu wanaovutiwa na kuchimba vidude vya mifumo ya kiteknolojia na kuunda upya kila miaka N hadi injini mpya wamechoshwa na 1C. Kila kitu ni kihafidhina sana huko.
• Waendelezaji pia wamechoka kwa sababu kuna wasiwasi mdogo sana kutoka kwa mtengenezaji. Lugha ya kuchosha, IDE dhaifu. Wanahitaji kisasa.
• Kwa upande mwingine, wasanidi programu ambao hawawezi kupata furaha kwa kutumia na kujifunza teknolojia nyingine wanayofurahia ni watengenezaji wabaya. Wataomboleza na kuhamia mfumo mwingine wa ikolojia.
• Waajiri ambao hawaruhusu lakabu zao za 1C kuandika kitu katika Python ni waajiri wabaya. Watapoteza wafanyikazi walio na akili za kudadisi, na mahali pao watakuja coders za tumbili ambao, wakati wanakubaliana na kila kitu, watavuta programu ya ushirika kwenye bwawa. Bado itabidi iandikwe upya, kwa hivyo labda itakuwa bora kuwekeza kidogo kwenye Python mapema kidogo?
• 1C ni kampuni ya kibiashara na hutekeleza vipengele kulingana na maslahi na manufaa yake pekee. Huwezi kumlaumu kwa hili, biashara lazima ifikirie juu ya faida, ndio maisha
• 1C hutengeneza pesa kwa kuuza suluhisho kwa shida za biashara, sio kwa shida za msanidi wa Vasya. Dhana hizi mbili zinahusiana, lakini kipaumbele ni kile nilichosema. Wakati msanidi Vasya yuko tayari kulipa leseni ya kibinafsi kwa 1C: Resharper, itaonekana haraka sana, "Resharper" na A. Orefkova ni uthibitisho wa hili. Ikiwa muuzaji aliiunga mkono, na hakupigana nayo, soko la programu kwa watengenezaji lingeonekana. Sasa kuna wachezaji mmoja na nusu katika soko hili na matokeo ya shaka, na yote kwa sababu ushirikiano na IDE ni mbaya na kila kitu kinafanywa kwa viboko.
• Mazoezi ya mwendeshaji wa mashine nyingi yatatoweka bila kusahaulika. Programu za kisasa ni kubwa mno kukumbuka kutoka upande wa msimbo na kutoka upande wa matumizi ya biashara. Seva ya 1C pia inakuwa ngumu zaidi; haitawezekana kushikilia aina zote za utaalamu katika mfanyakazi mmoja. Hii inapaswa kujumuisha mahitaji ya wataalamu, ambayo inamaanisha kuvutia kwa taaluma ya 1C na ongezeko la mishahara. Ikiwa hapo awali Vasya alifanya kazi tatu kwa moja kwa mshahara mmoja, sasa unahitaji kuajiri Vasyas mbili na ushindani kati ya Vasyas unaweza kuchochea ukuaji wa jumla wa ngazi yao.

Hitimisho

1C ni bidhaa inayostahili sana. Katika safu yangu ya bei, sijui analogues yoyote, andika kwenye maoni ikiwa kuna yoyote. Walakini, utokaji wa watengenezaji kutoka kwa mfumo wa ikolojia unaonekana zaidi na zaidi, na hii ni "kukimbia kwa ubongo", bila kujali jinsi unavyoiangalia. Sekta ina njaa ya kisasa.
Ikiwa wewe ni msanidi programu, usikatwe kwenye 1C na usifikiri kuwa kila kitu ni cha kichawi katika lugha zingine. Wakati wewe ni junior, labda. Mara tu jambo kubwa linapohitaji kutatuliwa, suluhu zilizotengenezwa tayari zitalazimika kutafutwa kwa muda mrefu na kukamilishwa kwa umakini zaidi. Kwa upande wa ubora wa "vitalu" ambavyo suluhisho linaweza kujengwa, 1C ni nzuri sana.

Na jambo moja zaidi - ikiwa jina la utani la 1C linakuja kwako kuajiri, basi jina la utani la 1C linaweza kuteuliwa kwa usalama kwa nafasi ya wachambuzi wakuu. Uelewa wao wa kazi, eneo la somo, na ujuzi wa mtengano ni bora. Nina hakika kuwa hii ni kwa sababu ya matumizi ya kulazimishwa ya DDD katika ukuzaji wa 1C. Mtu amefundishwa kufikiri juu ya maana ya kazi kwanza kabisa, kuhusu uhusiano kati ya vitu vya eneo la somo, na wakati huo huo ana historia ya kiufundi katika teknolojia ya ushirikiano na muundo wa kubadilishana data.

Jihadharini kwamba mfumo bora haupo na ujijali mwenyewe.
Kila la kheri!

PS: asante sana speshuric kwa msaada katika kuandaa makala.

Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. Weka sahihitafadhali.

Je, una 1C katika biashara yako?

• 13,3%Sivyo kabisa.71

• 30,3%Kuna, lakini tu katika idara ya uhasibu mahali fulani. Mifumo ya msingi kwenye majukwaa mengine162

• 41,4%Ndiyo, michakato kuu ya biashara hufanya kazi juu yake221

• 15,0%1C lazima ife, siku zijazo ni za %technology_name%80

Watumiaji 534 walipiga kura. Watumiaji 99 walijizuia.

Chanzo: mapenzi.com