עוד לפני הקוד

אמיר דותן

חשיבות התכנון ועיצוב הקוד - לקח אישי

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

הלקוח לא יודע כלום

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

להמשיך עבודה של מישהו אחר זה מ-א-ו-ד מסוכן

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

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

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

אי אפשר להתחיל את ה-איך לפני שמבינים את ה-מה

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

1. דרישות פונקציונליות (מה המערכת אמורה לעשות) - אלה הן כל הדרישות הטכניות לרוב, שמתארות את התפקוד והביצוע השוטף של המערכת. המערכת אמורה לרענן את תצוגת הנתונים כל חמש דקות, צריך להיות כפתור "שלח לחבר" ועוד ועוד ועוד. אסור לפספס שום פרט ולו הכי שולי, היות ותוספת מאוחרת יכולה להשפיע על גורמים אחרים, וליצור סיבוכים לא רצויים.
2. דרישות לא פונקציונליות (כל הדרישות האחרות( - אלה הן כל הדרישות שמצופות מהמערכת, אך לא קשורות לתפקוד שלה. כמו למשל מיקום הלוגו של החברה לאורך הדפים, או התאמה לדפדפנים מסוימים. דברים שהמערכת נדרשת ליישם אך לא לבצע.

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

1. דרישות מפורשות (Explicit) -אלה הן לרוב דרישות מצד הלקוח שיש לו מושג כללי מה הוא רוצה מהמערכת. אלה הן דרישות מאוד ברורות ולא משתמעות לשתי פנים, כמו "בכניסה למערכת המשתמש צריך להירשם ולקבל סיסמה".
2. דרישות מרומזות (Implicit)- העבודה החשובה של המתכנת היא לדעת לזהות ולהגדיר את הדרישות המרומזות, שמשתמעות מהדרישות המפורשות. אלה מאוד חשובות כי הן מהוות נדבך מרכזי בעבודת הפיתוח שתבוא אחר-כך, ואי אפשר להסתמך רק על הדרישות המפורטות. במקרה של הרשמת משתמשים אז הדרישות המרומזות יכולות להיות:
   - "צריך להיות מסך פידבק שמודיע למשתמש האם ההרשמה הושלמה בהצלחה, או שהייתה
   בעיה".
   - "צריכה להיות טבלת משתמשים בדאטאבייס, שכוללת שדות שם משתמש וסיסמה".
   - "צריך להיות מנגנון וולידציה בצד הלקוח ובצד השרת, על מנת לבדוק את השם והסיסמה".
   - "המערכת צריכה לזהות האם מישהו מנסה להירשם באותו שם פעמיים".

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

עיצוב הקוד - קריטי קריטי קריטי

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

חמישה שבועות של סיוט

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

לקחים אחרונים

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

פורסם לראשונה ב-"פלאש עברי".

		שם:
		דואר:
		אתר:
		כותרת:

		שם:
		דואר:
		אתר:
		כותרת: