כיצד לקרוא ולתקן 100,000 שורות קוד בשבוע

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

כיצד להעריך פרויקט של 100 שורות קוד או יותר בשבוע תוך מתן תוצאות שבאמת שימושיות ללקוח.

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

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

הגישה של החברה שלנו

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

ישנם שני סוגים של הערכת אדריכלות.

פְּנִים - אנחנו בדרך כלל עושים את זה עבור פרויקטים בתוך החברה. כל פרויקט עשוי לבקש הערכת אדריכלות מכמה סיבות:

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

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

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

הערכת ארכיטקטורת פרויקטים ארגוניים

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

בעיות שהלקוח עשוי להתלונן עליהן ויכול להיות מודע להן:

• בעיות ביצועים
• בעיות שמישות
• פריסה לטווח ארוך
• היעדר יחידה ובדיקות אחרות

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

• בעיות בטיחות
• בעיות עיצוב
• ארכיטקטורה שגויה
• שגיאות אלגוריתמיות
• טכנולוגיות לא מתאימות
• חוב טכני
• תהליך פיתוח שגוי

תהליך סקירת אדריכלות פורמלי

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

בקשה מלקוח

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

אדריכל פתרונות – האחראי העיקרי על הערכה ותיאום (ולרוב היחיד).
ערמו מומחים ספציפיים – .Net, Java, Python ומומחים טכניים אחרים בהתאם לפרויקט ולטכנולוגיות
מומחי ענן - אלה יכולים להיות ארכיטקטי ענן של Azure, GCP או AWS.
תשתית - DevOps, מנהל מערכת וכו'.
מומחים אחרים - כמו ביג דאטה, למידת מכונה, מהנדס ביצועים, מומחה אבטחה, מוביל QA.

איסוף מידע על הפרויקט

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

• שאלונים ושיטות אחרות לתקשורת בדואר. הדרך הכי לא יעילה.
• פגישות מקוונות.
• כלים מיוחדים להחלפת מידע כגון: Google doc, Confluence, מאגרים וכו'.
• פגישות "חי" באתר. הדרך היעילה והיקרה ביותר.

מה אתה צריך לקבל מהלקוח?

מידע בסיסי. על מה הפרויקט? המטרה והערך שלו. מטרות ותכניות עיקריות לעתיד. מטרות ואסטרטגיות עסקיות. בעיות עיקריות ותוצאות רצויות.

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

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

מקרי שימוש בסיסיים וזרימות נתונים.

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

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

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

תהליך הערכת אדריכלות

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

DevOps צריך להסתכל על התשתית. מוביל טכני לתוך הקוד. מהנדס ביצועים להצגת מדדי ביצועים. מומחה מסדי נתונים צריך לחפור עמוק יותר במבני נתונים.

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

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

כלים שימושיים לאוטומציה של הערכת פרויקטים

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

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

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

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

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

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

ניו שריד – כלי להערכת ביצועי האפליקציה
דאטהדוג – שירות ניטור מערכת ענן

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

OWASP ZAP – כלי לסריקת יישומי אינטרנט לצורך עמידה בתקני אבטחה.

בואו נחבר הכל לשלם אחד.

הכנת דו"ח

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

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

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

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

אנו משלימים את הערכת האדריכלות ומספקים ללקוח דוח

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

כסיכום הפגישה שלך, שלח את הדו"ח שלך ללקוח.

לסיכום

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

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

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

המטרה שלך היא להראות ללקוח שיפורים מרביים במחיר המינימלי.

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

אני מאחל לך קוד נקי והחלטות ארכיטקטוניות טובות.

קבוצת הפייסבוק שלנו - ארכיטקטורת ופיתוח תוכנה.

מקור: www.habr.com