חברים ועמיתים, לאחרונה היו מאמרים תכופים יותר על Habré עם שנאה כלפי 1C כפלטפורמת פיתוח, ונאומים של מגיניה. מאמרים אלו זיהו בעיה רצינית אחת: לרוב, מבקרי 1C מבקרים אותה מעמדה של "לא שולט בזה", נוזפים בבעיות שנפתרות דה פקטו בקלות, ולהפך, לא נוגעים בבעיות שבאמת חשובות, שוות דנים ואינם נפתרים על ידי הספק. אני מאמין שזה הגיוני לערוך סקירה מפוכחת ומאוזנת של פלטפורמת 1C. מה זה יכול לעשות, מה זה לא יכול לעשות, מה זה צריך לעשות אבל לא עושה, ולקינוח, מה זה עושה בקול גדול, והמפתחים שלך ב-%technology_name% יעשו מאה שנים, ויזרקו אותו יותר מתקציב שנתי אחד.
כתוצאה מכך, אתה, כמנהל או אדריכל, תוכל לקבל הבנה ברורה באיזו משימה יועיל לך להשתמש ב-1C, והיכן צריך לשרוף אותה עם מגהץ חם. כמפתחים בעולם ה"לא-1C", תוכל לראות מה יש ב-1C שגורם לרעש. וכמפתח 1C, תוכל להשוות את המערכת שלך עם מערכות אקולוגיות של שפות אחרות ולהבין את מיקומך במערכת הקואורדינטות של פיתוח תוכנה.
מתחת לגזירה יש הרבה התקפות עבות על 1C, על מבקרי 1C, על Java, .NET ובכלל... המאוורר מלא, ברוכים הבאים!
על עצמי
אני מכיר את נושא השיחה בערך משנת 2004. אני מתכנת כנראה מגיל 6, מהרגע שקיבלתי ספר על פרופסור פורטרן עם קומיקס על חתול, דרור וזחל. ניתחתי את התוכניות שהחתול כתב מהתמונות בספר וגיליתי מה הן עשו. וכן, לא היה לי מחשב אמיתי באותה תקופה, אבל היה ציור על התפשטות הספר ולחצתי בכנות על כפתורי הנייר, והכנסתי את הפקודות שרגלתי אחרי החתול X.
אחר כך היו BK0011 ו-BASIC בבית הספר, C++ והרכבים באוניברסיטה, ואז 1C, ואז כל כך הרבה דברים אחרים שאני עצלן מכדי לזכור. ב-15 השנים האחרונות התעסקתי בעיקר ב-1C, לא רק מבחינת קידוד, אלא בכלל ב-1C. הגדרת משימות, ניהול ו-devops כאן. ב-5 השנים האחרונות עסקתי בפעילויות מועילות חברתית מבחינת פיתוח כלי פיתוח ואוטומציה עבור משתמשי 1C אחרים, כתיבת מאמרים וספרים.
בואו נחליט על נושא הדיון
ראשית, בואו נגדיר על מה אנחנו הולכים לדבר, מכיוון שהאותיות "1C" יכולות להביע הרבה דברים. במקרה זה, באותיות "1C" נתכוון אך ורק למסגרת הפיתוח "1C: Enterprise" של הגרסה המודרנית, השמינית. לא נדבר הרבה על היצרן ועל המדיניות שלו (אבל נצטרך לעשות מעט לא נדון ביישומים ספציפיים שנכתבו באמצעות המסגרת הזו). הטכנולוגיה היא נפרדת, יישומים או תצורות נפרדות.
ארכיטקטורה ברמה גבוהה 1C: Enterprise
לא בכדי אני מזכיר את המילה "מסגרת". מנקודת מבט של מפתח, פלטפורמת 1C היא בדיוק מסגרת. ואתה צריך להתייחס לזה בדיוק כמו מסגרת. תחשוב על זה כמו Spring או ASP.NET, המבוצע על ידי זמן ריצה כלשהו (JVM או CLR בהתאמה). כך קורה שבעולם התכנות הקונבנציונלי ("לא 1C") החלוקה למסגרת, למכונות וירטואליות ולאפליקציות ספציפיות היא טבעית, בשל העובדה שרכיבים אלו מפותחים בדרך כלל על ידי יצרנים שונים. בעולם 1C, לא נהוג להבחין במפורש בין מסגרת הפיתוח לבין זמן הריצה עצמו בנוסף, גם אפליקציות ספציפיות שנכתבות באמצעות ה-framework מפותחות בעיקר על ידי 1C עצמה. כתוצאה מכך נוצר בלבול מסוים. לכן, במסגרת המאמר, נצטרך לשקול את 1C מכמה צדדים בבת אחת ולסווג אותו לאורך מספר צירי קואורדינטות. ובכל ציר קואורדינטות נשים את חפירה של חומר חום ונבחן את התכונות, היתרונות והחסרונות של הפתרון הקיים.
נקודות מבט על 1C
1C עבור הקונה
הקונה רוכש מערכת אוטומציה שבאמצעותה הוא יכול לפתור במהירות את הבעיות של אוטומציה של העסק שלו. עסק יכול להיות דוכן קטן, או שהוא יכול להיות חברת אחזקות גדולה. ברור שהצרכים של עסקים אלו שונים, אך שניהם נתמכים על ידי בסיס קוד פלטפורמה אחד.
עבור הקונה 1C זהו זמן הגעה מהיר לשוק. מָהִיר. מהיר יותר מ-Java, C# או JS. מְמוּצָע. מסביב לבית החולים. ברור שאתר כרטיסי ביקור באמצעות React ייצא טוב יותר, אבל הקצה האחורי של מערכת WMS יושק מהר יותר ב-1C.
1C ככלי
לכל פתרון טכנולוגי יש מגבלות של יישום. 1C אינה שפה למטרות כלליות היא אינה חיה בנפרד מהמסגרת שלה. רצוי להשתמש ב-1C כאשר אתה צריך:
- יישום שרת
- יישום שבו מופיעים כספים
- עם ממשק משתמש מוכן, ORM, דיווח, XML/JSON/COM/PDF/YourDataTransferingFormat
- עם תמיכה בתהליכי רקע ועבודות
- עם אבטחה מבוססת תפקידים
- עם היגיון עסקי שניתן לתסריט
- עם היכולת ליצור במהירות אב טיפוס וזמן יציאה נמוך לשוק
אתה לא צריך 1C אם אתה רוצה:
- למידת מכונה
- חישובי GPU
- גרפיקה ממוחשבת
- חישובים מתמטיים
- מערכת CAD
- עיבוד אותות (סאונד, וידאו)
- טען שיחות http עם מאות אלפי סל"ד
1C כחברת ייצור
כדאי להבין מה העסק של 1C כיצרנית תוכנה. חברת 1C מוכרת פתרונות לבעיות עסקיות באמצעות אוטומציה. עסקים שונים, גדולים או קטנים, אבל זה מה שהיא מוכרת. האמצעים להשגת מטרה זו הם יישומים עסקיים. להנהלת חשבונות, חשבות שכר ועוד. לכתיבת יישומים אלו, החברה משתמשת בפלטפורמת פיתוח אפליקציות עסקיות משלה. מותאם במיוחד למשימות נפוצות של אותם יישומים עסקיים:
- חשבונאות פיננסית
- התאמה אישית קלה של ההיגיון העסקי
- אפשרויות אינטגרציה רחבות בנופי IT הטרוגניים
כיצרנית, 1C מאמינה שזו האסטרטגיה שמאפשרת לך לעבוד עם שותפים ולקוחות במצב של win-win. אפשר להתווכח עם זה, אבל זה בערך האופן שבו החברה מקדמת את עצמה: פתרונות מוכנים לבעיות עסקיות שניתן להתאים במהירות על ידי שותפים ולשלב אותם בכל נוף IT.
יש לראות את כל הטענות או הרצונות עבור 1C כמסגרת באופן בלעדי דרך פריזמה זו. "אנחנו רוצים OOP ב-1C", אומרים המפתחים. "כמה יעלה לנו לתמוך ב-OOP בפלטפורמה, האם זה יעזור לנו להגדיל את המכירות של קופסאות?", אומר 1C. פותח את ה"פריזמה" שלו של מכירת פתרונות לבעיות עסקיות:
היי, עסקים, אתה רוצה OOP ב-1C שלך?
- האם זה יעזור לי לפתור את הבעיות שלי?
- מי יודע...
- אז אין צורך
גישה זו יכולה להיות טובה או רעה תלוי מי מסתכל עליה, אבל זה פשוט ככה. אם כבר מדברים על העובדה שאין תכונה X ב-1C, אתה צריך להבין שהיא לא שם מסיבה כלשהי, אלא בהקשר של הבחירה "עלות יישום מול סכום רווח".
סיווג טכנולוגי
"למעשה, אודינסניקים עושים כמיטב יכולתם להשתמש בדפוסים הטובים ביותר, שנבחרו בקפידה על ידי מתודולוגים אכפתיים ומפתחי פלטפורמת 1C.
כשאתה כותב את הקוד המטופש שלך עבור טופס מנוהל פשוט, במציאות אתה משתמש מודל-מבט-בקר с קשירת נתונים דו כיוונית в תלת-שכבתי-נתונים-אפליקציה-מנוע, בטעם מיפוי-יחסי אובייקט ברמה גבוהה על הבסיס תיאור מטא נתונים הצהרתיבעל משלו שפת שאילתה בלתי תלויה בפלטפורמה, ג ממשק משתמש מונחה נתונים הצהרתי, סדרה שקופה מלאה ושפת תוכנה מוכוונת תחום.המקום שבו מפתחי 1C שונים מעמיתיהם המערביים הוא ב-PR. הם אוהבים לתת לכל שטות שם גדול ולהתרוצץ עם זה כמו שקית מלוכלכת".
א.אורפקוב
לפלטפורמת 1C ארכיטקטורת 3 שכבות קלאסית, שבמרכזה נמצא שרת היישומים (או הדמייה שלו תמורת כסף קטן עבור בעלי חנויות קטנים). MS SQL או Postgres משמשים כ-DBMS. יש גם תמיכה ב-Oracle וב-IBM DB2, אבל זה די אזוטרי, אף אחד לא יודע מה יקרה אם תטמיע 1C על מסדי נתונים אלה בעומס בינוני וגבוה. אני מאמין ש-1C עצמה לא יודעת את זה.
חלק הלקוח הוא לקוח דק המותקן במחשב של המשתמש או לקוח אינטרנט. המאפיין המרכזי הוא שמתכנתים לא כותבים 2 קודים שונים, הם כותבים אפליקציה אחת, בשפה אחת, וניתן להציג אותה בדפדפן אם יש רצון או צורך. מי שם רצה ערימה מלאה אמיתית ושפה אחת עבור החזית והחלק האחורי, node.js? הם אף פעם לא הצליחו לעשות בדיוק את אותו הדבר עד הסוף. קיימת ערימה מלאה אמיתית, אבל תצטרך לכתוב אותה ב-1C. האירוניה של הגורל, דברים כאלה :)
פתרון הענן SaaS 1C:Fresh עובד גם במצב דפדפן, בו לא ניתן לקנות 1C, אלא לשכור מסד נתונים קטן ולעקוב אחר מכירות השווארמה שם. רק בדפדפן, בלי להתקין או להגדיר שום דבר.
בנוסף, יש לקוח מדור קודם, אשר ב-1C נקרא "אפליקציה רגילה". מורשת היא מורשת, ברוכים הבאים לעולם היישומים בשנת 2002, אבל אנחנו עדיין מדברים על המצב הנוכחי של המערכת האקולוגית.
חלק שרת 1C תומך באשכולות וסולם על ידי הוספת מכונות חדשות לאשכול. לא מעט עותקים נשברו כאן ויהיה סעיף נפרד במאמר בנושא זה. בקיצור, זה לא ממש זהה להוספת כמה מקרים בדיוק מאחורי HAProxy.
מסגרת פיתוח האפליקציות משתמשת בשפת תכנות משלה, הדומה בערך ל-VB6 משופר מעט שתורגם לרוסית. לאנשים ששונאים כל דבר רוסי, שאינם מאמינים ש"אם" מתורגם כ"אם", מוצעת אפשרות התחביר השנייה. הָהֵן. אם תרצה, תוכל לכתוב את זה ב-1C בצורה כזו שלא ניתן להבחין בה מ-VB.
שפת התכנות הזו היא הסיבה העיקרית לשנאת הכינויים של 1C כלפי הפלטפורמה שלהם. בואו נודה בזה, לא בלי סיבה. השפה נוצרה כמה שיותר פשוטה, שנועדה להגשים את המנטרה "מפתחים, מפתחים" בקנה מידה לפחות ב-CIS. המהות המסחרית של פתרון כזה, לדעתי, נראית בבירור: יותר מפתחים, כיסוי שוק גדול יותר. זה התגשם, לפי הערכות שונות מ-45% עד 95%. אני אגיד מיד שלכתוב בשפה שאתה חושב זה באמת קל יותר. ואני יודע די הרבה שפות תכנות.
נתחיל בשפה.
שפת תכנות 1C
יחד עם זאת הנקודה החזקה והחלשה של המערכת. מספק כניסה קלה וקריאות. מצד שני, הוא לא עודכן מאז יציאת גרסה 8 ב-2002 והוא מיושן מבחינה מוסרית. מישהו יגיד "החיסרון העיקרי הוא שאין OOP" והם יטעו. ראשית, אש"ף לא אוהב לא רק את נוראלייב, אלא גם את טורוואלדס. ושנית, OOP עדיין קיים.
מנקודת מבטו של המפתח, לרשותו מסגרת עם מחלקות בסיס המוצגות ב-DBMS. המפתח יכול לקחת את מחלקת הבסיס "Directory" ולרשת ממנה את ספריית "Clients". הוא יכול להוסיף לו שדות מחלקה חדשים, למשל, INN ו-Address, וגם, במידת הצורך, הוא יכול לעקוף (לעקוף) שיטות של מחלקת הבסיס, למשל שיטת OnWrite/AtRecord.
המסגרת מעוצבת בצורה כזו שלעתים רחוקות יש צורך בירושה עמוקה יותר, וההגבלה ב-OOP, לדעתי, הגיונית. 1C מתמקדת ב-Domain Driven Development וגורמת לך לחשוב, קודם כל, על תחום הנושא של הפתרון המפותח, וזה טוב. לא רק שאין פיתוי, אלא גם אין צורך לכתוב 10 DTOs ו-ViewModels שונים רק כדי להציג כמה נתונים מהתחום איפשהו. מפתח 1C פועל תמיד עם ישות אחת, מבלי לעמוס את ההקשר של התפיסה עם תריסר מחלקות בעלות שמות דומים, המייצגות את אותה ישות, אך מצד אחר. כל יישום NET, למשל, יכיל בהכרח חמישה או שניים ViewModels ו-DTOs להסדרה ל-JSON ולהעברת נתונים מלקוח לשרת. ובערך 10-15% מקוד היישום שלך יושקעו בהעברת נתונים ממחלקה אחת לאחרת באמצעות עטים או קביים כמו AutoMapper. יש לכתוב קוד זה ויש לשלם למתכנתים כדי ליצור ולתחזק אותו.
מסתבר שאת שפת 1C קשה לפתח מבלי לסבך אותה לרמת השפות המיינסטרים ובכך מאבדת את יתרון הפשטות. מה בעצם משימתו של הספק נפתרת: להנפיק פתרון סטנדרטי שכל תלמיד שנתפס ברחוב יכול להתאים אישית ברמת האיכות הנדרשת (כלומר, הושלם תיק המכסה מדוכן למפעל גדול). אם אתה דוכן, קח סטודנט אם אתה מפעל, קח גורו מהשותף שלך ליישום. העובדה ששותפים להטמעה מוכרים תלמידים במחיר של גורו אינה בעיה עם המסגרת. מבחינה אדריכלית, המסגרת חייבת לפתור את הבעיות של שניהם, הקוד של תצורות סטנדרטיות (שמכרנו לעסקים עם הבטחה להתאמה אישית) צריך להיות מסוגל להיות מובן על ידי סטודנט, וגורו צריך להיות מסוגל להבין מה שאתה רוצה.
מה שלדעתי באמת חסר בשפה, מה שמאלץ אותך לכתוב יותר ממה שאתה יכול, זה מבזבז זמן שמשלם הלקוח.
- אפשרות הקלדה ברמה, למשל, TypeScript (כתוצאה מכך, כלי ניתוח קוד מפותחים יותר ב-IDE, Refactoring, פחות ג'מבים פוגעניים)
זמינות פונקציות כאובייקטים מחלקה ראשונה. קונספט קצת יותר מורכב, אבל ניתן להפחית במידה ניכרת את כמות קוד ה-boilerplate הטיפוסי. ההבנה של התלמיד בקוד, IMHO, אפילו תגדל עקב הפחתת הנפח - מילולי אוסף אוניברסלי, אתחולים. אותו דבר – הפחתת כמות הקוד שצריך לכתוב ו/או להסתכל בעיניים. מילוי אוספים תופס למעלה מ-9000% מזמן התכנות של 1C. כתיבה זו ללא סוכר תחבירי היא ארוכה, יקרה ונוטה לשגיאות. באופן כללי, כמות ה-LOC בפתרונות 1C חורגת מכל המגבלות שניתן להעלות על הדעת בהשוואה למסגרות פתוחות זמינות ובאופן כללי, כל הג'אווה הארגוניים שלך ביחד. השפה היא מילולית, וזה מתדרדר לכמות נתונים, זיכרון, בלמים IDE, זמן, כסף...
- סוף סוף קונסטרוקציות יש לי השערה שהקונסטרוקציה הזו חסרה בגלל העובדה שלא מצאו לה תרגום מוצלח לרוסית :)
- סוגי נתונים משלו (ללא OOP), אנלוגים מסוג מ-VB6. זה יאפשר לך לא להקליד מבנים באמצעות הערות ב-BSP ושיטות קסם הבונות את המבנים הללו. אנו מקבלים: פחות קוד, רמז דרך נקודה, פתרון מהיר יותר לבעיה, פחות שגיאות עקב שגיאות הקלדה ומאפיינים חסרים של מבנים. כעת ההקלדה של מבני המשתמש מונחת כולה על צוות הפיתוח של ספריית המשנה הסטנדרטית, אשר יאמר לזכותו, כותב בקפידה הערות על המאפיינים הצפויים של מבני הפרמטרים שעברו.
- אין סוכר בעבודה עם שיחות אסינכרוניות בלקוח האינטרנט. callback-hell בצורת ProcessingNotifications הוא קב זמני שנגרם משינוי פתאומי ב-API של הדפדפנים הראשיים, אבל אתה לא יכול לחיות ככה כל הזמן היתרון של "הבנת התלמידים" של קוד אסינכרוני עוד ועוד. אין להוסיף תמיכה לפרדיגמה הזו ב-IDE הראשי והדברים יחמירו עוד יותר.
זו אחת הבעיות הדוחקות, ברור שהרשימה יכולה להיות הרבה יותר גדולה, אבל אסור לשכוח שזו עדיין לא שפה למטרות כלליות, היא לא דורשת ריבוי הליכי שרשור, פונקציות למבדה, גישה ל-GPU ומהירה חישובי נקודה צפה. זוהי שפת סקריפטים של לוגיקה עסקית.
מתכנת שכבר עבד הרבה עם השפה הזו, בודק לתוך js או c#, משתעמם במסגרת השפה הזו. זאת עובדה. הוא זקוק להתפתחות. בצד השני של הסקאלה עבור הספק נמצאת עלות הטמעת התכונות שצוינו לעומת הגידול בהכנסות לאחר הטמעתם. כאן אין לי מידע על מה שגובר כרגע בעיני החברה.
סביבת פיתוח
גם כאן הדברים לא מתנהלים חלק. ישנן שתי סביבות פיתוח. הראשון הוא Configurator הכלול במשלוח. השנייה היא סביבת Enterprise Development Tools, או בקיצור EDT, שפותחה על בסיס Eclipse.
הקופיגורטור מספק מגוון שלם של משימות פיתוח, תומך בכל התכונות ומהווה את הסביבה העיקרית בשוק. הוא גם מיושן מוסרית, לא מתפתח, לפי השמועות - בגלל כמות החוב הטכני בתוכו. ניתן לשפר את המצב על ידי פתיחת API פנימי (בצורה של ידידות עם A. Orefkova או על בסיס עצמאי), אבל זה לא המקרה. התרגול הראה שהקהילה תכתוב את התכונות שלה ב-IDE, כל עוד הספק לא יתערב. אבל יש לנו מה שיש לנו. הקופיגורטור היה נהדר בשנים 2004-2005, הזכיר מאוד את Visual Studio של אותם זמנים, במקומות מסוימים הוא היה אפילו יותר מגניב, אבל הוא היה תקוע בזמנים ההם.
בנוסף, נפח הפתרון הסטנדרטי הממוצע גדל מאז פי כמה, וכיום ה-IDE פשוט לא יכול להתמודד עם כמות הקוד איתו הוא ניזון. שימושיות ויכולות refactoring אפילו לא אפס, הן במינוס. כל זה לא מוסיף התלהבות למפתחים והם חולמים לעבור למערכות אקולוגיות אחרות ולהמשיך לקוד שם חרא, אבל בסביבה נעימה שלא יורקת לך בפרצוף עם ההתנהגות שלה.
כחלופה, מוצע IDE שנכתב מאפס, בנוי על Eclipse. שם, המקורות, כמו בכל תוכנה אחרת, חיים בצורה של קבצי טקסט, מאוחסנים ב-GIT, סניפים של pull request, כל זה. החיסרון, הוא לא עזב את סטטוס הבטא כבר שנים רבות, למרות שהוא משתפר עם כל מהדורה. אני לא אכתוב על החסרונות של EDT, היום זה מינוס, מחר זה תכונה קבועה. הרלוונטיות של תיאור כזה תיעלם במהירות. היום אפשר לפתח ב-EDT, אבל זה יוצא דופן צריך להיות מוכן למספר מסוים של באגים ב-IDE.
אם אתה מסתכל על המצב דרך הפריזמה "1C" הנזכרת לעיל, אתה מקבל משהו כזה: שחרור ה-IDE החדש לא מגדיל את מכירות הקופסאות, אך ייתכן שהזרימה של DEVELOPERS תקטן. קשה לומר מה מצפה לאקוסיסטם במונחים של נוחות מפתחים, אבל מיקרוסופט כבר פישלה את מפתחי המובייל בכך שהציעה להם את שירותיה מאוחר מדי.
ניהול פיתוח
הכל כאן יותר טוב משמעותית מאשר בכתיבת קוד, במיוחד לאחרונה, כאשר מאמצי הקהילה העלו לאור את הבעיות של אוטומציה של ניהול, השיקו אבות טיפוס הקוראים לזרוק את מאגר 1C לערימת האשפה ושימוש ב-git, האשמה מהירה, סקירת קוד. , ניתוח סטטי, פריסה אוטומטית וכו'. לפלטפורמה נוספו פיצ'רים רבים שמגבירים את רמת האוטומציה של משימות הפיתוח. עם זאת, כל התכונות הללו נוספו רק ובלעדי לפיתוח המוצרים הגדולים שלנו, כאשר התברר שאיננו יכולים בלי אוטומציה. היו מיזוגים אוטומטיים, השוואה משולשת עם KDiff וכל זה. הושק ב- Github , שלמען האמת, נגרר אידיאולוגית מהפרויקט , אך שונה כדי להתאים לתהליכים של החברה הספקית. בזכות החבר'ה העקשנים מהקוד הפתוח, אוטומציית הפיתוח ב-1C יצאה לדרך. API פתוח עבור הקופיגורטור, IMHO, יעביר גם את הפיגור המוסרי של ה-IDE הראשי.
כיום, אחסון מקורות 1C ב-git עם התחייבויות המקושרות לבעיות ב-Jira, ביקורות ב-Crucible, כפתור לחיצה מג'נקינס ודוחות Allure על בדיקות קוד ב-1C ואפילו - זה רחוק מלהיות חדשות, אלא המיינסטרים בחברות שבהן יש הרבה פיתוח 1C.
מינהל
יש הרבה מה לומר כאן. ראשית, זהו, כמובן, שרת (אשכול שרתים 1C). דבר נפלא, אבל בשל העובדה שמדובר בקופסה שחורה לחלוטין, מתועדת בפירוט מספיק, אבל בצורה ספציפית - שליטה בהשקה של פעולה בלתי פוסקת במצב עומס גבוה בכמה שרתים היא מנת חלקם של מעטים נבחרים שלובשים מדליה עם הכיתוב "מומחה בנושאים טכנולוגיים". ראוי לציין כי באופן עקרוני, ניהול שרת 1C אינו שונה מניהול כל שרת אחר. זוהי אפליקציה מבוססת רשת, מרובת הליכי הליכי שצורכת משאבי זיכרון, מעבד ודיסקים. מספק הזדמנויות רבות לאיסוף טלמטריה ואבחון.
הבעיה כאן היא שהספק לא מציע שום דבר מיוחד מבחינת פתרונות מוכנים לאבחון הזה בדיוק. כן, יש 1C: Instrumentation and Control Center, הם אפילו די טובים, אבל הם מאוד יקרים ולא לכולם יש אותם. ישנם מספר פיתוחים בקהילה לחיבור Grafana, Zabbix, ELK ועוד דברים ממערכת הניהול הסטנדרטית, אך אין פתרון אחד שיתאים לרוב. המשימה מחכה לגיבורה. ואם אתה עסק שמתכנן להשיק באשכול 1C, אתה צריך מומחה. שלך בפנים או מבחוץ, אבל אתה צריך את זה. זה נורמלי שיש תפקיד נפרד עם מיומנויות לתפעול שרת, לא כל משתמש 1C צריך לדעת את זה, אתה רק צריך להבין שיש צורך בתפקיד כזה. ניקח לדוגמה את SAP. שם, סביר להניח שמתכנת אפילו לא יקום מהכיסא שלו אם יתבקש להגדיר משהו בשרת האפליקציות. יכול להיות שהוא פשוט טיפש והוא לא יתבייש. במתודולוגיית SAP קיים תפקיד עובד נפרד לכך. משום מה, בענף 1C מאמינים שיש לשלב זאת בעובד אחד תמורת אותה משכורת. זו אשליה.
חסרונות של שרת 1C
יש בדיוק מינוס אחד - אמינות. או, אם אתה מעדיף, חוסר חיזוי. התנהגות מוזרה פתאומית של השרת כבר הפכה לשיחת העיר. תרופה אוניברסלית - עצירת השרת וניקוי כל המטמונים - אפילו מתוארת במדריך של המומחה, ואפילו ספר אצווה מומלץ שעושה זאת. אם מערכת 1C שלך מתחילה לעשות משהו שהיא אפילו לא אמורה לעשות תיאורטית, הגיע הזמן לנקות את מטמון נתוני הפגישה. לפי הערכתי, יש רק שלושה אנשים בכל הארץ שיודעים להפעיל שרת 1C ללא ההליך הזה והם לא חולקים סודות, כי... הם חיים מזה. אולי הסוד שלהם הוא שהם מנקים את נתוני הפגישה, אבל הם לא מספרים על זה לאף אחד, אחי.
אחרת, שרת 1C הוא אותו יישום כמו כל יישום אחר והוא מנוהל באופן כמעט זהה, על ידי קריאת התיעוד ודפיקה על הטמבורין.
סַוָר
התועלת של שימוש בשרת 1C במכולות בייצור טרם הוכחה. השרת אינו מקובץ רק על ידי הוספת צמתים מאחורי האיזון, מה שמפחית את היתרונות של מיכלי הייצור למינימום, והפרקטיקה של פעולה מוצלחת בקונטיינרים במצב עומס גבוה לא הוקמה. כתוצאה מכך, רק מפתחים משתמשים ב-Docker+1C כדי להגדיר סביבות בדיקה. שם זה מאוד שימושי, יישומי, מאפשר לך לשחק עם טכנולוגיות מודרניות ולקחת הפסקה מהדכדוך של הקופיגורטור.
מרכיב מסחרי
מנקודת מבט של השקעה, 1C מאפשר לך לפתור את הבעיה של השקה מהירה של רעיונות עסקיים בשל היכולות הרחבות של מחלקות יישומים. 1C מחוץ לקופסה נותן דיווח הגון מאוד, אינטגרציה עם כל דבר, לקוח אינטרנט, לקוח נייד, אפליקציה לנייד, תמיכה במערכות DBMS שונות, כולל. חינם, חוצה פלטפורמות הן חלקי שרת והן חלקי לקוח מותקנים. כן, ממשק המשתמש של האפליקציות יהיה צהוב, לפעמים זה מינוס, אבל לא תמיד.
בבחירה ב-1C, עסק מקבל סט פתרונות תוכנה המאפשרים להם לבנות מגוון רחב מאוד של אפליקציות, כמו גם הרבה מפתחים בשוק שרוצים פחות כסף מג'אוויסטים ובמקביל לייצר תוצאות מהר יותר.
לדוגמא, משימת שליחת חשבונית PDF ללקוח יכולה להיפתר בשעה של עבודה של תלמידים. ניתן לפתור את אותה בעיה ב-.NET על ידי רכישת ספרייה קניינית, או כמה ימים או שבועות של קידוד על ידי מפתח קשוח ומזוקן. לפעמים, שניהם בבת אחת. וכן, דיברתי רק על יצירת PDF. לא אמרנו מאיפה הצעת החוק הזו אפילו תגיע. על ה-web frontender ליצור טופס שבו המפעיל יזין את הנתונים, ה-backender יצטרך ליצור מודלים של dto להעברת JSON, מודלים לאחסון במסד הנתונים, מבנה בסיס הנתונים עצמו, הגירה אליו, יצירת גרפי. הצגת החשבון הזה בדיוק, ורק אז - PDF. ב-1C, כל המשימה, מאפס, מסתיימת תוך שעה בדיוק.
מערכת הנהלת חשבונות מלאה לדוכן קטן עם תהליך עסקי אחד שנקנה/נמכר מתבצעת תוך 3 שעות עם דיווח מכירות, חשבונאות של סחורה במחירי קנייה ומכירה, בחלוקה לפי מחסנים, בקרת זכויות גישה, לקוח אינטרנט ואפליקציה סלולרית. . אוקיי, שכחתי מהאפליקציה, כשהאפליקציה לא בעוד 3 שעות, בעוד שש.
כמה זמן ייקח משימה זו למפתח NET מהתקנת Visual Studio במחשב נקי ועד להדגמה ללקוח? מה לגבי עלות הפיתוח? אותו דבר.
עוצמות של 1C כפלטפורמה
1C חזק לא בגלל שיש בו משהו ספציפי שהוא הכי טוב בעולם. להיפך, בכל תת-מערכת בנפרד ניתן למצוא אנלוגי מעניין יותר בתוכנה העולמית. עם זאת, בהתבסס על שילוב של גורמים, אני לא רואה פלטפורמה דומה ל-1C. כאן טמונה ההצלחה המסחרית. יתרונות הפלטפורמה מפוזרים בה ונראים בצורה הכי ברורה כאשר רואים איך זה נעשה בפלטפורמות אחרות. בעצם, אלו אפילו לא תכונות, אלא להיפך - דחייה של תכונות לטובת פרדיגמה ספציפית אחת. כמה דוגמאות:
- Unicode. מה לעזאזל יכול להיות יותר פשוט? אין צורך להשתמש בקידוד ASCII של בייט בודד בשנת 2019 (למעט אינטגרציה עם קידודים עתיקים). לעולם לא. אבל לא. בכל מקרה, מישהו בטבלה כלשהי משתמש ב-varchar של בייט בודד ולאפליקציה יהיו בעיות עם קידודים. בשנת 2015, הרשאת LDAP של gitlab נכשלה עקב עבודה לא נכונה עם קידודים JetBrains IDE עדיין לא עובדת עם קירילי בשמות קבצים בכל מקום. 1C מספק בידוד באיכות גבוהה של קוד יישום משכבת מסד הנתונים. שם אי אפשר להקליד טבלאות ברמה נמוכה וג'מבים של זוטרים לא מוכשרים ברמת מסד הנתונים בלתי אפשריים שם. כן, אולי יש שם בעיות אחרות של זוטרים לא מוכשרים, אבל מגוון הבעיות קטן בהרבה. כעת תגיד לי שהאפליקציה שלך מעוצבת בצורה נכונה ושכבת הגישה למסד הנתונים מבודדת כפי שהיא צריכה להיות. תסתכל שוב על אפליקציית Java המותאמת אישית של החברה שלך. מקרוב ובכנות. המצפון שלך מטריד אותך? אז אני שמח בשבילך.
- מספור מסמכים/ספרי עיון. ב-1C זה בהחלט לא הכי גמיש ולא הכי טוב. אבל מה שהם עושים בתוכנות בנקאות ובמערכות חשבונאיות שנכתבו בעצמם - ובכן, זה פשוט חושך. או שזהות תהיה תקועה (ואז "אוי, למה יש לנו חורים"), או להיפך, הם ייצרו גנרטור שעובד עם נעילה ברמת DBMS (ויהפוך לצוואר בקבוק). למעשה, די קשה לבצע את המשימה הפשוטה לכאורה הזו - מונה ישויות מקצה לקצה, עם סעיף ייחודיות המבוסס על קבוצה מסוימת של מפתחות, קידומת, כך שלא יחסום את מסד הנתונים במהלך הזנת נתונים מקבילים .
- מזהים של רשומות במסד הנתונים. 1C קיבלה החלטה חזקה - כל מזהי הקישורים הם סינתטיים לחלוטין וזהו. ואין בעיות עם מסדי נתונים ומרכזיות מבוזרות. מפתחים של מערכות אחרות יוצרים בעקשנות משהו כמו זהות (זה קצר יותר!), גוררים אותם ל-GUI עד שהגיע הזמן ליצור כמה מופעים קשורים (ואז הם יתגלו). אין לך את זה? בִּיוֹשֶׁר?
- רשימות. ל-1C יש מנגנונים מוצלחים למדי לדפדוף ברשימות (גדולות) ולנווט בהן. הרשו לי לבצע הזמנה מיד - בשימוש נכון במנגנון! באופן כללי, הנושא די לא נעים, לא ניתן לפתור אותו באופן אידיאלי: הוא אינטואיטיבי ופשוט (אבל הסיכון של ערכות רשומות ענקיות על הלקוח), או שההחלפה היא עקומה כזו או אחרת. מי שעושה איתור לעתים קרובות עושה זאת בצורה עקומה. מי שעושה סרגל גלילה כנה מוסיף מסד נתונים, ערוץ ולקוח.
- טפסים מנוהלים. אין ספק, בלקוח האינטרנט הממשק לא עובד בצורה מושלמת. אבל זה עובד. אבל עבור מערכות חשבונאיות ובנקיות רבות אחרות, יצירת מקום עבודה מרוחק היא פרויקט ברמת הארגון. כתב ויתור: למרבה המזל עבור אלה שעשו את זה במקור באינטרנט, זה לא ישפיע.
- אפליקציה לנייד. לאחרונה, אתה יכול גם לכתוב יישומים ניידים באותה מערכת אקולוגית. זה קצת יותר מסובך כאן מאשר עם לקוח אינטרנט, הפרטים של המכשירים מאלצים אותך לכתוב במיוחד עבורם, אבל, בכל זאת, אתה לא שוכר צוות נפרד של מפתחים ניידים. אם אתה צריך אפליקציה לצרכים הפנימיים של חברה (כאשר פתרון נייד לבעיה ארגונית חשוב יותר מעיצוב ממשק משתמש צהוב), אתה פשוט משתמש באותה פלטפורמה מחוץ לקופסה.
- דיווח. במילה הזו אני לא מתכוון למערכת BI עם ביג דאטה ופיגור בתהליך ה-ETL. הכוונה היא לדוחות סגל תפעולי המאפשרים להעריך את מצב החשבונאות כאן ועכשיו. יתרות, הסדרים הדדיים, דירוג מחדש וכו'. 1C יוצא מהקופסה עם מערכת דיווח עם הגדרות גמישות לקבוצות, מסננים והדמיה בצד המשתמש. כן, יש אנלוגים מגניבים יותר בשוק. אבל לא במסגרת של פתרון הכל-ב-אחד ובמחיר גבוה לפעמים מפתרון הכל-ב-אחד. ולעתים קרובות יותר זה אפילו הפוך: רק דיווח, אבל יקר יותר מכל הפלטפורמה, ואיכות גרועה יותר.
- טפסים להדפסה. ובכן, השתמשו ב-.NET כדי לפתור את בעיית שליחת תלושי השכר ב-PDF לעובדים במייל. ועכשיו המשימה של הדפסת חשבוניות. מה לגבי שמירת העותקים שלהם באותו PDF? עבור כינוי 1C, הפלט של כל פריסה ל-PDF הוא שורת קוד +1. זה אומר + 40 שניות של זמן עבודה, במקום ימים או שבועות בשפה אחרת. פריסות טפסים מודפסים ב-1C קלות להפליא לפיתוח וחזקות מספיק כדי להתחרות עם עמיתים בתשלום. כן, כנראה, אין הרבה הזדמנויות אינטראקטיביות במסמכי גיליון אלקטרוני של 1C. אתה לא יכול לקבל במהירות דיאגרמת תלת-ממד עם קנה מידה באמצעות OpenGL. אבל האם זה באמת נחוץ?
אלו הן רק קומץ דוגמאות שבהן הגבלת הפונקציונליות או הטמעת פשרות מתבררות כיתרון אדריכלי חשוב בעתיד. אפילו פשרה או לא האופציה היעילה ביותר - היא כבר בקופסה ומובן מאליו. היישום העצמאי שלו יהיה בלתי אפשרי (כי החלטות כאלה חייבות להתקבל בתחילת הפרויקט, ואין לזה זמן ואין אדריכל בכלל), או כמה איטרציות יקרות. בכל אחת מהנקודות המפורטות (וזו אינה רשימה מלאה של פתרונות אדריכליים), ניתן לפשל ולהכניס מגבלות שחוסמות קנה מידה. בכל מקרה, אתה, כאיש עסקים, צריך לוודא שלמתכנתים שלך, בעת יצירת "מערכת מאפס", יהיו ידיים ישרות ויעשו בעיות מערכת עדינות מיד היטב.
כן, כמו בכל מערכת מורכבת אחרת, גם ל-1C עצמה יש פתרונות שחוסמים קנה מידה בהיבטים מסוימים. עם זאת, אני חוזר ואומר, על סמך שילוב של גורמים, עלות הבעלות ומספר הבעיות שכבר נפתרו מראש, אני לא רואה מתחרה ראוי בשוק. באותו מחיר אתה מקבל מסגרת אפליקציה פיננסית, שרת מאוזן מקובצים, עם ממשק משתמש וממשק אינטרנט, עם אפליקציה למובייל, עם דיווח, אינטגרציה ועוד המון דברים. בעולם הג'אווה, אתה שוכר צוות חזיתי ואחורי, מנפה באגים ברמה נמוכה של קוד שרת כתוב ביתי ומשלמת בנפרד עבור 2 יישומים ניידים עבור 2 מערכות הפעלה ניידות.
אני לא אומר ש-1C יפתור את כל המקרים, אבל לאפליקציה פנימית ארגונית, כשאין צורך למתג את ה-UI – מה עוד צריך?
כף זפת
בטח קיבלת את הרושם ש-1C תציל את העולם ושכל שאר הדרכים לכתיבת מערכות ארגוניות שגויות. זה בכלל לא ככה. מנקודת מבטו של איש עסקים, אם אתה בוחר ב-1C, אז בנוסף לזמן מהיר לשוק, עליך לקחת בחשבון את החסרונות הבאים:
- אמינות שרת. נדרשים מומחים איכותיים באמת שיכולים להבטיח את פעולתו ללא הפרעה. לא ידוע לי על תוכנית הכשרה מוכנה עבור מומחים כאלה מהספק. יש קורסים להכנה למבחן המומחה, אבל זה לדעתי לא מספיק.
- תמיכה. ראה פסקה קודמת. כדי לקבל תמיכה מהספק, אתה צריך לקנות אותו. משום מה זה לא מקובל בתעשיית 1C. ועם SAP, זה כמעט רכישת חובה וזה לא מפריע לאף אחד. ללא תמיכה ארגונית וללא מומחה בצוות, אתה יכול להישאר לבד עם תקלות 1C.
- ובכל זאת, אתה לא יכול לעשות הכל עם 1C. זהו כלי וכמו לכל כלי יש לו מגבלות תחולה. בנוף 1C, רצוי מאוד שיהיה ארכיטקט מערכת "לא 1C".
- כינויים טובים של 1C אינם זולים יותר ממתכנתים טובים בשפות אחרות. אמנם, מתכנתים גרועים יקרים להעסקה, ללא קשר לשפה בה הם כותבים.
בואו ננקד את הנקודות
- 1C היא מסגרת לפיתוח יישומים מהיר (RAD) לעסקים ומותאמת לכך.
- קישור תלת-שכבתי עם תמיכה ב-DBMS עיקריים, ממשק משתמש לקוח, ORM טוב מאוד ודיווח
- אפשרויות רחבות לאינטגרציה עם מערכות שיכולות לעשות מה ש-1C לא. אם אתה רוצה למידת מכונה, קח את Python ושלח את התוצאה ל-1C דרך http או RabbitMQ
- אין צורך להתאמץ לעשות הכל באמצעות 1C, אתה צריך להבין את החוזקות שלה ולהשתמש בהן למטרות שלך
- מפתחים שנמשכים לחפור בגאדג'טים של מסגרת טכנולוגית ועיצוב מחדש כל N שנים למנוע חדש משועממים עם 1C. הכל שם מאוד שמרני.
- מפתחים גם משועממים כי יש מעט מאוד דאגה אליהם מהיצרן. שפה משעממת, IDE חלש. הם דורשים מודרניזציה.
- מצד שני, מפתחים שלא יכולים למצוא כיף באמצעות ולמידה של טכנולוגיה אחרת שהם נהנים מהם הם מפתחים גרועים. הם ייללו ויעברו למערכת אקולוגית אחרת.
- מעסיקים שלא מאפשרים לכינויים 1C שלהם לכתוב משהו ב-Python הם מעסיקים גרועים. הם יאבדו עובדים עם מוחות סקרנים, ובמקומם יבואו קודני קופים שאמנם מסכימים עם הכל, אבל יגררו תוכנות ארגוניות לביצה. עדיין יהיה צורך לשכתב אותו, אז אולי עדיף להשקיע קצת ב-Python קצת קודם?
- 1C היא חברה מסחרית ומיישמת תכונות המבוססות אך ורק על האינטרסים והיעילות שלה. אתה לא יכול להאשים אותה בזה, העסק חייב לחשוב על רווח, אלה החיים
- 1C מרוויחה כסף על ידי מכירת פתרונות לבעיות עסקיות, לא לבעיות המפתחים של Vasya. שני המושגים האלה מתואמים, אבל העדיפות היא בדיוק מה שאמרתי. כאשר המפתח Vasya מוכן לשלם עבור רישיון אישי עבור 1C: Resharper, הוא יופיע די מהר, "Resharper" מאת A. Orefkova היא ההוכחה לכך. אם הספק היה תומך בו, ולא נלחם נגדו, יופיע שוק לתוכנות למפתחים. כעת יש בשוק הזה שחקנית וחצי עם תוצאות מפוקפקות, והכל בגלל שהאינטגרציה עם ה-IDE שלילית והכל נעשה על קביים.
- התרגול של מפעיל מרובה מכונות ייעלם אל תוך השכחה. אפליקציות מודרניות גדולות מכדי לזכור הן מהצד של הקוד והן מהצד של השימוש העסקי. גם שרת 1C הופך מורכב יותר, אי אפשר יהיה להחזיק את כל סוגי המומחיות בעובד אחד. זה אמור לגרור ביקוש למומחים, כלומר האטרקטיביות של מקצוע 1C ועלייה בשכר. אם בעבר Vasya עבד שלושה באחד עבור משכורת אחת, עכשיו אתה צריך לשכור שני Vasyas ותחרות בין Vasyas יכולה לעודד את הצמיחה הכוללת של הרמה שלהם.
מסקנה
1C הוא מוצר ראוי מאוד. בטווח המחירים שלי, אני לא מכיר אנלוגים בכלל, כתוב בתגובות אם יש כאלה. עם זאת, יציאת המפתחים מהמערכת האקולוגית הופכת יותר ויותר בולטת, וזהו "בריחת מוחות", איך שלא מסתכלים על זה. התעשייה רעבה למודרניזציה.
אם אתה מפתח, אל תתקע על 1C ואל תחשוב שהכל קסום בשפות אחרות. בזמן שאתה זוטר, אולי. ברגע שצריך לפתור משהו גדול יותר, יהיה צורך לחפש פתרונות מוכנים זמן רב יותר ולהשלים בצורה אינטנסיבית יותר. מבחינת איכות ה"בלוקים" מהם ניתן לבנות פתרון, 1C הוא מאוד מאוד טוב.
ועוד דבר - אם כינוי 1C מגיע אליכם להעסיק, אז את הכינוי 1C ניתן למנות בבטחה לתפקיד של אנליסטים מובילים. ההבנה שלהם במשימה, תחום הנושא וכישורי הפירוק מצוינת. אני בטוח שזה נובע בדיוק מהשימוש הכפוי ב-DDD בפיתוח 1C. אדם מאומן לחשוב על המשמעות של משימה קודם כל, על הקשרים בין אובייקטים של תחום הנושא, ובמקביל יש לו רקע טכני בטכנולוגיות אינטגרציה ופורמטים של חילופי נתונים.
היו מודעים לכך שהמסגרת האידיאלית לא קיימת ודאגו לעצמכם.
טוב לכולם!
נ.ב: תודה רבה לסיוע בהכנת המאמר.
רק משתמשים רשומים יכולים להשתתף בסקר. בבקשה.
האם יש לך 1C בארגון שלך?
13,3%בכלל לא.71
30,3%יש, אבל רק במחלקת הנהלת חשבונות איפשהו. מערכות ליבה בפלטפורמות אחרות162
41,4%כן, התהליכים העסקיים העיקריים עובדים על it221
15,0%1C חייב למות, העתיד שייך ל-%technology_name%80
534 משתמשים הצביעו. 99 משתמשים נמנעו.
מקור: www.habr.com
