קידוד מתחשב

מדוע קידוד הוא יותר ממיתרים של סמלים

קודן שמדבר על קוד

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

הפירמידות של Javascript

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

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

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

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

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

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

מנטליות של המכונאי

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

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

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

process.exit ();

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

  • Tom