תכנון ארכיטקטוני למפתחי web

6 בOctober 2014

אין תגובות

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

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

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

  •  SMAC – Scalable Modular Css Archtiecture
  • Css Anti patterns
  • JS Design patternss
  • Resposive Web Design Patterns
  • Semantics

מהי ארכיטקטורה בעולם התוכנה?

תכנון ארכיטקטוני הוא אוסף של החלטות שאנחנו לוקחים בנוגע לאפליקציה שאנחנו מפתחים. זה יכול להיות כל דבר החל מאיך אני מסדרים את הקוד(חלוקה לקבצים למשל), איך אנחנו בוחרים שמות למשתנים, באיזה תבניות עיצוב((design patterns נשתמש ועוד. ארכיטקטורה היא לא דבר אחד, זה לא עצם העובדה שאני שמה את ה JS שלי בקוד ניפרד או זה לא אופן סידור הקבצים  או שימוש במודלים,events, routing או minification אלה אוסף של כל ההחלטות שאנחנו לוקחים בנוגע לאפליקציה.

ארכיטקטורה טובה משתמשת בכמה שפחות קוד, היא בוחרת באופן מחושב ומודע את הכלים שמופיעים באתר או  האפליקציה ואת הדרך שבה הם עובדים זה עם זה. למשל לא נשתמש ב bootstrap  על מנת לבנות דף נחיתה שיש בו תמונה אחת ו-2 שורות קוד כי אנחנו מודעים לזה  bootstrap יעמיס על זמן הטעינה של הדף. כנ”ל גם באפליקציות גדולות לא נטען ספריה גדולה כמו Query  UI  אם נרצה פיצ’ר קטן מכלל המערכת או עם נעבוד בטכנולוגיה שלא מתממשקת טוב עם JQuery.

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

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

האופן שבו אנחנו נותנים שמות לכל חלק בקוד חשוב מאוד. נניח כי יש לי 3 משתנים:  .items,viewModel,getCurrent מהשמות האלה לא ברור מה הקשר בין שלושתם. אבל אם לאותה הרשימה הייתי נותנת שמות שונים למשל:

  • itemViewModelList
  • itemViewModel
  • getCurrentItemViewModel

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

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

ארכיטקטורה client טובה צריכה לדעת להביא באופן מחושב ומודע את פיסות הקוד הדרושות על מנת להריץ את הדף הנוכחי(dependency injection) כמו כן ארכיטקטורה טובה צריכה לדעת להגיד לנו כשמשהו לא תקין, והמערכת לא בריאה. ארכיטקטורה  מדברת הרבה גם על האופן שבו אנחנו ממשים פתרון בעיות שונות. היא מדברת על  פרדיגמות פיתוח, סטנדרטיזציה, חלוקת המוצר לקומפוננטות, תבניות עיצוב(design patterns), אבטחה, קנה מידה, אינטגרציה. 

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

מתי נבצע תכנון ארכיטקטוני?

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

איזה שיקולים עומדים לפני מהנדס/ארכיטקט?

תאימות(compatibility) – איך החלק במערכת שאני כותבת עובד ומתקשר עם יתר החלקים במערכת או איך האפליקציה שלי עובדת עם מוצרים(אפליקציות) אחרות. למשל מפתחי angular התאימו את המוצר שלהם לעבודה עם jquery  ע”י שילוב jqueryLight  במערכת.

התרחבות(Extensibility) – יכולת להוסיף עוד פונקציונליות ולהרחיב את יכולות המערכת ללא צורך בשכתוב או שכפול קוד קיים.

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

תחזוקה  – יכולת המערכת להתמודד עם עבודות תחזוקה שותפות כמו למשל עדכון גרסה.

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

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

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

מחזוריות – מתקשר למודולריות וזה היכול להשתמש בקוד קיים כדי לבנות קומפוננטות חדשות.

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

דוגמאות להחלטות ארכיטקטוניות בקרב מפתחי web

כתיבת תבניות עיצוב html  בצד שרת או קליינט – הרבה פעמים כשיש לנו אפליקציה גדולה אנחנו צריכים לצייר שוב ושוב את אותם האלמנטים, לכן ייתכן ונשקול להעביר את כל הלוגיקה שמחליטה היכן כל תבנית ממוקמת ב.client  אבל חשוב לזכור שאם נבחר להשאיר את כל הרינדור של הדף ל JS יקח לדף שלנו המון זמן להיטען כי ל- JS לוקח הרבה זמן להוריד את כל הקוד,לקמפל ובסוף לרנדר את ה HTML. זה שיקול שיש לקחת בחשבון ברגע שמחליטים איפה כל פיסת HTML תשב. יתכן שההחלטה הנכונה היא להשאיר חלק מהקוד בסרבר כמו למשל קוד בסיסי שאתר זקוק לוו כדי לפעול ולהציג view  בסיסי, וחלק להעביר ל JS. זהו שיקול שארכיטקט שרואה את המערכת בשלמותה לוקח בחשבון

Dependency Management – נניח כי האפליקציה שלנו צריכה לתמוך ב desktop וגם ב mobile. במידה ואין באפליקציה שלי מערכת טובה שיודעת לטעון חלקי קוד שונים בסיטואציות שונות אנחנו בבעיה. איננו רוצים שבמובייל נטען את כל הקוד שיש לנו ב desktop   כי זמן הטעינה יהיה גבוהה מידי ולא כל הפיצרים נתמכים כראוי. נרצה שבאפליקציית מובייל נטען את הקוד המינימלי הדרוש כדי שהאפליקציה תעבוד . במידה והאפליקציה שלנו לא תוכננה כראוי ולא דאגה מראש ל Dependencies  ברגע שנרצה לשחרר גרסת מובייל צנתרך לשכתב חלקים גדולים מהמערכת מההתחלה.

איך מתחילים לעבוד על ארכיטקטורה?

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

דוגמה להתחלה של תכנון ארכיטקטוני של עגלת קניות:

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

cart-full

השאלה הראשונה שנשאל היא אילו אובייקטים יש לנו בעגלת קניות?

  1. Cart – האובייקט של העגלת קניות עצמה
  2. Items – כל מידע על המוצרים בעגלת קניות כולל שם המוצר, מחיר, תמונה
  3. Meta information –מידע נלווה כמו סכום כולל של הקניה
  4. User – המשתמש שבפועל מבצע את הקניה
  5. Site info – שם פרטי , אימייל, וכל המידע של היוזר באתר
  6. Address  – לאן אנחנו שולחים את המשלוח
  7. Payment info  – אמצעי תשלום וכו’

השאלה הבאה שנשאל היא איזה states  יש לעגלת הקניות שלנו?

Application State

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

Error State

  1. מוצר חסר במלאי
  2. יוזר לא התחבר לאתר – חסר לנו מידע על היוזר
  3. הכתובת שהיוזר הזין לא נכונה
  4. האמצעי תשלום לא תקין

איזה אינטרקציות קיימות בעגלת קניות?

  1. התחברות לאתר
  2. שינויי מספר פריטים בעגלה
  3. מחיקה של מוצר מהעגלה
  4. לחיצה על  checkout

מה אנחנו יודעים על האפליקציה ששלנו בכללי?

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

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

הוסף תגובה
facebook linkedin twitter email

Leave a Reply

Your email address will not be published. Required fields are marked *