1C - चांगले आणि वाईट. 1C च्या आसपास होलिवर्समध्ये बिंदूंची व्यवस्था

मित्रांनो आणि सहकाऱ्यांनो, अलीकडेच विकास मंच म्हणून 1C बद्दल द्वेष असलेले Habré वर वारंवार लेख आले आहेत आणि त्याच्या बचावकर्त्यांची भाषणे आहेत. या लेखांनी एक गंभीर समस्या ओळखली: बऱ्याचदा, 1C चे समीक्षक "त्यावर प्रभुत्व मिळवू शकत नाहीत" या स्थितीतून टीका करतात, वास्तविकपणे सहजपणे सोडवल्या जाणाऱ्या समस्यांना फटकारतात आणि त्याउलट, खरोखर महत्त्वाच्या, किमतीच्या समस्यांना स्पर्श न करता. चर्चा करणे आणि विक्रेत्याद्वारे निराकरण केले जात नाही. माझा विश्वास आहे की 1C प्लॅटफॉर्मचे शांत आणि संतुलित पुनरावलोकन करणे अर्थपूर्ण आहे. तो काय करू शकतो, काय करू शकत नाही, त्याने काय केले पाहिजे पण करू नये, आणि मिष्टान्नसाठी, ते धमाकेदारपणे काय करते आणि %technology_name% वरील तुमचे डेव्हलपर शंभर वर्षे करतील, ते फेकून देतील एकापेक्षा जास्त वार्षिक बजेट.

परिणामी, तुम्हाला, व्यवस्थापक किंवा वास्तुविशारद म्हणून, तुम्हाला 1C वापरणे कोणते कार्य फायदेशीर ठरेल आणि ते गरम लोखंडाने कोठे जाळून टाकणे आवश्यक आहे याची स्पष्ट समज प्राप्त करण्यास सक्षम असाल. "नॉन-1C" जगामध्ये विकासक म्हणून, तुम्हाला 1C मध्ये असे काय आहे जे गडबड करत आहे हे पाहण्यास सक्षम असेल. आणि 1C विकसक म्हणून, तुम्ही तुमच्या सिस्टमची इतर भाषांच्या इकोसिस्टमशी तुलना करू शकाल आणि सॉफ्टवेअर डेव्हलपमेंटच्या समन्वय प्रणालीमध्ये तुमचे स्थान समजू शकाल.

कट अंतर्गत 1C वर, 1C च्या समीक्षकांवर, Java, .NET वर आणि सर्वसाधारणपणे खूप जाड हल्ले आहेत... पंखा भरला आहे, स्वागत आहे!

माझ्याबद्दल

मी अंदाजे 2004 पासून संभाषणाच्या विषयाशी परिचित आहे. मी 6 वर्षांचा असल्यापासून प्रोग्रॅमिंग करत आहे, तेव्हापासून मला प्रोफेसर फोर्ट्रान बद्दल एक मांजर, एक चिमणी आणि सुरवंट बद्दल कॉमिक्स असलेले पुस्तक मिळाले. मी पुस्तकातील चित्रांमधून मांजरीने लिहिलेल्या प्रोग्रामचे विश्लेषण केले आणि त्यांनी काय केले ते शोधून काढले. आणि हो, त्यावेळी माझ्याकडे खरा संगणक नव्हता, परंतु पुस्तकाच्या प्रसारावर एक रेखाचित्र होते आणि मी प्रामाणिकपणे कागदाची बटणे दाबली आणि मी एक्स मांजरीची हेरगिरी केली होती त्या आज्ञा प्रविष्ट केल्या.

त्यानंतर शाळेत BK0011 आणि BASIC, C++ आणि विद्यापीठात असेंबलर, नंतर 1C आणि नंतर इतर अनेक गोष्टी होत्या ज्या लक्षात ठेवण्यास मी खूप आळशी आहे. गेल्या 15 वर्षांपासून, मी मुख्यतः 1C मध्ये गुंतलो आहे, केवळ कोडिंगच्या बाबतीतच नाही तर सर्वसाधारणपणे 1C मध्ये. येथे कार्ये, प्रशासन आणि devops सेट करणे. गेल्या 5 वर्षांपासून मी इतर 1C वापरकर्त्यांसाठी विकास आणि ऑटोमेशन साधने विकसित करणे, लेख आणि पुस्तके लिहिणे या दृष्टीने सामाजिकदृष्ट्या उपयुक्त क्रियाकलापांमध्ये व्यस्त आहे.

चर्चेचा विषय ठरवू

प्रथम, आपण कशाबद्दल बोलणार आहोत ते परिभाषित करूया, कारण "1C" अक्षरांचा अर्थ बऱ्याच गोष्टी असू शकतो. या प्रकरणात, "1C" अक्षरांद्वारे आमचा अर्थ केवळ आधुनिक, आठव्या आवृत्तीचा विकास फ्रेमवर्क "1C: एंटरप्राइझ" असेल. आम्ही निर्माता आणि त्याच्या धोरणांबद्दल जास्त बोलणार नाही (परंतु आम्हाला थोडेसे करावे लागेल). तंत्रज्ञान वेगळे आहे, ऍप्लिकेशन उर्फ ​​कॉन्फिगरेशन वेगळे आहेत.

उच्च-स्तरीय आर्किटेक्चर 1C: Enterprise

मी “फ्रेमवर्क” या शब्दाचा उल्लेख करतो असे काही नाही. विकसकाच्या दृष्टिकोनातून, 1C प्लॅटफॉर्म तंतोतंत एक फ्रेमवर्क आहे. आणि आपल्याला ते अगदी फ्रेमवर्कप्रमाणे वागण्याची आवश्यकता आहे. याचा स्प्रिंग किंवा ASP.NET म्हणून विचार करा, काही रनटाइम (अनुक्रमे JVM किंवा CLR) द्वारे अंमलात आणला जातो. असे घडते की पारंपारिक प्रोग्रामिंगच्या जगात (“1C नाही”), फ्रेमवर्क, व्हर्च्युअल मशीन आणि विशिष्ट अनुप्रयोगांमध्ये विभागणी नैसर्गिक आहे, कारण हे घटक सामान्यतः भिन्न उत्पादकांद्वारे विकसित केले जातात. 1C जगामध्ये, विकास फ्रेमवर्क आणि रनटाइममध्ये स्पष्टपणे फरक करण्याची प्रथा नाही, याव्यतिरिक्त, फ्रेमवर्क वापरून लिहिलेले विशिष्ट अनुप्रयोग देखील मुख्यतः 1C द्वारे विकसित केले जातात; परिणामी, काही गोंधळ निर्माण होतो. म्हणून, लेखाच्या चौकटीत, आपल्याला एकाच वेळी अनेक बाजूंनी 1C विचारात घ्यावा लागेल आणि अनेक समन्वय अक्षांसह त्याचे वर्गीकरण करावे लागेल. आणि प्रत्येक समन्वय अक्षावर आम्ही तपकिरी पदार्थाचा एक फावडे ठेवू आणि विद्यमान द्रावणाची वैशिष्ट्ये, फायदे आणि तोटे पाहू.

1C वर दृश्य बिंदू

खरेदीदारासाठी 1C

खरेदीदार एक ऑटोमेशन सिस्टम खरेदी करतो ज्याद्वारे तो स्वतःचा व्यवसाय स्वयंचलित करण्याच्या समस्या त्वरीत सोडवू शकतो. व्यवसाय एक लहान स्टॉल असू शकतो किंवा ती मोठी होल्डिंग कंपनी असू शकते. हे स्पष्ट आहे की या व्यवसायांच्या गरजा भिन्न आहेत, परंतु दोन्ही एकाच प्लॅटफॉर्म कोड बेसद्वारे समर्थित आहेत.

1C खरेदीदारासाठी हे मार्केट टू-टू-टाईम आहे. जलद. Java, C# किंवा JS पेक्षा वेगवान. सरासरी. हॉस्पिटलच्या आसपास. हे स्पष्ट आहे की प्रतिक्रिया वापरणारी व्यवसाय कार्ड वेबसाइट अधिक चांगली होईल, परंतु WMS प्रणालीचा बॅकएंड 1C वर वेगाने लॉन्च होईल.

एक साधन म्हणून 1 सी

प्रत्येक तांत्रिक उपायाला लागू होण्याच्या मर्यादा असतात. 1C ही सामान्य-उद्देशाची भाषा नाही; ती त्याच्या चौकटीपासून वेगळी राहत नाही. जेव्हा आपल्याला आवश्यक असेल तेव्हा 1C वापरण्याचा सल्ला दिला जातो:

• सर्व्हर अनुप्रयोग
• अर्ज जेथे वित्त दिसते
• रेडीमेड UI, ORM, रिपोर्टिंग, XML/JSON/COM/PDF/YourDataTransferingFormat सह
• पार्श्वभूमी प्रक्रिया आणि नोकऱ्यांसाठी समर्थनासह
• भूमिका-आधारित सुरक्षिततेसह
• स्क्रिप्टेबल व्यवसाय तर्कासह
• त्वरीत प्रोटोटाइप तयार करण्याची क्षमता आणि कमी वेळ-मार्केट

तुम्हाला हवे असल्यास 1C ची गरज नाही:

• मशीन लर्निंग
• GPU गणना
• संगणक ग्राफिक्स
• गणिती आकडेमोड
• CAD प्रणाली
• सिग्नल प्रोसेसिंग (ध्वनी, व्हिडिओ)
• शेकडो हजारो आरपीएस सह HTTP कॉल हायलोड करा

एक उत्पादन कंपनी म्हणून 1C

सॉफ्टवेअर निर्माता म्हणून 1C चा व्यवसाय काय आहे हे समजून घेण्यासारखे आहे. 1C कंपनी ऑटोमेशनद्वारे व्यावसायिक समस्यांचे निराकरण करते. छोटे किंवा मोठे वेगवेगळे व्यवसाय, पण ती ती विकते. हे ध्येय साध्य करण्याचे साधन म्हणजे व्यवसाय अनुप्रयोग. अकाउंटिंग, पेरोल अकाउंटिंग इत्यादीसाठी हे ॲप्लिकेशन्स लिहिण्यासाठी, कंपनी स्वतःचा बिझनेस ॲप्लिकेशन डेव्हलपमेंट प्लॅटफॉर्म वापरते. या समान व्यावसायिक अनुप्रयोगांच्या सामान्य कार्यांसाठी खास तयार केलेले:

• आर्थिक लेखा
• व्यवसाय तर्काचे सोपे सानुकूलन
• विषम IT लँडस्केपमध्ये विस्तृत एकीकरण शक्यता

एक निर्माता म्हणून, 1C असा विश्वास ठेवतो की ही अशी रणनीती आहे जी तुम्हाला विन-विन मोडमध्ये भागीदार आणि क्लायंटसह कार्य करण्यास अनुमती देते. तुम्ही याच्याशी वाद घालू शकता, परंतु कंपनी स्वतःचा प्रचार कशाप्रकारे करते: व्यावसायिक समस्यांसाठी तयार केलेले उपाय जे भागीदारांद्वारे पटकन सानुकूलित केले जाऊ शकतात आणि कोणत्याही IT लँडस्केपमध्ये एकत्रित केले जाऊ शकतात.

फ्रेमवर्क म्हणून 1C साठी सर्व दावे किंवा इच्छा या प्रिझमद्वारे केवळ पाहिल्या पाहिजेत. "आम्हाला 1C मध्ये OOP पाहिजे," विकासक म्हणतात. "प्लॅटफॉर्ममध्ये OOP चे समर्थन करण्यासाठी आम्हाला किती खर्च येईल, हे आम्हाला बॉक्सची विक्री वाढविण्यात मदत करेल?" व्यवसायाच्या समस्यांवरील उपाय विकण्याचे त्याचे "प्रिझम" उघडते:

- अहो, व्यवसाय, तुम्हाला तुमच्या 1C मध्ये OOP हवा आहे का?
- हे मला माझ्या समस्यांचे निराकरण करण्यात मदत करेल?
- कोणास ठाऊक ...
- मग गरज नाही

हा दृष्टिकोन कोणाकडे पाहत आहे यावर अवलंबून तो चांगला किंवा वाईट असू शकतो, परंतु तो तसाच आहे. 1C मध्ये X हे कोणतेही वैशिष्ट्य नाही या वस्तुस्थितीबद्दल बोलताना, तुम्हाला हे समजून घेणे आवश्यक आहे की ते कारणास्तव नाही, परंतु "अंमलबजावणी खर्च वि नफा रक्कम" या निवडीच्या संदर्भात आहे.

तांत्रिक वर्गीकरण

“खरं तर, Odinesniks 1C प्लॅटफॉर्मच्या काळजी घेणाऱ्या मेथडॉलॉजिस्ट आणि डेव्हलपर्सनी काळजीपूर्वक निवडलेल्या सर्वोत्तम पॅटर्नचा वापर करण्याचा सर्वोत्तम प्रयत्न करतात.
जेव्हा तुम्ही तुमचा मूर्ख कोड एका साध्या व्यवस्थापित फॉर्मसाठी लिहिता, तेव्हा प्रत्यक्षात तुम्ही वापरत आहात मॉडेल-दृश्य-नियंत्रक с दुहेरी मार्ग डेटा बंधनकारक в तीन-स्तरीय-डेटा-ॲप-इंजिन, चविष्ट उच्च स्तरीय ऑब्जेक्ट-रिलेशन-मॅपिंग बेस वर घोषणात्मक मेटाडेटा वर्णनस्वतःचे असणे प्लॅटफॉर्म-स्वतंत्र क्वेरी भाषा, सी घोषणात्मक डेटा-चालित वापरकर्ता इंटरफेस, संपूर्ण पारदर्शक अनुक्रमिकरण आणि डोमेन-देणारं प्रोग्राम भाषा.

जेथे 1C विकासक त्यांच्या पाश्चात्य सहकाऱ्यांपेक्षा वेगळे आहेत ते PR मध्ये आहे. कोणत्याही बकवासाला मोठे नाव द्यायला आणि घाणेरड्या पिशवीसारखे ते घेऊन पळणे त्यांना आवडते.”
A. Orefkov

1C प्लॅटफॉर्ममध्ये क्लासिक 3-स्तरीय आर्किटेक्चर आहे, ज्याच्या मध्यभागी ऍप्लिकेशन सर्व्हर आहे (किंवा लहान दुकानदारांसाठी थोड्या पैशासाठी त्याचे अनुकरण). एकतर MS SQL किंवा Postgres DBMS म्हणून वापरले जाते. Oracle आणि IBM DB2 साठी देखील समर्थन आहे, परंतु हे गूढ आहे की आपण या डेटाबेसवर मध्यम आणि उच्च भाराखाली 1C लागू केल्यास काय होईल; माझा विश्वास आहे की 1C ला हे माहित नाही.

क्लायंट भाग एकतर वापरकर्त्याच्या मशीनवर स्थापित केलेला पातळ क्लायंट किंवा वेब क्लायंट असतो. मुख्य वैशिष्ट्य म्हणजे प्रोग्रामर 2 भिन्न कोड लिहित नाहीत, ते एका भाषेत एक अनुप्रयोग लिहितात आणि इच्छा किंवा गरज असल्यास आपण ते ब्राउझरमध्ये प्रदर्शित करू शकता. समोर आणि बॅकएंड, node.js साठी खरा पूर्ण स्टॅक आणि एकच भाषा कोणाला हवी होती? ते शेवटपर्यंत नेमके तेच करू शकले नाहीत. वास्तविक पूर्ण स्टॅक अस्तित्वात आहे, परंतु तुम्हाला ते 1C मध्ये लिहावे लागेल. नशिबाची विडंबना, अशा गोष्टी :)

क्लाउड सास सोल्यूशन 1C:फ्रेश ब्राउझर मोडमध्ये देखील कार्य करते, ज्यामध्ये आपण 1C खरेदी करू शकत नाही, परंतु एक छोटा डेटाबेस भाड्याने घेऊ शकता आणि तेथे शावरमा विक्रीचा मागोवा घेऊ शकता. फक्त ब्राउझरमध्ये, काहीही स्थापित किंवा कॉन्फिगर न करता.

याव्यतिरिक्त, एक वारसा क्लायंट आहे, ज्याला 1C मध्ये "नियमित अनुप्रयोग" म्हटले जाते. वारसा हा वारसा आहे, 2002 मध्ये ऍप्लिकेशन्सच्या जगात स्वागत आहे, परंतु आम्ही अजूनही इकोसिस्टमच्या सद्य स्थितीबद्दल बोलत आहोत.

1C सर्व्हर भाग क्लस्टरमध्ये नवीन मशीन जोडून क्लस्टरिंग आणि स्केलला समर्थन देतो. इथे बऱ्याच प्रती तुटल्या आहेत आणि त्याबद्दल लेखात एक स्वतंत्र विभाग असेल. थोडक्यात, हे HAProxy च्या मागे अगदी समान उदाहरणे जोडण्यासारखे नाही.

ऍप्लिकेशन डेव्हलपमेंट फ्रेमवर्क स्वतःची प्रोग्रामिंग भाषा वापरते, जी रशियनमध्ये अनुवादित केलेल्या किंचित सुधारित VB6 सारखी दिसते. जे लोक रशियन प्रत्येक गोष्टीचा तिरस्कार करतात, ज्यांना विश्वास नाही की "जर" चे भाषांतर "जर" म्हणून केले जाते, तर दुसरा वाक्यरचना पर्याय ऑफर केला जातो. त्या. तुमची इच्छा असल्यास, तुम्ही ते 1C मध्ये अशा प्रकारे लिहू शकता की ते VB पासून वेगळे करता येणार नाही.

ही प्रोग्रामिंग भाषा त्यांच्या प्लॅटफॉर्मबद्दल 1C टोपणनावांच्या द्वेषाचे मुख्य कारण आहे. चला सामोरे जाऊया, विनाकारण नाही. भाषेची संकल्पना शक्य तितकी सोपी केली गेली होती, जी किमान सीआयएसमध्ये "विकासक, विकासक" मंत्र पूर्ण करण्यासाठी डिझाइन केलेली होती. अशा सोल्यूशनचे व्यावसायिक सार, माझ्या मते, स्पष्टपणे दृश्यमान आहे: अधिक विकसक, अधिक बाजार व्याप्ती. 45% ते 95% पर्यंतच्या विविध अंदाजानुसार हे खरे ठरले. मी लगेच म्हणेन की तुम्हाला वाटते त्या भाषेत लिहिणे खरोखर सोपे आहे. आणि मला बऱ्याच प्रोग्रामिंग भाषा माहित आहेत.

चला भाषेपासून सुरुवात करूया.

1C प्रोग्रामिंग भाषा

त्याच वेळी प्रणालीचा मजबूत आणि कमकुवत बिंदू. सुलभ प्रवेश आणि वाचनीयता प्रदान करते. दुसरीकडे, 8 मध्ये आवृत्ती 2002 रिलीज झाल्यापासून ते अद्यतनित केले गेले नाही आणि नैतिकदृष्ट्या जुने आहे. कोणीतरी म्हणेल "मुख्य दोष म्हणजे OOP नाही" आणि ते चुकीचे असतील. प्रथम, पीएलओला केवळ नुरलीव्हच नाही तर टोरवाल्ड्स देखील आवडतात. आणि दुसरे म्हणजे, OOP अजूनही अस्तित्वात आहे.

विकसकाच्या दृष्टिकोनातून, त्याच्याकडे DBMS वर प्रदर्शित केलेल्या बेस क्लाससह एक फ्रेमवर्क आहे. डेव्हलपर बेस क्लास "डिरेक्टरी" घेऊ शकतो आणि त्यातून "क्लायंट" डिरेक्टरी इनहेरिट करू शकतो. ते त्यात नवीन वर्ग फील्ड जोडू शकते, उदाहरणार्थ, INN आणि पत्ता, आणि आवश्यक असल्यास, ते बेस क्लासच्या पद्धती ओव्हरराइड (ओव्हरराइड) करू शकते, उदाहरणार्थ, OnWrite/AtRecord पद्धत.

फ्रेमवर्क अशा प्रकारे डिझाइन केले आहे की सखोल वारसा क्वचितच आवश्यक आहे, आणि माझ्या मते, OOP मधील प्रतिबंध अर्थपूर्ण आहे. 1C डोमेन ड्रिव्हन डेव्हलपमेंटवर लक्ष केंद्रित करते आणि तुम्हाला सर्वप्रथम, विकसित केलेल्या सोल्यूशनच्या विषय क्षेत्राबद्दल विचार करण्यास प्रवृत्त करते आणि हे चांगले आहे. फक्त कुठलाही प्रलोभन नाही, तर कुठेतरी डोमेनवरून काही डेटा दाखवण्यासाठी 10 भिन्न DTO आणि ViewModels लिहिण्याचीही गरज नाही. 1C डेव्हलपर नेहमी एकाच घटकासह कार्य करतो, समान नावांसह डझनभर वर्गांसह आकलनाच्या संदर्भामध्ये गोंधळ न करता, समान अस्तित्वाचे प्रतिनिधित्व करतो, परंतु वेगळ्या बाजूने. कोणत्याही .NET ऍप्लिकेशनमध्ये, उदाहरणार्थ, JSON मध्ये क्रमवारी लावण्यासाठी आणि क्लायंटकडून सर्व्हरवर डेटा ट्रान्सफर करण्यासाठी पाच किंवा दोन ViewModels आणि DTOs असणे आवश्यक आहे. आणि तुमच्या ॲप्लिकेशन कोडपैकी अंदाजे 10-15% पेन किंवा ऑटोमॅपर सारख्या क्रॅचचा वापर करून एका वर्गातून दुसऱ्या वर्गात डेटा हस्तांतरित करण्यासाठी खर्च केला जाईल. हा कोड लिहिला जाणे आवश्यक आहे आणि प्रोग्रामरना ते तयार करण्यासाठी आणि देखरेख करण्यासाठी पैसे दिले पाहिजेत.

असे दिसून आले की 1C भाषा मुख्य प्रवाहातील भाषांच्या पातळीवर गुंतागुंत न करता विकसित करणे कठीण आहे, त्यामुळे साधेपणाचा फायदा गमावला जातो. विक्रेत्याचे काय कार्य मूलत: सोडवले जात आहे: रस्त्यावर पकडलेला कोणताही विद्यार्थी दर्जाच्या आवश्यक पातळीनुसार सानुकूलित करू शकेल असे मानक समाधान जारी करणे (म्हणजे, स्टॉलपासून मोठ्या कारखान्यापर्यंतचे केस कव्हर करणे पूर्ण झाले आहे). जर तुम्ही स्टॉल असाल तर विद्यार्थी घ्या, जर तुम्ही कारखाना असाल तर तुमच्या अंमलबजावणी करणाऱ्या भागीदाराकडून गुरू घ्या. अंमलबजावणी करणारे भागीदार विद्यार्थ्यांना गुरूच्या किमतीत विकतात ही वस्तुस्थिती फ्रेमवर्कमध्ये अडचण नाही. वास्तुशास्त्रीयदृष्ट्या, फ्रेमवर्कने दोन्ही समस्या सोडवल्या पाहिजेत, मानक कॉन्फिगरेशनचे कोड (जे आम्ही सानुकूलित करण्याचे वचन देऊन व्यवसायांना विकले आहे) विद्यार्थ्याला समजले पाहिजे आणि गुरु तुम्हाला जे हवे आहे ते समजण्यास सक्षम असावे.

माझ्या मते, भाषेत खरोखर काय गहाळ आहे, जे तुम्हाला तुमच्यापेक्षा जास्त लिहिण्यास भाग पाडते, ग्राहकाने दिलेला वेळ वाया जातो.

• स्तरावर टाइप करण्याची शक्यता, उदाहरणार्थ, TypeScript (परिणामी, IDE मध्ये अधिक विकसित कोड विश्लेषण साधने, रिफॅक्टरिंग, कमी आक्षेपार्ह जॅम्ब्स)
  फर्स्ट क्लास ऑब्जेक्ट्स म्हणून फंक्शन्सची उपलब्धता. थोडी अधिक क्लिष्ट संकल्पना, परंतु ठराविक बॉयलरप्लेट-कोडचे प्रमाण मोठ्या प्रमाणात कमी केले जाऊ शकते. IMHO या कोडची विद्यार्थ्याची समज कमी झाल्यामुळे आणखी वाढेल
• सार्वभौमिक संग्रह शाब्दिक, आरंभिक. तीच गोष्ट - कोडचे प्रमाण कमी करणे जे लिहिणे आणि/किंवा तुमच्या डोळ्यांनी पाहणे आवश्यक आहे. संग्रह भरण्यासाठी 9000C प्रोग्रामिंग वेळेपैकी 1% पेक्षा जास्त वेळ लागतो. सिंटॅक्टिक साखरेशिवाय हे लिहिणे लांब, महाग आणि त्रुटी प्रवण आहे. सर्वसाधारणपणे, 1C सोल्यूशन्समधील LOC चे प्रमाण उपलब्ध खुल्या फ्रेमवर्कच्या तुलनेत सर्व कल्पना करण्यायोग्य मर्यादा ओलांडते आणि सर्वसाधारणपणे, तुमचे सर्व एंटरप्राइझ Javas एकत्रितपणे. भाषा शब्दशः आहे आणि यामुळे डेटा, मेमरी, IDE ब्रेक, वेळ, पैसा...
• शेवटी बांधकामे मला एक गृहितक आहे की हे बांधकाम गहाळ आहे कारण त्यांना त्याचे रशियनमध्ये यशस्वी भाषांतर सापडले नाही :)
• स्वतःचे डेटा प्रकार (OOP शिवाय), VB6 मधील प्रकाराचे ॲनालॉग्स. हे तुम्हाला BSP मधील टिप्पण्या आणि या रचना तयार करणाऱ्या जादुई पद्धती वापरून रचना टाइप न करण्याची अनुमती देईल. आम्हाला मिळते: कमी कोड, बिंदूद्वारे एक इशारा, समस्येचे जलद निराकरण, टायपोमुळे कमी त्रुटी आणि संरचनांचे गुणधर्म गहाळ आहेत. आता युजर स्ट्रक्चर्सचे टायपिंग पूर्णपणे स्टँडर्ड सबसिस्टम लायब्ररीच्या डेव्हलपमेंट टीमवर अवलंबून आहे, जे त्याच्या श्रेयानुसार, पास केलेल्या पॅरामीटर स्ट्रक्चर्सच्या अपेक्षित गुणधर्मांवर काळजीपूर्वक टिप्पण्या लिहितात.
• वेब क्लायंटवर असिंक्रोनस कॉलसह काम करताना साखर नाही. कॉलबॅक-हेल प्रोसेसिंग नोटिफिकेशन्सच्या रूपात मुख्य ब्राउझरच्या एपीआयमध्ये अचानक बदल झाल्यामुळे एक तात्पुरता क्रॅच आहे, परंतु तुम्ही असे सर्व वेळ जगू शकत नाही, ॲसिंक्रोनस कोडच्या "विद्यार्थी समज" चा फायदा गमावला जातो अधिकाधिक. मुख्य IDE मध्ये या पॅराडाइमसाठी कोणतेही समर्थन जोडू नका आणि गोष्टी आणखी वाईट होतात.

ही एक महत्त्वाची समस्या आहे, हे स्पष्ट आहे की यादी खूप मोठी असू शकते, परंतु आपण हे विसरू नये की ही अद्याप सामान्य-उद्देशाची भाषा नाही, तिला मल्टीथ्रेडिंग, लॅम्बडा फंक्शन्स, GPU मध्ये प्रवेश आणि जलद आवश्यक नाही. फ्लोटिंग पॉइंट गणना. ही एक व्यवसाय लॉजिक स्क्रिप्टिंग भाषा आहे.

एक प्रोग्रामर ज्याने या भाषेवर आधीच खूप काम केले आहे, js किंवा c# मध्ये पाहतो, या भाषेच्या चौकटीत कंटाळा येतो. ती वस्तुस्थिती आहे. त्याला विकास हवा आहे. विक्रेत्यासाठी स्केलच्या दुसऱ्या बाजूला निर्दिष्ट वैशिष्ट्यांच्या अंमलबजावणीची किंमत विरुद्ध त्यांच्या अंमलबजावणीनंतर उत्पन्नात झालेली वाढ आहे. कंपनीच्या नजरेत सध्या काय जास्त आहे याबद्दल माझ्याकडे कोणतीही माहिती नाही.

विकासाचे वातावरण

इथेही गोष्टी सुरळीत होत नाहीत. विकासाचे दोन वातावरण आहेत. डिलिव्हरीमध्ये समाविष्ट केलेला पहिला कॉन्फिगरेटर आहे. दुसरे म्हणजे एंटरप्राइज डेव्हलपमेंट टूल्स एनवायरमेंट, किंवा थोडक्यात EDT, Eclipse च्या आधारावर विकसित केले गेले.

कॉन्फिगरेटर विकास कार्यांची संपूर्ण श्रेणी प्रदान करतो, सर्व वैशिष्ट्यांना समर्थन देतो आणि बाजारातील मुख्य वातावरण आहे. हे नैतिकदृष्ट्या अप्रचलित आहे, विकसित होत नाही, अफवांनुसार - स्वतःमध्ये तांत्रिक कर्जाच्या रकमेमुळे. अंतर्गत API उघडून परिस्थिती सुधारली जाऊ शकते (सह मैत्रीच्या स्वरूपात स्नोमॅन A. Orefkova किंवा स्वतंत्र आधारावर), परंतु हे असे नाही. सरावाने दाखवले आहे की जोपर्यंत विक्रेता हस्तक्षेप करत नाही तोपर्यंत समुदाय स्वतःची वैशिष्ट्ये IDE मध्ये लिहील. पण आपल्याकडे जे आहे ते आपल्याकडे आहे. 2004-2005 मध्ये कॉन्फिग्युरेटर उत्तम होता, त्या काळातील व्हिज्युअल स्टुडिओची खूप आठवण करून देणारा, काही ठिकाणी तो अगदी थंड होता, पण त्या काळात तो अडकला होता.

याव्यतिरिक्त, तेव्हापासून सरासरी मानक सोल्यूशनचे प्रमाण अनेक वेळा वाढले आहे आणि आज IDE फक्त त्याला दिलेला कोडचा सामना करू शकत नाही. उपयोगिता आणि रिफॅक्टरिंग क्षमता शून्य देखील नाहीत, त्या लाल रंगात आहेत. हे सर्व विकासकांमध्ये उत्साह वाढवत नाही आणि ते इतर इकोसिस्टममध्ये जाण्याचे आणि तेथे कोड शिट चालू ठेवण्याचे स्वप्न पाहतात, परंतु आपल्या वर्तनाने आपल्या चेहऱ्यावर थुंकत नाही अशा आनंददायी वातावरणात.

एक पर्याय म्हणून, Eclipse वर तयार केलेला, सुरवातीपासून लिहिलेला IDE ऑफर केला जातो. तेथे, स्त्रोत, इतर कोणत्याही सॉफ्टवेअरप्रमाणे, मजकूर फायलींच्या स्वरूपात राहतात, जीआयटीमध्ये संग्रहित केले जातात, विनंती शाखा, हे सर्व. नकारात्मक बाजूने, त्याने अनेक वर्षांपासून बीटा स्थिती सोडलेली नाही, जरी ती प्रत्येक रिलीझसह अधिक चांगली होत आहे. मी EDT च्या तोट्यांबद्दल लिहिणार नाही, आज ते उणे आहे, उद्या ते एक निश्चित वैशिष्ट्य आहे. अशा वर्णनाची प्रासंगिकता त्वरीत नाहीशी होईल. आज EDT मध्ये विकसित करणे शक्य आहे, परंतु हे असामान्य आहे की आपल्याला विशिष्ट संख्येच्या IDE बगसाठी तयार असणे आवश्यक आहे.

जर तुम्ही वर नमूद केलेल्या "1C प्रिझम" द्वारे परिस्थिती पाहिली तर तुम्हाला असे काहीतरी मिळेल: नवीन IDE च्या रिलीझमुळे बॉक्सची विक्री वाढत नाही, परंतु डेव्हलपर्सचा बहिर्वाह कमी होऊ शकतो. डेव्हलपर सोईच्या दृष्टीने इकोसिस्टमची काय प्रतीक्षा आहे हे सांगणे कठीण आहे, परंतु मायक्रोसॉफ्टने आधीच मोबाईल डेव्हलपर्सना त्यांच्या सेवा खूप उशीरा ऑफर करून त्यांना त्रास दिला आहे.

विकास व्यवस्थापन

कोड लिहिण्यापेक्षा येथे सर्व काही लक्षणीयरित्या चांगले आहे, विशेषत: अलीकडे, जेव्हा समुदायाच्या प्रयत्नांमुळे प्रशासनाच्या ऑटोमेशनच्या समस्या प्रकाशात आल्या, 1C भांडार कचऱ्याच्या ढिगाऱ्यात फेकण्यासाठी आणि गिट, द्रुत दोष, कोड-रिव्ह्यू वापरण्यासाठी प्रोटोटाइप लॉन्च केले गेले. , स्थिर विश्लेषण, ऑटो-डिप्लॉय आणि इ. प्लॅटफॉर्मवर अनेक वैशिष्ट्ये जोडली गेली आहेत जी विकास कार्यांच्या ऑटोमेशनची पातळी वाढवतात. तथापि, ही सर्व वैशिष्ट्ये केवळ आणि केवळ आमच्या स्वतःच्या मोठ्या उत्पादनांच्या विकासासाठी जोडली गेली, जेव्हा हे स्पष्ट झाले की आम्ही ऑटोमेशनशिवाय करू शकत नाही. तेथे स्वयं-विलीनीकरण, KDiff सह त्रि-मार्गी तुलना आणि हे सर्व होते. Github वर लाँच केले gitconverter, जे स्पष्टपणे, वैचारिकदृष्ट्या प्रकल्पापासून दूर खेचले गेले gitsync, परंतु विक्रेता कंपनीच्या प्रक्रियेनुसार सुधारित केले आहे. ओपन-सोर्सच्या हट्टी मुलांबद्दल धन्यवाद, 1C मधील विकास ऑटोमेशन जमिनीवर उतरले. कॉन्फिगरेटरसाठी एक ओपन API, IMHO, मुख्य IDE चे नैतिक मागासलेपण देखील बदलेल.

आज, जिरामधील समस्यांशी लिंक केलेल्या कमिटसह 1C स्रोत गिटमध्ये संग्रहित करणे, क्रूसिबलमधील पुनरावलोकने, जेनकिन्सचे पुश बटण आणि 1C मध्ये कोड चाचणी आणि अल्युअर अहवाल SonarQube मध्ये स्थिर विश्लेषण - हे बातम्यांपासून दूर आहे, परंतु ज्या कंपन्यांमध्ये 1C विकास भरपूर आहे अशा कंपन्यांमधील मुख्य प्रवाह.

प्रशासन

इथे खूप काही सांगण्यासारखे आहे. प्रथम, हे अर्थातच एक सर्व्हर आहे (1C सर्व्हर क्लस्टर). एक आश्चर्यकारक गोष्ट आहे, परंतु हा एक पूर्णपणे ब्लॅक बॉक्स आहे या वस्तुस्थितीमुळे, पुरेशा तपशीलाने दस्तऐवजीकरण केले गेले आहे, परंतु विशिष्ट प्रकारे - अनेक सर्व्हरवर हायलोड मोडमध्ये अखंडित ऑपरेशन सुरू करण्यात प्रभुत्व मिळवणे हे काही निवडक लोकांसाठी आहे जे कपडे घालतात. "तांत्रिक समस्यांवरील तज्ञ" शिलालेख असलेले पदक. हे लक्षात घेण्यासारखे आहे की, तत्त्वानुसार, 1C सर्व्हरचे व्यवस्थापन करणे हे इतर कोणत्याही सर्व्हरचे व्यवस्थापन करण्यापेक्षा वेगळे नाही. हे नेटवर्क-आधारित, मल्टी-थ्रेडेड ऍप्लिकेशन आहे जे मेमरी, CPU आणि डिस्क संसाधने वापरते. टेलीमेट्री संकलन आणि निदानासाठी भरपूर संधी प्रदान करते.

येथे समस्या अशी आहे की विक्रेते या निदानासाठी तयार-तयार उपायांच्या बाबतीत काही विशेष ऑफर करत नाहीत. होय, 1C आहे: इन्स्ट्रुमेंटेशन आणि कंट्रोल सेंटर, ते अगदी चांगले आहेत, परंतु ते खूप महाग आहेत आणि प्रत्येकाकडे ते नसतात. Grafana, Zabbix, ELK आणि इतर गोष्टींना स्टँडर्ड ॲडमिन सेटवरून जोडण्यासाठी समुदायामध्ये अनेक घडामोडी घडत आहेत, परंतु बहुसंख्यांना अनुकूल असा कोणताही उपाय नाही. कार्य त्याच्या नायकाची वाट पाहत आहे. आणि जर तुम्ही असा व्यवसाय असाल जो 1C क्लस्टरवर लॉन्च करण्याची योजना आखत असेल, तर तुम्हाला तज्ञाची गरज आहे. तुमचे स्वतःचे आतून किंवा बाहेरून, परंतु तुम्हाला ते आवश्यक आहे. हे सामान्य आहे की सर्व्हर ऑपरेशनसाठी सक्षमतेसह एक वेगळी भूमिका आहे, प्रत्येक 1C वापरकर्त्याला हे माहित नसावे, तुम्हाला फक्त अशी भूमिका आवश्यक आहे हे समजून घेणे आवश्यक आहे. उदाहरणार्थ SAP घेऊ. तेथे, प्रोग्रामर, बहुधा, जर त्याला ऍप्लिकेशन सर्व्हरवर काहीतरी कॉन्फिगर करण्यास सांगितले तर तो त्याच्या खुर्चीवरून उठणार नाही. तो कदाचित मूर्ख असेल आणि त्याला लाज वाटणार नाही. SAP पद्धतीमध्ये यासाठी स्वतंत्र कर्मचारी भूमिका आहे. काही कारणास्तव, 1C उद्योगात असे मानले जाते की हे एकाच पगारासाठी एका कर्मचार्यामध्ये एकत्र केले जावे. तो एक भ्रम आहे.

1C सर्व्हरचे तोटे

नक्की एक वजा आहे - विश्वसनीयता. किंवा, आपण प्राधान्य दिल्यास, अप्रत्याशितता. सर्व्हरचे अचानक विचित्र वर्तन यापूर्वीच चर्चेत आले आहे. एक सार्वत्रिक उपाय - सर्व्हर थांबवणे आणि सर्व कॅशे साफ करणे - अगदी तज्ञांच्या हँडबुकमध्ये वर्णन केले आहे, आणि अगदी बॅच बुकची शिफारस केली जाते जी हे करते. जर तुमची 1C सिस्टीमने असे काही करायला सुरुवात केली की ती सैद्धांतिकदृष्ट्या देखील करू नये, तर सत्र डेटा कॅशे साफ करण्याची वेळ आली आहे. माझ्या अंदाजानुसार, संपूर्ण देशात असे फक्त तीन लोक आहेत ज्यांना या प्रक्रियेशिवाय 1C सर्व्हर कसा ऑपरेट करायचा हे माहित आहे आणि ते रहस्य सामायिक करत नाहीत, कारण... ते यातून जगतात. कदाचित त्यांचे रहस्य हे आहे की ते सत्राचा डेटा साफ करतात, परंतु ते त्याबद्दल कोणालाही सांगत नाहीत मित्रा.

अन्यथा, 1C सर्व्हर इतर कोणत्याही सारखाच अनुप्रयोग आहे आणि दस्तऐवज वाचून आणि तंबोरीवर ठोठावून, त्याच प्रकारे प्रशासित केले जाते.

गोदी कामगार

उत्पादनात कंटेनरीकृत 1C सर्व्हर वापरण्याची उपयुक्तता अद्याप सिद्ध झालेली नाही. बॅलन्सरच्या मागे फक्त नोड्स जोडून सर्व्हर क्लस्टर केलेला नाही, ज्यामुळे उत्पादन कंटेनरीकरणाचे फायदे कमीतकमी कमी होतात आणि हायलोड मोडमध्ये कंटेनरमध्ये यशस्वी ऑपरेशनची प्रथा स्थापित केलेली नाही. परिणामी, चाचणी वातावरण सेट करण्यासाठी फक्त विकसक डॉकर+1सी वापरतात. तेथे ते खूप उपयुक्त आहे, लागू केले आहे, आपल्याला आधुनिक तंत्रज्ञानासह खेळण्याची आणि कॉन्फिगरेटरच्या निराशेपासून विश्रांती घेण्यास अनुमती देते.

व्यावसायिक घटक

गुंतवणुकीच्या दृष्टिकोनातून, 1C तुम्हाला ॲप्लिकेशन क्लासच्या विस्तृत क्षमतेमुळे व्यवसाय कल्पना त्वरीत लॉन्च करण्याच्या समस्येचे निराकरण करण्यास अनुमती देते. 1C आउट ऑफ द बॉक्स अतिशय सभ्य रिपोर्टिंग, कोणत्याही गोष्टीसह एकत्रीकरण, वेब क्लायंट, मोबाइल क्लायंट, मोबाइल ऍप्लिकेशन, विविध DBMS साठी समर्थन, यासह देते. विनामूल्य, क्रॉस-प्लॅटफॉर्म दोन्ही सर्व्हर आणि स्थापित क्लायंट भाग. होय, अनुप्रयोगांचा UI पिवळा असेल, कधीकधी हे उणे असते, परंतु नेहमीच नाही.
1C निवडून, व्यवसायाला सॉफ्टवेअर सोल्यूशन्सचा एक संच मिळतो ज्यामुळे त्यांना अनुप्रयोगांची विस्तृत श्रेणी तयार करता येते, तसेच बाजारात बरेच विकासक असतात ज्यांना Javaists पेक्षा कमी पैसे हवे असतात आणि त्याच वेळी परिणाम जलद निर्माण करतात.

उदाहरणार्थ, क्लायंटला पीडीएफ इनव्हॉइस पाठवण्याचे काम विद्यार्थ्यांच्या कामाच्या तासाभरात सोडवले जाऊ शकते. .NET मधील समान समस्या मालकीचे लायब्ररी खरेदी करून किंवा कठोर, दाढी असलेल्या विकसकाने काही दिवस किंवा आठवडे कोडिंग करून सोडवता येते. कधीकधी, दोन्ही एकाच वेळी. आणि हो, मी फक्त पीडीएफ जनरेशनबद्दल बोलत होतो. हे विधेयक कुठून येईल हे आम्ही सांगितलेले नाही. वेब फ्रंटेंडरने एक फॉर्म तयार करणे आवश्यक आहे जेथे ऑपरेटर डेटा प्रविष्ट करेल, बॅकेंडरला JSON हस्तांतरित करण्यासाठी dto मॉडेल्स, डेटाबेसमध्ये संग्रहित करण्यासाठी मॉडेल्स, डेटाबेसची स्वतःची रचना, त्यात स्थलांतरण, ग्राफिकल तयार करणे आवश्यक आहे. या खात्याचे प्रदर्शन, आणि त्यानंतरच - PDF. 1C वर, संपूर्ण कार्य, सुरवातीपासून, अगदी एका तासात पूर्ण केले जाते.

एका छोट्या स्टॉलसाठी खरेदी/विक्रीच्या प्रक्रियेसह संपूर्ण लेखा प्रणाली 3 तासांत विक्री अहवाल, खरेदी आणि विक्रीच्या किंमतींवर मालाचे लेखांकन, वेअरहाऊस, ऍक्सेस राइट्स कंट्रोल, वेब क्लायंट आणि मोबाइल ऍप्लिकेशनसह पूर्ण केले जाते. . ठीक आहे, मी अर्जाबद्दल विसरलो, अर्जासह 3 तासांत नाही, सहा मध्ये.

हे काम .NET विकसकाला स्वच्छ संगणकावर व्हिज्युअल स्टुडिओ स्थापित करण्यापासून ते ग्राहकांना दाखविण्यासाठी किती वेळ लागेल? विकास खर्चाचे काय? समान गोष्ट.

प्लॅटफॉर्म म्हणून 1C ची ताकद

1C मजबूत नाही कारण त्याबद्दल काहीतरी विशिष्ट आहे जे जगातील सर्वोत्तम आहे. त्याउलट, प्रत्येक वैयक्तिक उपप्रणालीमध्ये आपण जगातील सॉफ्टवेअरमध्ये अधिक मनोरंजक ॲनालॉग शोधू शकता. तथापि, घटकांच्या संयोजनावर आधारित, मला 1C सारखा प्लॅटफॉर्म दिसत नाही. येथेच व्यावसायिक यश दडलेले आहे. प्लॅटफॉर्मचे फायदे सर्वत्र विखुरलेले आहेत आणि जेव्हा तुम्ही हे इतर प्लॅटफॉर्मवर कसे केले जाते ते पाहता तेव्हा स्पष्टपणे दृश्यमान होतात. मूलभूतपणे, ही वैशिष्ट्ये देखील नाहीत, परंतु त्याउलट - एका विशिष्ट प्रतिमानाच्या बाजूने वैशिष्ट्यांचा नकार. काही उदाहरणे:

1. युनिकोड. यापेक्षा सोपे काय असू शकते? 2019 मध्ये सिंगल-बाइट ASCII एन्कोडिंग्स वापरण्याची गरज नाही (प्राचीन वारसा असलेल्या एकत्रीकरणाशिवाय). कधीच नाही. पण नाही. असं असलं तरी, काही टेबलमधील कोणीतरी सिंगल-बाइट वर्चर वापरतो आणि ऍप्लिकेशनला एन्कोडिंगमध्ये समस्या असतील. 2015 मध्ये, एन्कोडिंगसह चुकीच्या कामामुळे gitlab चे LDAP अधिकृतता अयशस्वी झाली; 1C डेटाबेस स्तरावरील अनुप्रयोग कोडचे उच्च-गुणवत्तेचे अलगाव प्रदान करते. तेथे कमी स्तरावर टेबल टाइप करणे अशक्य आहे आणि डेटाबेस स्तरावर अक्षम कनिष्ठांचे जॅम्ब्स तेथे अशक्य आहेत. होय, अक्षम कनिष्ठांसह इतर समस्या असू शकतात, परंतु समस्यांची विविधता खूपच लहान आहे. आता तुम्ही मला सांगाल की तुमचा ऍप्लिकेशन योग्यरित्या तयार केला आहे आणि डेटाबेस ऍक्सेस लेयर जसा असावा तसा वेगळा केला आहे. तुमच्या कॉर्पोरेट कस्टम Java ऍप्लिकेशनवर आणखी एक नजर टाका. जवळून आणि प्रामाणिकपणे. तुमचा विवेक तुम्हाला त्रास देतो का? मग मी तुझ्यासाठी आनंदी आहे.
2. दस्तऐवज/संदर्भ पुस्तकांची संख्या. 1C मध्ये ते निश्चितपणे सर्वात लवचिक नाही आणि सर्वोत्तम नाही. परंतु ते बँकिंग सॉफ्टवेअर आणि स्वयं-लिखित अकाउंटिंग सिस्टममध्ये काय करतात - ठीक आहे, तो फक्त अंधार आहे. एकतर ओळख अडकली जाईल (आणि नंतर “अरे, आमच्याकडे छिद्र का आहेत”), किंवा त्याउलट, ते एक जनरेटर बनवतील जे डीबीएमएस स्तरावर लॉकिंगसह कार्य करेल (आणि अडचण होईल). खरेतर, हे वरवर सोपे वाटणारे कार्य करणे खूप कठीण आहे - घटकांचा एक एंड-टू-एंड गणक, विशिष्ट कीच्या सेटवर आधारित विशिष्टता विभाग, उपसर्ग, जेणेकरून समांतर डेटा एंट्री दरम्यान डेटाबेस ब्लॉक होणार नाही. .
3. डेटाबेसमधील रेकॉर्डचे अभिज्ञापक. 1C ने दृढ-इच्छेने निर्णय घेतला - सर्व लिंक आयडेंटिफायर पूर्णपणे सिंथेटिक आहेत आणि तेच. आणि वितरित डेटाबेस आणि एक्सचेंजेसमध्ये कोणतीही समस्या नाही. इतर सिस्टीमचे विकसक जिद्दीने ओळख सारखे काहीतरी तयार करतात (ते लहान आहे!), अनेक संबंधित उदाहरणे तयार करण्याची वेळ येईपर्यंत त्यांना GUI मध्ये ड्रॅग करा (आणि नंतर ते शोधले जातील). तुमच्याकडे हे नाही का? प्रामाणिकपणे?
4. याद्या. 1C मध्ये (मोठ्या) याद्यांमधून पेजिंग करण्यासाठी आणि त्याद्वारे नेव्हिगेट करण्यासाठी बरीच यशस्वी यंत्रणा आहे. मला ताबडतोब आरक्षण करू द्या - यंत्रणेचा योग्य वापर करून! सर्वसाधारणपणे, हा विषय खूपच अप्रिय आहे, तो आदर्शपणे सोडवला जाऊ शकत नाही: तो एकतर अंतर्ज्ञानी आणि सोपा आहे (परंतु क्लायंटवर प्रचंड रेकॉर्डसेटचा धोका आहे), किंवा पेजिंग एक किंवा दुसर्या कुटिलपणाचे आहे. पेजिंग करणारे बरेचदा ते वाकड्या पद्धतीने करतात. जे प्रामाणिक स्क्रोलबार बनवतात ते डेटाबेस, एक चॅनेल आणि क्लायंट जोडतात.
5. व्यवस्थापित फॉर्म. यात शंका नाही, वेब क्लायंटमध्ये इंटरफेस उत्तम प्रकारे कार्य करत नाही. पण ते चालते. परंतु इतर अनेक लेखा आणि बँकिंग प्रणालींसाठी, दूरस्थ कार्यस्थळ तयार करणे हा एक एंटरप्राइझ-स्तरीय प्रकल्प आहे. अस्वीकरण: सुदैवाने ज्यांनी मूळतः वेबवर बनवले त्यांच्यासाठी, याचा परिणाम होणार नाही.
6. मोबाइल ॲप. अलीकडे, त्याच इकोसिस्टममध्ये असताना तुम्ही मोबाईल ॲप्लिकेशन्स देखील लिहू शकता. हे वेब क्लायंटपेक्षा थोडे अधिक क्लिष्ट आहे; तुम्हाला एखाद्या कंपनीच्या अंतर्गत गरजांसाठी (जेव्हा कॉर्पोरेट समस्येचे मोबाइल सोल्यूशन पिवळ्या UI डिझाइनपेक्षा अधिक महत्त्वाचे असते) अनुप्रयोगाची आवश्यकता असल्यास, तुम्ही बॉक्सच्या बाहेर समान प्लॅटफॉर्म वापरता.
7. अहवाल देत आहे. या शब्दाचा अर्थ मोठा डेटा असलेली BI प्रणाली आणि ETL प्रक्रियेतील अंतर असा माझा अर्थ नाही. हे ऑपरेशनल स्टाफच्या अहवालांचा संदर्भ देते जे तुम्हाला येथे आणि आताच्या लेखा स्थितीचे मूल्यांकन करण्याची परवानगी देतात. शिल्लक, परस्पर समझोता, पुनर्प्रतवारी इ. वापरकर्त्याच्या बाजूने गट, फिल्टर आणि व्हिज्युअलायझेशनसाठी लवचिक सेटिंग्जसह रिपोर्टिंग सिस्टमसह 1C बॉक्समधून बाहेर येतो. होय, बाजारात कूलर ॲनालॉग्स आहेत. परंतु ऑल-इन-वन सोल्यूशनच्या चौकटीत नाही आणि कधीकधी ऑल-इन-वन सोल्यूशनपेक्षा जास्त किंमतीत. आणि बऱ्याचदा ते अगदी उलट असते: फक्त अहवाल देणे, परंतु संपूर्ण प्लॅटफॉर्मपेक्षा अधिक महाग आणि गुणवत्तेत वाईट.
8. छापण्यायोग्य फॉर्म. बरं, कर्मचाऱ्यांना ईमेलद्वारे पीडीएफमध्ये सॅलरी स्लिप पाठवण्याची समस्या सोडवण्यासाठी .NET चा वापर करा. आणि आता पावत्या छापण्याचे काम. त्याच पीडीएफमध्ये त्यांच्या प्रती जतन करण्याबद्दल काय? 1C टोपणनावासाठी, कोणत्याही लेआउटला PDF मध्ये आउटपुट करणे ही कोडची +1 ओळ आहे. याचा अर्थ दुसऱ्या भाषेत दिवस किंवा आठवड्यांऐवजी + 40 सेकंद कामाचा वेळ. 1C मधील मुद्रित फॉर्म लेआउट विकसित करणे आश्चर्यकारकपणे सोपे आहे आणि सशुल्क समकक्षांशी स्पर्धा करण्यासाठी पुरेसे शक्तिशाली आहे. होय, कदाचित, 1C स्प्रेडशीट दस्तऐवजांमध्ये फारशी परस्परसंवादी संधी नाहीत; तुम्ही ओपनजीएल वापरून स्केलिंगसह 3D आकृती पटकन मिळवू शकत नाही. पण ते खरोखर आवश्यक आहे का?

ही काही मूठभर उदाहरणे आहेत जिथे कार्यक्षमता मर्यादित करणे किंवा तडजोड करणे हे भविष्यात एक महत्त्वपूर्ण वास्तुशिल्प लाभ ठरेल. अगदी तडजोड किंवा सर्वात प्रभावी पर्याय नाही - तो आधीपासूनच बॉक्समध्ये आहे आणि तो गृहीत धरला जातो. त्याची स्वतंत्र अंमलबजावणी एकतर अशक्य होईल (कारण प्रकल्पाच्या सुरुवातीला असे निर्णय घेतले जाणे आवश्यक आहे, आणि त्यासाठी वेळ नाही आणि तेथे कोणीही आर्किटेक्ट नाही), किंवा अनेक महाग पुनरावृत्ती. सूचीबद्ध केलेल्या प्रत्येक बिंदूमध्ये (आणि ही आर्किटेक्चरल सोल्यूशन्सची संपूर्ण यादी नाही), आपण स्क्रू करू शकता आणि स्केलिंग अवरोधित करणारे प्रतिबंध लागू करू शकता. कोणत्याही परिस्थितीत, तुम्हाला, एक व्यापारी म्हणून, "सुरुवातीपासून सिस्टम" बनवताना, तुमच्या प्रोग्रामरचे हात सरळ आहेत आणि ते लगेचच सूक्ष्म प्रणाली समस्या चांगल्या प्रकारे पार पाडतील याची खात्री करणे आवश्यक आहे.

होय, इतर कोणत्याही जटिल प्रणालीप्रमाणे, 1C मध्ये देखील उपाय आहेत जे विशिष्ट पैलूंमध्ये स्केलिंग अवरोधित करतात. तथापि, मी पुनरावृत्ती करतो, घटकांच्या संयोजनावर आधारित, मालकीची किंमत आणि आधीच सोडवलेल्या समस्यांची संख्या, मला बाजारात योग्य प्रतिस्पर्धी दिसत नाही. त्याच किमतीत, तुम्हाला एक आर्थिक अनुप्रयोग फ्रेमवर्क, क्लस्टर केलेला संतुलित सर्व्हर, UI आणि वेब इंटरफेस, मोबाइल अनुप्रयोगासह, रिपोर्टिंग, एकत्रीकरण आणि इतर गोष्टींचा समूह मिळेल. जावाच्या जगात, तुम्ही फ्रंट-एंड आणि बॅक-एंड टीम भाड्याने देता, होम-लिखीत सर्व्हर कोडचे निम्न-स्तरीय शॉल डीबग करा आणि 2 मोबाइल OS साठी 2 मोबाइल अनुप्रयोगांसाठी स्वतंत्रपणे पैसे द्या.

मी असे म्हणत नाही की 1C सर्व प्रकरणे सोडवेल, परंतु अंतर्गत कॉर्पोरेट अनुप्रयोगासाठी, जेव्हा UI ब्रँड करण्याची आवश्यकता नसते, तेव्हा आणखी काय आवश्यक आहे?

मलम मध्ये उडणे

तुम्हाला कदाचित असे समजले असेल की 1C जगाला वाचवेल आणि कॉर्पोरेट प्रणाली लिहिण्याचे इतर सर्व मार्ग चुकीचे आहेत. असं अजिबात नाही. व्यावसायिकाच्या दृष्टीकोनातून, जर तुम्ही 1C निवडले तर, टाइम-टू-मार्केट जलद व्यतिरिक्त, तुम्ही खालील तोटे विचारात घेणे आवश्यक आहे:

• सर्व्हर विश्वसनीयता. खरोखर उच्च-गुणवत्तेचे विशेषज्ञ आवश्यक आहेत जे त्याचे अखंड ऑपरेशन सुनिश्चित करू शकतात. मला विक्रेत्याकडून अशा तज्ञांसाठी तयार प्रशिक्षण कार्यक्रमाची माहिती नाही. तज्ञांच्या परीक्षेची तयारी करण्यासाठी अभ्यासक्रम आहेत, परंतु माझ्या मते हे पुरेसे नाही.
• सपोर्ट. मागील मुद्दा पहा. विक्रेत्याकडून समर्थन मिळविण्यासाठी, तुम्हाला ते खरेदी करणे आवश्यक आहे. काही कारणास्तव हे 1C उद्योगात स्वीकारले जात नाही. आणि SAP सह, हे जवळजवळ खरेदी करणे आवश्यक आहे आणि ते कोणालाही त्रास देत नाही. कॉर्पोरेट समर्थनाशिवाय आणि कर्मचाऱ्यांच्या तज्ञाशिवाय, तुम्हाला 1C समस्यांसह एकटे सोडले जाऊ शकते.
• तरीही, तुम्ही 1C सह पूर्णपणे सर्वकाही करू शकत नाही. हे एक साधन आहे आणि प्रत्येक साधनाप्रमाणे याला लागू होण्याच्या मर्यादा आहेत. 1C लँडस्केपमध्ये, "नॉन-1C" सिस्टम आर्किटेक्ट असणे अत्यंत इष्ट आहे.
• चांगली 1C टोपणनावे इतर भाषांमधील चांगल्या प्रोग्रामरपेक्षा स्वस्त नाहीत. जरी, वाईट प्रोग्रामरना भाड्याने घेणे महाग असते, ते कोणत्याही भाषेत लिहितात.

चला ठिपके करू

• 1C हे व्यवसायासाठी रॅपिड ॲप्लिकेशन डेव्हलपमेंट (RAD) फ्रेमवर्क आहे आणि यासाठी तयार केले आहे.
• प्रमुख डीबीएमएस, क्लायंट UI, खूप चांगला ORM आणि रिपोर्टिंगसाठी समर्थनासह तीन-स्तरीय लिंक
• 1C जे करू शकत नाही ते करू शकणाऱ्या प्रणालींसह एकत्रीकरणासाठी विस्तृत शक्यता. तुम्हाला मशीन लर्निंग हवे असल्यास, पायथन घ्या आणि निकाल http किंवा RabbitMQ द्वारे 1C वर पाठवा
• 1C वापरून सर्व काही करण्याचा प्रयत्न करण्याची गरज नाही, आपल्याला त्याची ताकद समजून घेणे आणि ते आपल्या स्वतःच्या हेतूंसाठी वापरणे आवश्यक आहे.
• तांत्रिक फ्रेमवर्क गॅझेटमध्ये खोदण्याकडे आणि प्रत्येक N वर्षांनी नवीन इंजिनमध्ये पुन्हा डिझाइन करण्यासाठी गुरुत्वाकर्षण करणारे विकसक 1C सह कंटाळले आहेत. तिथे सर्व काही खूप पुराणमतवादी आहे.
• निर्मात्याकडून त्यांच्याबद्दल फारच कमी काळजी असल्याने विकासक देखील कंटाळले आहेत. कंटाळवाणा भाषा, कमकुवत IDE. त्यांना आधुनिकीकरणाची गरज आहे.
• दुसरीकडे, जे विकसक त्यांना आनंद देणारे दुसरे तंत्रज्ञान वापरून आणि शिकून मजा मिळवू शकत नाहीत ते वाईट विकासक आहेत. ते ओरडतील आणि दुसऱ्या परिसंस्थेत जातील.
• जे नियोक्ते त्यांच्या 1C टोपणनावांना Python मध्ये काहीतरी लिहू देत नाहीत ते वाईट नियोक्ते आहेत. ते जिज्ञासू मन असलेले कर्मचारी गमावतील आणि त्यांच्या जागी मंकी कोडर येतील जे प्रत्येक गोष्टीशी सहमत असताना, कॉर्पोरेट सॉफ्टवेअरला दलदलीत ओढतील. हे अद्याप पुन्हा लिहावे लागेल, म्हणून कदाचित पायथनमध्ये थोडेसे आधी गुंतवणूक करणे चांगले होईल?
• 1C ही एक व्यावसायिक कंपनी आहे आणि ती केवळ स्वतःच्या आवडी आणि सोयीनुसार वैशिष्ट्ये लागू करते. यासाठी तुम्ही तिला दोष देऊ शकत नाही, व्यवसायाने नफ्याचा विचार केला पाहिजे, हेच जीवन आहे
• 1C वास्याच्या विकसकांच्या समस्यांवर नव्हे तर व्यावसायिक समस्यांवर उपाय विकून पैसे कमवते. या दोन संकल्पना परस्परसंबंधित आहेत, परंतु प्राधान्य मी जे सांगितले तेच आहे. जेव्हा विकसक Vasya 1C: Resharper साठी वैयक्तिक परवान्यासाठी पैसे देण्यास तयार असेल, तेव्हा ते खूप लवकर दिसेल, A. Orefkova द्वारे "Resharper" याचा पुरावा आहे. जर विक्रेत्याने त्याचे समर्थन केले आणि त्याविरूद्ध लढा दिला नाही तर, विकसकांसाठी सॉफ्टवेअरची बाजारपेठ दिसून येईल. आता या मार्केटमध्ये संशयास्पद परिणामांसह दीड खेळाडू आहेत आणि सर्व कारण IDE सह एकत्रीकरण नकारात्मक आहे आणि सर्वकाही क्रॅचवर केले जाते.
• मल्टी-मशीन ऑपरेटरची प्रथा विस्मृतीत नाहीशी होईल. आधुनिक ऍप्लिकेशन कोडच्या बाजूने आणि व्यवसायाच्या वापराच्या बाजूने लक्षात ठेवण्यासाठी खूप मोठे आहेत. 1C सर्व्हर देखील अधिक जटिल होत आहे; एका कर्मचाऱ्यामध्ये सर्व प्रकारचे कौशल्य ठेवणे अशक्य होईल यासाठी तज्ञांची मागणी असणे आवश्यक आहे, याचा अर्थ 1C व्यवसायाचे आकर्षण आणि पगारात वाढ. जर पूर्वी वास्याने एका पगारासाठी तीन-एक काम केले असेल, तर आता तुम्हाला दोन वस्यांना नियुक्त करण्याची आवश्यकता आहे आणि वास्यांमधील स्पर्धा त्यांच्या पातळीच्या एकूण वाढीला चालना देऊ शकते.

निष्कर्ष

1C एक अतिशय योग्य उत्पादन आहे. माझ्या किंमतीच्या श्रेणीमध्ये, मला कोणतेही analogues माहित नाहीत, काही असल्यास टिप्पण्यांमध्ये लिहा. तथापि, इकोसिस्टममधून विकसकांचा बहिर्वाह अधिकाधिक लक्षात येण्याजोगा होत आहे आणि हे "ब्रेन ड्रेन" आहे, तुम्ही याकडे कसे पहात आहात हे महत्त्वाचे नाही. उद्योग आधुनिकीकरणासाठी भुकेले आहेत.
तुम्ही डेव्हलपर असल्यास, 1C वर थांबू नका आणि इतर भाषांमध्ये सर्वकाही जादुई आहे असे समजू नका. तुम्ही कनिष्ठ असताना, कदाचित. काहीतरी मोठे निराकरण करणे आवश्यक आहे म्हणून, तयार-तयार उपाय अधिक काळ पहावे लागतील आणि अधिक तीव्रतेने पूर्ण करावे लागतील. "ब्लॉक्स" च्या गुणवत्तेच्या बाबतीत, ज्यामधून सोल्यूशन तयार केले जाऊ शकते, 1C खूप, खूप चांगले आहे.

आणि आणखी एक गोष्ट - जर तुमच्याकडे 1C टोपणनाव भाड्याने घेण्यासाठी आले, तर 1C टोपणनाव सुरक्षितपणे आघाडीच्या विश्लेषकांच्या पदावर नियुक्त केले जाऊ शकते. कार्य, विषय क्षेत्र आणि विघटन कौशल्य यांची त्यांची समज उत्कृष्ट आहे. मला खात्री आहे की हे 1C विकासामध्ये DDD च्या सक्तीच्या वापरामुळे आहे. एखाद्या व्यक्तीस सर्व प्रथम एखाद्या कार्याच्या अर्थाबद्दल, विषय क्षेत्राच्या वस्तूंमधील कनेक्शनबद्दल विचार करण्यास प्रशिक्षित केले जाते आणि त्याच वेळी एकीकरण तंत्रज्ञान आणि डेटा एक्सचेंज फॉरमॅटमध्ये तांत्रिक पार्श्वभूमी असते.

आदर्श चौकट अस्तित्वात नाही याची जाणीव ठेवा आणि स्वतःची काळजी घ्या.
सर्वांना चांगले!

PS: खूप खूप धन्यवाद speshuric लेख तयार करण्यात मदतीसाठी.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

तुमच्या एंटरप्राइझमध्ये 1C आहे का?

• 13,3%अजिबात नाही.71

• 30,3%आहे, पण फक्त लेखा विभागात कुठेतरी. इतर प्लॅटफॉर्मवरील कोर सिस्टम 162

• 41,4%होय, मुख्य व्यवसाय प्रक्रिया त्यावर कार्य करतात221

• 15,0%1C मरणे आवश्यक आहे, भविष्य %technology_name%80 चे आहे

534 वापरकर्त्यांनी मतदान केले. 99 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com