למה (ואיך) אני כותב קוד עם עיפרון ונייר

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

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

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

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

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

למה לרשום את זה?

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

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

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

בוא נראה איפה אנחנו יכולים להתחיל בכל הנוגע לקוד כתב יד.

דע את השאלה שלך

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

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

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

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

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

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

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

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

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

תאר את הקוד שלך

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

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

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

1. ממשק משתמש ללכידת חתימה - HTML Canvas? WebGL?
2. השבת אירועי מצביע בשאר דף האינטרנט כאשר המשתמש חותם
3. המר ושמור את התמונה שנלכדה לקובץ PNG - JS
4. לאחר מכן המר אותו ל-blob (אולי) ושמור אותו בטבלת נתוני היומן של המבקר.

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

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

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

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

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

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

אורך יד לעומת קצר יד

הגיע הזמן להתחיל בקידוד. אז מה אתה כותב? "Bdrs" או "border-radius"; "div -> p"או"<div><p></div></p>"; "pl()"או"println()"; "q()"או"querySelector()"

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

זה באמת תלוי בך.

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

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

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

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

זרימת הקוד הלא רציפה

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

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

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

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

1. קבלו את הקלט.
2. חשב את מספר פיבונאצ'י.
3. סכמו את הפלט.
4. הדפס את הפלט.

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

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

הקדישו את זמנכם לכתיבת קוד שמתמקד בלב הבעיה.

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

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

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

קוד פסאודו

כריס כבר כתב א מאמר שימושי על פסאודו-קוד שאני מאוד ממליץ לך לקרוא מוצק.

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

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

הנה כמה פסאודו-קוד מהיר לפריסת רשת CSS:

Grid
5 60px rows
6 100px columns

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

מקום והערות

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

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

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

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

אנלוגי מול דיגיטלי

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

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

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

הכלים האהובים עליי לקוד כתב יד

כל עיפרון ונייר יצליחו! אבל יש הרבה אפשרויות בחוץ, ואלו כמה כלי בחירה שאני משתמש בהם:

אין דרך "כתיבה" לקוד

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

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

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

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