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

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

1. הקוד לא רץ. גם לא מתקמפל.

2. אין לי מושג מה הסיסמה למסך הניהול על שרת הבדיקות. היא היתה שמורה לי איפשהו אבל כבר מזמן שכחתי איפה.

3. התיעוד ברשת לא רלוונטי כי הפרויקט משתמש בספריות ישנות.

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

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

מה כן עובד לי-

1. יצירת מנגנון הרצה סטנדרטי, גם לפרויקטים ישנים - כלומר צריך לוודא ש npm start או docker compose up עובדים ומעלים את הסביבה. זה תמיד שווה את ההשקעה.

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

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

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

יש לכם עוד טיפים לתחזוקת פרויקטים פעם בכמה חודשים? אל תתביישו לשתף בתגובות.