תכנון פרויקט: למדוד פעמיים - לחתוך פעם אחת - "פרויקט ג'אווה מא' עד ת'"

שלום, עמיתים. היום אנחנו הולכים לדבר על סוג עבודת ההכנה שאתה צריך לעשות לפני שאתה מתחיל לתכנת בצורה פראית. ליתר דיוק, על תכנון ויצירת ארכיטקטורת אפליקציה. אבל מאיפה להתחיל? איך לבנות את הארכיטקטורה הזו? כמו בכל דבר, צריך להתחיל מההתחלה. כלומר - עם IDEA. הרעיון של הפרויקט שלנו היה ליצור בוט טלגרם שימושי עם פונקציונליות בסיסית. הבה נחזור על מה בדיוק: "אני, כמשתמש, רוצה להיות מסוגל לקבל הודעות כאשר מאמרים חדשים מתפרסמים באותן קבוצות ב-JavaRush שמעניינות אותי." בהתאם לעקרון YAGNI, אנו נבנה את האפליקציה שלנו. זה אומר שניקח רק את מה שאנחנו צריכים. אנחנו לא ניצור פונקציונליות מראש ובמילואים רק כי אנחנו רוצים ויום אחד זה באמת עשוי להועיל. כן, ניצור אפליקציה ניתנת להרחבה, אבל זה לא אומר שניצור סכימת מסד נתונים "לצמיחה". כדי לא לתמוך ב"צמיחה" הזו החלטתי שעדיף לנטוש אותה לגמרי. זה יעזור לנו להימנע מתמיכה מיותרת במהלך הפיתוח ובדיקות מיותרות. בהמשך, כשהפרויקט שלנו ייכנס לייצור (שוב אנגליזם, מהקיצור prod - production), נוכל לעשות עוד משהו. לאחר שהחלטתם על רעיון, אתם צריכים להיות קצת שובבים ולצייר. מה לצייר? נצטרך את היכולת לשמור נתונים על מנויים לקבוצות של משתמשים שונים. אני יודע שאתה יכול להשתמש במזהה משתמש בצורה של מזהה צ'אט בטלגרם. ויש מושג איך יתקדם החיפוש אחר מאמרים חדשים בפועל: נחפש בכל הקבוצות שיש להן מנויים למאמרים חדשים ונשלח אותם לצ'אטים. בהתבסס על זה, אנו מקבלים את הדברים הבאים כקירוב ראשון (הנה הפיתוח ללא קישוט): אני לא מקווה שתבינו את כתב היד שלי: אני רוצה להראות בדיוק איך והיכן מתחיל הפיתוח. השלב הראשון הושלם: איכשהו החלטנו מה יקרה. המודלים/טבלאות במסד הנתונים מתוארים לעיל. אבל זו טיוטה: אפשר וצריך ללטש אותה ולהביא אותה לצורה קריאה יותר. תוך כדי ליטוש נזכרתי שגם אני רוצה לקבל סטטיסטיקות על עבודת הבוט. הוסיף את זה. בציור זה יותר ברור מה ואיך זה יהיה מסודר. כלומר, אילו טבלאות ושדות יהיו בהם, אילו שמות ישויות יהיו עבור הטבלאות. הוחלט שיהיו כמה מהם:

• משתמש - מידע על משתמש הטלגרם שישתמש בבוט שלנו. כפי שאתה יכול לראות, אנו שומרים רק את מזהה הצ'אט והדגל בין אם המשתמש פעיל או לא. למה? כי המטרה שלנו היא לא לאסוף מידע על משתמשים, אלא להועיל להם;
• GroupSub - כאן יהיה מידע על הקבוצה אליה יש לך מנוי והמאמר האחרון שנשלח למנויים;
• סטטיסטיקה - לא יצרתי סכימה עבורה - נעשה זאת מאוחר יותר. זו לא המטרה העיקרית ב-MVP של הפרויקט.

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

צור מאגר לעבודה

לבסוף, אתה יכול ליצור מאגר לעבודה עם בוט טלגרם.

1. אנו ממלאים את הפריטים שכבר מוכרים לנו - שם המאגר, התיאור הקצר שלו.
2. הוסף רישיון - Apache 2.0 (תוכל לבחור את הרישיון לפי שיקול דעתך).
3. הפרויקט שלנו זמין כעת - הנה הקישור אליו: JavaRush Telegrambot .

צור פרוייקט במאגר

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

1. לעשות - כל המשימות שמתוכננות להתבצע;
2. בתהליך - משימות שעובדים עליהן כעת;
3. בוצע - משימות שכבר הושלמו במסגרת פרויקט זה.

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

בעיות כתיבה (בעיות) עבור הפרויקט

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

• SpringBoot - כמסגרת לאפליקציה שלנו,
• Spring Data - לעבודה עם מסד נתונים,
• Flyway - לעבודה עם העברת מסדי נתונים,
• MySQL - כמסד נתונים עבור הפרויקט,
• Telegrambot StringBoot starter - ספרייה לעבודה עם בוט טלגרם,
• Unirest היא ספרייה לעבודה עם בקשות REST.

מכל האמור לעיל, בואו נתחיל ליצור משימות.

תבנית יצירת משימות

אנו ניצור משימות באמצעות התבנית הבאה:

1. שם המשימה ייראה כך: JRTB-{IssueNumber}:{IssueDescription} , כאשר:
   • {IssueNumber} הוא המספר הסידורי של הבעיה. בואו ניקח את זה עוד אחד מהבעיה האחרונה;
   • {IssueDescription} - תיאור קצר של הבעיה.
2. בגוף המשימה נבצע תיאור מפורט יותר שלה (לעיתים הוא עשוי להתאים לתיאור בשם המשימה).
3. קריטריוני קבלה הם רשימת דרישות, שלאחריהן ניתן לראות שהמשימה הושלמה. כביכול, הקריטריונים לקבלת המשימה. באמצעותם, סוקר (מהסוקר האנגלי - מבקר - אדם שמסתכל על אופן השלמת משימה) יכול להבין האם המשימה הושלמה במלואה או לא.

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

1. [תכונה] JRTB-0: צור פרויקט אתחול של שלד אביב - הכל ברור כאן: אתה צריך לעשות את החלק הראשון של מה שעשינו במאמר הקודם.
2. [פיצ'ר] JRTB-2: הוסף בוט טלגרם לפרויקט - הוסף בוט ריק שפשוט יגיב ויגיד שהוא חי וקיים.
3. [תכונה] JRTB-3: הטמעת תבנית פקודה עבור טלגרם – בואו נגדיר את הגישה הנכונה לעבודה עם פקודות בבוט טלגרם. עד כה עבור מספר קבוצות.
4. [תכונה] JRTB-1: הוסף שכבת מאגר - זו אחת המשימות הגדולות ביותר - היא משלבת את כל מה שצריך לעשות כדי לעבוד עם מסד הנתונים.
5. [פיצ'ר] JRTB-5: כמשתמש, אני רוצה להוסיף את הקבוצה למנוי - זה כבר User Story הראשון בהבנה Agile. זה יהיה יתרון אמיתי עבור המשתמשים שלנו: ניתן יהיה להוסיף מנויי קבוצה לבוט.
6. [FEATURE] JRTB-12: הטמעת תזמון לשליחת הודעות על מאמרים חדשים – כאן יתבצע יישום חיפוש מאמרים חדשים במידה והם מתפרסמים עבור כל אחת מהקבוצות ונשלחים לכל המשתמשים הרשומים לקבוצות.
7. [תכונה] JRTB-6: כמשתמש, אני רוצה לראות רשימה של מנויי הקבוצה שלי - הכל פשוט כאן: אנחנו מוסיפים פקודה שמציגה רשימה של כל הקבוצות שהמשתמש מנוי אליהן.
8. [תכונה] JRTB-7: כמשתמש, אני רוצה להסיר את המנוי לקבוצה מהמנויים שלי - כאן אתה צריך להסיר את המנוי של המשתמש לעדכונים בקבוצה.
9. [תכונה] JRTB-8: כמשתמש, אני רוצה להגדיר לא פעיל באמצעות בוט - יישם עצירת הבוט. כלומר, כל מה שצריך לעשות במערכת שלנו כדי שהעבודה תיפסק. הוסף את הפקודה /stop לעיבוד.
10. [תכונה] JRTB-9: כמשתמש, אני רוצה להתחיל לעבוד עם בוט או להגדיר פעיל אם השתמשתי בו בעבר - הוסף עיבוד של הפקודה /start. בדיוק כמו שאנחנו רוצים.
11. [תכונה] JRTB-10: כמנהל, אני רוצה לראות סטטיסטיקות של בוטים - יצירת אוסף של סטטיסטיקות בוט. הוספת יכולות מנהל.
12. [תכונה] JRTB-11: כמשתמש, אני רוצה לראות תיעוד עבור בוט הטלגרם הזה - כתיבת תיעוד. כן, כן, חברים, אתם לא יכולים לחיות בלעדיו, וככל שתלמדו לעשות זאת מוקדם יותר, כך זה יהיה טוב יותר עבורכם))

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

מילוי המאגר

מה עוד צריך לעשות לפני שנתחיל בקידוד? - מחבר, כמה מהפסקאות האלה אתה יכול להוסיף, אתה שולף אותן מהתהום?? - לא, איכות העבודה מוצגת בפרטים. והם אלו שהגיוניים. אז בואו נוסיף עוד פרט אחד. על מנת שהפרויקט יהפוך לפופולרי ומובן עבור מפתחים אחרים, יש למלא אותו. מה עלי להוסיף? תיארתי רשימה מלאה של מה שניתן לעשות במאמר אופטימיזציה של העבודה עם הפרויקטים שלך ב-GitHub: היכרות עם מאגר תבניות Github . אני ממליץ בחום לקרוא אותו. חשוב לנו שיהיה לנו גרסאות ברורות, הבנה ברורה של מה שאנחנו עושים. לכן, הוספתי קובץ RELEASE_NOTES שבו יתועדו שינויים בפרויקט שלנו. כדוגמה, אתה יכול להסתכל על RELEASE_NOTES מהפרויקט שלי (כן, למה לא להראות במה אני משקיע את האנרגיה והיצירתיות שלי). השינויים עבור כל גרסה חדשה מתוארים שם. הוספתי גם תבניות ליצירת משימות חדשות, שיש להן 4 אפשרויות:

• דוח באגים הוא משימה שנוצרה על ידי משתמשים/בודקים שמוצאים באג בעבודה שלהם. זה דבר חשוב מאוד: זה עוזר לנהל תיקוני באגים;
• בקשת תכונה היא משימה להוספת פונקציונליות חדשה. כל המשימות הראשונות בפרויקט הן משימות בקשת תכונה;
• בקשת שיפור - משימה לשיפור פעולת האפליקציה. לדוגמה, כדי לשנות תשובות למבחן בעת ​​עבודה עם בוט. אני לא כותב טכני ואני יכול להמציא תשובות לא לגמרי נכונות. אז אם יש לך את הרצון והיכולת, תציע את זה :)
• שאלה היא שאלה למפתחים לגבי פעולת האפליקציה. דבר מאוד שימושי. נניח שאין הבנה בעבודה או שיש ספקות לגבי שאלה כלשהי - אתה יכול לשאול שאלה בדרך זו ולקבל תשובה ממקור ראשון.

אם תסתכל על GitHub, זה ייראה בדיוק כך: יש לנו גם כרגע מסמך על עבודה עם JavaRush API לעבודה עם קבוצות.

מה הלאה?

ובכן, אנחנו משלימים את כל השלבים האלה ומה, הפרויקט ייסגר? בכלל לא. הפרויקט הזה ימשיך לחיות. זה יפותח על ידי ועל ידי כל אותם סטודנטים/בוגרי JavaRush שרוצים לקחת חלק. מה התוכניות שלך לעתיד? הרבה מהם. התוכנית הראשונה היא ליצור לקוח Java עבור JavaRush API. המפתחים הבטיחו להפוך את Swagger לגישה פתוחה. נסתכל גם מה זה סבבה. דבר מגניב ושימושי מאוד. בשלב הבא נשלב את אתר JavaRush עם בוט טלגרם. בואו נחבר את המשתמש לבוט כדי לסנכרן מנויים. בואו ניצור סטטיסטיקות על סיום הקורס. וכל מה שאתה רוצה כקהילת JavaRush.

מסקנות

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

רשימה של כל החומרים בסדרה נמצאת בתחילת מאמר זה.