ברור למה אתם כאן: ללמוד איך סוף סוף גם אתה תכתוב תוכנה. הרי העיתונות הכלכלית פותחת על המפתחים עיניים. מה שמחלחל לאמא ואבא ואז לקידוש רגע אחרי מתי נתחתן ונביא ילדים הנדוש: “נו, אז מתי תעבוד בהייטקס”. מה שהוביל למערכון בארץ נהדרת שהחליטו להצטרף לחגיגה.
תוכן עניינים
זה באמת הזמן ללמוד פיתוח. אבל בואו רגע נפרק את זה: מה אדם צריך כדי להגדיר את עצמו “מפתח”? כלומר – מה זה בכלל פיתוח?
אז פיתוח – או פיתוח תוכנה, לפי IBM: “מערכת של פעולות מתחום מדעי המחשב שמוקדשות לתהליך של: יצירה, תכנון והפעלה של תוכנה. תחת זה, כל ההיבטים של כתיבה והפעלת קוד התוכנה.”.
אז כדי לייצר, לתכנן ולהפעיל תוכנה צריכים להכיר את הקונספטים והכלים הבאים:
לכתוב תוכנה
בשביל זה צריך לכתוב קוד בשפת תכנות. כלומר – שפה שאיתה אפשר להנחות את המחשב מה לבצע. בצורה לא מדוייקת – אבל מספיק נכונה כדי לא להסתבך – השפה שהמחשב מבין. לצורך ההתחלה – אני ממליץ על פייתון, כי היא קלה ללימוד ואינטואטיבית.
אבל מעבר לעניין הטכני הבסיסי – יש סטנדרטים לכתיבת תוכנה:
קוד נקי – Clean Code
ממליץ לקרוא את הספר: clean code של בוב מרטין.
בכל אופן, בקצרה: לכתוב קוד שקל להבין, וקל לשנות.
בשביל זה צריכים קוד שהוא קצר. שבו כל פונקציה וכל מחלקה מטפלים בדבר אחד בלבד.
שיש חלוקה נוחה בין קבצים. ולמשתנים יש שם משמעותי. יש פונקציות שנורא ברור מהן עושות.
קוד לפי קונבנציות מקובלות
אם נדמה שפת תכנות לשפה רגילה, הרי שכמו שקיים שוני בעברית של ירושלמים לעברית של התל אביביים. אבל ירושלמיים יבינו תל-אביביים ולהיפך. עם זאת, ועל-אף שהתקשורת הזאת תהיה מובנת לשני צדי השיח – הרי שהיא לא תהיה נוחה.
ארגונים מנחילים בתוכם סוגים של כתיבה. עדיף “לדבר” בשפה שלו כדי שלמתכנת חדש מהארגון יהיה קל להבין.
לא מספיק לקרוא – לימדו דרך עשייה
טעות נפוצה שמתחילים עושים בזמן לימוד תכנות היא פשוט לקרוא ספר של שפה כזאת או אחרת.
קל יחסית לקרוא על תנאים ולולאות, להבין את המשתנים והפעולות שניתן לעשות איתם, אבל התכנות בפועל לא עובד בצורה הזו,
כמו בכל מקצוע – אתם צריכים ללכלך את הידיים בעשייה ולהמשיך לתרגל את זה באופן קבוע.
כשמתחילים לתכנת מתמודדים עם הרבה בעיות, לפעמים גם בדברים בסיסיים ומזה הכי לומדים,
שלא תבינו לא נכון – קריאה זה סופר חשוב אך אל תצפו מעצמכם להבין קוד ע”י הדרך הזו.
DI – Dependency Injection
עיקרון בכתיבת קוד שאומר שאנחנו מזריקים את התלויות מבחוץ לתוך הפונקציות או לבנאים של המחלקות.
המטרה היא לגרום לקוד להיות כמה שפחות תלוי. ניתן דוגמה:
על העיקרון הזה שווה לכתוב מאמר, אבל בשביל מה? הנה מאמר על DI.
להריץ ולדבג את התוכנה שנכתבה
ככל שתדעו לזהות ולהתמודד עם באגים, יהיה קל יותר ללמוד לתכנת.
זוהי כבר מיומנות ותחום בפני עצמו: כדי לגרום לתוכנה לעבוד, צריכים להשתמש בכלי / סביבה שיודעת לדבג ולהריץ אותה.
זה נושא מורכב מדי לכאן 🙂
לתכנן תכנה
זה התחום הגדול והמשמעותי בפיתוח: כשמדובר במערכת גדולה, היא מחייבת תכנון וכתיבה מתאימים לצורך. לצורך העניין, אם לחנות בגדים יש מערכת חיפוש שבה מחפשים בעיקר ג’ינס מידה 32. הרי שאם המערכת תצטרך לתמוך בשליחה מהירה של המידע הזה, ולאחסן אותו בצורה שיהיה לה קל יותר לשלוף אותו למשתמש.
לצורך כך, על המפתח לחשוב איך הוא יאחסן מידע. זה לא מסתכם בקוד שרק יציג מידע: הוא צריך לחשוב על המערכת, ולהבין את הצרכים שלה כדי לתמוך בהם בצורה היעילה והנוחה ביותר.
אולי הוא ישתמש במערך של פריטים, ובנוסף – יכניס פריטים פופולריים למילון כדי לשלוף אותם מהר יותר. או שמא הוא ישתמש במערך של פריטים, אך ימיין אותו כל הזמן לפי הפופולריות של הפריטים. אולי יעמיק במערכת ויגלה שיש פריטים שיש מהם כמה סוגים, ולמרות שיש ג’ינס ידוע שהוא מידה 32 – מדי פעם הרשימה מתעדכנת. ואז – הוא ייאלץ לחשוב על דרך אחרת.
לתכנון יש כמובן המון רבדים נוספים: מה ה-flow, מה תהיה הקונפיגורציה, האם הקוד יהיה גנרי מספיק וכד’.
בתוך תכנון הקוד נכנסים המושגים הבאים
Design Patterns
קווים כלליים לתכנון התוכנה וה-flow שלה: מה יוצר את האובייקטים ואיך? איך ניגשים אליהם? בבלוג הזה קטגוריה שלימה של התחום.
מבני נתונים
איך שומרים את הנתונים. מה הממשק שלהם. למה זה חשוב?
במקרה שצריך לשלוף מידע במהירות למשל, תהיה בעיה לשמור אותו בזיכרון על מערך – כי זה אומר שנצטרך לעבור על כולו. במקרה כזה נרצה לעבוד עם hash. כפי שעלה בריאיון עם דוד רכטמן בפודקאסט “המסלול להייטק” – שאלות על מבני נתונים עולות בריאיונות עבודה למשרות backend.
לעומת זאת, אם יש רשימה שנרצה להציג במלואה – מערך/רשימה יהיה מבנה נכון יותר. במקרים אחרים – נרצה לייצר לעצמנו מבנה משלנו, שיתאים לצרכים הייחודיים שלנו.
קונפיגורציה
איך נגדיר את המשתנים של התוכנה מבחוץ אליה. איך ייראה הקובץ:
האם נשתמש בקובץ json? ואם כן – אילו פרמטרים? הוא יהיה עמוק או ארוך?
מה יגדיר את מה? האם הקוד יצטרך להיות גנרי כדי להבין כל דבר שיהיה כתוב בקובץ, או שיש מבנה לקובץ הזה?
לסיכום
מעבר לכל הטיפים שהצגתי כאן שהם סופר חשובים, ללמוד שפה חדשה ועולם חדש דורש תכנון נכון ופירוק למשימות קטנות, תדאגו לכך שתדעו שבכל שבוע / חודש תוכלו להניח עוד לבנה ועוד אחת וכך תגיעו אל המטרה, אל תחפשו את הסוף אלא את הדבר הקרוב שאותו תרצו להשיג – בין אם זה להבין משהו מהשפה, פרוייקט שאתם רוצים לממש ועוד.