מיומנות המפתחים החיונית שתשפר את הקוד שלך

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

אמור לא לקוד מיותר. כל שעליכם לעשות הוא לחבר שלוש אותיות ולומר את המילה. בואו ננסה לעשות את זה ביחד: "לאווווו!"

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

אנו מזכירים: לכל קוראי Habr - הנחה של 10 רובל בעת הרשמה לכל קורס Skillbox באמצעות קוד ההטבה של Habr.

Skillbox ממליצה: קורס מעשי "Mobile Developer PRO".

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

ממה מתכנתים מעלימים עין?

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

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

לפי ריץ' סקרנט, הקוד הוא האויב שלנו. הנה מה שהוא כותב:

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

איך יודעים מתי לא לכתוב קוד?

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

עליך להבין בבירור מה הפרויקט שלך צריך ומה לא.

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

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

לעולם אל תאבד את המיקוד של היישום שלך.

שאל את עצמך תמיד:

— איזו פונקציה צריכה להיות מיושמת כעת?
- איזה קוד עלי לכתוב?

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

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

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

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

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

כעת עלינו להילחם על חיי הפרויקט. למה?

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

נשמע כמו תסריט של סרט אימה, נכון?

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

"אחד הימים הכי פרודוקטיביים שלי היה כשמחקתי 1000 שורות קוד."
- קן תומפסון.

קשה ללמוד מתי לא לכתוב קוד. אבל זה הכרחי.

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

המשיכו ליצור, אבל דעו מתי להגיד לא.

Skillbox ממליצה:

• קורס מקוון יישומי "Python Data Analyst".
• קורס מקוון "מפתח חזיתי מקצועי".
• קורס מעשי בן שנה "מפתח PHP מ-0 ל-PRO".

מקור: www.habr.com