סוד היעילות הוא קוד איכות, לא מנהל יעיל

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

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

אלה שהם הרוב.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקור: www.habr.com