אחרי מספר שנים בתור מפתח פלקס ובערך שנתיים של יעוץ פלקס לחברות גדולות וקטנות, ראיתי עשרות צוותים, עשרות שיטות עבודה ומאות מפתחים. כולם תמיד טעו באותם דברים.
מה שעצוב ומתסכל הוא שחברות ממשיכות להכנס לתחום הפלקס וצוותים ומנהלי צוותים ממשיכים לעשות את אותן טעויות.
החלטתי לכתוב על זה פוסט, אולי אני אעזור לכמה אנשים לפני שנכנסים לתחום הflex ולהבין טוב יותר את מערך ההחלטות ואת הטכנולוגיה שהולכים להתמודד איתה.
1. שימוש בflex כדי לבנות אתרי אינטרנט או אפליקציות מדור ישן
טעות מאוד נפוצה וגדולה, אנשים לוקחים את פלקס, בונים איתה אתרי אינטרנט, אתרי מסחר אלקטרוני ואפילו דפי נחיתה. כאשר הכוח של flex ושל RIA לא נרתם לטובתכם, אין סיבה להשתמש בו.
אני זוכר, בתור ילד צעיר למדתי קראטה, with great power comes great responsibility, אמצו את זה כאשר אתם ניגשים לפתח אפליקציה. אם אין לכם אפליקציה שדורשת ויזואליות מסוימת, אנימציות, עבודה עם datasets גדולים וכו', עדיף שתשתמשו בטכנולוגיות אחרות כמו html, css ואפילו פלאש.
Flash this not that
אפשר לראות פוסט באנגלית על זה כאן
מקור התמונה The Flash Blog
2. האטת האפליקציה עד כדי זחילה על ידי שימוש ביותר מדי containers
בכל קורס פלקס שאני מעביר, יש שקף אחד שאני עומד עליו הכי הרבה זמן, וגם חוזר על עצמי הכי הרבה פעמים (אני שונא לחזור על עצמי).
השקף הזה מדבר על ריבוי containers. הרבה אנשים שמגיעים מhtml לתוך עולם הפלקס (וזה קורה המון) לא מבינים שcontainer בפלקס הוא component בפני עצמו שיש מאחוריו עשרות (לעיתים מאות) חישובים של גודל, מיקום, מיקום ילדים, גודל ילדים. ועוד יותר גרוע מזה, ולידציות וinvalidations.
מפתחים לא תמיד מבינים את מחזור החיים של container ולכן עושים שימוש במספר כאלה מקוננים אחד בתוך השני, באפליקציות dashboard ראיתי לפעמים 15-20 רמות של קינון. זה פשוט נורא, אפליקציה עם המון containers תצרוך כמות כפולה ומשולשת של זכרון וכול תזוזה תקח שניות רבות וחווית השימוש תפגם.
אפשר לראות כאן צילום מסך של תחקיר שעשו חברים בקהילה מאתר Inside RIA
צריכת זכרון כאשר יש יותר מדי Containers
ניקח דוגמה שפורסמה בזמנו בYahoo Developer Network (את המאמר המקורי אפשר למצוא כאן, אבל אני מתמצת את עיקרו שרלוונטי לנושא)
עם ניקח לדוגמה מצב שבו אנחנו רוצים אפליקציה שמציגה כפתור אחד בימין וכפתור אחד בשמאל, אפשר לבצע את זה במספר דרכים (3 ליתר דיוק) שרק אחת מהן תצרוך הכי מעט זכרון והשתיים האחרות יזללו לנו אותו, תכפילו את מספר הפעמים שיש לכם כזה layout בתוך אפליקציה גדולה וקיבלתם מכונה לזלילת זכרון יותר מpacman ביום טוב.
יותר מדי container באפליקצית flex
הדרך הראשונה
והקוד:
<Application layout="absolute">
<HBox width="100%">
<Button label="Left"/>
<Spacer width="100%"/>
<Button label="Left"/>
</HBox>
</Application>
יותר מדי container באפליקצית flex
שימו לב שיש לנו כאן מספר containers, רובם מיותרים, סבב התיקונים הראשון ועכשיו האפליקציה שלנו נראית כך
הקוד שלנו נראה כך:
<Application layout="horizontal">
<Button label="Left"/>
<Spacer width="100%"/>
<Button label="Left"/>
</Application>
הורדנו container אחד אבל עדיין יש לנו כאן Space מיותר, כול מה שאנחנו רוצים זה כפתור אחד צמוד לימין וכפתור אחד צמוד לשמאל, לא משנה מה גודל האפליקציה.
מספר container נכון באפליקצית flex
הטיוב האחרון שלנו נראה כך:
והקוד נראה כך:
<Application layout="absolute">
<Button label="Left" left="5"/>
<Button label="Left" right="5"/>
</Application>
כמובן שמדובר בדוגמה פשוטה ביותר, אבל אני מבטיח לכם שכול קומפוננטה יכולה לעבור תהליכי טיוב שכאלה, עם שימוש במספר containers מועט ככול האפשר, תעשו לעצמכם הרגל ובכול פעם שאתם ניגשים לכתוב קוד בקומפוננטה שלא נגעתם בה, תורידו container אחד, מבטיח לכם שאחרי שבוע, תרגישו בשיפור משמעותי במהירות.
3. שימוש בXML
אחד היתרונות הכי גדולים בפלקס זה היכולת של הפריימוורק להתמודד עם XML אבל עדיין בטכנולוגיות של היום יש שיטות כול כך יותר טובות להעביר Data שכל מעבר כזה בין הClient לServer והפוך לוקח הרבה פחות זמן.
XML לא רק לוקח יותר זמן לפרסר אלא לוקח יותר זמן להעביר על הwire ויכול לעלות המון כסף של BandWidth.
אחד המפתחים בקהילה יצר אפליקציה לדוגמא שמדגימה את מעבר המידע בכול אחת ואחת מהשיטות, אני חושב שאם אפסיק את הכתיבה עכשיו ותנסו את האפליקציה הזו, אתם תבינו על מה אני מדבר.
את האפליקציה הזו אפשר למצוא כאן
דוגמאות לסוגי העברת מידע בין Client לServer
4. שבירת מוסכמות והרגלי גלישה באינטרנט
כן כן, אתם יודעים על מה אני מדבר, כול מתכנתי הפלקס לדורותיהם שאי פעם אמרו " אי אפשר לעשות back", "פלקס זה רק דף אחד, אי אפשר לנווט לדפים אחרים" או כל אמרה אחרת תלושה מהמציאות.
עם פלקס אפשר להגיע לניווט רגיל לגמרי, אפשר לעשות Bookmark, אפשר להגיע לדף ספציפי עם כתובת ספציפית בלי ליצור SWF's נפרדים, אפשר הכול. כאשר אתן ניגשים לבנות את האפליקציה שלכם, שימו לב לזה, לעשות Deep Linking שיהיה אפשר להגיע לכול חלק מיידית, ללא ניווטים וקליקים מיותרים.
למשל, אם אתם בונים אפליקציה למסחר במטבע חוץ, אני ארצה כלקוח לנווט ישירות לחשבון שלי, ולא לגשת לפני זה לאף מסך, למה למנוע את זה ממני?
5. שימוש מוגזם באנימציות ומעברי עמודים
אני אהיה הראשון שאעמוד לימין הframework והיכולת שלו להתמודד עם משימות גראפיות כבדות, אבל אני גם אהיה הראשון לומר ש"My Account" לא צריך לעוף ב720 מעלות מתוך הקצה הימני של המסך, הוא לא צריך לשנות את הצבע שלו ולא צריך להזיז את הכפתור ב200 קמ"ש אחרי שלחצתי.
Less Is more, ככול שהתחכום של האפליקציה שלכם יהיה מרומז יותר כך יגדל הקסם שלה בעיני המשתמשים שלכם והם יהנו להשתמש בה, עם בכול פעולה של המשתמש הוא יחכה לאיזה אנימציה, זה לא טוב.
יודעים מה, כבר עשיתם את זה, תאפשרו למשתמש לכתוב את זה.
כנ"ל עם מוזיקה או Audio Effects.
6. לא לפתח סביבת פיתוח תומכת Craftsmanship או Agile או לא לפתח EcoSystem בכלל
זה נכון לכול טכנולוגיה, בין אם זה flex או אפילו Ruby on rails. לגשת ישירות לפיתוח מבלי להתחשב ולא להנהיג שיטות Tdd/Bdd, Unit Testing, Code Coverage וכו' זה פשוט לא אחראי, זה לא אחראי במיוחד באפליקציות פלקס מכיוון שכשלא עושים את זה, צריכים לבדוק את הכול דרך הUI, לחכות לקומפיילר שירנדר את האפליקציה בכול פעם, זה בזבוז זמן ומשאבים אדירים.
אל תשתמשו בQA כמכונה לאיתור באגים בUI, תבדקו את האפליקציה שלכם, היום עם פלקס 4 יש כול כך הרבה שיטות ויכולות שזה פשוט פשע לא לעשות את זה.
הנה כמה:
תפתחו שיטות עבודה איכותיות שמעודדות בדיקות, מעודדות Craftsmanship, מעודדות Clean Code ואחריות מפתחים.
7. לא לעשות שימוש בBuild Machine ובContinuous Integration
היות ואפליקציות Flex עוברות קומפליציה, כלומר מקוד מקור לאפליקציה סגורה, קובץ SWF שיטת הpublish צריכה להיות כזו
תהליך פיתוח ומעבר נכון לProduction
מה זה אומר בעצם?
זה אומר במפתח עושה Commit לקוד שלו, לתוך מכונה יעודית, במקרה הזה עדיף לעשות שימוש בGIT כי אז הוא יכול לעשות local commits וpush רק כשהוא בטוח שיש אצלו הכול.
המפתח כמובן בודק את הקוד שלו, כך שקוד שנכנס למכונה הוא קוד שעבר בדיקות.
על המכונה הקוד עובד בדיקות נוספות, כדי לבדוק Integration של כול המפתחים, במידה וכול הבדיקות עוברות, הקוד מתקמפל לאפליקציה ועולה לאוויר (אם צריך)
יעיל נכון?
סביבת העבודה הזו צריכה לבוא מלמעלה, היא לא יכולה לבוא רק מהמפתח והיא מועילה לכול הארגון בצורה מדהימה, ראיתי ארגונים שהטמיעו את זה ועשו סקרים לשביעות רצון לקוחות שהרקיעו שחקים בעקבות הטיפול המהיר בבעיות ועוד.
אני חושב שאלה הנקודות העיקריות שעולות לי לראש בשלב זה, אם יהיו דברים נוספים אוסיף אותם לפוסט.
כרגיל, אשמח לשמוע את דעתכם.
