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

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

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

שכירת קודאי גיבוי

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

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

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

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

עריכת ביקורות קוד

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

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

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

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

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

הימנעות מקודנים זדוניים

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

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

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

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

• מה לעשות כשפרצו לך מה לעשות כשפרצו לך
• 6 דברים שלא לעשות לאחר הפרת נתונים 6 דברים שלא לעשות לאחר הפרת נתונים
• פלורידה סיטי תשלם 600, 000 $ להאקרים לאחר התקפת Ransomware פלורידה סיטי תשלם 600, 000 $ להאקרים לאחר התקפת Ransomware

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

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