שיפוץ 1C-Bitrix: סילוק חוב טכני ללא השבתה

קוד נקי עבור 1C-Bitrix: רפקטורינג ללא סיכון

תרחיש טיפוסי: require_once גדל ל-3000 שורות, שאילתות SQL ישירות ב-/local/php_interface/classes/ מאטות את הדפים, קוד זהה מועתק ל-12 קומפוננטות. הוספת שדה חדש בקטלוג דורשת עריכות ב-8 מקומות. זהו חוב טכני, שמפחית את מהירות הפיתוח ומגדיל את עלויות התחזוקה. אנו מבצעים רפקטורינג מבלי לשנות את ההתנהגות החיצונית, כך שהאתר ממשיך לעבוד באותו אופן, אך הקוד הופך לנקי וניתן לתחזוקה. לצוות שלנו ניסיון של למעלה מ-10 שנים בפיתוח 1C-Bitrix ויותר מ-50 פרויקטי רפקטורינג מוצלחים.

חוב טכני הוא מטאפורה המתארת את העלויות הנוספות של תחזוקת קוד הנגרמות מפתרונות מהירים אך לא אופטימליים. בפרויקטי Bitrix, הוא מצטבר במהירות רבה במיוחד בשל אינטגרציות מרובות ולוגיקה מותאמת אישית. החיסכון בתקציב על תחזוקה יכול להגיע ל-60%—בממוצע $5,000 עד $15,000 לשנה עבור פרויקט טיפוסי. עבור פרויקטים גדולים יותר, החיסכון יכול לעלות על $20,000 לשנה.

מדוע רפקטורינג עדיף על שכתוב מלא?

שכתוב מלא של פרויקט Bitrix הוא מלכודת. לוגיקה עסקית שהצטברה במשך שנים בתבניות ובמטפלים אינה מתועדת. שכתוב מאפס מבטיח אובדן של מקרי קצה שנתפסו על ידי תיקונים חמים. הגישה הנכונה היא רפקטורינג אינקרמנטלי: לבודד מודול אחד, לשכתב אותו, לוודא התנהגות זהה, ולהמשיך הלאה. כל איטרציה היא אתר עובד. רפקטורינג אינקרמנטלי זול פי 2 ומהיר פי 3 משכתוב מלא. השוו:

אילו אזורי קוד זקוקים לרפקטורינג קודם?

עדיפות 1 — פירוק /local/modules/. /local/ "רע" טיפוסי מכיל מטפלי אירועים, פונקציות מותאמות אישית, מחלקות ואתחול ישיר. המצב הרצוי: /local/ php_interface/ init.php → автолоадер + регистрация classes/ EventHandlers/ → обработчики событий Битрикс Helpers/ → утилиты Services/ → бизнес-логика modules/ project.core/ → кастомный модуль проекта components/ → кастомные компоненты templates/ → шаблоны сайта מכיל רק /local/ עבור הטוען האוטומטי ורישום מטפלים. כל הלוגיקה עוברת למחלקות נפרדות ב-/local/ או /bitrix/.

מבנה של template.php:

/local/
  php_interface/
    init.php → автолоадер + регистрация
    classes/
      EventHandlers/ → обработчики событий Битрикс
      Helpers/ → утилиты
      Services/ → бизнес-логика
    modules/
      project.core/ → кастомный модуль проекта
    components/ → кастомные компоненты
    templates/ → шаблоны сайта

מעבר ל-CIBlockElement::GetList() הוא נוהג סטנדרטי ב-Bitrix. כל מה שנמצא ב-$DB->Query() מקבל עדיפות על פני template.php, מה שמאפשר עדכוני ליבה ללא התנגשויות. ההשקעה בשלב זה בדרך כלל מחזירה את עצמה תוך 2–3 חודשים על ידי הפחתת זמן השינויים.

עדיפות 2 — הוצאת לוגיקה מתבניות קומפוננטות. תבנית קומפוננטה (CBitrixComponent) צריכה להכיל רק פלט HTML. אם היא כוללת /local/components/project/, $DB->Query() או חישובים מורכבים, זו בעיה. שלוש רמות של רפקטורינג:

1. phpcpd — העברת הכנת הנתונים מתוך catalog.section.
2. .gitignore — יצירת מחלקת קומפוננטה המרחיבה את /bitrix/.
3. קומפוננטה מותאמת אישית ב-/upload/ — כאשר הקומפוננטה הסטנדרטית כבר לא מתאימה לדרישות.

עדיפות 3 — החלפת SQL ישיר ב-D7 ORM. שאילתות ישירות דרך /vendor/ משמעותן ללא escape, נעילת ספק מסד נתונים וללא מטמון. עברו ל-D7 ORM או לשאילתות עם פרמטרים. לפי התיעוד הרשמי של 1C-Bitrix, D7 ORM מאפשר שאילתות עם מטמון אוטומטי והגנה מפני הזרקת SQL.

עדיפות 4 — ביטול כפילויות. השתמשו ב-/local/ כדי למצוא בלוקי קוד זהים בתבניות שונות. דפוס טיפוסי: לקומפוננטת CIBlockElement יש 5 תבניות עם 80% קוד זהה, הנבדלות רק במחלקות CSS. פתרון: תבנית אחת עם פרמטרים או קבצי include.

איך לבצע רפקטורינג ללא השבתה?

1. Snapshot — צרו גיבוי והתחייבו למצב הנוכחי ב-git.
2. בדיקות — כתבו בדיקות עשן לדפים קריטיים (סטטוסי HTTP, אלמנטים מרכזיים).
3. החלפה — העבירו בלוק לוגיקה אחד למחלקה, חברו אותו, וודאו שהבדיקות עוברות.
4. הסרה — מחקו קוד ישן לאחר אישור שהבדיקות עוברות.
5. פריסה — דחפו לייצור ועקבו אחר שגיאות במשך 24 שעות.

מלכודות טיפוסיות ברפקטורינג

• רפקטורינג ללא מערכת בקרת גרסאות. באופן מפתיע, פרויקטי Bitrix רבים עדיין לא נמצאים ב-Git. שלב הרפקטורינג הראשון הוא אתחול מאגר עם CSale* נכון (לא לכלול b_event_log, /upload/, /vendor/, לשמור על /local/).
• מעבר ל-D7 "בבת אחת". ממשק ה-API של D7 אינו מכסה הכול. ה-API הישן (CIBlockElement, CSale*) עובד ונתמך. העבירו רק קוד שאתם מרפקטרים—אל תיגעו בקוד ישן שעובד למען "עקביות".
• רפקטורינג ללא ניטור. לאחר פריסת הרפקטורינג, עקבו אחר b_event_log ויומני השרת. שגיאות עשויות להופיע רק בתנאים מסוימים: סוג מוצר ספציפי, קבוצת משתמשים או דפדפן.

הערכות זמנים

רפקטורינג הוא השקעה. ההשפעה שלו נמדדת לא ויזואלית, אלא במהירות הפיתוח הבאה ובמספר הרגרסיות במהלך עדכונים. לקבלת ייעוץ והערכה מדויקת לפרויקט שלכם, צרו קשר. הזמינו ביקורת כבר עכשיו.