1C - Mabuti at masama. Pag-aayos ng mga punto sa holivar sa paligid ng 1C

1C - Mabuti at masama. Pag-aayos ng mga punto sa holivar sa paligid ng 1C

Mga kaibigan at kasamahan, kamakailan ay nagkaroon ng mas madalas na mga artikulo sa HabrΓ© na may galit sa 1C bilang isang platform ng pag-unlad, at mga talumpati ng mga tagapagtanggol nito. Tinukoy ng mga artikulong ito ang isang seryosong problema: kadalasan, pinupuna ito ng mga kritiko ng 1C mula sa posisyon na "hindi ito pinagkadalubhasaan", ang mga problema na de facto ay madaling lutasin, at, sa kabaligtaran, hindi hawakan ang mga problema na talagang mahalaga, nagkakahalaga. pinag-uusapan at hindi nalutas ng vendor. Naniniwala ako na makatuwirang magsagawa ng matino at balanseng pagsusuri ng 1C platform. Ano ang magagawa nito, kung ano ang hindi nito magagawa, kung ano ang dapat nitong gawin ngunit hindi ginagawa, at, para sa dessert, kung ano ang ginagawa nito nang malakas, at ang iyong mga developer sa %technology_name% ay gagawa ng isang daang taon, itatapon ito. higit sa isang taunang badyet.

Bilang isang resulta, ikaw, bilang isang tagapamahala o arkitekto, ay makakakuha ng isang malinaw na pag-unawa sa kung anong gawain ang magiging kapaki-pakinabang para sa iyo na gumamit ng 1C, at kung saan ito kailangang sunugin gamit ang isang mainit na bakal. Bilang isang developer sa mundong "hindi 1C", makikita mo kung ano ang naroroon sa 1C na nagdudulot ng kaguluhan. At bilang isang developer ng 1C, magagawa mong ihambing ang iyong system sa mga ecosystem ng iba pang mga wika at maunawaan ang iyong lokasyon sa coordinate system ng software development.

Sa ilalim ng hiwa mayroong maraming makapal na pag-atake sa 1C, sa mga kritiko ng 1C, sa Java, .NET at sa pangkalahatan... Puno ang fan, maligayang pagdating!

Tungkol sa aking sarili

Pamilyar ako sa paksa ng pag-uusap mula noong humigit-kumulang 2004. Nagprograma na ako marahil mula noong ako ay 6 na taong gulang, mula sa sandaling nakakuha ako ng isang libro tungkol kay Professor Fortran na may mga komiks tungkol sa isang pusa, isang maya at isang uod. Sinuri ko ang mga programa na isinulat ng pusa mula sa mga larawan sa aklat at nalaman kung ano ang kanilang ginawa. At oo, wala akong totoong computer sa oras na iyon, ngunit mayroong isang guhit sa pagkalat ng libro at tapat kong pinindot ang mga pindutan ng papel, na ipinasok ang mga utos na aking natiktikan sa pusa X.

Pagkatapos ay mayroong BK0011 at BASIC sa paaralan, C++ at mga assembler sa unibersidad, pagkatapos ay 1C, at pagkatapos ay napakaraming iba pang mga bagay na tinatamad akong matandaan. Sa nakalipas na 15 taon, higit sa lahat ay kasali ako sa 1C, hindi lamang sa mga tuntunin ng coding, ngunit sa 1C sa pangkalahatan. Pagtatakda ng mga gawain, pangangasiwa at mga devops dito. Sa nakalipas na 5 taon, nakikibahagi ako sa mga aktibidad na kapaki-pakinabang sa lipunan sa mga tuntunin ng pagbuo at mga tool sa automation para sa iba pang mga gumagamit ng 1C, pagsusulat ng mga artikulo at aklat.

Magpasya tayo sa paksa ng talakayan

Una, tukuyin natin kung ano ang pag-uusapan natin, dahil ang mga titik na "1C" ay maaaring mangahulugan ng maraming bagay. Sa kasong ito, sa pamamagitan ng mga titik na "1C" ang ibig naming sabihin ay eksklusibo ang balangkas ng pag-unlad na "1C: Enterprise" ng moderno, ikawalong bersyon. Hindi kami masyadong magsasalita tungkol sa tagagawa at sa mga patakaran nito (ngunit kailangan naming gumawa ng kaunti). Hindi namin tatalakayin ang mga partikular na application na isinulat gamit ang balangkas na ito. Hiwalay ang teknolohiya, hiwalay ang mga application aka configuration.

Mataas na antas ng arkitektura 1C: Enterprise

Ito ay hindi para sa wala na binanggit ko ang salitang "balangkas". Mula sa pananaw ng isang developer, ang 1C platform ay isang balangkas. At kailangan mong tratuhin ito nang eksakto tulad ng isang balangkas. Isipin ito bilang Spring o ASP.NET, na pinaandar ng ilang runtime (JVM o CLR ayon sa pagkakabanggit). Nangyayari na sa mundo ng maginoo na programming ("hindi 1C"), ang paghahati sa mga balangkas, virtual machine at mga partikular na aplikasyon ay natural, dahil sa ang katunayan na ang mga sangkap na ito ay karaniwang binuo ng iba't ibang mga tagagawa. Sa mundo ng 1C, hindi kaugalian na tahasang tukuyin ang balangkas ng pag-unlad at mismong runtime; bilang karagdagan, ang mga partikular na application na isinulat gamit ang balangkas ay pangunahing binuo ng 1C mismo. Bilang resulta, lumitaw ang ilang pagkalito. Samakatuwid, sa loob ng balangkas ng artikulo, kailangan nating isaalang-alang ang 1C mula sa maraming panig nang sabay-sabay at pag-uri-uriin ito kasama ang ilang mga coordinate axes. At sa bawat coordinate axis ay maglalagay kami ng pala ng brown substance at titingnan ang mga tampok, pakinabang at disadvantages ng umiiral na solusyon.

Mga punto ng view sa 1C

1C para sa bumibili

Bumili ang mamimili ng isang sistema ng automation kung saan maaari niyang mabilis na malutas ang mga problema sa pag-automate ng kanyang sariling negosyo. Ang isang negosyo ay maaaring isang maliit na stall, o maaari itong maging isang malaking holding company. Malinaw na ang mga pangangailangan ng mga negosyong ito ay iba, ngunit pareho ay sinusuportahan ng isang solong platform code base.

Para sa mamimili ng 1C ito ay isang mabilis na time-to-market. Mabilis. Mas mabilis kaysa sa Java, C# o JS. Katamtaman. Sa paligid ng ospital. Malinaw na magiging mas mahusay ang website ng business card na gumagamit ng React, ngunit mas mabilis na ilulunsad ang backend ng isang WMS system sa 1C.

1C bilang isang kasangkapan

Ang bawat teknolohikal na solusyon ay may mga limitasyon ng kakayahang magamit. Ang 1C ay hindi isang pangkalahatang layunin na wika; hindi ito nabubuhay nang hiwalay sa balangkas nito. Maipapayo na gumamit ng 1C kapag kailangan mo:

  • application ng server
  • application kung saan lumilitaw ang pananalapi
  • na may handa na UI, ORM, Pag-uulat, XML/JSON/COM/PDF/YourDataTransferingFormat
  • na may suporta para sa mga proseso sa background at trabaho
  • na may seguridad na nakabatay sa tungkulin
  • na may scriptable business logic
  • na may kakayahang mabilis na lumikha ng isang prototype at mababang oras-sa-market

Hindi mo kailangan ng 1C kung gusto mo:

  • machine learning
  • Mga kalkulasyon ng GPU
  • computer graphics
  • mga kalkulasyon sa matematika
  • CAD system
  • pagpoproseso ng signal (tunog, video)
  • highload http na mga tawag na may daan-daang libong rps

1C bilang isang kumpanya ng pagmamanupaktura

Ito ay nagkakahalaga ng pag-unawa kung ano ang negosyo ng 1C bilang isang tagagawa ng software. Ang kumpanya ng 1C ay nagbebenta ng mga solusyon sa mga problema sa negosyo sa pamamagitan ng automation. Iba't ibang negosyo, malaki man o maliit, ngunit iyon ang kanyang ibinebenta. Ang mga paraan upang makamit ang layuning ito ay mga aplikasyon sa negosyo. Para sa accounting, payroll accounting, atbp. Para isulat ang mga application na ito, ginagamit ng kumpanya ang sarili nitong business application development platform. Espesyal na iniakma para sa mga karaniwang gawain ng parehong mga aplikasyon sa negosyo:

  • accounting sa pananalapi
  • madaling pag-customize ng lohika ng negosyo
  • malawak na mga posibilidad ng pagsasama sa magkakaibang mga landscape ng IT

Bilang isang tagagawa, naniniwala ang 1C na ito ang diskarte na nagbibigay-daan sa iyong makipagtulungan sa mga kasosyo at kliyente sa win-win mode. Maaari kang makipagtalo dito, ngunit ito ay halos kung paano itinataguyod ng kumpanya ang sarili nito: mga handa na solusyon sa mga problema sa negosyo na maaaring mabilis na ma-customize ng mga kasosyo at maisama sa anumang IT landscape.

Ang lahat ng mga paghahabol o kagustuhan para sa 1C bilang isang balangkas ay dapat na eksklusibong tingnan sa pamamagitan ng prisma na ito. "Gusto namin ang OOP sa 1C," sabi ng mga developer. "Magkano ang magagastos sa amin upang suportahan ang OOP sa platform, makakatulong ba ito sa amin na madagdagan ang mga benta ng mga kahon?" sabi ng 1C. Binubuksan ang kanyang "prisma" ng pagbebenta ng mga solusyon sa mga problema sa negosyo:

- Uy, negosyo, gusto mo bang OOP sa iyong 1C?
- Makakatulong ba ito sa paglutas ng aking mga problema?
- Sino ang nakakaalam...
- Kung gayon ay hindi na kailangan

Ang diskarte na ito ay maaaring maging mabuti o masama depende sa kung sino ang tumitingin dito, ngunit ganoon talaga ito. Sa pagsasalita tungkol sa katotohanan na walang tampok na X sa 1C, kailangan mong maunawaan na wala ito doon para sa isang dahilan, ngunit sa konteksto ng pagpipiliang "gastos sa pagpapatupad kumpara sa halaga ng kita".

Pag-uuri ng teknolohiya

"Sa katunayan, ginagawa ng mga Odinesnik ang kanilang makakaya upang magamit ang pinakamahusay na mga pattern, maingat na pinili ng mga nagmamalasakit na metodologo at mga developer ng 1C platform.
Kapag isinulat mo ang iyong hangal na code para sa isang simpleng pinamamahalaang form, sa katotohanan ay gumagamit ka model-view-controller с double-way na data binding в tatlong-layered-data-app-engine, may lasa mataas na antas ng object-relation-mapping sa base declarative metadata descriptionpagkakaroon ng sarili wika ng query na independiyente sa platform, C deklaratibong data-driven na user interface, kumpletong transparent na serialization at domain-oriented na wika ng programa.

Kung saan ang mga developer ng 1C ay naiiba sa kanilang mga kasamahan sa Kanluran ay nasa PR. Gustung-gusto nilang bigyan ang anumang kalokohan ng isang malaking pangalan at tumakbo kasama ito tulad ng isang maruming bag."
A. Orefkov

Ang 1C platform ay may klasikong 3-tier na arkitektura, sa gitna nito ay ang application server (o ang pagtulad nito para sa maliit na pera para sa maliliit na tindera). Ang alinman sa MS SQL o Postgres ay ginagamit bilang isang DBMS. Mayroon ding suporta para sa Oracle at IBM DB2, ngunit ito ay medyo esoteric; walang nakakaalam kung ano ang mangyayari kung ipapatupad mo ang 1C sa mga database na ito sa ilalim ng katamtaman at mataas na pagkarga. Naniniwala ako na ang 1C mismo ay hindi alam ito.

Ang bahagi ng kliyente ay alinman sa isang manipis na kliyente na naka-install sa makina ng gumagamit o isang web client. Ang pangunahing tampok ay ang mga programmer ay hindi nagsusulat ng 2 magkaibang mga code, nagsusulat sila ng isang aplikasyon, sa isang wika, at maaari mo itong ipakita sa browser kung may pagnanais o pangangailangan. Sino doon ang gusto ng totoong buong stack at iisang wika para sa harap at backend, node.js? Hindi nila nagawang gawin ang eksaktong parehong bagay hanggang sa wakas. Mayroong isang tunay na buong stack, ngunit kakailanganin mong isulat ito sa 1C. Ang kabalintunaan ng tadhana, mga ganyang bagay :)

Gumagana rin ang cloud SaaS solution 1C:Fresh sa browser mode, kung saan hindi ka makakabili ng 1C, ngunit magrenta ng maliit na database at subaybayan ang mga benta ng shawarma doon. Sa browser lang, nang walang pag-install o pag-configure ng anuman.

Bilang karagdagan, mayroong isang legacy na kliyente, na sa 1C ay tinatawag na "regular na aplikasyon". Ang legacy ay legacy, maligayang pagdating sa mundo ng mga aplikasyon noong 2002, ngunit pinag-uusapan pa rin natin ang kasalukuyang estado ng ecosystem.

Ang bahagi ng 1C server ay sumusuporta sa clustering at mga kaliskis sa pamamagitan ng pagdaragdag ng mga bagong machine sa cluster. Napakaraming kopya ang nasira dito at magkakaroon ng hiwalay na seksyon sa artikulo tungkol dito. Sa madaling salita, hindi ito kapareho ng pagdaragdag ng ilang eksaktong parehong mga pagkakataon sa likod ng HAProxy.

Ang application development framework ay gumagamit ng sarili nitong programming language, na halos kamukha ng bahagyang pinahusay na VB6 na isinalin sa Russian. Para sa mga taong napopoot sa lahat ng Ruso, na hindi naniniwala na ang "kung" ay isinalin bilang "kung," inaalok ang pangalawang opsyon sa syntax. Yung. Kung nais mo, maaari mo itong isulat sa 1C sa paraang hindi ito makikilala sa VB.

1C - Mabuti at masama. Pag-aayos ng mga punto sa holivar sa paligid ng 1C

Ang mismong programming language na ito ang pangunahing dahilan ng pagkamuhi sa mga palayaw ng 1C sa kanilang platform. Aminin natin, hindi nang walang dahilan. Ang wika ay naisip bilang simple hangga't maaari, na idinisenyo upang matupad ang mantra na "DEVELOPERS, DEVELOPERS" sa isang sukat ng hindi bababa sa CIS. Ang komersyal na kakanyahan ng naturang solusyon, sa aking opinyon, ay malinaw na nakikita: mas maraming mga developer, mas malawak na saklaw ng merkado. Natupad ito, ayon sa iba't ibang mga pagtatantya mula 45% hanggang 95%. Sasabihin ko kaagad na ang pagsulat sa wikang sa tingin mo ay talagang mas madali. At marami akong alam na programming language.

Magsimula tayo sa wika.

1C programming language

Kasabay nito ang malakas at mahinang punto ng sistema. Nagbibigay ng madaling pagpasok at pagiging madaling mabasa. Sa kabilang banda, hindi pa ito na-update mula nang ilabas ang bersyon 8 noong 2002 at luma na sa moral. May magsasabi na "ang pangunahing sagabal ay walang OOP" at sila ay mali. Una, hindi lamang gusto ng PLO si Nuraliev, kundi pati na rin ang Torvalds. At pangalawa, umiiral pa rin ang OOP.

Mula sa pananaw ng developer, mayroon siyang isang balangkas na may mga baseng klase na ipinapakita sa DBMS. Maaaring kunin ng developer ang base class na "Directory" at magmana ng direktoryo ng "Mga Kliyente" mula dito. Maaari itong magdagdag ng mga bagong field ng klase dito, halimbawa, INN at Address, at gayundin, kung kinakailangan, maaari nitong i-override (i-override) ang mga pamamaraan ng base class, halimbawa ang OnWrite/AtRecord method.

Ang balangkas ay idinisenyo sa paraang bihirang kailanganin ang mas malalim na pamana, at ang paghihigpit sa OOP, sa palagay ko, ay may katuturan. Nakatuon ang 1C sa Domain Driven Development at pinapaisip ka, una sa lahat, ang tungkol sa paksa ng solusyon na binuo, at ito ay mabuti. Hindi lamang walang tukso, ngunit hindi rin kailangang magsulat ng 10 iba't ibang DTO at ViewModel para lamang magpakita ng ilang data mula sa domain sa isang lugar. Ang 1C developer ay palaging nagpapatakbo sa isang entity, nang hindi pinagkakalat ang konteksto ng perception sa isang dosenang klase na may magkatulad na pangalan, na kumakatawan sa parehong entity, ngunit mula sa ibang panig. Anumang .NET application, halimbawa, ay kinakailangang maglaman ng lima o dalawang ViewModel at DTO para sa serialization sa JSON at paglilipat ng data mula sa kliyente patungo sa server. At humigit-kumulang 10-15% ng iyong application code ang gagastusin sa paglilipat ng data mula sa isang klase patungo sa isa pa gamit ang mga panulat o saklay tulad ng AutoMapper. Ang code na ito ay dapat na nakasulat at ang mga programmer ay dapat bayaran upang lumikha at mapanatili ito.

Lumalabas na ang wikang 1C ay mahirap na paunlarin nang hindi kumplikado ito sa antas ng mga pangunahing wika, kaya nawawala ang bentahe ng pagiging simple. Ano ang gawain ng vendor na mahalagang niresolba: mag-isyu ng karaniwang solusyon na maaaring i-customize ng sinumang mag-aaral na nahuli sa kalye sa kinakailangang antas ng kalidad (ibig sabihin, natapos ang isang case na sumasaklaw mula sa isang stall hanggang sa isang malaking pabrika). Kung ikaw ay isang stall, kumuha ng isang mag-aaral; kung ikaw ay isang pabrika, kumuha ng isang guru mula sa iyong kasosyo sa pagpapatupad. Ang katotohanan na ang mga kasosyo sa pagpapatupad ay nagbebenta ng mga mag-aaral sa presyo ng isang guru ay hindi isang problema sa balangkas. Sa arkitektura, dapat malutas ng balangkas ang mga problema ng pareho, ang code ng mga karaniwang pagsasaayos (na ibinenta namin sa mga negosyong may pangako ng pagpapasadya) ay dapat na maunawaan ng isang mag-aaral, at dapat na maunawaan ng isang guro ang anumang gusto mo.

Ano, sa aking opinyon, ay talagang nawawala sa wika, kung ano ang nagpipilit sa iyo na magsulat ng higit sa iyong makakaya, ay kung ano ang nag-aaksaya ng oras na binabayaran ng customer.

  • Posibilidad ng pag-type sa antas, halimbawa, TypeScript (bilang resulta, mas binuo na mga tool sa pagsusuri ng code sa IDE, refactoring, mas kaunting mga nakakasakit na jamb)
    Availability ng mga function bilang first class object. Ang isang bahagyang mas kumplikadong konsepto, ngunit ang dami ng karaniwang boilerplate-code ay maaaring lubos na mabawasan. Ang pag-unawa ng estudyante sa code, IMHO, ay tataas pa dahil sa pagbabawas ng volume
  • Mga pangkalahatang literal na koleksyon, mga initializer. Ang parehong bagay - pagbabawas ng dami ng code na kailangang isulat at/o tingnan gamit ang iyong mga mata. Ang pagpuno ng mga koleksyon ay tumatagal ng higit sa 9000% ng 1C programming time. Ang pagsulat nito nang walang syntactic sugar ay mahaba, mahal at madaling magkamali. Sa pangkalahatan, ang halaga ng LOC sa mga solusyon sa 1C ay lumampas sa lahat ng naiisip na limitasyon kumpara sa mga available na open framework at, sa pangkalahatan, pinagsama ang lahat ng iyong enterprise Java. Ang wika ay verbose, at ito ay bumababa sa dami ng data, memorya, IDE brakes, oras, pera...
  • sa wakas constructions Mayroon akong hypothesis na nawawala ang construction na ito dahil sa katotohanan na hindi sila nakahanap ng matagumpay na pagsasalin nito sa Russian :)
  • Sariling uri ng data (walang OOP), mga analogue ng Uri mula sa VB6. Papayagan ka nitong huwag mag-type ng mga istruktura gamit ang mga komento sa BSP at mga magic na pamamaraan na bumubuo sa mga istrukturang ito. Nakukuha namin ang: mas kaunting code, isang pahiwatig sa pamamagitan ng isang tuldok, mas mabilis na solusyon sa problema, mas kaunting mga error dahil sa mga typo at nawawalang katangian ng mga istruktura. Ngayon ang pag-type ng mga istruktura ng user ay ganap na nakasalalay sa development team ng Standard Subsystem Library, na, sa kredito nito, maingat na nagsusulat ng mga komento sa mga inaasahang katangian ng mga naipasa na istruktura ng parameter.
  • Walang asukal kapag nagtatrabaho sa mga asynchronous na tawag sa web client. Ang callback-hell sa anyo ng ProcessingNotifications ay isang pansamantalang saklay na dulot ng isang biglaang pagbabago sa API ng mga pangunahing browser, ngunit hindi ka maaaring mamuhay nang ganito sa lahat ng oras; ang bentahe ng "pag-unawa ng mag-aaral" ng asynchronous na code ay nawawala. parami nang parami. Magdagdag ng walang suporta para sa paradigm na ito sa pangunahing IDE at mas lumalala ang mga bagay.

Ito ay isa sa mga pagpindot sa mga problema, malinaw na ang listahan ay maaaring mas malaki, ngunit hindi natin dapat kalimutan na ito ay hindi pa rin isang pangkalahatang layunin na wika, hindi ito nangangailangan ng multithreading, lambda function, access sa GPU at mabilis mga kalkulasyon ng floating point. Ito ay isang business logic scripting language.

Ang isang programmer na marami nang nagtrabaho sa wikang ito, tumitingin sa js o c#, ay nababato sa loob ng balangkas ng wikang ito. Ito ay katotohanan. Kailangan niya ng development. Sa kabilang panig ng sukat para sa vendor ay ang halaga ng pagpapatupad ng mga tinukoy na feature kumpara sa pagtaas ng kita pagkatapos ng kanilang pagpapatupad. Dito wala akong anumang impormasyon tungkol sa kung ano ang kasalukuyang mas matimbang sa mga mata ng kumpanya.

Pagpapaunlad ng kapaligiran

Hindi rin maayos ang mga pangyayari dito. Mayroong dalawang kapaligiran sa pag-unlad. Ang una ay ang Configurator na kasama sa paghahatid. Ang pangalawa ay ang Enterprise Development Tools environment, o EDT para sa maikli, na binuo batay sa Eclipse.

Ang configurator ay nagbibigay ng isang buong hanay ng mga gawain sa pag-unlad, sumusuporta sa lahat ng mga tampok at ang pangunahing kapaligiran sa merkado. Ito rin ay lipas na sa moral, hindi umuunlad, ayon sa mga alingawngaw - dahil sa dami ng teknikal na utang sa loob mismo. Maaaring mapabuti ang sitwasyon sa pamamagitan ng pagbubukas ng panloob na API (sa anyo ng pakikipagkaibigan sa taong yari sa niyebe A. Orefkova o sa isang malayang batayan), ngunit hindi ito ang kaso. Ipinakita ng pagsasanay na susulat ang komunidad ng sarili nitong mga tampok sa IDE, hangga't hindi nakikialam ang vendor. Ngunit mayroon tayo kung ano ang mayroon tayo. Ang configurator ay mahusay noong 2004-2005, napaka nakapagpapaalaala sa Visual Studio ng mga panahong iyon, sa ilang mga lugar ay mas malamig pa ito, ngunit ito ay natigil sa mga oras na iyon.

Bilang karagdagan, ang dami ng karaniwang karaniwang solusyon ay lumago nang maraming beses mula noon, at ngayon ang IDE ay hindi maaaring makayanan ang dami ng code kung saan ito pinapakain. Ang kakayahang magamit at refactoring ay hindi kahit na zero, ang mga ito ay nasa pula. Ang lahat ng ito ay hindi nagdaragdag ng sigasig sa mga developer at nangangarap silang lumipat sa iba pang mga ecosystem at patuloy na mag-code ng tae doon, ngunit sa isang maayang kapaligiran na hindi dumura sa iyong mukha sa pag-uugali nito.

Bilang kahalili, isang IDE na isinulat mula sa simula, na binuo sa Eclipse, ay inaalok. Doon, ang mga mapagkukunan, tulad ng sa anumang iba pang software, ay nabubuhay sa anyo ng mga text file, ay naka-imbak sa GIT, hilahin ang mga sanga ng kahilingan, lahat ng ito. Sa downside, hindi ito umalis sa beta status sa loob ng maraming taon, bagama't ito ay nagiging mas mahusay sa bawat release. Hindi ako magsusulat tungkol sa mga disadvantages ng EDT, ngayon ito ay isang minus, bukas ito ay isang nakapirming tampok. Ang kaugnayan ng naturang paglalarawan ay mabilis na mawawala. Ngayon ay posible na bumuo sa EDT, ngunit ito ay hindi karaniwan; kailangan mong maging handa para sa isang tiyak na bilang ng mga IDE bug.

Kung titingnan mo ang sitwasyon sa pamamagitan ng nabanggit na "1C prism", makakakuha ka ng ganito: ang paglabas ng bagong IDE ay hindi nagpapataas ng mga benta ng mga kahon, ngunit ang pag-agos ng mga DEVELOPERS ay maaaring mabawasan. Mahirap sabihin kung ano ang naghihintay sa ecosystem sa mga tuntunin ng kaginhawaan ng developer, ngunit nahuli na ng Microsoft ang mga mobile developer sa pamamagitan ng pag-aalok sa kanila ng mga serbisyo nito nang huli.

Pamamahala ng pag-unlad

Ang lahat dito ay mas mahusay kaysa sa pagsulat ng code, lalo na kamakailan, nang ang mga pagsisikap ng komunidad ay nagbigay-liwanag sa mga problema ng automation ng administrasyon, naglunsad ng mga prototype na nananawagan para sa pagtatapon ng 1C repository sa tambak ng basura at paggamit ng git, mabilis na sisihin, pagsusuri ng code , static na pagsusuri, auto-deploy at iba pa. Maraming mga tampok ang naidagdag sa platform na nagpapataas ng antas ng automation ng mga gawain sa pag-unlad. Gayunpaman, ang lahat ng mga tampok na ito ay idinagdag lamang at eksklusibo para sa pagbuo ng aming sariling malalaking produkto, nang naging malinaw na hindi namin magagawa nang walang automation. May mga auto-merge, three-way na paghahambing sa KDiff at lahat ng iyon. Inilunsad sa Github gitconverter, na, sa totoo lang, ay ideolohikal na kinaladkad palayo sa proyekto gitsync, ngunit binago upang umangkop sa mga proseso ng kumpanya ng vendor. Salamat sa mga matigas ang ulo mula sa open-source, ang automation ng pag-unlad sa 1C ay bumagsak. Ang isang bukas na API para sa configurator, IMHO, ay maglilipat din sa moral na pagkaatrasado ng pangunahing IDE.

Ngayon, ang pag-iimbak ng mga 1C na source sa git na may mga commit na naka-link sa mga isyu sa Jira, mga review sa Crucible, push button mula sa Jenkins at Allure na mga ulat sa pagsubok ng code sa 1C at maging static na pagsusuri sa SonarQube - ito ay malayo sa balita, ngunit sa halip ang pangunahing sa mga kumpanya kung saan maraming 1C development.

Pangangasiwa

Maraming gustong sabihin dito. Una, ito ay, siyempre, isang server (1C server cluster). Isang kahanga-hangang bagay, ngunit dahil sa ang katunayan na ito ay isang ganap na itim na kahon, na dokumentado sa sapat na detalye, ngunit sa isang tiyak na paraan - mastering ang paglulunsad ng walang patid na operasyon sa highload mode sa ilang mga server ay ang pulutong ng isang piling ilang na nagsusuot ng isang medalya na may inskripsiyon na "Dalubhasa sa Mga Isyu sa Teknolohikal". Ito ay nagkakahalaga na tandaan na, sa prinsipyo, ang pangangasiwa ng isang 1C server ay hindi naiiba sa pangangasiwa ng anumang iba pang server. Ito ay isang network-based, multi-threaded na application na kumukonsumo ng memory, CPU, at mga mapagkukunan ng disk. Nagbibigay ng sapat na pagkakataon para sa koleksyon at diagnostic ng telemetry.

Ang problema dito ay ang vendor ay hindi nag-aalok ng anumang espesyal sa mga tuntunin ng mga handa na solusyon para sa napaka diagnostic na ito. Oo, mayroong 1C: Instrumentation and Control Center, ang mga ito ay medyo mahusay, ngunit sila ay napakamahal at hindi lahat ay mayroon nito. Mayroong ilang mga pag-unlad sa komunidad para sa pagkonekta ng Grafana, Zabbix, ELK at iba pang mga bagay mula sa karaniwang hanay ng admin, ngunit walang solong solusyon na babagay sa karamihan. Ang gawain ay naghihintay sa kanyang bayani. At kung ikaw ay isang negosyo na nagpaplanong maglunsad sa isang 1C cluster, kailangan mo ng isang Eksperto. Ang iyong sarili sa loob o mula sa labas, ngunit kailangan mo ito. Normal na mayroong isang hiwalay na tungkulin na may mga kakayahan para sa pagpapatakbo ng server, hindi lahat ng gumagamit ng 1C ay dapat malaman ito, kailangan mo lamang na maunawaan na ang ganoong tungkulin ay kinakailangan. Kunin natin ang SAP bilang halimbawa. Doon, ang isang programmer, malamang, ay hindi babangon mula sa kanyang upuan kung hihilingin sa kanya na i-configure ang isang bagay sa server ng application. Baka bobo lang siya at hindi siya mapapahiya. Sa pamamaraan ng SAP mayroong isang hiwalay na tungkulin ng empleyado para dito. Para sa ilang kadahilanan, sa industriya ng 1C pinaniniwalaan na dapat itong pagsamahin sa isang empleyado para sa parehong suweldo. Isa itong maling akala.

Mga disadvantages ng 1C server

Mayroong eksaktong isang minus - pagiging maaasahan. O, kung gusto mo, unpredictability. Naging usap-usapan na ang biglang kakaibang ugali ng server. Ang isang unibersal na lunas - pagpapahinto sa server at pag-clear sa lahat ng mga cache - ay inilarawan pa sa handbook ng eksperto, at kahit isang batch book ay inirerekomenda na gumagawa nito. Kung ang iyong 1C system ay nagsimulang gumawa ng isang bagay na hindi naman dapat gawin ayon sa teorya, oras na upang i-clear ang cache ng data ng session. Ayon sa aking tantiya, tatlong tao lang sa buong bansa ang marunong mag-operate ng 1C server nang walang ganitong procedure at hindi sila nagbabahagi ng mga sikreto, dahil... nabubuhay sila mula dito. Marahil ang kanilang sikreto ay ang paglilinis ng data ng session, ngunit hindi nila sinasabi sa sinuman ang tungkol dito, pare.

Kung hindi, ang 1C server ay kapareho ng aplikasyon gaya ng iba at pinangangasiwaan sa halos parehong paraan, sa pamamagitan ng pagbabasa ng dokumentasyon at pagkatok sa tamburin.

Manggagawa sa pantalan

Ang pagiging kapaki-pakinabang ng paggamit ng containerized na 1C server sa produksyon ay hindi pa napatunayan. Ang server ay hindi naka-cluster sa pamamagitan lamang ng pagdaragdag ng mga node sa likod ng balancer, na nagpapababa ng mga benepisyo ng production containerization sa pinakamababa, at ang kasanayan ng matagumpay na operasyon sa mga container sa highload mode ay hindi pa naitatag. Bilang resulta, ang mga developer lamang ang gumagamit ng Docker+1C upang mag-set up ng mga kapaligiran sa pagsubok. Doon ito ay lubhang kapaki-pakinabang, inilapat, nagbibigay-daan sa iyo upang maglaro sa mga modernong teknolohiya at magpahinga mula sa kawalang-pag-asa ng configurator.

Komersyal na bahagi

Mula sa isang pananaw sa pamumuhunan, pinapayagan ka ng 1C na malutas ang problema ng mabilis na paglulunsad ng mga ideya sa negosyo dahil sa malawak na kakayahan ng mga klase ng aplikasyon. Ang 1C out of the box ay nagbibigay ng napaka disenteng Pag-uulat, pagsasama sa kahit ano, web client, mobile client, mobile application, suporta para sa iba't ibang DBMS, incl. libre, cross-platform parehong server at naka-install na mga bahagi ng kliyente. Oo, ang UI ng mga application ay magiging dilaw, kung minsan ito ay isang minus, ngunit hindi palaging.
Sa pamamagitan ng pagpili sa 1C, nakakakuha ang isang negosyo ng isang hanay ng mga solusyon sa software na nagbibigay-daan sa kanila na bumuo ng napakalawak na hanay ng mga application, pati na rin ang maraming developer sa merkado na gustong mas kaunting pera kaysa sa mga Javaist at sa parehong oras ay makagawa ng mga resulta nang mas mabilis.

Halimbawa, ang gawain ng pagpapadala ng isang PDF invoice sa isang kliyente ay malulutas sa isang oras ng gawain ng mag-aaral. Ang parehong problema sa .NET ay maaaring malutas sa pamamagitan ng pagbili ng isang pagmamay-ari na library, o ilang araw o linggo ng coding ng isang mabagsik, balbas na developer. Minsan, sabay sabay. At oo, pinag-uusapan ko lang ang tungkol sa pagbuo ng PDF. Hindi pa namin sinabi kung saan manggagaling ang panukalang batas na ito. Ang web frontender ay dapat lumikha ng isang form kung saan ang operator ay ipasok ang data, ang backender ay kailangang lumikha ng mga modelo ng dto para sa paglilipat ng JSON, mga modelo para sa pag-iimbak sa database, ang istraktura ng database mismo, ang paglipat dito, ang pagbuo ng isang graphical pagpapakita ng mismong account na ito, at pagkatapos lamang - PDF. Sa 1C, ang buong gawain, mula sa simula, ay nakumpleto sa eksaktong isang oras.

Ang isang ganap na sistema ng accounting para sa isang maliit na stall na may isang proseso ng negosyo na binili/ibinenta ay ginagawa sa loob ng 3 oras. Gamit ang pag-uulat ng mga benta, accounting ng mga kalakal sa mga presyo ng pagbili at pagbebenta, pinaghiwa-hiwalay ayon sa warehouse, kontrol sa mga karapatan sa pag-access, web client at mobile application . Okay, nakalimutan ko ang tungkol sa aplikasyon, na ang aplikasyon ay hindi sa 3 oras, sa anim.

Gaano katagal aabutin ng isang .NET developer ang gawaing ito mula sa pag-install ng visual studio sa isang malinis na computer hanggang sa pagpapakita nito sa customer? Paano ang tungkol sa gastos ng pag-unlad? Parehas na bagay.

Mga lakas ng 1C bilang isang platform

Malakas ang 1C hindi dahil may partikular na bagay tungkol dito na pinakamaganda sa mundo. Sa kabaligtaran, sa bawat indibidwal na subsystem maaari kang makahanap ng isang mas kawili-wiling analogue sa software ng mundo. Gayunpaman, batay sa isang kumbinasyon ng mga kadahilanan, wala akong nakikitang platform na katulad ng 1C. Dito nakasalalay ang komersyal na tagumpay. Ang mga bentahe ng platform ay nakakalat sa kabuuan nito at malinaw na nakikita kapag nakita mo kung paano ito ginagawa sa ibang mga platform. Karaniwan, HINDI ito kahit na mga tampok, ngunit sa kabaligtaran - isang pagtanggi sa mga tampok na pabor sa isang tiyak na paradigma. Ilang halimbawa:

  1. Unicode. Ano ang maaaring maging mas simple? Hindi na kailangang gumamit ng mga single-byte na ASCII encoding sa 2019 (maliban sa pagsasama sa mga sinaunang legacy). Hindi kailanman. Pero hindi. Gayunpaman, ang isang tao sa ilang talahanayan ay gumagamit ng isang solong-byte na varchar at ang application ay magkakaroon ng mga problema sa mga pag-encode. Noong 2015, nabigo ang awtorisasyon sa LDAP ng gitlab dahil sa maling trabaho sa mga pag-encode; hindi pa rin gumagana ang JetBrains IDE sa Cyrillic sa mga pangalan ng file sa lahat ng dako. Nagbibigay ang 1C ng mataas na kalidad na paghihiwalay ng code ng aplikasyon mula sa layer ng database. Doon imposibleng mag-type ng mga talahanayan sa mababang antas at ang mga jamb ng mga walang kakayahan na junior sa antas ng database ay imposible doon. Oo, maaaring may iba pang mga problema sa mga junior na walang kakayahan, ngunit ang iba't ibang mga problema ay mas maliit. Ngayon ay sasabihin mo sa akin na ang iyong application ay idinisenyo nang tama at ang database access layer ay nakahiwalay ayon sa nararapat. Tingnan muli ang iyong corporate custom na Java application. Malapit at matapat. Inaabala ka ba ng iyong konsensya? Tapos masaya ako para sayo.
  2. Pagbilang ng mga dokumento/sangguniang libro. Sa 1C ito ay talagang hindi ang pinaka-kakayahang umangkop at hindi ang pinakamahusay. Ngunit kung ano ang ginagawa nila sa software ng pagbabangko at sa mga self-written accounting system - mabuti, ito ay kadiliman lamang. Alinman sa pagkakakilanlan ay mananatili (at pagkatapos ay "oh, bakit tayo may mga butas"), o sa kabaligtaran, gagawa sila ng generator na gumagana sa pag-lock sa antas ng DBMS (at magiging bottleneck). Sa katunayan, medyo mahirap gawin ang tila simpleng gawain na ito - isang end-to-end enumerator ng mga entity, na may seksyon ng pagiging natatangi batay sa isang tiyak na hanay ng mga susi, prefixation, upang hindi nito harangan ang database sa panahon ng parallel na pagpasok ng data .
  3. Mga identifier ng mga tala sa database. Gumawa ng malakas na desisyon ang 1C - lahat ng link identifier ay ganap na synthetic at iyon lang. At walang mga problema sa mga ibinahagi na database at palitan. Ang mga nag-develop ng iba pang mga system ay matigas ang ulo na lumikha ng isang bagay tulad ng pagkakakilanlan (ito ay mas maikli!), i-drag ang mga ito sa GUI hanggang sa oras na upang lumikha ng ilang nauugnay na mga pagkakataon (at pagkatapos ay matutuklasan sila). Wala ka ba nito? Sa totoo lang?
  4. Mga listahan. Ang 1C ay may medyo matagumpay na mga mekanismo para sa paging sa pamamagitan ng (malalaki) na mga listahan at pag-navigate sa mga ito. Hayaan akong magpareserba kaagad - sa tamang paggamit ng mekanismo! Sa pangkalahatan, ang paksa ay medyo hindi kasiya-siya, hindi ito malulutas nang perpekto: ito ay alinman sa intuitive at simple (ngunit ang panganib ng malaking recordset sa kliyente), o ang paging ay isa o isa pang baluktot. Madalas baluktot ang ginagawa ng mga gumagawa ng paging. Ang mga gumagawa ng isang matapat na scrollbar ay nagdaragdag ng isang database, isang channel at isang kliyente.
  5. Mga pinamamahalaang form. Walang alinlangan, sa web client ang interface ay hindi gumagana nang perpekto. Ngunit ito ay gumagana. Ngunit para sa maraming iba pang mga sistema ng accounting at pagbabangko, ang paglikha ng isang malayong lugar ng trabaho ay isang proyekto sa antas ng enterprise. Disclaimer: sa kabutihang palad para sa mga orihinal na ginawa ito sa web, hindi ito makakaapekto.
  6. Mobile app. Kamakailan, maaari ka ring sumulat ng mga mobile application habang nasa parehong ecosystem. Ito ay medyo mas kumplikado dito kaysa sa isang web client; pinipilit ka ng mga detalye ng mga device na magsulat ng partikular para sa kanila, ngunit, gayunpaman, hindi ka umuupa ng hiwalay na pangkat ng mga mobile developer. Kung kailangan mo ng isang application para sa mga panloob na pangangailangan ng isang kumpanya (kapag ang isang mobile na solusyon sa isang corporate na problema ay mas mahalaga kaysa sa isang dilaw na disenyo ng UI), gagamitin mo lang ang parehong platform sa labas ng kahon.
  7. Pag-uulat. Sa salitang ito, hindi ko ibig sabihin ang BI system na may malaking data at lag sa proseso ng ETL. Ito ay tumutukoy sa mga ulat ng mga kawani ng pagpapatakbo na nagbibigay-daan sa iyo upang masuri ang estado ng accounting dito at ngayon. Balanse, mutual settlements, re-grading, atbp. Ang 1C ay lumabas sa kahon na may sistema ng pag-uulat na may mga naiaangkop na setting para sa mga pagpapangkat, filter, at visualization sa panig ng user. Oo, may mga mas malamig na analogue sa merkado. Ngunit hindi sa loob ng balangkas ng isang all-in-one na solusyon at sa presyo kung minsan ay mas mataas kaysa sa isang all-in-one na solusyon. At mas madalas, baligtad pa ito: pag-uulat lamang, ngunit mas mahal kaysa sa buong platform, at mas masahol pa sa kalidad.
  8. Mga napi-print na form. Well, gamitin ang .NET upang malutas ang problema ng pagpapadala ng mga salary slip sa PDF sa mga empleyado sa pamamagitan ng email. At ngayon ang gawain ng pag-print ng mga invoice. Paano ang tungkol sa pag-save ng kanilang mga kopya sa parehong PDF? Para sa 1C nickname, ang pag-output ng anumang layout sa PDF ay +1 na linya ng code. Nangangahulugan ito ng + 40 segundo ng oras ng pagtatrabaho, sa halip na mga araw o linggo sa ibang wika. Ang mga naka-print na layout ng form sa 1C ay napakadaling bumuo at sapat na makapangyarihan upang makipagkumpitensya sa mga bayad na katapat. Oo, malamang, walang maraming interactive na pagkakataon sa 1C spreadsheet na mga dokumento; hindi ka mabilis na makakakuha ng 3D diagram na may scaling gamit ang OpenGL. Pero kailangan ba talaga?

Ang mga ito ay ilan lamang sa mga halimbawa kung saan ang paglilimita sa functionality o pagpapatupad ng mga kompromiso ay lumalabas na isang mahalagang benepisyo sa arkitektura sa hinaharap. Kahit na isang kompromiso o hindi ang pinaka-epektibong pagpipilian - ito ay nasa kahon at kinuha para sa ipinagkaloob. Ang independiyenteng pagpapatupad nito ay magiging imposible (dahil ang mga naturang desisyon ay dapat gawin sa simula ng proyekto, at walang oras para doon, at walang arkitekto), o ilang mga mamahaling pag-ulit. Sa bawat isa sa mga nakalistang punto (at hindi ito kumpletong listahan ng mga solusyon sa arkitektura), maaari mong sirain at ipakilala ang mga paghihigpit na humaharang sa pag-scale. Sa anumang kaso, ikaw, bilang isang negosyante, ay kailangang tiyakin na ang iyong mga programmer, kapag gumagawa ng isang "sistema mula sa simula," ay may mga tuwid na kamay at gagawa kaagad ng mga banayad na isyu sa system.

Oo, tulad ng sa anumang iba pang kumplikadong sistema, ang 1C mismo ay mayroon ding mga solusyon na humaharang sa pag-scale sa ilang mga aspeto. Gayunpaman, inuulit ko, batay sa isang kumbinasyon ng mga kadahilanan, ang halaga ng pagmamay-ari, at ang bilang ng mga problema na nalutas nang maaga, wala akong nakikitang karapat-dapat na katunggali sa merkado. Para sa parehong presyo, makakakuha ka ng isang financial application framework, isang clustered balanced server, na may UI at web interface, na may isang mobile application, na may pag-uulat, pagsasama at marami pang iba. Sa mundo ng Java, umarkila ka ng front-end at back-end na team, i-debug ang mababang antas na mga shoal ng home-written na server code at magbabayad nang hiwalay para sa 2 mobile application para sa 2 mobile OS.

Hindi ko sinasabi na malulutas ng 1C ang lahat ng mga kaso, ngunit para sa isang panloob na aplikasyon ng korporasyon, kapag hindi na kailangang i-brand ang UI - ano pa ang kailangan?

Lumipad sa ang ungguwento

Marahil ay nakakuha ka ng impresyon na ililigtas ng 1C ang mundo at ang lahat ng iba pang paraan ng pagsulat ng mga corporate system ay mali. Hindi naman ganoon. Mula sa pananaw ng isang negosyante, kung pipiliin mo ang 1C, at bilang karagdagan sa mabilis na time-to-market, dapat mong isaalang-alang ang mga sumusunod na disadvantages:

  • pagiging maaasahan ng server. Kailangan talaga ng mga de-kalidad na espesyalista na makatitiyak sa walang patid na operasyon nito. Hindi ko alam ang isang handa na programa sa pagsasanay para sa mga naturang espesyalista mula sa vendor. May mga kursong ihahanda para sa Expert exam, ngunit ito, sa aking palagay, ay hindi sapat.
  • Suporta. Tingnan ang nakaraang punto. Upang magkaroon ng suporta mula sa vendor, kailangan mong bilhin ito. Para sa ilang kadahilanan, hindi ito tinatanggap sa industriya ng 1C. At sa SAP, halos kailangan itong bilhin at hindi ito nakakaabala sa sinuman. Kung walang suporta sa korporasyon at walang eksperto sa staff, maaari kang maiwang mag-isa sa mga 1C glitches.
  • Gayunpaman, hindi mo ganap na magagawa ang lahat sa 1C. Ito ay isang tool at tulad ng bawat tool ay mayroon itong mga limitasyon sa kakayahang magamit. Sa landscape ng 1C, napakainam na magkaroon ng arkitekto ng sistemang "hindi-1C".
  • Ang magagandang 1C na palayaw ay hindi mas mura kaysa sa mahuhusay na programmer sa ibang mga wika. Bagaman, ang mga masasamang programmer ay mahal na umupa, anuman ang wikang kanilang sinusulatan.

tuldok natin ang mga tuldok

  • Ang 1C ay isang mabilis na pag-unlad ng aplikasyon (RAD) na balangkas para sa negosyo at iniakma para dito.
  • Three-tier na link na may suporta para sa mga pangunahing DBMS, client UI, isang napakahusay na ORM at pag-uulat
  • Malawak na posibilidad para sa pagsasama sa mga system na kayang gawin ang hindi kayang gawin ng 1C. Kung gusto mo ng machine learning, kumuha ng Python at ipadala ang resulta sa 1C sa pamamagitan ng http o RabbitMQ
  • Hindi na kailangang magsikap na gawin ang lahat gamit ang 1C, kailangan mong maunawaan ang mga lakas nito at gamitin ang mga ito para sa iyong sariling mga layunin
  • Nababagot sa 1C ang mga developer na gustong maghukay sa mga teknolohikal na framework na gadget at muling magdisenyo tuwing N taon sa isang bagong makina. Napaka-conservative ng lahat doon.
  • Ang mga developer ay naiinip din dahil napakakaunting alalahanin para sa kanila mula sa tagagawa. Nakakainip na wika, mahinang IDE. Nangangailangan sila ng modernisasyon.
  • Sa kabilang banda, ang mga developer na hindi nakakahanap ng kasiyahan sa pamamagitan ng paggamit at pag-aaral ng isa pang teknolohiyang tinatamasa nila ay mga masasamang developer. Sila ay magbubulungan at lilipat sa ibang ecosystem.
  • Ang mga employer na hindi pinapayagan ang kanilang mga 1C na palayaw na magsulat ng isang bagay sa Python ay masamang employer. Mawawalan sila ng mga empleyadong may matanong na pag-iisip, at sa kanilang lugar ay darating ang mga monkey coders na, habang sumasang-ayon sa lahat, ay mag-drag ng corporate software sa swamp. Kakailanganin pa rin itong muling isulat, kaya mas mabuting mag-invest ng kaunti sa Python nang mas maaga?
  • Ang 1C ay isang komersyal na kumpanya at nagpapatupad ng mga feature na batay lamang sa sarili nitong mga interes at kahusayan. You can’t blame her for this, business must think about profit, that’s life
  • Kumikita ang 1C sa pamamagitan ng pagbebenta ng mga solusyon sa mga problema sa negosyo, hindi sa mga problema ng developer ni Vasya. Ang dalawang konsepto na ito ay magkakaugnay, ngunit ang priyoridad ay eksakto kung ano ang sinabi ko. Kapag ang developer na si Vasya ay handa nang magbayad para sa isang personal na lisensya para sa 1C: Resharper, ito ay lilitaw nang mabilis, "Resharper" ni A. Orefkova ay patunay nito. Kung sinusuportahan ito ng vendor, at hindi nilalabanan ito, lilitaw ang isang merkado para sa software para sa mga developer. Ngayon ay may isa't kalahating manlalaro sa market na ito na may mga kaduda-dudang resulta, at lahat dahil ang pagsasama sa IDE ay negatibo at lahat ay ginagawa sa saklay.
  • Ang pagsasanay ng isang multi-machine operator ay mawawala sa limot. Ang mga modernong application ay masyadong malaki upang matandaan ang parehong mula sa gilid ng code at mula sa panig ng paggamit ng negosyo. Ang 1C server ay nagiging mas kumplikado din; magiging imposibleng hawakan ang lahat ng uri ng kadalubhasaan sa isang empleyado. Dapat itong magsama ng isang pangangailangan para sa mga espesyalista, na nangangahulugan ng pagiging kaakit-akit ng propesyon ng 1C at pagtaas ng mga suweldo. Kung dati ay nagtrabaho si Vasya ng three-in-one para sa isang suweldo, ngayon kailangan mong umarkila ng dalawang Vasyas at ang kumpetisyon sa mga Vasya ay maaaring mag-udyok sa pangkalahatang paglago ng kanilang antas.

Konklusyon

Ang 1C ay isang napakakarapat-dapat na produkto. Sa aking hanay ng presyo, hindi ko alam ang anumang mga analogue, isulat sa mga komento kung mayroon man. Gayunpaman, ang pag-agos ng mga developer mula sa ecosystem ay nagiging mas at higit na kapansin-pansin, at ito ay isang "brain drain", kahit paano mo ito tingnan. Ang industriya ay gutom para sa modernisasyon.
Kung ikaw ay isang developer, huwag mabitin sa 1C at huwag isipin na ang lahat ay mahiwaga sa ibang mga wika. Habang ikaw ay isang junior, marahil. Sa sandaling kailangang lutasin ang isang bagay na mas malaki, ang mga handa na solusyon ay kailangang hanapin nang mas matagal at makumpleto nang mas masinsinang. Sa mga tuntunin ng kalidad ng "mga bloke" kung saan maaaring itayo ang isang solusyon, ang 1C ay napakahusay.

At isa pang bagay - kung dumating sa iyo ang isang palayaw na 1C upang mag-hire, maaaring ligtas na maitalaga ang palayaw na 1C sa posisyon ng mga lead analyst. Ang kanilang pag-unawa sa gawain, lugar ng paksa, at mga kasanayan sa pagkabulok ay mahusay. Sigurado ako na ito ay tiyak dahil sa sapilitang paggamit ng DDD sa 1C development. Ang tao ay sinanay na mag-isip tungkol sa kahulugan ng gawain una sa lahat, tungkol sa mga koneksyon sa pagitan ng mga bagay ng lugar ng paksa, at sa parehong oras ay may teknikal na background sa mga teknolohiya ng pagsasama at mga format ng palitan ng data.

Magkaroon ng kamalayan na ang perpektong balangkas ay hindi umiiral at alagaan ang iyong sarili.
Mabuti sa lahat!

PS: maraming salamat po speshuric para sa tulong sa paghahanda ng artikulo.

Ang mga rehistradong user lamang ang maaaring lumahok sa survey. Mag-sign in, pakiusap

Mayroon ka bang 1C sa iyong negosyo?

  • 13,3%Hindi naman.71

  • 30,3%Meron, pero sa accounting department lang somewhere. Mga pangunahing sistema sa iba pang mga platform162

  • 41,4%Oo, gumagana dito ang pangunahing proseso ng negosyo221

  • 15,0%Dapat mamatay ang 1C, ang hinaharap ay pag-aari ni %technology_name%80

534 na user ang bumoto. 99 user ang umiwas.

Pinagmulan: www.habr.com

Magdagdag ng komento