כיצד תוודאו עבודה איכותית

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

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

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

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

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

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

תבנית העיצוב באתר צריכה להיות כתובה כתבנית בת של תבנית אחרת או כתבנית עצמאית (לא כמודיפיקציה של תבנית קיימת).

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

.

בתבנית שנבנתה מאפס – הסתמכות על פריימוורק של CSS

CSS הוא קוד המשמש לעיצוב האתר. המתכנת כותב CSS ובאמצעותו מעצב את הדפים השונים –  פריימוורקים של CSS מכילים קוד CSS קיים שעל בסיסו אפשר לבנות קוד המשכי. יש לא מעט פריימוורקים של CSS כמו Twitter Bootstrap ו-foundation, הסתמכות על פריימוורק כזה היא כמו בניית בסיס איתן ויציב לבניית בניין ויכולה למנוע לא מעט צרות, תקלות ובעיות. כמו כן, הרבה יותר קל לשנות עיצוב או להוסיף לו אם משתמשים בפריימוורק כזה. אם אתם משתמשים בתבנית בסיס, חשוב להקפיד שהיא תשען על פריימוורק CSS מוכר.

ה-CSS של התבנית חייב להיות ארוז כ-SASS או כ-LESS

SASS\LESS הן שפות סקריפט המיועדות לייצור CSS. הרבה יותר קל לשנות או לתקן קוד ב-SASS או ב-LESS וכמובן לתחזק אותו. כמעט כל הפרויקטים היום משתמשים בשפות סקריפט כאלו ויש לדרוש זאת ממתכנת האתר.

דרישה מהקוד שנכתב לאתר להיות ארוז בתוסף יעודי

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

קוד שנכתב לאתר במסגרת תוסף צריך להיות כתוב ב-object oriented

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

קוד ה-PHP שנכתב לאתר אמור לעבור בדיקת PHP Sniffer לפי WordPress Coding Standards

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

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

קוד ה-JavaScript שנכתב לאתר אמור לעבור בדיקת eslint לפי תקן וורדפרס

JavaScript היא שפת תכנות שרצה בדפדפן ועושה מגוון פעולות שונות – כמו למשל הקפצת הודעות למשתמש, הפעלת טפסים וכל פעולה 'אינטראקטיבית'. הקוד הזה גם אמור לעבור בדיקה אוטומטית לפי הסטנדרטים שנקבעו על ידי חברת אוטומטיק. האכיפה הזו מתבצעת באמצעות כלי שנקרא eslint עם הרחבה שנקראת eslint-config-wordpress.

בדיקות ביצועים

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

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

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

בדיקות אוטומטיות

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

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

סיכום

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