בקשות משיכה הן כמו הדם של המאגר. הם שומרים על בריאות העסק ועל תנועה מתמדת. בדף הזה מוסבר איך ליצור בקשת תיקון (PR) מלאה וקלה לבדיקה, וכך להגדיל את הסיכוי שהיא תאוחד.
ריכזנו כאן כמה פעולות שאפשר לבצע כדי ליצור את יחסי הציבור הטובים ביותר האפשריים.
תקשורת
לפני שמתחילים לכתוב קוד, כדאי ליצור קשר עם צוות הליבה כדי שהם ידעו מה מעניין אתכם.
אם יש בעיה שמעניינת אתכם, תוכלו לכתוב בה תגובה על כך שאתם מתכוונים להתחיל לטפל בה. כך אנחנו יכולים לוודא שלא יהיו כמה אנשים עובדים על אותו דבר. חבר בצוות יגיב כדי לאשר שהחשבון שייך לכם.
אם יש לכם רעיון שלא מופיע בבעיה, עליכם לכתוב דיווח על בעיה לפני שתתחילו לעבוד. כך הצוות יוכל לדון איך הכי טוב לבצע את השינוי לפני שתתחילו לפתח, וכך לחסוך לכם עבודה בטווח הארוך.
טיפים להגדרה
אם זו הפעם הראשונה שאתם תורמים ל-Blockly או ל-blockly-samples, כדאי להתחיל בדף הגדרת הפיתוח.
שמירה על גודל קטן
תמיד כדאי לנסות לשמור על שינויים קטנים וממוקדים. אנחנו מעדיפים לבדוק כמה בקשות קטנות יותר מאשר בקשה אחת גדולה. כמה כללי אצבע טובים:
- פתרון בעיה אחת אל תנסו לטפל בכמה בעיות בבת אחת.
- הגבלת ההיקף בדרך כלל, תהליך ה-PR אמור להימשך פחות מ-8 שעות (בהתאם לרמת ההיכרות שלכם עם קוד הבסיס).
- שימוש ב-commits אם בקשת העריכה (PR) גדולה מדי, אפשר לפצל את השינויים לקבוצות לוגיות באמצעות השמירה ב-git.
שמירה על ניקיון
למה חשוב להקפיד על סגנון הקוד? אנחנו כאן לטווח הארוך, וסגנון עקבי מקל על התחזוקה. הסגנון מתייחס לאופן שבו נותנים שמות למשתנים, אבל הוא כולל גם את המבנה של הקוד, כתיבת תגובות ועוד. כשהדבר אפשרי, אנחנו משתמשים בכלים כמו eslint כדי לבצע אוטומציה של בדיקות הסגנון.
בנוסף ל-eslint, יש לפעול לפי המדריכים הבאים:
- מדריך הסגנון של Google ל-JavaScript
- מדריך בנושא הודעות לגבי שינויים
- הרשאות גישה ל-API
- מדריך הסגנון של Codelab
בדיקת השינוי
לפני ששולחים בקשת תיקון, תמיד צריך לבדוק שהשינויים פועלים, כדי שלא תצטרכו לחזור ולתקן אותם מאוחר יותר. ריכזנו כאן כמה רעיונות לבדיקה של הקטגוריות השונות של הפרויקטים:
- ביישומי פלאגין: כותבים בדיקות mocha אוטומטיות שמכסות את השינויים.
- דוגמאות: בדיקה ידנית של כל הפונקציונליות שמוצגת.
- בcodelabs: מריצים את המדריך כולו בסביבה נקייה ובודקים את כל קוד הדוגמה שסיפקתם.
תקשורת
זהו החלק האחרון, ואפשר לטעון שהוא החלק החשוב ביותר בתהליך יצירת הבקשה ל-PR: כתיבת הסיכום.
כתיבת סיכום מצוין של יחסי הציבור עוזרת למפתחים אחרים לבדוק את השינויים, וכך מגדילה את הסיכוי שהם יאושרו מהר יותר.
הסיכום צריך לכלול פרטים כמו:
- לאיזו בעיה הבקשה קשורה.
- מהו השינוי שמוסיף ה-PR.
- איך בדקתם את השינוי.
- כל פרט שרוצים שהבודקים יבדקו לעומק.
- כל מידע נוסף שלדעתך יעזור למבקרים.
אם תפעלו לפי התבנית של בקשת התיקון כשאתם יוצרים את הבקשה, הכול אמור להיות בסדר. רק חשוב לזכור להיות קצרים ומלאים ככל האפשר.
שתהיה לכם תכנות מהנה!