1C - Goed en kwaad. Rangschikking van punten in holivars rond 1C

Vrienden en collega's, de laatste tijd zijn er vaker artikelen verschenen over Habré met haat jegens 1C als ontwikkelingsplatform, en toespraken van de verdedigers ervan. Deze artikelen identificeerden één ernstig probleem: meestal bekritiseren critici van 1C het vanuit de positie dat ze het ‘niet beheersen’, waarbij ze problemen uitschelden die de facto gemakkelijk kunnen worden opgelost, en, in tegendeel, niet ingaan op problemen die echt belangrijk zijn en de moeite waard zijn. bespreken en worden door de verkoper niet opgelost. Ik geloof dat het zinvol is om een ​​nuchtere en evenwichtige evaluatie van het 1C-platform uit te voeren. Wat het kan doen, wat het niet kan, wat het zou moeten doen, maar niet doet, en als dessert, wat het met een knal doet, en jouw ontwikkelaars bij %technology_name% zullen honderd jaar doen en het weggooien meer dan één jaarbegroting.

Hierdoor krijgt u als manager of architect duidelijk inzicht in welke taak het voor u nuttig is om 1C te gebruiken en waar het met een heet strijkijzer moet worden uitgebrand. Als ontwikkelaar in de ‘niet-1C’-wereld kun je zien wat er in 1C zit dat voor ophef zorgt. En als 1C-ontwikkelaar kunt u uw systeem vergelijken met de ecosystemen van andere talen en uw locatie in het coördinatensysteem van softwareontwikkeling begrijpen.

Onder de snede zitten veel dikke aanvallen op 1C, op critici van 1C, op Java, .NET en in het algemeen... De fan is vol, welkom!

Over mij

Ik ben sinds ongeveer 2004 bekend met het gespreksonderwerp. Ik programmeer waarschijnlijk al vanaf mijn zesde, vanaf het moment dat ik een boek kreeg over professor Fortran met strips over een kat, een mus en een rups. Ik analyseerde de programma's die de kat schreef op basis van de afbeeldingen in het boek en ontdekte wat ze deden. En ja, ik had toen nog geen echte computer, maar er stond een tekening op de verspreiding van het boek en ik drukte eerlijk op de papieren knoppen en voerde de commando's in die ik op de kat X had bespioneerd.

Dan was er BK0011 en BASIC op school, C++ en assemblers op de universiteit, daarna 1C, en nog zoveel andere dingen die ik te lui ben om te onthouden. De afgelopen 15 jaar ben ik voornamelijk betrokken geweest bij 1C, niet alleen op het gebied van coderen, maar bij 1C in het algemeen. Stel hier taken, beheer en devops in. De afgelopen 5 jaar heb ik mij beziggehouden met sociaal nuttige activiteiten op het gebied van het ontwikkelen van ontwikkelings- en automatiseringstools voor andere 1C-gebruikers, het schrijven van artikelen en boeken.

Laten we beslissen over het onderwerp van discussie

Laten we eerst definiëren waar we het over gaan hebben, aangezien de letters ‘1C’ veel dingen kunnen betekenen. In dit geval bedoelen we met de letters “1C” uitsluitend het ontwikkelingsframework “1C: Enterprise” van de moderne, achtste versie. We zullen niet veel praten over de fabrikant en zijn beleid (maar we zullen wel een beetje moeten doen). We zullen geen specifieke toepassingen bespreken die met dit raamwerk zijn geschreven. Technologie is gescheiden, applicaties oftewel configuraties zijn gescheiden.

Architectuur op hoog niveau 1C: Enterprise

Niet voor niets noem ik het woord ‘framework’. Vanuit het perspectief van een ontwikkelaar is het 1C-platform precies een raamwerk. En je moet het precies als een raamwerk behandelen. Zie het als Spring of ASP.NET, uitgevoerd door een bepaalde runtime (respectievelijk JVM of CLR). Het gebeurt zo dat in de wereld van conventioneel programmeren (“niet 1C”) de indeling in frameworks, virtuele machines en specifieke applicaties natuurlijk is, vanwege het feit dat deze componenten meestal door verschillende fabrikanten worden ontwikkeld. In de 1C-wereld is het niet gebruikelijk om expliciet onderscheid te maken tussen het ontwikkelframework en de runtime zelf; bovendien worden specifieke applicaties die met behulp van het framework zijn geschreven ook voornamelijk door 1C zelf ontwikkeld. Als gevolg hiervan ontstaat er enige verwarring. Daarom zullen we, binnen het kader van het artikel, 1C van meerdere kanten tegelijk moeten bekijken en deze langs verschillende coördinaatassen moeten classificeren. En in elke coördinatenas zullen we een schep bruine substantie plaatsen en kijken naar de kenmerken, voor- en nadelen van de bestaande oplossing.

Standpunten over 1C

1C voor de koper

De koper schaft een automatiseringssysteem aan waarmee hij de problemen van het automatiseren van zijn eigen bedrijf snel kan oplossen. Een bedrijf kan een kleine kraam zijn, maar ook een grote holdingmaatschappij. Het is duidelijk dat de behoeften van deze bedrijven verschillend zijn, maar beide worden ondersteund door één enkele platformcodebasis.

Voor de 1C-koper is dit een snelle time-to-market. Snel. Sneller dan Java, C# of JS. Gemiddeld. Rondom het ziekenhuis. Het is duidelijk dat een visitekaartjeswebsite die React gebruikt beter zal uitpakken, maar de backend van een WMS-systeem zal sneller starten op 1C.

1C als hulpmiddel

Elke technologische oplossing heeft beperkingen qua toepasbaarheid. 1C is geen taal voor algemeen gebruik; het leeft niet los van zijn raamwerk. Het is raadzaam om 1C te gebruiken wanneer u:

• serverapplicatie
• applicatie waar financiën verschijnen
• met kant-en-klare gebruikersinterface, ORM, rapportage, XML/JSON/COM/PDF/YourDataTransferingFormat
• met ondersteuning voor achtergrondprocessen en banen
• met rolgebaseerde beveiliging
• met scriptbare bedrijfslogica
• met de mogelijkheid om snel een prototype te maken en een lage time-to-market

Je hebt geen 1C nodig als je:

• machine learning
• GPU-berekeningen
• computer beelden
• wiskundige berekeningen
• CAD-systeem
• signaalverwerking (geluid, video)
• highload http-aanroepen met honderdduizenden rps

1C als productiebedrijf

Het is de moeite waard om te begrijpen wat de activiteiten van 1C als softwarefabrikant zijn. 1C-bedrijf verkoopt oplossingen voor zakelijke problemen door middel van automatisering. Verschillende bedrijven, groot of klein, maar dat is wat ze verkoopt. Het middel om dit doel te bereiken zijn bedrijfsapplicaties. Voor de boekhouding, loonadministratie, etc. Voor het schrijven van deze applicaties maakt het bedrijf gebruik van een eigen ontwikkelplatform voor bedrijfsapplicaties. Speciaal afgestemd op de algemene taken van dezelfde bedrijfsapplicaties:

• financiële boekhouding
• eenvoudige aanpassing van bedrijfslogica
• brede integratiemogelijkheden in heterogene IT-landschappen

Als fabrikant gelooft 1C dat dit de strategie is waarmee u in een win-win-modus met partners en klanten kunt samenwerken. Daar kun je tegenin gaan, maar dit is grofweg hoe het bedrijf zichzelf promoot: kant-en-klare oplossingen voor bedrijfsproblemen die snel door partners op maat kunnen worden gemaakt en in elk IT-landschap kunnen worden geïntegreerd.

Alle claims of wensen voor 1C als raamwerk moeten uitsluitend door dit prisma worden bekeken. “We willen OOP in 1C”, zeggen de ontwikkelaars. “Hoeveel gaat het ons kosten om OOP op het platform te ondersteunen, zal dit ons helpen de verkoop van boxen te vergroten?”, zegt 1C. Opent zijn ‘prisma’ van het verkopen van oplossingen voor zakelijke problemen:

- Hé, zaken, wil je OOP in je 1C?
- Zal dit mij helpen mijn problemen op te lossen?
- Wie weet...
- Dan is dat niet nodig

Deze aanpak kan goed of slecht zijn, afhankelijk van wie er naar kijkt, maar zo is het nu eenmaal. Als we het hebben over het feit dat er geen functie X is in 1C, moet je begrijpen dat deze er niet om een ​​reden is, maar in de context van de keuze “implementatiekosten versus winstbedrag”.

Technologische classificatie

“In feite doen Odinesniks hun best om de beste patronen te gebruiken, zorgvuldig geselecteerd door zorgzame methodologen en ontwikkelaars van het 1C-platform.
Wanneer u uw domme code schrijft voor een eenvoudig beheerd formulier, gebruikt u in werkelijkheid model-view-controller с dubbele gegevensbinding в drielaagse data-app-engine, op smaak gebracht objectrelatie-mapping op hoog niveau op de basis declaratieve metadatabeschrijvingzijn eigen hebben platformonafhankelijke zoektaal, C declaratieve datagestuurde gebruikersinterface, volledige transparante serialisatie en domeingeoriënteerde programmataal.

Waar 1C-ontwikkelaars verschillen van hun westerse collega's is PR. Ze houden ervan om elke onzin een grote naam te geven en ermee rond te rennen als een vuile zak.
A. Orefkov

Het 1C-platform heeft een klassieke architectuur met drie niveaus, met in het midden de applicatieserver (of de emulatie ervan voor weinig geld voor kleine winkeliers). Als DBMS wordt MS SQL of Postgres gebruikt. Er is ook ondersteuning voor Oracle en IBM DB3, maar dit is nogal esoterisch; niemand weet wat er zal gebeuren als je 2C op deze databases implementeert onder gemiddelde en hoge belasting. Ik geloof dat 1C dit zelf niet weet.

Het clientgedeelte is een thin client die op de computer van de gebruiker is geïnstalleerd of een webclient. Het belangrijkste kenmerk is dat programmeurs niet twee verschillende codes schrijven, ze schrijven één applicatie, in één taal, en je kunt deze in de browser weergeven als daar behoefte aan is. Wie wilde daar een echte volledige stack en één taal voor de front- en backend, node.js? Ze zijn er tot het einde toe nooit in geslaagd precies hetzelfde te doen. Er bestaat een echte volledige stapel, maar je zult deze in 2C moeten schrijven. De ironie van het lot, zulke dingen :)

De cloud SaaS-oplossing 1C:Fresh werkt ook in browsermodus, waarin je geen 1C kunt kopen, maar een kleine database kunt huren en daar de shoarmaverkoop kunt bijhouden. Gewoon in de browser, zonder iets te installeren of te configureren.

Daarnaast is er een legacy-client, die in 1C een “reguliere applicatie” wordt genoemd. Legacy is legacy, welkom in de wereld van applicaties anno 2002, maar we hebben het nog steeds over de huidige staat van het ecosysteem.

Het 1C-servergedeelte ondersteunt clustering en schaalbaarheid door nieuwe machines aan het cluster toe te voegen. Er zijn hier behoorlijk wat kopieën kapot gegaan en hierover zal in het artikel een aparte sectie verschijnen. Kortom, dit is niet helemaal hetzelfde als het toevoegen van een paar exact dezelfde instances achter HAProxy.

Het applicatieontwikkelingsframework gebruikt een eigen programmeertaal, die grofweg lijkt op een licht verbeterde VB6, vertaald in het Russisch. Voor mensen die alles Russisch haten, die niet geloven dat 'als' wordt vertaald als 'als', wordt de tweede syntaxisoptie aangeboden. Die. Als je wilt, kun je het zo in 1C schrijven dat het niet te onderscheiden is van VB.

Deze programmeertaal is de belangrijkste reden voor de haat tegen 1C-bijnamen jegens hun platform. Laten we eerlijk zijn, niet zonder reden. De taal is zo eenvoudig mogelijk bedacht, ontworpen om de mantra “ONTWIKKELAARS, ONTWIKKELAARS” op een schaal te vervullen, tenminste in het GOS. De commerciële essentie van een dergelijke oplossing is naar mijn mening duidelijk zichtbaar: meer ontwikkelaars, een grotere marktdekking. Dit kwam volgens verschillende schattingen uit van 45% tot 95%. Ik zeg meteen dat schrijven in de taal die jij denkt echt gemakkelijker is. En ik ken behoorlijk wat programmeertalen.

Laten we beginnen met de taal.

1C programmeertaal

Tegelijkertijd het sterke en zwakke punt van het systeem. Biedt gemakkelijke toegang en leesbaarheid. Aan de andere kant is het sinds de release van versie 8 in 2002 niet meer bijgewerkt en is het moreel verouderd. Iemand zal zeggen: "Het belangrijkste nadeel is dat er geen OOP is", en hij of zij zal het mis hebben. Ten eerste houdt de PLO niet alleen van Nuraliev, maar ook van Torvalds. En ten tweede bestaat OOP nog steeds.

Vanuit het standpunt van de ontwikkelaar beschikt hij over een raamwerk met basisklassen die op het DBMS worden weergegeven. De ontwikkelaar kan de basisklasse “Directory” nemen en daarvan de directory “Clients” overnemen. Het kan er nieuwe klassevelden aan toevoegen, bijvoorbeeld Taxpayer Identification Number en Address, en indien nodig kan het ook de methoden van de basisklasse overschrijven, bijvoorbeeld de OnWrite/AtRecord-methode.

Het raamwerk is zo ontworpen dat diepere overerving zelden nodig is, en de beperking in OOP is naar mijn mening logisch. 1C richt zich op Domain Driven Development en laat je allereerst nadenken over het onderwerpgebied van de oplossing die wordt ontwikkeld, en dat is goed. Er is niet alleen geen verleiding, maar het is ook niet nodig om 10 verschillende DTO's en ViewModels te schrijven om ergens wat gegevens van het domein te tonen. De 1C-ontwikkelaar werkt altijd met één entiteit, zonder de perceptiecontext te vervuilen met een tiental klassen met vergelijkbare namen, die dezelfde entiteit vertegenwoordigen, maar van een andere kant. Elke .NET-applicatie zal bijvoorbeeld noodzakelijkerwijs vijf of twee ViewModels en DTO's bevatten voor serialisatie naar JSON en gegevensoverdracht van client naar server. En ongeveer 10-15% van uw applicatiecode wordt besteed aan het overbrengen van gegevens van de ene klasse naar de andere met behulp van pennen of krukken zoals AutoMapper. Deze code moet worden geschreven en programmeurs moeten worden betaald om deze te maken en te onderhouden.

Het blijkt dat de 1C-taal moeilijk te ontwikkelen is zonder deze te compliceren tot het niveau van reguliere talen, waardoor het voordeel van eenvoud verloren gaat. Wat wordt in wezen de taak van de verkoper opgelost: een standaardoplossing uitbrengen die elke student die op straat wordt betrapt, kan aanpassen met het vereiste kwaliteitsniveau (d.w.z. een zaak die zich uitstrekt van een kraampje tot een grote fabriek is voltooid). Als je een kraam bent, neem dan een student; als je een fabriek bent, neem dan een goeroe van je implementatiepartner. Het feit dat uitvoerende partners studenten verkopen voor de prijs van een goeroe is geen probleem met het raamwerk. Op architectonisch vlak moet het raamwerk de problemen van beide oplossen; de code van standaardconfiguraties (die we aan bedrijven hebben verkocht met de belofte van maatwerk) moet door een student kunnen worden begrepen, en een goeroe moet kunnen begrijpen wat je maar wilt.

Wat naar mijn mening echt ontbreekt in de taal, wat je dwingt om meer te schrijven dan je zou kunnen, is wat de tijd verspilt die door de klant wordt betaald.

• Mogelijkheid om op het niveau te typen, bijvoorbeeld TypeScript (als resultaat meer ontwikkelde tools voor codeanalyse in de IDE, refactoring, minder aanstootgevende stijlen)
  Beschikbaarheid van functies als eersteklas objecten. Een iets complexer concept, maar de hoeveelheid typische boilerplate-code zou aanzienlijk kunnen worden verminderd. Het begrip van de code door de student, IMHO, zou zelfs toenemen als gevolg van de vermindering van het volume
• Universele verzamelingsliterals, initialisatoren. Hetzelfde: het verminderen van de hoeveelheid code die met uw ogen moet worden geschreven en/of bekeken. Het vullen van collecties neemt meer dan 9000% van de 1C-programmeertijd in beslag. Dit schrijven zonder syntactische suiker is lang, duur en foutgevoelig. Over het algemeen overschrijdt de hoeveelheid LOC in 1C-oplossingen alle denkbare limieten in vergelijking met beschikbare open frameworks en, in het algemeen, al uw enterprise Java's samen. De taal is breedsprakig, en dit ontaardt in de hoeveelheid data, geheugen, IDE-remmen, tijd, geld...
• eindelijk constructies Ik heb een hypothese dat deze constructie ontbreekt vanwege het feit dat ze er geen succesvolle vertaling van in het Russisch hebben gevonden :)
• Eigen datatypen (zonder OOP), analogen van Type uit VB6. Hiermee kunt u geen structuren typen met behulp van commentaar in de BSP en met magische methoden die deze structuren construeren. We krijgen: minder code, een hint via een punt, een snellere oplossing van het probleem, minder fouten door typefouten en ontbrekende eigenschappen van constructies. Nu ligt het typen van gebruikersstructuren volledig bij het ontwikkelingsteam van de Standard Subsystem Library, dat, naar eigen zeggen, zorgvuldig commentaar schrijft op de verwachte eigenschappen van de doorgegeven parameterstructuren.
• Geen suiker bij het werken met asynchrone oproepen op de webclient. callback-hel in de vorm van ProcessingNotifications is een tijdelijke kruk die wordt veroorzaakt door een plotselinge verandering in de API van de hoofdbrowsers, maar je kunt niet altijd zo leven; het voordeel dat het “studentenbegrip” van asynchrone code verloren gaat meer en meer. Voeg geen ondersteuning voor dit paradigma toe in de hoofd-IDE en de zaken worden nog erger.

Dit is een van de urgente problemen, het is duidelijk dat de lijst veel groter zou kunnen zijn, maar we mogen niet vergeten dat dit nog steeds geen taal voor algemeen gebruik is, het vereist geen multithreading, lambda-functies, toegang tot de GPU en snelle berekeningen met drijvende komma. Dit is een scripttaal voor bedrijfslogica.

Een programmeur die al veel met deze taal heeft gewerkt, zich verdiept in js of c#, verveelt zich binnen het raamwerk van deze taal. Het is een feit. Hij heeft ontwikkeling nodig. Aan de andere kant van de schaal staan ​​voor de leverancier de kosten voor het implementeren van de gespecificeerde functies versus de omzetstijging na de implementatie ervan. Hier heb ik geen informatie over wat momenteel zwaarder weegt in de ogen van het bedrijf.

Ontwikkelomgeving

Ook hier gaat het niet van een leien dakje. Er zijn twee ontwikkelomgevingen. De eerste is de meegeleverde configurator. De tweede is de Enterprise Development Tools-omgeving, kortweg EDT, ontwikkeld op basis van Eclipse.

De configurator biedt een volledig scala aan ontwikkelingstaken, ondersteunt alle functies en is de belangrijkste omgeving op de markt. Het is ook moreel achterhaald en ontwikkelt zich volgens de geruchten niet, vanwege de hoeveelheid technische schulden die er in zitten. De situatie zou kunnen worden verbeterd door een interne API te openen (in de vorm van vriendschap met Sneeuwman A. Orefkova of op onafhankelijke basis), maar dit is niet het geval. De praktijk heeft geleerd dat de gemeenschap haar eigen features in de IDE zal schrijven, zolang de leverancier zich er niet mee bemoeit. Maar we hebben wat we hebben. De configurator was geweldig in 2004-2005 en doet erg denken aan Visual Studio uit die tijd, op sommige plekken was het nog cooler, maar hij bleef in die tijd hangen.

Bovendien is het volume van de gemiddelde standaardoplossing sindsdien verschillende keren gegroeid, en tegenwoordig kan de IDE eenvoudigweg niet omgaan met de hoeveelheid code waarmee hij wordt gevoed. De bruikbaarheid en refactoringmogelijkheden zijn niet eens nul, ze staan ​​in het rood. Dit alles voegt geen enthousiasme toe aan de ontwikkelaars en ze dromen ervan om naar andere ecosystemen te verhuizen en daar shit te blijven coderen, maar in een prettige omgeving die je niet in je gezicht spuugt met zijn gedrag.

Als alternatief wordt een geheel opnieuw geschreven IDE, gebouwd op Eclipse, aangeboden. Daar leven de bronnen, net als in elke andere software, in de vorm van tekstbestanden, worden ze opgeslagen in GIT, pull-request branches, dit alles. Het nadeel is dat het al jaren de bètastatus niet meer heeft verlaten, hoewel het met elke release beter wordt. Ik zal niet schrijven over de nadelen van EDT, vandaag is het een minpuntje, morgen is het een vaste functie. De relevantie van een dergelijke beschrijving zal snel vervagen. Tegenwoordig is het mogelijk om in EDT te ontwikkelen, maar het is ongebruikelijk; je moet voorbereid zijn op een bepaald aantal IDE-bugs.

Als je de situatie bekijkt door het eerder genoemde “1C-prisma”, krijg je zoiets als dit: de release van de nieuwe IDE verhoogt de verkoop van boxen niet, maar de uitstroom van ONTWIKKELAARS kan worden verminderd. Het is moeilijk te zeggen wat het ecosysteem te wachten staat op het gebied van ontwikkelaarscomfort, maar Microsoft heeft mobiele ontwikkelaars al verpest door hen zijn diensten te laat aan te bieden.

Ontwikkelingsmanagement

Alles is hier aanzienlijk beter dan het schrijven van code, vooral recentelijk, toen de inspanningen van de gemeenschap de problemen van administratieve automatisering aan het licht brachten, prototypen lanceerden die opriepen om de 1C-repository in de prullenbak te gooien en git, snelle schuld, code-review te gebruiken , statische analyse, automatisch implementeren en etc. Er zijn veel functies aan het platform toegevoegd die het automatiseringsniveau van ontwikkelingstaken verhogen. Al deze functies zijn echter alleen en exclusief toegevoegd voor de ontwikkeling van onze eigen grote producten, toen duidelijk werd dat we niet zonder automatisering konden. Er waren automatische samenvoegingen, driewegvergelijkingen met KDiff en zo. Gelanceerd op Github gitconverter, die, eerlijk gezegd, ideologisch van het project werd weggesleept gitsync, maar aangepast aan de processen van het leverancierbedrijf. Dankzij de eigenwijze jongens van open-source kwam ontwikkelingsautomatisering in 1C van de grond. Een open API voor de configurator, IMHO, zou ook de morele achterlijkheid van de belangrijkste IDE verschuiven.

Tegenwoordig worden 1C-bronnen opgeslagen in git met commits gekoppeld aan problemen in Jira, beoordelingen in Crucible, drukknop van Jenkins en Allure-rapporten over het testen van code in 1C en zelfs statische analyse in SonarQube - dit is verre van nieuws, maar eerder mainstream in bedrijven waar veel 1C-ontwikkeling plaatsvindt.

administratie

Er valt hier veel te zeggen. Ten eerste is dit uiteraard een server (1C-servercluster). Een prachtig iets, maar vanwege het feit dat het een volledig zwarte doos is, voldoende gedetailleerd gedocumenteerd, maar op een specifieke manier - het beheersen van de lancering van een ononderbroken werking in highload-modus op verschillende servers is het lot van een select aantal mensen die een medaille met de inscriptie “Expert on Technological Issues”. Het is vermeldenswaard dat het beheer van een 1C-server in principe niet verschilt van het beheer van een andere server. Het is een netwerkgebaseerde, multi-threaded applicatie die geheugen, CPU en schijfbronnen verbruikt. Biedt ruime mogelijkheden voor het verzamelen en diagnosticeren van telemetrie.

Het probleem hier is dat de leverancier niets speciaals aanbiedt in termen van kant-en-klare oplossingen voor deze diagnose. Ja, er is 1C: Instrumentatie en Controlecentrum, ze zijn zelfs best goed, maar ze zijn erg duur en niet iedereen heeft ze. Er zijn een aantal ontwikkelingen in de community voor het verbinden van Grafana, Zabbix, ELK en andere zaken uit de standaard adminset, maar er is niet één oplossing die voor de meerderheid geschikt is. De taak wacht op zijn held. En als u een bedrijf bent dat van plan is te starten op een 1C-cluster, heeft u een expert nodig. Van binnen of van buiten, maar je hebt het nodig. Het is normaal dat er een aparte rol is met competenties voor serverbediening, niet elke 1C-gebruiker zou dit moeten weten, je moet alleen begrijpen dat zo'n rol nodig is. Laten we SAP als voorbeeld nemen. Daar zal een programmeur hoogstwaarschijnlijk niet eens uit zijn stoel komen als hem wordt gevraagd iets op de applicatieserver te configureren. Hij is misschien gewoon dom en hij zal zich niet schamen. In de SAP-methodiek is hiervoor een aparte medewerkersrol. Om de een of andere reden wordt in de 1C-industrie aangenomen dat dit gecombineerd moet worden in één werknemer voor hetzelfde salaris. Het is een waanidee.

Nadelen van 1C-server

Er is precies één minpunt: betrouwbaarheid. Of, zo u wilt, onvoorspelbaarheid. Plotseling vreemd gedrag van de server is al het gesprek van de dag geworden. Een universele oplossing - het stoppen van de server en het wissen van alle caches - wordt zelfs beschreven in het handboek van de expert, en zelfs een batchboek wordt aanbevolen dat dit doet. Als uw 1C-systeem iets begint te doen wat het theoretisch gezien niet eens zou moeten doen, is het tijd om de sessiegegevenscache te wissen. Volgens mijn inschatting zijn er in het hele land slechts drie mensen die weten hoe ze een 1C-server moeten bedienen zonder deze procedure en die geen geheimen delen, omdat... zij leven hiervan. Misschien is hun geheim dat ze sessiegegevens opschonen, maar ze vertellen er niemand over, kerel.

Voor het overige is de 1C-server dezelfde applicatie als alle andere en wordt deze op vrijwel dezelfde manier beheerd, door de documentatie te lezen en op de tamboerijn te kloppen.

havenarbeider

Het nut van het gebruik van een gecontaineriseerde 1C-server in productie is nog niet bewezen. De server wordt niet geclusterd door eenvoudigweg knooppunten achter de balancer toe te voegen, wat de voordelen van productiecontainerisatie tot een minimum beperkt, en de praktijk van succesvolle werking in containers in highload-modus is nog niet vastgesteld. Als gevolg hiervan gebruiken alleen ontwikkelaars Docker+1C om testomgevingen in te richten. Daar is het erg handig, toegepast, kun je spelen met moderne technologieën en een pauze nemen van de moedeloosheid van de configurator.

Commercieel onderdeel

Vanuit investeringsoogpunt kunt u met 1C het probleem van het snel lanceren van zakelijke ideeën oplossen dankzij de brede mogelijkheden van applicatieklassen. 1C out-of-the-box biedt zeer goede rapportage, integratie met alles, webclient, mobiele client, mobiele applicatie, ondersteuning voor verschillende DBMS'en, incl. gratis, platformonafhankelijke zowel server- als geïnstalleerde clientonderdelen. Ja, de gebruikersinterface van applicaties zal geel zijn, soms is dit een minpuntje, maar niet altijd.
Door voor 1C te kiezen, krijgt een bedrijf een reeks softwareoplossingen waarmee het een zeer breed scala aan applicaties kan bouwen, evenals veel ontwikkelaars op de markt die minder geld willen dan Javaisten en tegelijkertijd sneller resultaten boeken.

De taak van het verzenden van een pdf-factuur naar een klant kan bijvoorbeeld worden opgelost in een uur studentenwerk. Hetzelfde probleem in .NET kan worden opgelost door een eigen bibliotheek aan te schaffen, of door een paar dagen of weken te coderen door een strenge, bebaarde ontwikkelaar. Soms allebei tegelijk. En ja, ik had het alleen over het genereren van PDF's. We hebben niet gezegd waar dit wetsvoorstel vandaan zal komen. De webfrontender moet een formulier maken waarin de operator de gegevens invoert, de backender zal dto-modellen moeten maken voor het overbrengen van JSON, modellen voor opslag in de database, de structuur van de database zelf, migratie ernaartoe, de vorming van een grafische weergave van dit account, en alleen dan - PDF. Op 1C wordt de hele taak, helemaal opnieuw, in precies één uur voltooid.

Een volwaardig boekhoudsysteem voor een kleine kraam met één bedrijfsproces gekocht/verkocht is in 3 uur klaar. Met verkooprapportage, boekhouding van goederen tegen aan- en verkoopprijzen, uitgesplitst per magazijn, controle van toegangsrechten, webclient en mobiele applicatie . Oké, ik vergat de aanvraag, de aanvraag niet binnen drie uur, maar binnen zes uur.

Hoe lang duurt deze taak voor een .NET-ontwikkelaar vanaf het installeren van Visual Studio op een schone computer tot het demonstreren ervan aan de klant? Hoe zit het met de ontwikkelingskosten? Hetzelfde.

Sterke punten van 1C als platform

1C is niet sterk omdat er iets specifieks aan is dat de beste ter wereld is. Integendeel, in elk afzonderlijk subsysteem kun je een interessantere analoog vinden in de software van de wereld. Op basis van een combinatie van factoren zie ik echter geen platform vergelijkbaar met 1C. Dit is waar het commerciële succes ligt. De voordelen van het platform zijn overal verspreid en het duidelijkst zichtbaar als je ziet hoe dit op andere platforms gebeurt. Kortom, dit zijn NIET eens kenmerken, maar integendeel: een afwijzing van kenmerken ten gunste van één specifiek paradigma. Een paar voorbeelden:

1. Unicode. Wat kan er in vredesnaam eenvoudiger zijn? Het is in 2019 niet nodig om single-byte ASCII-coderingen te gebruiken (behalve voor integratie met oude, oudere coderingen). Nooit. Maar nee. Hoe dan ook, iemand in een tabel gebruikt een varchar van één byte en de applicatie zal problemen hebben met coderingen. In 2015 mislukte de LDAP-autorisatie van gitlab vanwege onjuist werken met coderingen; JetBrains IDE werkt nog steeds niet overal met Cyrillisch in bestandsnamen. 1C biedt hoogwaardige isolatie van applicatiecode van de databaselaag. Daar is het onmogelijk om tabellen op een laag niveau te typen en zijn de stijlen van incompetente junioren op databaseniveau daar onmogelijk. Ja, er kunnen andere problemen zijn met incompetente junioren, maar de verscheidenheid aan problemen is veel kleiner. Nu zult u mij vertellen dat uw applicatie correct is ontworpen en dat de databasetoegangslaag geïsoleerd is zoals het hoort. Kijk nog eens goed naar uw bedrijfseigen Java-applicatie. Dichtbij en eerlijk. Heeft u last van uw geweten? Dan ben ik blij voor je.
2. Nummering van documenten/naslagwerken. In 1C is het zeker niet de meest flexibele en niet de beste. Maar wat ze doen in banksoftware en in zelfgeschreven boekhoudsystemen – nou ja, het is gewoon duisternis. Ofwel zal de identiteit erin blijven steken (en dan “oh, waarom hebben we gaten”), of integendeel, ze zullen een generator maken die werkt met vergrendeling op DBMS-niveau (en een knelpunt zal worden). In feite is het vrij moeilijk om deze ogenschijnlijk eenvoudige taak uit te voeren: een end-to-end-enumerator van entiteiten, met een uniciteitssectie gebaseerd op een bepaalde set sleutels, voorvoegsel, zodat deze de database niet blokkeert tijdens parallelle gegevensinvoer .
3. Identificatiegegevens van records in de database. 1C heeft een wilskrachtige beslissing genomen: alle link-ID's zijn absoluut synthetisch en dat is alles. En er zijn geen problemen met gedistribueerde databases en uitwisselingen. Ontwikkelaars van andere systemen creëren koppig zoiets als identiteit (het is korter!), slepen ze naar de GUI totdat het tijd is om verschillende gerelateerde instanties te maken (en dan zullen ze ontdekt worden). Heb je dit niet? Eerlijk gezegd?
4. Lijsten. 1C beschikt over behoorlijk succesvolle mechanismen om door (grote) lijsten te bladeren en er doorheen te navigeren. Laat mij meteen een reservering maken - met correct gebruik van het mechanisme! Over het algemeen is het onderwerp nogal onaangenaam, het kan niet ideaal worden opgelost: het is intuïtief en eenvoudig (maar het risico van enorme recordsets op de client), of paging is op de een of andere manier scheef. Degenen die paging doen, doen het vaak scheef. Degenen die een eerlijke scrollbar maken, voegen een database, een kanaal en een klant toe.
5. Beheerde formulieren. Ongetwijfeld werkt de interface in de webclient niet perfect. Maar het werkt. Maar voor veel andere boekhoud- en banksystemen is het creëren van een externe werkplek een project op ondernemingsniveau. Disclaimer: gelukkig voor degenen die het oorspronkelijk op internet hebben gemaakt, heeft dit geen invloed.
6. Applicatie voor de mobiele telefoon. Sinds kort kunt u ook mobiele applicaties schrijven terwijl u zich in hetzelfde ecosysteem bevindt. Het is hier iets ingewikkelder dan bij een webclient; de specifieke kenmerken van apparaten dwingen je om specifiek voor hen te schrijven, maar je huurt niettemin geen apart team van mobiele ontwikkelaars in. Als je een applicatie nodig hebt voor de interne behoeften van een bedrijf (wanneer een mobiele oplossing voor een bedrijfsprobleem belangrijker is dan een geel UI-ontwerp), gebruik je gewoon kant-en-klaar hetzelfde platform.
7. Rapportage. Met dit woord bedoel ik niet een BI-systeem met big data en vertraging in het ETL-proces. Het gaat hier om operationele stafrapporten waarmee u hier en nu de stand van zaken van de boekhouding kunt beoordelen. Saldo's, onderlinge verrekeningen, herwaardering, etc. 1C komt kant-en-klaar met een rapportagesysteem met flexibele instellingen voor groeperingen, filters en visualisatie aan de gebruikerszijde. Ja, er zijn koelere analogen op de markt. Maar niet binnen het kader van een alles-in-één oplossing en tegen een prijs die soms hoger ligt dan een alles-in-één oplossing. En vaker is het zelfs andersom: alleen rapportage, maar duurder dan het hele platform, en slechter van kwaliteit.
8. Afdrukbare formulieren. Gebruik .NET om het probleem op te lossen van het per e-mail verzenden van salarisstroken in PDF naar werknemers. En nu de taak om facturen af ​​te drukken. Hoe zit het met het opslaan van hun kopieën in dezelfde PDF? Voor de 1C-bijnaam bedraagt ​​het uitvoeren van elke lay-out naar PDF +1 regel code. Dit betekent + 40 seconden werktijd, in plaats van dagen of weken in een andere taal. Lay-outs voor gedrukte formulieren in 1C zijn ongelooflijk eenvoudig te ontwikkelen en krachtig genoeg om te concurreren met betaalde tegenhangers. Ja, waarschijnlijk zijn er niet veel interactieve mogelijkheden in 1C-spreadsheetdocumenten; je kunt niet snel een 3D-diagram krijgen met schaling met behulp van OpenGL. Maar is het echt nodig?

Dit zijn slechts een handvol voorbeelden waarbij het beperken van functionaliteit of het implementeren van compromissen in de toekomst een belangrijk architectonisch voordeel blijkt te zijn. Zelfs een compromis of niet de meest effectieve optie - het zit al in de doos en wordt als vanzelfsprekend beschouwd. De onafhankelijke implementatie ervan zal ofwel onmogelijk zijn (omdat dergelijke beslissingen aan het begin van het project moeten worden genomen, en daar is geen tijd voor, en er is helemaal geen architect), ofwel verschillende dure iteraties. In elk van de genoemde punten (en dit is geen volledige lijst van architecturale oplossingen) kun je het verknoeien en beperkingen introduceren die de schaalvergroting blokkeren. In ieder geval moet u er als zakenman voor zorgen dat uw programmeurs, wanneer ze een “systeem vanaf het begin” maken, rechte handen hebben en subtiele systeemproblemen meteen goed kunnen oplossen.

Ja, net als in elk ander complex systeem heeft 1C zelf ook oplossingen die schaalvergroting in bepaalde aspecten blokkeren. Ik herhaal echter dat ik op basis van een combinatie van factoren, de eigendomskosten en het aantal problemen dat al van tevoren is opgelost, geen waardige concurrent op de markt zie. Voor dezelfde prijs krijg je een financieel applicatieframework, een geclusterde gebalanceerde server, met een gebruikersinterface en webinterface, met een mobiele applicatie, met rapportage, integratie en een heleboel andere dingen. In de Java-wereld huur je een front-end- en back-end-team in, debug je kleine hoeveelheden zelfgeschreven servercode en betaal je afzonderlijk voor 2 mobiele applicaties voor 2 mobiele besturingssystemen.

Ik zeg niet dat 1C alle gevallen zal oplossen, maar voor een interne bedrijfsapplicatie, als het niet nodig is om de gebruikersinterface te brandmerken, wat is er dan nog meer nodig?

Vlieg in de zalf

Je hebt waarschijnlijk de indruk gekregen dat 1C de wereld zal redden en dat alle andere manieren om bedrijfssystemen te schrijven verkeerd zijn. Het is helemaal niet zo. Als u vanuit het oogpunt van een zakenman voor 1C kiest, moet u naast een snelle time-to-market ook rekening houden met de volgende nadelen:

• Betrouwbaarheid van de server. Er zijn echt hoogwaardige specialisten nodig die een ononderbroken werking kunnen garanderen. Ik ben niet op de hoogte van een kant-en-klaar trainingsprogramma voor dergelijke specialisten bij de leverancier. Er zijn cursussen ter voorbereiding op het Expert-examen, maar dit is naar mijn mening niet voldoende.
• Steun. Zie vorig punt. Om ondersteuning van de verkoper te krijgen, moet u het kopen. Om de een of andere reden wordt dit niet geaccepteerd in de 1C-industrie. En met SAP is het bijna een must-purchase en heeft niemand er last van. Zonder bedrijfsondersteuning en zonder een deskundige op het gebied van personeel kunt u alleen achterblijven met 1C-problemen.
• Toch kun je niet absoluut alles doen met 1C. Dit is een hulpmiddel en zoals elk hulpmiddel kent het zijn toepasbaarheidsgrenzen. In het 1C-landschap is het zeer wenselijk om een ​​“niet-1C” systeemarchitect te hebben.
• Goede 1C-bijnamen zijn niet goedkoper dan goede programmeurs in andere talen. Hoewel het duur is om slechte programmeurs in te huren, ongeacht de taal waarin ze schrijven.

Laten we de puntjes op de i zetten

• 1C is een rapid application development (RAD) raamwerk voor het bedrijfsleven en is hiervoor op maat gemaakt.
• Drieledige koppeling met ondersteuning voor grote DBMS'en, client-UI, een zeer goede ORM en rapportage
• Brede mogelijkheden voor integratie met systemen die kunnen wat 1C niet kan. Als je machine learning wilt, neem dan Python en stuur het resultaat naar 1C via http of RabbitMQ
• Het is niet nodig om ernaar te streven alles met 1C te doen, u moet de sterke punten ervan begrijpen en deze voor uw eigen doeleinden gebruiken
• Ontwikkelaars die de neiging hebben zich te verdiepen in technologische raamwerkgadgets en elke N jaar opnieuw te ontwerpen voor een nieuwe engine, zijn verveeld met 1C. Alles is daar heel conservatief.
• Ontwikkelaars vervelen zich ook omdat er vanuit de fabrikant weinig aandacht voor hen is. Saaie taal, zwakke IDE. Ze vereisen modernisering.
• Aan de andere kant zijn ontwikkelaars die geen plezier beleven aan het gebruiken en leren van een andere technologie die ze leuk vinden, slechte ontwikkelaars. Ze zullen zeuren en naar een ander ecosysteem verhuizen.
• Werkgevers die niet toestaan ​​dat hun 1C-bijnamen iets in Python schrijven, zijn slechte werkgevers. Ze zullen werknemers met een nieuwsgierige geest verliezen, en in hun plaats zullen apencodeerders komen die, hoewel ze het met alles eens zijn, bedrijfssoftware het moeras in sleuren. Het zal nog herschreven moeten worden, dus misschien is het beter om wat eerder een beetje in Python te investeren?
• 1C is een commercieel bedrijf en implementeert functies uitsluitend op basis van zijn eigen belangen en opportuniteiten. Je kunt haar dit niet kwalijk nemen, het bedrijfsleven moet aan winst denken, zo is het leven
• 1C verdient geld door oplossingen voor zakelijke problemen te verkopen, niet voor Vasya's ontwikkelaarsproblemen. Deze twee concepten correleren, maar de prioriteit is precies wat ik zei. Wanneer ontwikkelaar Vasya bereid is te betalen voor een persoonlijke licentie voor 1C: Resharper, zal het vrij snel verschijnen, “Resharper” van A. Orefkova is hiervan het bewijs. Als de leverancier het zou steunen en er niet tegen zou vechten, zou er een markt voor software voor ontwikkelaars ontstaan. Nu zijn er anderhalve speler op deze markt met twijfelachtige resultaten, en dat allemaal omdat de integratie met de IDE negatief is en alles op krukken gebeurt.
• De praktijk van een multi-machine operator zal in de vergetelheid verdwijnen. Moderne applicaties zijn te groot om te onthouden, zowel vanuit de codekant als vanuit de kant van zakelijk gebruik. Ook wordt de 1C-server steeds complexer; het zal onmogelijk worden om alle expertises in één medewerker te huisvesten. Dit zou een vraag naar specialisten met zich mee moeten brengen, wat de aantrekkelijkheid van het 1C-vak en een stijging van de salarissen betekent. Als Vasya voorheen drie-in-één werkte voor één salaris, moet je nu twee Vasya's inhuren en kan de concurrentie tussen Vasya's de algehele groei van hun niveau stimuleren.

Conclusie

1C is een zeer waardevol product. In mijn prijsklasse ken ik helemaal geen analogen, schrijf in de reacties als die er zijn. De uitstroom van ontwikkelaars uit het ecosysteem wordt echter steeds merkbaarder, en dit is een ‘braindrain’, hoe je het ook bekijkt. De industrie hongert naar modernisering.
Als je een ontwikkelaar bent, blijf dan niet hangen in 1C en denk niet dat alles magisch is in andere talen. Terwijl je junior bent, misschien. Zodra er iets groters moet worden opgelost, zal er langer gezocht moeten worden naar kant-en-klare oplossingen en intensiever moeten worden ingevuld. Wat betreft de kwaliteit van de ‘blokken’ waaruit een oplossing kan worden opgebouwd, is 1C heel erg goed.

En nog een ding: als u een 1C-bijnaam krijgt om in te huren, kan de 1C-bijnaam veilig worden benoemd tot hoofdanalist. Hun begrip van de taak, het vakgebied en de ontbindingsvaardigheden is uitstekend. Ik ben er zeker van dat dit precies te wijten is aan het gedwongen gebruik van DDD bij de ontwikkeling van 1C. De persoon is getraind om allereerst na te denken over de betekenis van de taak, over de verbindingen tussen objecten van het vakgebied, en heeft tegelijkertijd een technische achtergrond in integratietechnologieën en formaten voor gegevensuitwisseling.

Wees je ervan bewust dat het ideale kader niet bestaat en zorg goed voor jezelf.
Allemaal goed!

PS: hartelijk dank speshurisch voor hulp bij het voorbereiden van het artikel.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Heeft u 1C in uw onderneming?

• 13,3%Helemaal niet.71

• 30,3%Die is er, maar alleen ergens op de boekhoudafdeling. Kernsystemen op andere platforms162

• 41,4%Ja, de belangrijkste bedrijfsprocessen werken erop221

• 15,0%1C moet sterven, de toekomst is van %technology_name%80

534 gebruikers hebben gestemd. 99 gebruikers onthielden zich van stemming.

Bron: www.habr.com