פורמט קוד אוטומטי ב-CI/CD: Prettier, Black, gofmt

עיצוב קוד אוטומטי: היכן התהליך נשבר

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

המחיר מתגלה לא בוויכוחים על טעם, אלא בדברים מדידים. תיקונים ידניים ב-review — הסיבה הנפוצה ביותר להערות: מעגל הדיון מתבזבז על רווחים ושבירות שורה במקום על לוגיקת השינוי.

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

קטגוריה נפרדת — כשלי בנייה בגלל סגנון. Prettier, Black ו-gofmt רצים בשלב אחד של המסלול, בדיקת סגנון — בשלב אחר, והכללים במכונת המפתחים שונים מהכללים בשרת הבנייה. התוצאה — בנייה אדומה על שורה שהמחבר לא נגע בה, והרגל להפעיל אותה מחדש במקום לנתח את הסיבה. בהמשך נפרט איך זה נסגר ולמה לפורמטר צריך להישאר מצב הרצה אחד.

מה משתנה בצוות ובמסלול אחרי הטמעת עיצוב אוטומטי

הפורמטר רץ לפני ה-review, לא אחריו: hook על commit משכתב את הקובץ, והבדיקה במסלול נכשלת אם הסגנון סוטה מהקונפיג. המבקר רואה רק שינויים סמנטיים — החלפת רווחים ושבירות שורה כבר בוצעה על ידי הכלי. זה משנה לא את המהירות של אנשים בודדים, אלא את מבנה התהליך עצמו.

האפקט מדיד. לפני ההטמעה תיקוני הזחות ומרכאות לקחו בין רבע לחצי מזמן ה-review, וה-diffs הוסיפו מאות שורות רעש. אחרי — שיעור השורות ששונו מסיבות סגנון יורד כמעט לאפס, ותיקונים שנויים במחלוקת מפסיקים להיות נושא לדיון: מסכימים עליהם פעם אחת בקונפיג.

סגנון אחיד ללא תיקונים ידניים

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

פחות רעש ב-review ופחות תיקונים ב-diffs

פחות רעש ב-diff — בדיקה מתכנסת מהר יותר: ההערות עוברות מעיצוב ללוגיקה ולמקרי קצה. יציבות הבנייה עולה מאותה סיבה — פערים בסגנון יוצאים מרשימת סיבות הכשל. לפני ריצה מסיבית מפרידים את העיצוב ל-commit נפרד, כדי שההיסטוריה לא תערבב שינויים סמנטיים וקוסמטיים.

מצבי בדיקה ותיקון: מ-hook מקומי ועד שלב בנייה

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

תיקון מקומי לפני commit

עיצוב בעת שמירה בעורך שומר על עותק עבודה עקבי: המחבר לא חושב על סגנון, וה-diffs לא מתמלאים בהחלפת רווחים. תיקון לפני commit דרך pre-commit hook מריץ את הפורמטר על הקבצים שהשתנו ועוצר את ה-commit אם משהו נשאר לא מתוקן. הרצה סלקטיבית על קבצים חשובה במאגרים גדולים: מעבר מלא על כל הקוד בכל commit מאט משמעותית את העבודה.

בדיקה כשלב חובה במסלול

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

איך אנחנו משלבים בדיקות סגנון במסלול: שלבי עבודה

עיצוב שמופעל ב-commit אחד בכל המאגרים מאפס את היסטוריית התיקונים: לא ברור מי ולמה שינה שורה, וסקירת השינויים טובעת בהחלפת רווחים. לכן הטמעת העיצוב מתבצעת בפרויקט נפרד עם צעדים הפיכים, שלא חוסמים שחרורים.

מלאי מאגרים וחריגים

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

1. מלאי מאגרים: שפות, פעילות, ספריות מיוצרות וצד שלישי.
2. פרופיל כללים משותף — סט הגדרות אחיד לארגון, הבדלים בין שפות מוגדרים בדריסות, לא בעותקים.
3. פיילוט על מאגר אחד במצב בדיקה ללא תיקונים — מעריכים את שיעור הקבצים שיושפעו.
4. ריצה חד-פעמית על המאגר ב-commit נפרד: רק עיצוב, בלי שינויים סמנטיים.
5. חיבור הבדיקה בענף — תחילה אזהרה, אחר כך תנאי חובה למיזוג.
6. הפעלה הדרגתית של שאר המאגרים בקבוצות, מהפעילים ביותר ועד לארכיוניים.
7. מסירה לצוות: פרופיל, פקודות הרצה, תיקון אוטומטי לפני commit בסביבה המקומית.

החמרה הדרגתית של הבדיקות

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

מה נשאר לצוות: קונפיגורציות, כללים, נהלים

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

קבצי קונפיגורציה ופרופיל כללים משותף

• פרופיל כללים אחיד בשורש המאגר: קונפיג אחד לכל השפות, בלי וריאציות מקומיות בתת-תיקיות — פער הגדרות בין מודולים נעלם כקטגוריה.
• תיאום עם העורך: .editorconfig חוזר על אותן הזחות ושבירות שורה, כדי שעריכות ב-IDE לא יתנגשו בפורמטר בזמן מיזוג.
• רשימות חריגים: קוד מיוצר, ספריות צד שלישי, מיגרציות — מעצבים רק את מה שהצוות מתקן ידנית.
• שלב בדיקה במסלול: המיזוג נחסם אם הקובץ לא מעוצב; תיקון אוטומטי מגיע ב-commit נפרד.
• Hook במכונת המפתח: בדיקת pre-commit לא מכניסה קוד לא מעוצב וחוסכת הרצות מסלול.

תיעוד ונוהל חריגים

• הוראה קצרה במאגר: איך להריץ עיצוב מקומית, איפה נמצא הקונפיג ומה לעשות בעת התנגשות עם linter.
• נוהל חריגים מהכללים: חריג מנוסח עם סיבה ובעלים, אחרת הרשימה גדלה והכללים מפסיקים לפעול.
• נוהל שינויי פרופיל: תיקון כללים מתבצע בשינוי נפרד עם ריצה על כל המאגר, לא "על הדרך" במשימת עבודה.

התוצאה — עיצוב מפסיק להיות תלוי בהסכמות: ה-diffs ב-review מכילים משמעות, והבדיקה משוחזרת בכל מכונה.

מקרה בוחן: monorepo ללא תיקוני סגנון ידניים

הלקוח הגיע עם monorepo: עשרה שירותים בכמה שפות, וסגנון אחיד היה קיים רק כהסכמה בעל פה. כל אחד הריץ עיצוב ידנית, לא תמיד לפני commit, ובדיקת קוד הפכה לוויכוח על הזחות — כשליש מההערות נגעו למראה הקובץ, לא ללוגיקה.

לפני

בדיקת קוד בענף בינוני לקחה כ-35 דקות, וכמעט כל הערה שלישית הייתה על עיצוב. בערך כל commit חמישי לא שינה את התנהגות המערכת, אלא רק תיקן הזחות ושבירות שורה: תיקונים כאלה שקעו בהיסטוריה המשותפת והפריעו לנתח שינויים בזמן rollback.

התנגשויות מיזוג בקבצים שמנוהלים על ידי כמה צוותים נוצרו בדיוק בגלל פורמט שונה — פתרון המיזוג לקח יותר זמן מהשינוי עצמו.

אחרי

את העיצוב העבירו למסלול: הבדיקה רצה לפני דיון בשינויים, ובמקרה של פער הבנייה נכשלת ומצרפת גרסה מתוקנת מוכנה. קבצים היסטוריים הורצו ב-commit נפרד דרך Prettier — בלי שינויים בלוגיקה, כדי שהתיקונים יישארו קריאים.

זמן בדיקת הקוד הצטמצם מ-35 ל-12 דקות. שיעור ה-commits שרק סגנון — פחות מ-2%. התנגשויות מיזוג בגלל עיצוב כמעט נעלמו: מספר המקרים ירד בערך פי חמישה, ותוכן זהה בשני ענפים נותן כעת קובץ זהה. הדיון שוב על לוגיקה, לא על רווחים.

עיצוב ולינטינג: מה ההבדל ומה לעשות עם legacy

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

ה-linter מסתכל על המשמעות: משתנים לא בשימוש, ענפים בלתי ניתנים להשגה, השוואות חשודות — ומתקן אותם רק חלקית.

הפרדת הבדיקות במסלול נעשית לפי שלבים: עיצוב — שלב נפרד עם תיקון אוטומטי, lint — שלב נפרד, עם קוד יציאה משלו. כשל של אחד לא מסווה את האחר, והמפתח רואה מיד מה בדיוק צריך לתקן.

בקוד ותיק סדר הפעולות הפוך מהרגיל. תחילה מעבר מסיבי אחד של הפורמטר, שמופרד ל-commit נפרד — אחר כך כל תיקון נעשה על קובץ מיושר, וההיסטוריה לא מתמלאת בתיקוני סגנון. את ה-linter מפעילים בהדרגה: כלל אחר כלל, הערות במודולים ישנים עוברות לאזהרות, ורק חדשים נחסמים.

כללים ללא התנגשויות נוצרים כשהאמת אחת: את הסגנון קובע הפורמטר, ומסט ה-linter מסירים כל מה שמשכפל עיצוב. אחרת הכלים מושכים את אותו קוד לכיוונים שונים, והצוות מכבה את הבדיקות לגמרי — יחד עם המועילות.

ספקות טכניים: רעש בהיסטוריה, שפות זרות, חריגים

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

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

יש לנו סטאק משולב

הבדיקה מתחלקת לפי מסכות: לכל שפה יש פורמטר וקונפיג משל עצמה, שרצים רק על הקבצים שלה. מה שלא נכנס לאף מסכה — לא נבדק, לכן שפה חדשה לא מחייבת לכתוב מחדש את הכלל כולו.

יש קוד מיוצר וספריות צד שלישי

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

לצוותים יש סגנונות שונים

הסגנון עובר מהתכתבות לקונפיג משותף אחד — הוויכוח הופך לתיקון של קובץ אחד, שנראה ב-review. הבדיקה במסלול הופכת את התוצאה לבלתי נתונה לדיון: סגנונות הצוותים מתכנסים לסט כללים מקובע, לא לטעם של מישהו.

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

• הרכב המאגרים: איפה monorepo, איפה שירותים נפרדים, אילו שפות ובאיזה יחס, האם יש תיקיות משותפות עם ספריות.
• כללי העיצוב הנוכחיים: קונפיגורציות של פורמטרים, הגדרות עורך, חריגים לקוד מיוצר ולצד שלישי, קבצים שנויים במחלוקת.
• דרישות לבדיקות: מה צריך לחסום מיזוג, מה מספיק כאזהרה, אילו ענפים מוגנים והאם נדרש תיקון אוטומטי במקום כישלון.
• שיעור הקוד הישן: היקף קבצים שאי אפשר לעצב ב-commit אחד, ומוכנות הצוות לתיקון מסיבי חד-פעמי.
• סדר הפריסה: האם לתכנן הפעלה מיידית על כל הענפים או בהדרגה — תחילה דוח, אחר כך תיקון אוטומטי, אחר כך חסימה.
• סביבת הרצה: איפה רצות משימות הבנייה, האם יש מגבלות הרשאות ומריצים מבודדים.

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