צ'קליסט לבדיקת פרויקט ריילס
לאחרונה אני מסתובב הרבה באפוורק כדי למצוא פרילאנסר/ית לפרויקט ריילס וככה יוצא לחטט בהרבה מאגרי גיטהאב של אנשים. בשביל לא להתחיל כל פעם לחשוב מחדש מה צריך להיות בפרויקט הכנתי צ'קליסט קטן של דברים שאני מחפש לפי סדרי עדיפויות. מוזמנים לקרוא לספר מה דעתכם וגם להציע סעיפים שפספסתי.
1. אבטחת מידע
הרגלי אבטחת מידע זה משהו שקשה מאוד ללמוד ועל טעויות אבטחת מידע קשה מאוד לעלות ב Code Review שוטף. הבעיה שפשוט אנשים כותבים יותר מדי קוד ובנושא אבטחת מידע כל פסיק לא במקום יכול להיות קטלני, ולכן אני מעדיף לסנן מראש מתכנתים שלא מודעים לנושא או שאין להם את האינסטינקט של קוד מאובטח. זה לא אומר שאנחנו נתפוס 100% מהבעיות - תמיד יהיו בעיות. אבל כן חשוב שנקודת ההתחלה תהיה של כתיבה מאובטחת.
בפועל בפרויקט ריילס זה מתרגם ל:
לשים לב לנקות כל פרמטר שמגיע מה Client.
לוודא בקרת גישה נכונה לכל נתיב.
לוודא ניקוי יסודי של קלט לפני פקודות פגיעות במיוחד (כמו system או eval).
לוודא שכל המחרוזות שנכנסות ל HTML עברו ניקוי.
אם הפרויקט נראה רציני אפעיל עליו גם את brakeman כדי לראות שלא פספסתי כלום, אבל בדרך כלל את הדברים הגדולים אפשר לראות בעין.
2. התמודדות עם הבלתי צפוי
התכונה השניה שאני מחפש אצל מתכנים היא הבחירה להתמודד גם עם מצבים מפתיעים בקוד. בפרויקט ריילס זה אומר למשל תמיד לבדוק שהשורה שניסית להכניס ל DB באמת נשמרה ולכתוב קוד שיודע להיכשל יפה אם היתה בעיה.
נקודות בגדול שחשוב לשים לב אליהן יהיו:
לוודא שתמיד אחרי save או create יש בדיקה של ערך ההחזר.
לוודא שמוגדר Exception Handler גלובאלי ליישום כדי שמשתמשים לא יקבלו מסך "שגיאת שרת".
לדאוג ל Validation על מידע גם במודלים וגם לאינדקסים בבסיס הנתונים.
לדאוג לערכי ברירת מחדל במודלים ובבסיס הנתונים.
3. ביצועים
בעיה נוספת אופיינית ליישומי Rails היא שימוש לא נכון ב ORM שגורם לבעיות ביצועים. בעולם מושלם אנחנו רוצים שמספר הפניות לבסיס הנתונים מכל דף יהיה חסום ועדיף שיהיה קבוע. בחיים האמיתיים קורה שיש מספר משתנה של שאילתות, אבל אם מספר השאילתות יכול לגדול עד אין סוף אנחנו בבעיה.
בעיה של שאילתות לא חסומות מופיעה כמעט תמיד בתיקיית ה views בתוך קבצי ERB כשקוד ERB מבצע שאילתות בתוך לולאה. דוגמא לקוד ריילס בעייתי כזה היא:
<table>
<tr>
<th>User Name</th>
<th>Tasks Count</th>
</tr>
<% @users.each do |user| %>
<tr>
<td><%= user.name %></td>
<td><%= user.tasks.count %></td>
</tr>
עבור כל משתמש מתוך @users אנחנו שולפים מבסיס הנתונים את מספר כל המשימות של אותו משתמש. ככל שיהיו יותר משתמשים כך יהיו יותר שליפות וכך העמוד ייטען הרבה יותר לאט. תקלה כזאת מאוד אופיינית ליישומי ריילס ויש אפילו ספריה שעוזרת למצוא קוד עם הבעיה, אבל כשמסתכלים על פרויקט דוגמא הרבה פעמים גם בעין קל לראות את זה.
4. בדיקות ותיעוד
סעיף אחרון שאני בודק הוא איכות הבדיקות והתיעוד. אם פרויקט הדוגמא שהפרילאנסרית בחרה לשלוח כולל את קובץ ה Readme הדיפולטי של ריילס זה חשוד. אם אין בדיקות זה Deal Breaker אבל גם בהנחה שיש בדיקות בהרבה פרויקטים הבדיקות פשוט לא בודקות כלום.
לדוגמא בפרויקט של ניהול משימות אתה יכול למצוא בדיקה שנראית כך:
כנס לטופס "יצירת משימה חדשה"
הכנס את פרטי המשימה בטופס
וודא שעל המסך הופיע הטקסט "המשימה נוצרה בהצלחה"
זו בדיקה גרועה כי המטרה של הטופס היא ליצור משימה חדשה, ולכן היינו מצפים שבדיקת הטופס תסתיים בוידוא בבסיס הנתונים שאכן המשימה החדשה נוצרה.
בדיקות גרועות בפרויקט זה לא סוף העולם כי זה משהו שאפשר יחסית בקלות לשפר, אבל בדיקות טובות בפרויקט בהחלט יכולות להוסיף הרבה נקודות ולשפר את הרושם.
זו הרשימה שלי - אם יש לכם הצעות או דברים אחרים שאתם הייתם מסתכלים עליהם בפרויקטי דוגמא מוזמנים לספר בתגובות.