7 הבעיות המטרידות ביותר בתכנות

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

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

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

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

ריבוי השחלות

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

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

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

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

סגירות

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

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

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

נתונים גדולים מדי

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

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

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

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

NP-complete

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

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

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

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

בִּטָחוֹן

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

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

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

הצפנה

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

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

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

ניהול זהות

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

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

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

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

מדידת קשיות

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

מאמרים קשורים

  • הורדה: מדריך לפיתוח קריירה למפתחים
  • כוחה של תכנות עצלן
  • 7 רעיונות תכנות גרועים שעובדים
  • 9 הרגלי תכנות גרועים שאנחנו אוהבים בסתר
  • 21 מגמות תכנות חמות - ו 21 מתקררות
  • הורדה: מדריך ההישרדות העסקי של המתכנת המקצועי
  • הורדה: 29 טיפים להצליח כמפתח עצמאי
  • 7 שפות תכנות שאנחנו אוהבים לשנוא
  • 5 שיעורים נצחיים נוספים של תכנות 'זקן אפור'
  • 22 עלבונות שאף מפתח לא רוצה לשמוע
  • 9 תחזיות לעתיד התכנות
  • 13 כישורי המפתח שאתה צריך לשלוט בהם עכשיו
  • תכנת את העולם: 12 טכנולוגיות שאתה צריך להכיר עכשיו
  • התקפה של שפות התכנות באות אחת