בעולם התכנות המודרני הכולל גישה לאינטרנט מצד אחד וכלי פיתוח עם השלמה אוטומטית מצד שני, כתיבת קוד היא כבר לא בעיה כזו גדולה. ארגון קוד לעומת זאת זה סיפור אחר לגמרי. השאלות המעניינות הפכו להיות באיזה כלים להשתמש (PHP או node.js? בסיס נתונים טבלאי או NoSql? ובאיזה שפת תכנות?), איך לארגן את הקוד לקבצים ולמחלקות ואיך לכתוב קוד שיהיה קל לתחזוקה ולבדיקה.

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

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

1. לכתוב המון קוד, ואז לכתוב שוב

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

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

2. לחקור פתרונות טכניים נוספים

יש לכם אפליקציה? מעולה. עכשיו בואו נתחיל לשאול עליה שאלות. הדרך הכי קלה לראות טעויות בארגון הקוד היא להוסיף בדיקות יחידה (unit tests). מסתבר שרוב הקוד שתכתבו בפעם הראשונה יהיה כזה שמאוד קשה לבדוק אותו.

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

בנוסף, נסו לשלב פתרונות טכניים נוספים רק בשביל המשחק. כתבתם את השרת ב PHP בפעם הראשונה? בואו ננסה להחליף אותו בשרת node.js ונראה איך זה הולך. האפליקציה נכתבה ב Objective C ? בואו נוסיף גירסא ב Swift או אפליקציה היברידית כדי לראות איך זה מסתדר.

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

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

3. להתחיל לקרוא

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

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

1. The Pragmatic Programmer: From Journeyman to Master
2. Design Patterns Explained: A New Perspective on Object Oriented Design, 2nd Edition
3. Code Complete: A Practical Handbook of Software Construction, Second Edition

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

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

4. אין קיצורי דרך

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

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

הזמן הכי טוב לשתול עץ היה לפני 20 שנה. הזמן השני הכי טוב הוא היום. התחילו היום.