פיתוח אינטרנט 10 Antipatterns קידוד עליך להימנע
עיצוב הארכיטקטורה של אתר או יישום, או הגדרת יעיל קידוד זרימת עבודה לעתים קרובות לגרום לנו להתמודד עם בעיות חוזרות. אנחנו לא בהכרח צריכים לפתור את הבעיות הללו עיצוב תוכנה מאפס, כמו פתרונות ברמה האדריכלית ניתן לעשות בה שימוש חוזר באותה דרך כמו קטעי קוד ברמת המיקרו.
דפוסי העיצוב הם בדרך כלל פתרונות לשימוש חוזר עבור תרחישים מסוימים, שיכולים לבוא שימושי כדי לפתור בעיות מתרחשות בדרך כלל, והוא יכול לעזור לנו מאוד לייעל את הקוד שלנו.
בעוד דפוסי העיצוב הם אמצעי נהדר כדי לשפר את תהליך הפיתוח שלנו באמצעות נוסחאות נבדק היטב, לפעמים אנחנו יכולים גם להשתבש איתם. אלה נקראים antipatterns.
מה הם אנטיפטרנים?
התנאי “אנטיפטרן” טבוע בספר שנקרא אנטיפטרנס בשנת 1998. הוא מתייחס פתרונות בשימוש חוזר, כי בתחילה נראה שימושי, אבל מאוחר יותר מתברר לעשות יותר נזק מאשר טוב.
זה יכול לקרות מסיבות שונות, למשל אם אנחנו לא משתמשים בדפוסים בהקשר הנכון, הגדרה או זמן (פתרונות שהיו יעילים בעבר לא תמיד עובד בהווה), או במקרים אחרים את הפרדיגמה כולה היה רק רע מההתחלה.
Antipatterns נקראים לעתים קרובות דפוסי כישלון. החדשות הטובות הן שזה אפשר לזהות ולהימנע מהם.
בהודעה זו יהיה לנו להסתכל על 10 מקודדים antipatterns קידוד בפיתוח אינטרנט זה עלול לשלוף אותנו לחשוב שיש לנו אופטימיזציה היטב קוד. (שים לב כי antipatterns המפורטים בהודעה זו לא בהכרח זהה למה שאתה יכול למצוא בספר שהוזכר לעיל.)
1. אופטימיזציה מוקדמת
עיתוי טוב הוא גורם מכריע בקוד אופטימיזציה. אנחנו יכולים בקלות לשחזר את antipattern של “אופטימיזציה מוקדמת”, אם נקדיש תשומת לב ליעילות קטנה ואופטימי עבורם מוקדם מדי בתהליך הפיתוח, לפני שנדע בדיוק מה אנחנו רוצים לעשות.
על פי הציטוט המפורסם של דונלד קנוט “אופטימיזציה מוקדמת היא שורש כל רע“, אשר עשוי להיות הגזמה, אבל עדיין מראה עד כמה בעיות חמורות אופטימיזציה בטרם עת יכול לגרום מאוחר יותר.
אם אנו מבצעים אופטימיזציה לביצוע לפני הגדרת ארכיטקטורה יעילה, אנו עשויים קריאת קוד נמוך יותר, עשה באגים ותחזוקה קשה יותר, ו מוסיפים חלקים מיותרים אל הקוד שלנו.
כדי למנוע אופטימיזציה מוקדמת זה רעיון טוב לעקוב אחר YAGNI (אתה לא הולך צריך את זה) עקרון התכנות, אשר מייעצת “תמיד ליישם דברים כאשר אתה באמת צריך אותם, לא כאשר אתה רק לחזות שאתה צריך אותם.”
2. Reinventing את הגלגל
ה “להמציא מחדש את הגלגל” אנטיפטרן הוא מכונה גם לפעמים “עיצוב בחלל ריק”. זה קורה כאשר אנחנו רוצים לעשות הכל בעצמנו ו לכתוב הכל מאפס, מבלי לחפש שיטות קיימות, ממשקי API או ספריות.
החזרתו מחדש של הגלגל אינה רק דבר מבזבז זמן, אלא פתרונות מותאמים אישית, במיוחד עבור פונקציות בסיסיות, הם לעתים רחוקות טוב כמו אלה סטנדרטיים כי כבר נבדקו על ידי מפתחים ומשתמשים רבים.
3. תלות גיהנום
ההפך של “להמציא מחדש את הגלגל” antipattern הוא עוד antipattern משותף שנקרא “תלות הגיהינום”.
אם, במקום לכתוב הכל מאפס, אנו משתמשים יותר מדי ספריות צד שלישי המסתמכות על גרסאות ספציפיות של ספריות אחרות, אנו יכולים בקלות להיתקל במצב בקושי לניהול כאשר אנחנו רוצים לעדכן, כמו אלה תלות הבת במקרים רבים שאינם תואמים זה את זה.
הגיהנום תלות ניתן לפתור באמצעות מנהלי החבילה כי הם מסוגלים לעדכן בחוכמה תלויות הדדית. אם אנחנו overwhelmed יותר מדי על ידי הבעיה, refactoring יכול גם להיות רעיון טוב.
4. קוד ספגטי
“קוד ספגטי” הוא כנראה האנטי-טטרנינג המפורסם ביותר. זה מתאר יישום שקשה לנטרל או לשנות בגלל היעדר ארכיטקטורה ראויה.
התוצאה של עיצוב תוכנה ירודה היא חבורה של קוד דומה במבנה לקערה של ספגטי, כלומר. סבוך ומפותל. הקריאה של קוד הספגטי היא נמוכה מאוד, וזה בדרך כלל משימה כמעט בלתי אפשרית להבין איך זה בדיוק עובד.
קוד ספגטי בדרך כלל נובע מן שילוב של שיטות קידוד רע שונות, כגון קודים שאינם מכילים בלוקים מותנים כראוי, עם הרבה הצהרות goto, חריגים, וחוטים, המכילים חלקים השייכים למקום אחר, יש יחסים מינימליים בין אובייקטים, יש פונקציות או שיטות שלא ניתן לעשות בה שימוש חוזר, או לא מתועד כראוי או בכלל.
5. תכנות לפי תמורה
“תכנות על ידי תמורה” או “תכנות במקרה” קורה כאשר אנו מנסים למצוא פתרון לבעיה על ידי ניסויים עוקבים עם שינויים קטנים, בדיקה והערכת אותם אחד אחד, ולבסוף יישום אחד שעובד בהתחלה.
תכנות על ידי תמורה יכול בקלות להציג באגים חדשים לתוך הקוד שלנו, גרוע מכך, הם חרקים שאנחנו לא בהכרח מכירים בבת אחת. במקרים רבים, זה גם בלתי אפשרי לצפות אם הפתרון יפעל עבור כל התרחישים האפשריים, או לא.
6. העתק והדבק תכנות
“העתק והדבק תכנות” מתרחשת כאשר איננו עוקבים אחר עקרון קידוד אל תמשיך (DRY), ובמקום ליצור פתרונות גנריים, אנו מכניסים קטעי קוד קיימים למקומות שונים, ומאוחר יותר לערוך אותם כך שיתאימו להקשר הנתון.
נוהג זה תוצאות בקוד שחוזר על עצמו מאוד, כמו חלקים קוד שנוספו בדרך כלל שונים רק פערים קטנים.
העתק והדבק תכנות לא רק שבוצעו על ידי מפתחי טירון, אבל מנוסים מתכנתים כמו גם, כמו רבים מהם נוטים להשתמש בקודים קודמים שנבחנו מראש ובדקו היטב עבור משימות ספציפיות, אשר יכול בקלות להוביל חזרות לא מכוונות.
7. מטען- Cult תכנות
השם של “תכנות פולחן מטען” נובע מתופעה אתנוגרפית ספציפית הנקראת “כת מטען”. כתבות מטען הופיעו בדרום האוקיינוס השקט לאחר מלחמת העולם השנייה, כאשר הקשר הכפוי עם תרבויות מתקדמות הובילו את הילידים לחשוב שמוצרים מיוצרים, כגון קוקה קולה, טלוויזיות ומקררים שהובאו על ידי אוניות משא לאיים, נוצרו על ידי טבעי שיטות; ואם הם מבצעים טקסים קסומים הדומים למנהגי המערב, המטען המלא בסחורה יבוא שוב.
כאשר אנו מבצעים את האנטי-אפטרן של תכנות כריתת מטען, אנחנו בעצם עושים את אותו הדבר. אנו משתמשים במסגרות, ספריות, פתרונות, תבניות עיצוב וכו 'שפעלו היטב עבור אחרים, בלי להבין מדוע אנו עושים זאת, או איך טכנולוגיות אמר בדיוק.
במקרים רבים מפתחי רק בטקסיות לעשות מה שהוא באותו זמן ללא כל מטרה אמיתית. בפועל זה לא רק רע כי זה עושה את היישום שלנו bloated bloated, אבל זה יכול גם בקלות להציג באגים חדשים לתוך הקוד שלנו.
8. זרימת לבה
אנחנו מדברים על “זרם לבה” antipattern כאשר אנחנו צריכים להתמודד עם קוד כי יש חלקים מיותרים או באיכות נמוכה כי נראה אינטגרלי לתוכנית, אבל אנחנו לא לגמרי מבינים מה זה עושה או איך זה משפיע על היישום כולו. זה עושה את זה מסוכן להסיר אותו.
זה קורה בדרך כלל עם קוד מורשת, או כאשר הקוד נכתב על ידי מישהו אחר (בדרך כלל ללא תיעוד מתאים), או כאשר הפרויקט עבר מהר מדי מן הפיתוח לשלב הייצור.
שמו של האנטי-אפטרן נובע ממראהו עם לבה שמגיעה מהרי געש, כלומר בהתחלה הוא נע במהירות ובזריזות בלי לנקוט באמצעי זהירות רבים מדי, אך מאוחר יותר הוא מתמצק ונעשה קשה להסרה.
בתיאוריה, אנחנו יכולים להיפטר לבה זורם עם בדיקות מקיפות ו -, אבל בפועל, היישום הוא לעתים קרובות קשה או אפילו בלתי אפשרי. כמו זרמי לבה בדרך כלל יש עלויות ביצועים גבוהים, עדיף למנוע אותם על ידי הגדרת ארכיטקטורה מעוצבת היטב זרימת קול מההתחלה.
9. קידוד קשה
“קידוד קשה” הוא אנטיפטרן ידוע נגד רוב ספרי הפיתוח באינטרנט מזהיר אותנו ממש בהקדמה. קידוד קשה הוא הנוהג האומלל שבו אנו מאחסנים תצורה או נתוני קלט, כגון נתיב קובץ או שם מארח מרוחק, בקוד המקור במקום לקבל אותו מקובץ תצורה, מסד נתונים, קלט משתמש או מקור חיצוני אחר.
הבעיה העיקרית עם קוד קשה זה זה עובד רק כראוי בסביבה מסוימת, ו ב בכל פעם שהמצב משתנה, אנחנו צריכים לשנות את קוד המקור, בדרך כלל במספר מקומות נפרדים.
10. קידוד רך
אם אנחנו מנסים מאוד קשה כדי למנוע את pitfall של קידוד קשה, אנחנו יכולים בקלות לרוץ לתוך antipattern נוסף שנקרא “קידוד רך”, וזה בדיוק ההפך.
ב קידוד רך, אנחנו שמים דברים שצריך להיות בקוד המקור למקורות חיצוניים, לדוגמה, אנו מאחסנים לוגיקה עסקית במסד הנתונים. הסיבה הנפוצה ביותר מדוע אנו עושים זאת, היא החשש כי הכללים העסקיים ישתנו בעתיד, ולכן נצטרך לכתוב מחדש את הקוד.
במקרים קיצוניים, תוכנית רכה מוצפנת יכולה נעשים מופשטים ומפותלים עד כדי כך שאי אפשר כמעט להבין זאת (במיוחד עבור חברי צוות חדשים), מאוד קשה לשמור ו Debug.
