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

1. קנה SSD.
2. הוסף עוד זיכרון RAM.
3. אם אתה מפתחים אפליקציית אינטרנט: השתמש ב browserify כדי לטעון מחדש את קוד צד הלקוח שלך.
4. בעת הפיתוח, בנה רק את החלקים של בסיס הקוד שמשתנים.
5. בדוק את קוד הבנייה ובמחשב המקומי שלך, קצר את הבנייה כך שהוא יבנה רק את החלקים של בסיס הקוד שמשתנים.
6. שקול להריץ בדיקות יחידה אוטומטיות רק לפני הבדיקה. -ins.
7. שתף פעולה עם חברי הצוות והמנהלים כדי לצמצם את זמן הבנייה לצמיתות.

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

עריכה:

1. לאנשים שאמרו שלא עניתי לשאלת ה- OP: אנא שקול תשובת מטא זו.
2. בנייה איטית יכולה לשבש את מקום העבודה. חשוב מאוד לבחון את כל האפשרויות לפני שתקבל את העובדה שהבנייה איטית.

קרב חרב הוא תרגיל נהדר. השתמש בו.

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

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

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

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

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

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

משהו מהניסיון שלי:

נסה לתקן טעויות מרובות בבת אחת.

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

לדוגמה, תוכל להפחית את מספר המחזורים על ידי בדיקת דברים אחרים:

• האם העמודות לפחות מעוצבות כראוי?
• האם כל העמודות האחרות מכילות את מה שהן צריכות?
• ...

זה חשוב במיוחד ב מחזור אחד או שניים ראשונים ויכול לעזור לך לחזור בין 15 ל -5 עיכובים של 30 שניות (וכנראה גם תוצאה טובה יותר).

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

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

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

התשובה שלי תלויה במהדר אך נסה זאת:

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

תוכלו:

למשל, מחליפים שני מזהים (שתועדו בצורה גרועה).

ראיתי בעיה זו בתוכנות רבות המשתמשות ב Int או מחרוזת לכל מזהה יחיד; במקרה זה קל להעביר בטעות תעודת זהות במקום אחרת ולא להבחין בזה ... זמן רב.

אם אתה יכול להעביר מזהה עוף למכונת השתייה, בקוד שלך יש סוגיה (*).

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

הפוך אותם לסוגים שונים, והמהדר יצביע לך בשמחה על השגיאות שלך, שיאיצו מעלה את לולאת ה- Fix-Compile-Test (על ידי חיתוך שלב הבדיקה והפרעה של ה- Compile).

זו הגרסה המקלדת סטטית של עקרון ה Fail Fast : שם הוא בקושי מהיר יותר מאשר שהמהדר (או אפילו IDE אם הוא מהדר ברקע) יפנה אליך שגיאות.

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

( *) אלא אם כן שתיית דם עוף אינה נוהגת אצלך, מה אני יודע ...

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

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

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

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

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

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

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

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

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

תסתכל עליו, כתוב כמה הערות, תסתכל שוב. ואז הידור.

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

השקיע את הזמן בעצמך.

10 שניות בחינם: בצע שכיבות סמיכה.
60 שניות בחינם: עיין בשאלות רשת חמות של Stack Exchange. .
120 שניות חינם: קום ושתה מעט מים.

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

היזהר יותר / השג תוכנה טובה יותר

האם הבעיה האמיתית היא שאתה צריך לחכות עד שהבנייה תסתיים כדי לדעת אם עשית טעות או שאתה נותן מספיק טעויות קטנות באמצעות זמן בנייה קצר מאוד (30 שניות!) הפך לבעיה?

לא כל הבעיות יהיו ברורות מיד; זו הסיבה ש תכנות במקרה הוא רעיון נורא, וזה נשמע כמו מה שאתה עוסק בו.

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

השתמש בזמן למשימות חד פעמיות קטנות

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

ריבוי משימות

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

אני מנסה שתהיה משימה A ומשימה B - משימה B שאין לה שום קשר. תוכניות מהודרות, שאוכל לעבוד עליהן בזמן שמשימה א 'בונה ומוצצת כמעט את כל ה- IO של הדיסק שלי.

יישום אינטגרציה רציפה / בניית שרת ובדיקות אוטומטיות.

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

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

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

(זה בתגובה לעריכה של השאלה המקורית שקובעת כי השגיאות המדוברות אינן שגיאות אוסף אלא אלה שאתה מזהה רק ברגע שהתוכנית פועלת.)

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

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

חומרה טובה יותר

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

תהליך בנייה טוב יותר

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

שפר את עצמך

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

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

  - מצא את סמל הכפתור המתאים והנח אותו בקובץ index.html. - הפוך את הכפתור להתקשר למשהו בקצה האחורי, בדרך כלל API - הפוך את ה- API התקשר לשירות המתאים. - תן לשירות להתקשר לשיטות DataAccess המתאימות - צור בדיקות לכניסות חוקיות ולא חוקיות (backend) - צור בדיקות לכניסות חוקיות ולא חוקיות (אינטגרציה) - הוסף בדיקות אלה לרישום בדיקות אוטומטי - התחייב קוד - המשך אל המשימה הבאה  

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

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