1C - Hyvä ja paha. Pisteiden järjestely holivareissa noin 1C

Ystävät ja kollegat, Habresta on viime aikoina ollut useammin artikkeleita, joissa vihataan 1C:tä kehitysalustana, ja sen puolustajien puheita. Nämä artikkelit tunnistivat yhden vakavan ongelman: useimmiten 1C:n kriitikot arvostelevat sitä asennosta "ei hallitse sitä", moittivat ongelmia, jotka ovat tosiasiassa helposti ratkaistavissa, ja päinvastoin, eivät kosketa ongelmiin, jotka ovat todella tärkeitä, arvoisia. keskustellaan ja myyjä ei ratkaise niitä. Uskon, että on järkevää tehdä 1C-alustan hillitty ja tasapainoinen tarkistus. Mitä se voi tehdä, mitä se ei pysty, mitä sen pitäisi tehdä, mutta ei tee, ja jälkiruoaksi, mitä se tekee räjähdysmäisesti, ja kehittäjäsi yrityksessä %technology_name% tekevät sata vuotta ja heittävät sen pois. enemmän kuin yksi vuosibudjetti.

Tämän seurauksena sinä johtajana tai arkkitehtina saat selkeän käsityksen siitä, mihin tehtävään 1C:n käyttäminen on sinulle hyödyllistä ja missä se pitää polttaa kuumalla raudalla. Kehittäjänä "ei-1C" -maailmassa voit nähdä, mitä 1C:ssä on, mikä aiheuttaa meteliä. Ja 1C-kehittäjänä voit verrata järjestelmääsi muiden kielten ekosysteemeihin ja ymmärtää sijaintisi ohjelmistokehityksen koordinaattijärjestelmässä.

Leikkauksen alla on paljon paksuja hyökkäyksiä 1C:tä, 1C:n arvostelijoita, Javaa, .NET:iä ja yleensäkin vastaan... Fani on täynnä, tervetuloa!

Tietoja minusta

Olen tuntenut keskustelun aiheen noin vuodesta 2004 lähtien. Olen ohjelmoinut luultavasti 6-vuotiaasta lähtien, siitä hetkestä lähtien, kun sain kirjan professori Fortranista, jossa on sarjakuvia kissasta, varpusesta ja toukista. Analysoin kissan kirjoittamia ohjelmia kirjan kuvista ja selvitin mitä ne tekivät. Ja kyllä, minulla ei tuolloin ollut oikeaa tietokonetta, mutta kirjan leviämisestä oli piirros ja painoin rehellisesti paperipainikkeita syöttäen komennot, joita olin vakoillut kissa X: tä.

Sitten oli BK0011 ja BASIC koulussa, C++ ja kokoonpanot yliopistossa, sitten 1C ja sitten niin monet muut asiat, joita olen liian laiska muistamaan. Viimeiset 15 vuotta olen ollut pääasiassa mukana 1C:ssä, ei vain koodauksen suhteen, vaan 1C:ssä yleensä. Tehtävien asettaminen, hallinto ja devops täällä. Viimeiset 5 vuotta olen ollut mukana sosiaalisesti hyödyllisissä toimissa, jotka liittyvät kehitys- ja automaatiotyökalujen kehittämiseen muille 1C-käyttäjille, artikkeleiden ja kirjojen kirjoittamiseen.

Päätetään keskustelun aihe

Ensin määritellään, mistä puhumme, koska kirjaimet "1C" voivat tarkoittaa monia asioita. Tässä tapauksessa kirjaimilla "1C" tarkoitamme yksinomaan nykyaikaisen, kahdeksannen version kehityskehystä "1C: Enterprise". Emme puhu paljon valmistajasta ja sen käytännöistä (mutta meidän on tehtävä vähän Emme keskustele erityisistä tämän kehyksen avulla kirjoitetuista sovelluksista). Tekniikka on erillinen, sovellukset eli konfiguraatiot ovat erillisiä.

Korkean tason arkkitehtuuri 1C: Enterprise

En turhaan mainitse sanaa "kehys". Kehittäjän näkökulmasta 1C-alusta on juuri kehys. Ja sinun on kohdeltava sitä täsmälleen kuin kehystä. Ajattele sitä Spring tai ASP.NET, jonka suorittaa jokin ajonaika (JVM tai CLR). Sattuu niin, että perinteisen ohjelmoinnin ("not 1C") maailmassa jako kehyksiin, virtuaalikoneisiin ja tiettyihin sovelluksiin on luonnollista, koska nämä komponentit ovat yleensä eri valmistajien kehittämiä. 1C-maailmassa ei ole tapana erottaa nimenomaisesti kehityskehystä ja itse ajonaikaa, lisäksi 1C itse kehittää tiettyjä puitteita käyttämällä. Tämän seurauksena syntyy jonkin verran hämmennystä. Siksi artikkelin puitteissa meidän on tarkasteltava 1C:tä useilta sivuilta kerralla ja luokiteltava se useille koordinaattiakseleille. Ja jokaiseen koordinaattiakseliin laitamme lapion ruskeaa ainetta ja tarkastelemme olemassa olevan ratkaisun ominaisuuksia, etuja ja haittoja.

Näkökulmat 1C:stä

1C ostajalle

Ostaja ostaa automaatiojärjestelmän, jolla hän voi nopeasti ratkaista oman liiketoimintansa automatisoinnin ongelmat. Yritys voi olla pieni kioski tai se voi olla suuri holdingyhtiö. On selvää, että näiden yritysten tarpeet ovat erilaisia, mutta molempia tukee yksi alustakoodipohja.

1C:n ostajalle tämä on nopea markkinoilletuloaika. Nopeasti. Nopeampi kuin Java, C# tai JS. Keskiverto. Sairaalan ympärillä. On selvää, että Reactia käyttävästä käyntikorttisivustosta tulee parempi, mutta WMS-järjestelmän taustaosa käynnistyy nopeammin 1C:ssä.

1C työkaluna

Jokaisella teknologisella ratkaisulla on sovellettavuusrajat. 1C ei ole yleiskäyttöinen kieli, se ei elä erillään kehyksestään. On suositeltavaa käyttää 1C:tä, kun tarvitset:

• palvelinsovellus
• sovellus, jossa rahoitus näkyy
• valmiilla käyttöliittymällä, ORM:lla, raportoinnilla, XML/JSON/COM/PDF/YourDataTransferingFormat
• taustaprosessien ja töiden tuella
• roolipohjaisella suojauksella
• käsikirjoitettavalla liiketoimintalogiikalla
• kyky luoda nopeasti prototyyppi ja lyhyt markkinoilletuloaika

Et tarvitse 1C:tä, jos haluat:

• koneoppimista
• GPU-laskelmat
• tietokonegrafiikka
• matemaattiset laskelmat
• CAD-järjestelmä
• signaalinkäsittely (ääni, video)
• highload http-puhelut sadoilla tuhansilla rps

1C valmistusyrityksenä

On syytä ymmärtää, mikä on 1C:n liiketoiminta ohjelmistovalmistajana. 1C-yritys myy ratkaisuja liiketoiminnan ongelmiin automatisoinnin avulla. Erilaisia ​​yrityksiä, isoja tai pieniä, mutta sitä hän myy. Keinoja tämän tavoitteen saavuttamiseksi ovat yrityssovellukset. Kirjanpitoon, palkanlaskentaan jne. Näiden sovellusten kirjoittamiseen yritys käyttää omaa liiketoimintasovelluskehitysalustaa. Erityisesti räätälöity näiden samojen yrityssovellusten yleisiin tehtäviin:

• talouskirjanpito
• helppo mukauttaa liiketoimintalogiikkaa
• laajat integraatiomahdollisuudet heterogeenisissä IT-ympäristöissä

Valmistajana 1C uskoo, että tämä on strategia, jonka avulla voit työskennellä kumppaneiden ja asiakkaiden kanssa win-win-tilassa. Tästä voi kiistellä, mutta suunnilleen näin yritys mainostaa itseään: valmiita ratkaisuja liiketoiminnan ongelmiin, jotka kumppanit voivat nopeasti räätälöidä ja integroida mihin tahansa IT-maisemaan.

Kaikkia vaatimuksia tai toiveita 1C:stä kehyksenä tulee tarkastella yksinomaan tämän prisman kautta. "Haluamme OOP:n 1C:ssä", kehittäjät sanovat. "Kuinka paljon meille maksaa OOP:n tukeminen alustassa, auttaako tämä meitä lisäämään laatikoiden myyntiä?", sanoo 1C. Avaa "prismansa" myydä ratkaisuja yritysongelmiin:

- Hei, liike, haluatko OOP:n 1C:hen?
- Auttaako tämä minua ratkaisemaan ongelmani?
- Kuka tietää...
– Silloin ei ole tarvetta

Tämä lähestymistapa voi olla hyvä tai huono riippuen siitä, kuka sitä katsoo, mutta niin se vain on. Kun puhutaan siitä, että 1C:ssä ei ole ominaisuutta X, sinun on ymmärrettävä, että se ei ole olemassa syystä, vaan valinnan "toteutuskustannukset vs voittosumma" yhteydessä.

Tekninen luokitus

"Itse asiassa Odinesniks tekee parhaansa käyttääkseen parhaita malleja, jotka huolehtivat metodologit ja 1C-alustan kehittäjät ovat huolellisesti valinneet.
Kun kirjoitat typerää koodia yksinkertaiselle hallittavalle lomakkeelle, todellisuudessa käytät sitä malli-näkymä-ohjain с kaksisuuntainen tietojen sidonta в kolmikerroksinen data-sovellusmoottori, maustettu korkean tason objekti-relaatiokartoitus pohjassa deklaratiivinen metatietojen kuvausjolla on omansa alustasta riippumaton kyselykieli, C deklaratiivinen dataohjattu käyttöliittymä, täydellinen läpinäkyvä serialisointi ja toimialuesuuntautunut ohjelmakieli.

1C-kehittäjät eroavat länsimaisista kollegoistaan ​​PR-alalla. He rakastavat antaa mille tahansa paskalle suuren nimen ja juoksevat sen kanssa kuin likaisen pussin.
A. Orefkov

1C-alustalla on klassinen 3-tasoinen arkkitehtuuri, jonka keskellä on sovelluspalvelin (tai sen emulointi pienellä rahalla pienille kauppiaille). Tietokannanhallintajärjestelmänä käytetään joko MS SQL:ää tai Postgresia. Myös Oraclelle ja IBM DB2:lle on olemassa tuki, mutta tämä on melko esoteerista. Kukaan ei tiedä mitä tapahtuu, jos 1C toteutetaan näissä tietokantoissa keskisuurella ja suurella kuormituksella. Uskon, että 1C itse ei tiedä tätä.

Asiakasosa on joko käyttäjän koneelle asennettu ohut asiakaskone tai web-asiakas. Tärkein ominaisuus on, että ohjelmoijat eivät kirjoita kahta eri koodia, he kirjoittavat yhden sovelluksen, yhdellä kielellä, ja voit näyttää sen selaimessa, jos on halu tai tarve. Kuka halusi todellisen täyden pinon ja yhden kielen etu- ja taustajärjestelmään, node.js? He eivät koskaan onnistuneet tekemään täsmälleen samaa asiaa loppuun asti. Todellinen täysi pino on olemassa, mutta sinun on kirjoitettava se 2C:ssä. Kohtalon ironia, sellaisia ​​asioita :)

Pilvi SaaS -ratkaisu 1C:Fresh toimii myös selaintilassa, jossa et voi ostaa 1C:tä, vaan vuokrata pienen tietokannan ja pitää kirjaa shawarman myynnistä siellä. Vain selaimessa asentamatta tai määrittämättä mitään.

Lisäksi on olemassa vanha asiakas, jota 1C:ssä kutsutaan "tavalliseksi sovellukseksi". Legacy on perintöä, tervetuloa sovellusten maailmaan vuonna 2002, mutta puhumme silti ekosysteemin nykytilasta.

1C-palvelinosa tukee klusterointia ja skaalausta lisäämällä klusteriin uusia koneita. Täällä on rikottu melko paljon kopioita ja tästä tulee artikkelissa erillinen osio. Lyhyesti sanottuna tämä ei ole aivan sama kuin muutaman täsmälleen saman esiintymän lisääminen HAProxyn taakse.

Sovelluskehityskehys käyttää omaa ohjelmointikieltä, joka muistuttaa karkeasti venäjäksi käännettynä hieman parannettua VB6:ta. Ihmisille, jotka vihaavat kaikkea venäläistä, jotka eivät usko, että "jos" käännetään "jos", tarjotaan toinen syntaksivaihtoehto. Nuo. Voit halutessasi kirjoittaa sen 1C:llä siten, että sitä ei voi erottaa VB:stä.

Tämä ohjelmointikieli on tärkein syy 1C:n lempinimien vihaan heidän alustaansa kohtaan. Todettakoon, ei ilman syytä. Kieli suunniteltiin mahdollisimman yksinkertaiseksi, ja se on suunniteltu täyttämään mantra "KEHITTÄJÄT, KEHITTÄJÄT" ainakin IVY:n mittakaavassa. Tällaisen ratkaisun kaupallinen olemus on mielestäni selvästi näkyvissä: enemmän kehittäjiä, suurempi markkinakattavuus. Tämä toteutui eri arvioiden mukaan 45 prosentista 95 prosenttiin. Sanon heti, että kirjoittaminen kielelläsi on todella helpompaa. Ja tiedän aika monta ohjelmointikieliä.

Aloitetaan kielestä.

1C ohjelmointikieli

Samaan aikaan järjestelmän vahva ja heikko kohta. Tarjoaa helpon syöttämisen ja luettavuuden. Toisaalta sitä ei ole päivitetty sen jälkeen, kun versio 8 julkaistiin vuonna 2002, ja se on moraalisesti vanhentunut. Joku sanoo "pääasiallinen haittapuoli on, että OOP:ta ei ole", ja he ovat väärässä. Ensinnäkin PLO ei pidä Nuralievista, vaan myös Torvaldsista. Ja toiseksi, OOP on edelleen olemassa.

Kehittäjän näkökulmasta hänellä on käytössään kehys, jonka perusluokat näkyvät DBMS:ssä. Kehittäjä voi ottaa perusluokan “Hakemisto” ja periä siitä “Clients”-hakemiston. Se voi lisätä siihen uusia luokkakenttiä, esimerkiksi INN ja Address, ja tarvittaessa myös ohittaa (ohita) perusluokan menetelmiä, esimerkiksi OnWrite/AtRecord-metodia.

Kehys on suunniteltu siten, että syvempää periytymistä harvoin tarvitaan, ja OOP:n rajoitus on mielestäni järkevä. 1C keskittyy Domain Driven Developmentiin ja saa miettimään ennen kaikkea kehitettävän ratkaisun aihealuetta, mikä on hyvä asia. Ei ole vain kiusausta, mutta ei myöskään tarvetta kirjoittaa 10 erilaista DTO:ta ja ViewModelia vain näyttääksesi tietoja toimialueelta jossain. 1C-kehittäjä toimii aina yhden entiteetin kanssa sotkematta havaintokontekstia tusinalla samannimisellä luokalla, jotka edustavat samaa kokonaisuutta, mutta eri puolelta. Mikä tahansa .NET-sovellus esimerkiksi sisältää välttämättä viisi tai kaksi ViewModelia ja DTO:ta JSON-serialisointia ja tiedonsiirtoa varten asiakkaalta palvelimelle. Ja noin 10-15 % sovelluskoodistasi käytetään tietojen siirtämiseen luokasta toiseen käyttämällä kyniä tai kainalosauvoja, kuten AutoMapper. Tämä koodi on kirjoitettava ja ohjelmoijille on maksettava sen luomisesta ja ylläpitämisestä.

Osoittautuu, että 1C-kieltä on vaikea kehittää mutkistamatta sitä valtavirran kielten tasolle, mikä menettää yksinkertaisuuden edun. Mikä on myyjän tehtävä pohjimmiltaan ratkaistava: laatia vakioratkaisu, jonka jokainen kadulta kiinni jäänyt opiskelija voi räätälöidä vaaditulla laatutasolla (eli kojuista suureen tehtaaseen kattava tapaus valmistuu). Jos olet kioski, ota opiskelija, jos olet tehdas, ota guru toteuttajaltasi. Se, että toteutuskumppanit myyvät opiskelijoita gurun hintaan, ei ole kehyksen ongelma. Arkkitehtonisesti viitekehyksen on ratkaistava molempien ongelmat, vakiokokoonpanojen koodin (jotka myimme yrityksille räätälöinnin lupauksella) tulisi olla opiskelijan ymmärrettävissä ja gurun pitäisi pystyä ymmärtämään mitä haluat.

Se, mikä mielestäni todella puuttuu kielestä, pakottaa kirjoittamaan enemmän kuin jaksaisi, on asiakkaan maksaman ajan hukkaa.

• Mahdollisuus kirjoittaa tasolle, esimerkiksi TypeScript (tuloksena kehittyneemmät koodianalyysityökalut IDE:ssä, uudelleenmuodostus, vähemmän loukkaavia jambeja)
  Toimintojen saatavuus ensimmäisen luokan objekteina. Hieman monimutkaisempi konsepti, mutta tyypillisen kattilakoodin määrää voitaisiin vähentää huomattavasti. Opiskelijan ymmärrys koodista, IMHO, jopa lisääntyisi volyymin pienentyessä
• Universal kokoelma literaalit, alustusohjelmat. Sama asia - kirjoitettavan ja/tai silmin katsottavan koodin määrän vähentäminen. Kokoelmien täyttäminen vie yli 9000 % 1C:n ohjelmointiajasta. Tämän kirjoittaminen ilman syntaktista sokeria on pitkää, kallista ja virhealtista. Yleisesti ottaen LOC:n määrä 1C-ratkaisuissa ylittää kaikki ajateltavissa olevat rajat verrattuna käytettävissä oleviin avoimiin kehyksiin ja yleensä kaikkiin yrityksesi Javaihin yhteensä. Kieli on monisanaista, ja tämä muuttuu datamääräksi, muistiksi, IDE-jarruiksi, ajaksi, rahaksi...
• lopuksi rakenteet Minulla on hypoteesi, että tämä konstruktio puuttuu, koska he eivät löytäneet onnistunutta käännöstä venäjäksi :)
• Omat tietotyypit (ilman OOP:ta), Typen analogit VB6:sta. Sen avulla et kirjoita rakenteita käyttämällä kommentteja BSP:ssä ja taikamenetelmiä, jotka rakentavat näitä rakenteita. Saamme: vähemmän koodia, vihjettä pisteen kautta, nopeampi ratkaisu ongelmaan, vähemmän kirjoitusvirheistä ja rakenteiden puuttuvista ominaisuuksista johtuvia virheitä. Nyt käyttäjärakenteiden kirjoittaminen on täysin Standard Subsystem Libraryn kehitystiimin vastuulla, joka ansiokseensa kirjoittaa huolella kommentteja läpäistyjen parametrirakenteiden odotettavissa olevista ominaisuuksista.
• Ei sokeria, kun työskentelet asynkronisten puhelujen kanssa verkkoasiakassovelluksessa. Callback-hell ProcessingNotifications-muodossa on väliaikainen kainalosauva, joka aiheutuu pääselaimien API:n äkillisestä muutoksesta, mutta näin ei voi elää jatkuvasti yhä enemmän. Älä lisää tukea tälle paradigmalle pää-IDE:ssä, niin asiat pahenevat entisestään.

Tämä on yksi kiireellisistä ongelmista, on selvää, että luettelo voisi olla paljon suurempi, mutta emme saa unohtaa, että tämä ei silti ole yleiskäyttöinen kieli, se ei vaadi monisäikeistystä, lambda-toimintoja, pääsyä GPU: hin ja nopeaa liukulukuja. Tämä on liiketoimintalogiikan komentosarjakieli.

Ohjelmoija, joka on jo työskennellyt paljon tämän kielen kanssa, tutkii js:ää tai c#:a, kyllästyy tämän kielen puitteissa. Se on tosiasia. Hän tarvitsee kehitystä. Asteikon toisella puolella toimittajalle on määritettyjen ominaisuuksien käyttöönoton kustannukset verrattuna tulojen kasvuun niiden käyttöönoton jälkeen. Täällä minulla ei ole tietoa siitä, mikä on tällä hetkellä yrityksen silmissä painavampaa.

Kehitysympäristö

Asiat eivät suju täälläkään. Kehitysympäristöjä on kaksi. Ensimmäinen on toimitukseen sisältyvä Configurator. Toinen on Eclipsen pohjalta kehitetty Enterprise Development Tools -ympäristö tai lyhyesti EDT.

Konfiguraattori tarjoaa täyden valikoiman kehitystehtäviä, tukee kaikkia ominaisuuksia ja on markkinoiden pääympäristö. Se on myös moraalisesti vanhentunut, ei kehity huhujen mukaan - itsessään olevan teknisen velan määrän vuoksi. Tilannetta voitaisiin parantaa avaamalla sisäinen API (ystävyyssuhteen muodossa Lumiukko A. Orefkova tai itsenäisesti), mutta näin ei ole. Käytäntö on osoittanut, että yhteisö kirjoittaa omia ominaisuuksiaan IDE:hen, kunhan toimittaja ei puutu asiaan. Mutta meillä on mitä meillä on. Konfiguraattori oli loistava vuosina 2004-2005, muistutti kovasti sen ajan Visual Studiota, paikoin jopa viileämpää, mutta se oli jumissa noihin aikoihin.

Lisäksi keskimääräisen standardiratkaisun määrä on kasvanut useita kertoja sen jälkeen, ja nykyään IDE ei yksinkertaisesti pysty selviytymään sille syötettävän koodin määrästä. Käytettävyys ja refaktorointiominaisuudet eivät ole edes nollaa, ne ovat miinuksella. Kaikki tämä ei lisää innostusta kehittäjiin ja he haaveilevat muuttamisesta muihin ekosysteemeihin ja jatkavansa siellä paskan koodaamista, mutta miellyttävässä ympäristössä, joka ei sylke naamaan käyttäytymisellään.

Vaihtoehtona tarjotaan tyhjästä kirjoitettu IDE, joka on rakennettu Eclipselle. Siellä lähteet, kuten kaikissa muissakin ohjelmistoissa, elävät tekstitiedostoina, tallennetaan GIT:hen, vedä pyyntöhaaroja, kaikki tämä. Huono puoli on se, että se ei ole jättänyt beta-tilaa moneen vuoteen, vaikka se paranee jokaisen julkaisun myötä. En kirjoita EDT:n haitoista, tänään se on miinus, huomenna se on kiinteä ominaisuus. Tällaisen kuvauksen merkitys katoaa nopeasti. Nykyään EDT:ssä on mahdollista kehittää, mutta se on epätavallista, että sinun on varauduttava tiettyyn määrään IDE-virheitä.

Jos katsot tilannetta edellä mainitun "1C-prisman" kautta, saat jotain tällaista: uuden IDE:n julkaisu ei lisää laatikoiden myyntiä, mutta KEHITTÄJIEN ulosvirtaus saattaa vähentyä. On vaikea sanoa, mitä ekosysteemiä odottaa kehittäjien mukavuuden suhteen, mutta Microsoft on jo tyrkyttänyt mobiilikehittäjät tarjoamalla heille palvelujaan liian myöhään.

Kehityksen hallinta

Kaikki täällä on huomattavasti parempaa kuin koodin kirjoittamisessa, varsinkin viime aikoina, kun yhteisön ponnistelut nostivat päivänvaloon hallinnon automaation ongelmat, lanseerasivat prototyyppejä, jotka vaativat 1C-arkiston heittämistä roskakoriin ja gitin, pikasyyttelyn, kooditarkistuksen käyttöä. , staattinen analyysi, automaattinen käyttöönotto jne. Alustaan ​​on lisätty monia ominaisuuksia, jotka lisäävät kehitystehtävien automatisointia. Kaikki nämä ominaisuudet lisättiin kuitenkin vain ja yksinomaan omien suurten tuotteidemme kehittämiseen, kun kävi selväksi, ettemme pärjäisi ilman automaatiota. Siellä oli automaattinen yhdistäminen, kolmisuuntainen vertailu KDiffin kanssa ja kaikkea muuta. Julkaistu Githubissa gitconverter, joka suoraan sanottuna vetäytyi ideologisesti pois projektista gitsync, mutta muokattu sopimaan toimittajayrityksen prosesseihin. Avoimen lähdekoodin itsepäisten kaverien ansiosta 1C:n kehitysautomaatio pääsi liikkeelle. Avoin API konfiguraattorille, IMHO, muuttaisi myös pää-IDE:n moraalista jälkeenjääneisyyttä.

Nykyään 1C-lähteiden tallentaminen gitiin, Jiran ongelmiin linkitettyjen sitoumusten, Crucible-arvostelujen, Jenkinsin painike ja Allure raportoi kooditestauksesta 1C:ssä ja jopa staattinen analyysi SonarQubessa - Tämä on kaukana uutisesta, vaan pikemminkin valtavirtaa yrityksissä, joissa on paljon 1C-kehitystä.

antaminen

Täällä on paljon sanottavaa. Ensinnäkin tämä on tietysti palvelin (1C-palvelinklusteri). Hieno asia, mutta johtuen siitä, että se on täysin musta laatikko, dokumentoitu riittävän yksityiskohtaisesti, mutta erityisellä tavalla - keskeytymättömän toiminnan käynnistämisen hallitseminen highload-tilassa useilla palvelimilla on harvojen valittujen, jotka käyttävät mitali, jossa on merkintä "Teknologisten asioiden asiantuntija". On syytä huomata, että periaatteessa 1C-palvelimen hallinta ei eroa minkään muun palvelimen hallinnoinnista. Se on verkkopohjainen, monisäikeinen sovellus, joka kuluttaa muistia, suoritinta ja levyresursseja. Tarjoaa runsaasti mahdollisuuksia telemetrian keräämiseen ja diagnostiikkaan.

Ongelmana tässä on se, että myyjä ei tarjoa mitään erityistä valmiiden ratkaisujen suhteen juuri tähän diagnoosiin. Kyllä, on olemassa 1C: Instrumentation and Control Center, ne ovat jopa melko hyviä, mutta ne ovat erittäin kalliita, eikä niitä ole kaikilla. Yhteisössä on useita kehityshankkeita Grafanan, Zabbixin, ELK:n ja muiden asioiden yhdistämiseksi vakiojärjestelmänvalvojajoukosta, mutta yhtä ainoaa ratkaisua ei ole, joka sopisi enemmistölle. Tehtävä odottaa sankariaan. Ja jos olet yritys, joka aikoo käynnistää 1C-klusterin, tarvitset asiantuntijan. Omasi sisältä tai ulkoa, mutta tarvitset sitä. On normaalia, että palvelimen toiminnalle on erillinen rooli, jossa on kompetenssit, ei jokaisen 1C-käyttäjän pitäisi tietää tätä, sinun on vain ymmärrettävä, että tällaista roolia tarvitaan. Otetaan esimerkiksi SAP. Siellä ohjelmoija ei todennäköisesti edes nouse tuolistaan, jos häntä pyydetään määrittämään jotain sovelluspalvelimella. Hän voi olla vain tyhmä, eikä hän häpeä. SAP-metodologiassa tätä varten on erillinen työntekijärooli. Jostain syystä 1C-teollisuudessa uskotaan, että tämä pitäisi yhdistää yhdelle työntekijälle samalle palkalle. Se on harhaa.

1C-palvelimen haitat

Siinä on täsmälleen yksi miinus - luotettavuus. Tai jos haluat, arvaamattomuus. Palvelimen äkillinen outo käyttäytyminen on jo tullut kaupungin puheeksi. Universaali ratkaisu - palvelimen pysäyttäminen ja välimuistien tyhjentäminen - on jopa kuvattu asiantuntijan käsikirjassa, ja jopa eräkirjaa suositellaan, joka tekee tämän. Jos 1C-järjestelmäsi alkaa tehdä jotain, mitä sen ei pitäisi edes teoreettisesti tehdä, on aika tyhjentää istunnon datavälimuisti. Arvioni mukaan koko maassa on vain kolme henkilöä, jotka osaavat käyttää 1C-palvelinta ilman tätä menettelyä, eivätkä he jaa salaisuuksia, koska... he elävät tästä. Ehkä heidän salaisuutensa on se, että he puhdistavat istuntotiedot, mutta he eivät kerro siitä kenellekään, jätkä.

Muuten 1C-palvelin on sama sovellus kuin mikä tahansa muu ja sitä hallitaan pitkälti samalla tavalla, lukemalla dokumentaatiota ja koputtamalla tamburiinia.

Satamatyöläinen

Konteissa olevan 1C-palvelimen käytön hyödyllisyyttä tuotannossa ei ole vielä todistettu. Palvelinta ei klusteroida yksinkertaisesti lisäämällä solmuja tasapainottimen taakse, mikä vähentää tuotannon konttien edut minimiin, eikä käytäntöä onnistuneesta toiminnasta konteissa highload-tilassa ole vakiinnutettu. Tämän seurauksena vain kehittäjät käyttävät Docker+1C:tä testiympäristöjen määrittämiseen. Siellä se on erittäin hyödyllinen, sovellettu, sen avulla voit pelata nykyaikaisilla tekniikoilla ja pitää tauon konfiguraattorin epätoivosta.

Kaupallinen komponentti

Investoinnin näkökulmasta 1C:n avulla voit ratkaista liiketoimintaideoiden nopean käynnistämisen ongelman sovellusluokkien laajojen ominaisuuksien vuoksi. 1C out of the box tarjoaa erittäin kunnollisen raportoinnin, integroinnin mihin tahansa, verkkoasiakasohjelmaan, mobiiliasiakasohjelmaan, mobiilisovellukseen, tuen erilaisille DBMS-järjestelmille, mm. ilmaisia, monialustaisia ​​sekä palvelin- että asennettuja asiakasosia. Kyllä, sovellusten käyttöliittymä on keltainen, joskus tämä on miinus, mutta ei aina.
Valitsemalla 1C:n yritys saa joukon ohjelmistoratkaisuja, joiden avulla ne voivat rakentaa erittäin laajan valikoiman sovelluksia, sekä paljon markkinoilla olevia kehittäjiä, jotka haluavat vähemmän rahaa kuin Javaistit ja samalla tuottavat tuloksia nopeammin.

Esimerkiksi PDF-laskun lähettäminen asiakkaalle voidaan ratkaista tunnin opiskelijatyössä. Sama ongelma .NET:ssä voidaan ratkaista ostamalla oma kirjasto tai muutaman päivän tai viikon koodaus ankaran, parrakkaan kehittäjän toimesta. Joskus molempia kerralla. Ja kyllä, puhuin vain PDF-luonnosta. Emme ole edes kertoneet, mistä tämä lasku tulee. Web frontenderin on luotava lomake, johon operaattori syöttää tiedot, backenderin on luotava dto-malleja JSON-siirtoa varten, mallit tietokantaan tallentamista varten, itse tietokannan rakenne, siirtyminen siihen, graafisen tiedoston muodostaminen. tämän tilin näyttö ja vasta sitten - PDF. 1C:llä koko tehtävä on suoritettu tyhjästä tasan tunnissa.

Täysimääräinen kirjanpitojärjestelmä pienelle kioskille yhdellä ostetulla/myydyllä liiketoimintaprosessilla tehdään 3 tunnissa Myyntiraportoinnilla, tavaroiden kirjanpidolla osto- ja myyntihinnoilla, varastokohtaisesti jaoteltuna, käyttöoikeuksien hallinnassa, verkkoasiakassovelluksella ja mobiilisovelluksella. . Okei, unohdin hakemuksen, kun hakemus ei ole 3 tunnissa, kuudessa.

Kuinka kauan tämä tehtävä kestää .NET-kehittäjällä Visual Studion asentamisesta puhtaaseen tietokoneeseen sen esittelyyn asiakkaalle? Entä kehityskustannukset? Sama asia.

1C:n vahvuudet alustana

1C ei ole vahva siksi, että siinä olisi jotain erityistä, mikä on maailman parasta. Päinvastoin, jokaisesta yksittäisestä osajärjestelmästä voit löytää mielenkiintoisemman analogin maailman ohjelmistoista. Useiden tekijöiden yhdistelmän perusteella en kuitenkaan näe 1C:n kaltaista alustaa. Tässä on kaupallinen menestys. Alustan edut ovat hajallaan läpi sen ja näkyvät selkeimmin, kun näet, kuinka tämä tehdään muilla alustoilla. Pohjimmiltaan nämä EIVÄT ole edes ominaisuuksia, vaan päinvastoin - piirteiden hylkääminen yhden tietyn paradigman hyväksi. Muutama esimerkki:

1. Unicode. Mikä helvetti voisi olla yksinkertaisempaa? Yksitavuisia ASCII-koodauksia ei tarvitse käyttää vuonna 2019 (lukuun ottamatta integrointia vanhojen perintöjen kanssa). Ei koskaan. Mutta ei. Joka tapauksessa joku jossain taulukossa käyttää yksitavuista varcharia ja sovelluksella on ongelmia koodauksen kanssa. Vuonna 2015 gitlabin LDAP-valtuutus epäonnistui virheellisen koodauksen vuoksi. JetBrains IDE ei edelleenkään toimi kyrillisillä tiedostonimillä. 1C tarjoaa korkealaatuisen sovelluskoodin eristämisen tietokantakerroksesta. Siellä on mahdotonta kirjoittaa taulukoita matalalla tasolla ja epäpätevien junioreiden jambit tietokantatasolla ovat mahdottomia siellä. Kyllä, siellä voi olla muita ongelmia epäpätevien junioreiden taholta, mutta ongelmien kirjo on paljon pienempi. Nyt kerrot minulle, että sovelluksesi on suunniteltu oikein ja tietokannan käyttökerros on eristetty niin kuin sen pitäisi olla. Tutustu yrityksesi mukautettuun Java-sovellukseesi. Läheisesti ja rehellisesti. Vaivaako omatuntosi sinua? Sitten olen iloinen puolestasi.
2. Asiakirjojen/viitekirjojen numerointi. 1C:ssä se ei todellakaan ole joustavin eikä paras. Mutta mitä he tekevät pankkiohjelmistoissa ja itse kirjoitetuissa kirjanpitojärjestelmissä - no, se on vain pimeyttä. Joko identiteetti juuttuu sisään (ja sitten "oi, miksi meillä on reikiä"), tai päinvastoin, he tekevät generaattorin, joka toimii lukitsemalla DBMS-tasolla (ja siitä tulee pullonkaula). Itse asiassa tämän näennäisen yksinkertaisen tehtävän suorittaminen on melko vaikeaa - kokonaisuuksien luettelointi, jonka ainutlaatuisuusosio perustuu tiettyyn avainsarjaan, etuliite, jotta se ei estä tietokantaa rinnakkaisen tiedon syöttämisen aikana. .
3. Tietokannan tietueiden tunnisteet. 1C teki voimakkaan päätöksen - kaikki linkkitunnisteet ovat täysin synteettisiä ja siinä se. Ja hajautettujen tietokantojen ja vaihtojen kanssa ei ole ongelmia. Muiden järjestelmien kehittäjät luovat itsepäisesti jotain identiteetin kaltaista (se on lyhyempi!), vetää ne graafiseen käyttöliittymään, kunnes on aika luoda useita toisiinsa liittyviä ilmentymiä (ja sitten ne löydetään). Eikö sinulla ole tätä? Rehellisesti?
4. Luettelot. 1C:llä on varsin onnistuneita mekanismeja (suurien) luetteloiden selaamiseen ja niiden selailuun. Anna minun tehdä varaus heti - mekanismin oikealla käytöllä! Yleisesti ottaen aihe on varsin epämiellyttävä, sitä ei voida ratkaista ihanteellisesti: se on joko intuitiivinen ja yksinkertainen (mutta suurien tietuejoukkojen riski asiakkaalla) tai sivutus on jollakin tavalla vino. Hakuajat tekevät sen usein vinosti. Rehellisen vierityspalkin tekejät lisäävät tietokannan, kanavan ja asiakkaan.
5. Hallitut lomakkeet. Epäilemättä verkkoasiakasohjelmassa käyttöliittymä ei toimi täydellisesti. Mutta se toimii. Mutta monille muille kirjanpito- ja pankkijärjestelmille etätyöpaikan luominen on yritystason projekti. Vastuuvapauslauseke: onneksi niille, jotka tekivät sen alun perin verkossa, tämä ei vaikuta.
6. Mobiilisovellus. Viime aikoina voit myös kirjoittaa mobiilisovelluksia ollessasi samassa ekosysteemissä. Se on täällä hieman monimutkaisempaa kuin verkkoasiakasohjelmassa. Laitteiden erityispiirteet pakottavat kirjoittamaan nimenomaan niitä varten, mutta et kuitenkaan palkkaa erillistä mobiilikehittäjien tiimiä. Jos tarvitset sovelluksen yrityksen sisäisiin tarpeisiin (kun mobiiliratkaisu yritysongelmaan on tärkeämpää kuin keltainen käyttöliittymäsuunnittelu), käytät yksinkertaisesti samaa alustaa heti valmiina.
7. Raportointi. Tällä sanalla en tarkoita BI-järjestelmää, jossa on suuri data ja viive ETL-prosessissa. Tämä viittaa operatiivisiin henkilöstöraportteihin, joiden avulla voit arvioida kirjanpidon tilaa tässä ja nyt. Saldot, keskinäiset selvitykset, uudelleenluokitukset jne. 1C:ssä on raportointijärjestelmä, jossa on joustavat asetukset ryhmittelyä, suodattimia ja visualisointia varten käyttäjäpuolella. Kyllä, markkinoilla on viileämpiä analogeja. Mutta ei all-in-one-ratkaisun puitteissa ja hintaan, joka on joskus korkeampi kuin all-in-one-ratkaisu. Ja useammin se on jopa päinvastoin: vain raportointi, mutta kalliimpi kuin koko alusta ja huonompi laatu.
8. Tulostettavat lomakkeet. No, käytä .NET-verkkoa ratkaistaksesi ongelman, joka liittyy palkkakuittien lähettämiseen PDF-muodossa työntekijöille sähköpostitse. Ja nyt laskujen tulostustehtävä. Entäpä niiden kopioiden tallentaminen samaan PDF-tiedostoon? 1C-lempinimelle minkä tahansa asettelun tulostaminen PDF-muotoon on +1 koodirivi. Tämä tarkoittaa + 40 sekuntia työaikaa toisen kielen päivien tai viikkojen sijaan. 1C:n painetut lomakeasettelut ovat uskomattoman helppoja kehittää ja riittävän tehokkaita kilpailemaan maksullisten kollegoiden kanssa. Kyllä, luultavasti 1C-laskentataulukkoasiakirjoissa ei ole paljon interaktiivisia mahdollisuuksia, et voi saada nopeasti 3D-kaaviota skaalauksella OpenGL:n avulla. Mutta onko se todella tarpeellista?

Nämä ovat vain kourallinen esimerkkejä, joissa toiminnallisuuden rajoittaminen tai kompromissien toteuttaminen osoittautuu tärkeäksi arkkitehtoniseksi hyödyksi tulevaisuudessa. Jopa kompromissi tai ei tehokkain vaihtoehto - se on jo laatikossa ja sitä pidetään itsestäänselvyytenä. Sen itsenäinen toteutus on joko mahdotonta (koska tällaiset päätökset on tehtävä projektin alussa, eikä siihen ole aikaa, eikä arkkitehtia ole ollenkaan), tai useita kalliita iteraatioita. Jokaisessa luetellussa kohdassa (ja tämä ei ole täydellinen luettelo arkkitehtonisista ratkaisuista) voit sekoittaa ja ottaa käyttöön rajoituksia, jotka estävät skaalauksen. Joka tapauksessa sinun, liikemiehenä, on varmistettava, että ohjelmoijallasi, kun he tekevät "järjestelmän tyhjästä", on suorat kädet ja he tekevät hienovaraiset järjestelmäongelmat heti hyvin.

Kyllä, kuten kaikissa muissakin monimutkaisissa järjestelmissä, myös 1C:llä itsessään on ratkaisuja, jotka estävät skaalauksen tietyiltä osin. Toistan kuitenkin, että tekijöiden, omistuskustannusten ja jo etukäteen ratkaistujen ongelmien yhdistelmän perusteella en näe markkinoilla kelvollista kilpailijaa. Samalla hinnalla saat taloussovelluskehyksen, klusteroidun tasapainotetun palvelimen, käyttöliittymän ja verkkoliittymän, mobiilisovelluksen, raportoinnin, integroinnin ja joukon muita asioita. Java-maailmassa palkkaat etu- ja taustatiimin, korjaat matalan tason kotikirjoitetun palvelinkoodin ja maksat erikseen kahdesta mobiilisovelluksesta kahdesta mobiilikäyttöjärjestelmästä.

En sano, että 1C ratkaisee kaikki tapaukset, mutta mitä muuta tarvitaan sisäiselle yrityssovellukselle, kun käyttöliittymää ei tarvitse brändätä?

Liota voiteessa

Olet luultavasti saanut sellaisen vaikutelman, että 1C pelastaa maailman ja että kaikki muut tavat kirjoittaa yritysjärjestelmiä ovat vääriä. Se ei ole ollenkaan niin. Liikemiehen näkökulmasta, jos valitset 1C:n, sinun on nopean markkinoille tulon lisäksi otettava huomioon seuraavat haitat:

• Palvelimen luotettavuus. Tarvitaan todella laadukkaita asiantuntijoita, jotka voivat varmistaa sen keskeytymättömän toiminnan. En ole tietoinen toimittajan valmista koulutusohjelmasta tällaisille asiantuntijoille. Asiantuntijakokeeseen valmistautumiseen on olemassa kursseja, mutta tämä ei mielestäni riitä.
• Tuki. Katso edellinen kohta. Saadaksesi tukea myyjältä, sinun on ostettava se. Jostain syystä tätä ei hyväksytä 1C-teollisuudessa. Ja SAP:lla se on melkein pakollinen hankinta, eikä se haittaa ketään. Ilman yritystukea ja ilman asiantuntijaa voit jättää yksin 1C-häiriöiden kanssa.
• Silti et voi tehdä kaikkea 1C:llä. Tämä on työkalu, ja kuten jokaisella työkalulla, sillä on käyttörajat. 1C-maisemassa on erittäin toivottavaa, että meillä on "ei-1C" -järjestelmäarkkitehti.
• Hyvät 1C-lempinimet eivät ole halvempia kuin hyvät ohjelmoijat muilla kielillä. Huonojen ohjelmoijien palkkaaminen on kuitenkin kallista, riippumatta siitä, millä kielellä he kirjoittavat.

Pistellään pisteitä

• 1C on nopea sovelluskehitys (RAD) -kehys yrityksille, ja se on räätälöity tähän tarkoitukseen.
• Kolmikerroksinen linkki, jossa on tuki tärkeimmille tietokantajärjestelmille, asiakaskäyttöliittymä, erittäin hyvä ORM ja raportointi
• Laajat integraatiomahdollisuudet järjestelmiin, jotka pystyvät siihen, mitä 1C ei pysty. Jos haluat koneoppimisen, ota Python ja lähetä tulos 1C:lle http:n tai RabbitMQ:n kautta
• Ei tarvitse yrittää tehdä kaikkea 1C:n avulla, sinun on ymmärrettävä sen vahvuudet ja käytettävä niitä omiin tarkoituksiinsi
• Kehittäjät, jotka haluavat syventyä teknisten puitteiden vempaimiin ja suunnitella uudelleen N vuoden välein uuteen moottoriin, ovat kyllästyneet 1C:hen. Siellä kaikki on hyvin konservatiivista.
• Kehittäjät ovat myös tylsiä, koska valmistaja ei välitä heistä hyvin vähän. Tylsä kieli, heikko IDE. Ne vaativat modernisointia.
• Toisaalta kehittäjät, jotka eivät löydä hauskaa käyttämällä ja oppimalla toista teknologiaa, josta nauttivat, ovat huonoja kehittäjiä. He valittavat ja siirtyvät toiseen ekosysteemiin.
• Työnantajat, jotka eivät salli 1C lempinimiensä kirjoittaa jotain Pythonissa, ovat huonoja työnantajia. He menettävät uteliasmielisiä työntekijöitä, ja heidän tilalleen tulee apinakoodaajia, jotka kaikesta huolimatta raahaavat yritysohjelmistoja suohon. Se on vielä kirjoitettava uudelleen, joten ehkä olisi parempi panostaa hieman Pythoniin hieman aikaisemmin?
• 1C on kaupallinen yritys ja toteuttaa ominaisuuksia yksinomaan omien etujensa ja tarkoituksenmukaisuuden perusteella. Et voi syyttää häntä tästä, liiketoiminnan täytyy ajatella voittoa, se on elämää
• 1C ansaitsee rahaa myymällä ratkaisuja yritysongelmiin, ei Vasyan kehittäjäongelmiin. Nämä kaksi käsitettä korreloivat, mutta prioriteetti on juuri se, mitä sanoin. Kun kehittäjä Vasya on valmis maksamaan henkilökohtaisesta lisenssistä 1C: Resharperille, se ilmestyy melko nopeasti, A. Orefkovan "Resharper" on todiste tästä. Jos myyjä tukisi sitä eikä taistele sitä vastaan, kehittäjille tarkoitettujen ohjelmistojen markkinat ilmestyisivät. Nyt näillä markkinoilla on puolitoista pelaajaa kyseenalaisilla tuloksilla, ja kaikki siksi, että integraatio IDE:n kanssa on negatiivinen ja kaikki tehdään kainalosauvoilla.
• Monen koneen kuljettajan käytäntö katoaa unohduksiin. Nykyaikaiset sovellukset ovat liian suuria muistaakseen sekä koodin että yrityskäytön puolelta. 1C-palvelin on myös tulossa monimutkaisemmaksi, on mahdotonta pitää kaikenlaista asiantuntemusta yhdessä työntekijässä. Tämän pitäisi edellyttää asiantuntijoiden kysyntää, mikä tarkoittaa 1C-ammatin houkuttelevuutta ja palkkojen nousua. Jos aiemmin Vasya työskenteli kolmessa yhdessä palkalla, niin nyt sinun on palkattava kaksi Vasyaa ja kilpailu Vasyoiden välillä voi vauhdittaa heidän tasonsa yleistä kasvua.

Johtopäätös

1C on erittäin arvokas tuote. Hintaluokissani en tiedä yhtään analogia, kirjoita kommentteihin, jos niitä on. Kehittäjien ulosvirtaus ekosysteemistä on kuitenkin yhä havaittavampaa, ja tämä on "aivovuotoa", katsoipa sitä miten tahansa. Teollisuus kaipaa modernisaatiota.
Jos olet kehittäjä, älä jää jumiin 1C:hen äläkä ajattele, että kaikki on taianomaista muilla kielillä. Kun olet juniori, ehkä. Heti kun jotain suurempaa on ratkaistava, valmiita ratkaisuja on etsittävä pidempään ja saatava valmiiksi intensiivisemmin. Niiden "lohkojen", joista ratkaisu voidaan rakentaa, laadulla 1C on erittäin, erittäin hyvä.

Ja vielä yksi asia - jos 1C-lempinimi tulee sinulle palkattavaksi, 1C-lempinimi voidaan turvallisesti nimittää johtavan analyytikon tehtävään. He ymmärtävät tehtävän, aihealueen ja hajotustaidot erinomaisesti. Olen varma, että tämä johtuu juuri DDD:n pakkokäytöstä 1C-kehityksessä. Henkilö on koulutettu ajattelemaan ennen kaikkea tehtävän merkitystä, aihealueen objektien välisiä yhteyksiä, ja samalla hänellä on tekninen tausta integraatiotekniikoista ja tiedonvaihtoformaateista.

Muista, että ihanteellisia puitteita ei ole olemassa ja pidä huolta itsestäsi.
Hyvä kaikille!

PS: kiitos paljon speshuric apua artikkelin valmistelussa.

Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. Kirjaudu sisään, ole kiltti.

Onko yrityksessäsi 1C?

• 13,3%Ei ollenkaan.71

• 30,3%On, mutta vain kirjanpitoosastolla jossain. Ydinjärjestelmät muilla alustoilla162

• 41,4%Kyllä, tärkeimmät liiketoimintaprosessit toimivat sen kanssa221

• 15,0%1C:n täytyy kuolla, tulevaisuus kuuluu %technology_name%80:lle

534 käyttäjää äänesti. 99 käyttäjää pidättyi äänestämästä.

Lähde: will.com