מאושפזים בכפייה: רן מ-invi, איתי מ-Google, ערן מ-Outbrain, גילי מ-IBM (אבל דעותיו אינן מייצגות את החברה), אביב מ-BillGuard. בסוף גם ישי בא (QWallet).
- והנושאים להיום: פשטות בתוכנה וחדי-קרן. אם כבר פנטזיות אז עד הסוף. סתם, בלי חדי-קרן.
- הנושא עלה בעקבות פוסט של Avdi בעניין.
- פשטות היא עניין יחסי ותרבותי, תלוי מאוד למה מתרגלים וגם תלוי מאוד מי אמור לתחזק את הקוד וכמה היכרות יש בין הכותב לקורא.
- מתכנת אמיתי לא משתמט, הוא משכתב קוד מסובך בלילה (עדיף כשהוא נורא עייף) ובבוקר הכול שוב פשוט.
- קנט בק חושב שאתם מסבכים את הדברים. הקוד משקף את היכולת של כותבו להתמודד עם הסיבוכיות של הבעיה שאותה הוא פותר.
- מערכת מורכבת היא כזו שבה ישנן הרבה יחידות קטנות ופשוטות מחוברות יחדיו.
- 4 כללים לדיזיין פשוט. כן, רק ארבעה. פשוט, לא ? הפרחים לקנת בק.
- קוד פשוט נשאר כזה לאורך זמן, גם עוד שנה הוא יהיה פשוט (גם ובעיקר למי שכתב אותו …)
- קוד פשוט, בניגוד לרוב דיירי האח הגדול, יודע להסביר את עצמו מצוין
- פונקציונאליות פשוטה אפשר להסביר בקצרה.
- בשביל קוד פשוט אפשר לכתוב טסטים קצרים.
- אבדי והחבר'ה מדברים על קוד יפה. הם גם מתאהבים בקוד והקוד אוהב אותם. מה שנקרא - Get a (chat) room
- ישנם כלים המיועדים לנתח את הסיבוכיות של קוד.
- יישום קפדני של Coding conventions מקל מאוד על ההבנה של קוד.
- הרבה פחות נעים לחרב בניין יפה - וזה נכון גם לגבי קוד.
- תמיד קשה לגשר על פערי שפה.
- האם יש מדדי נחשלות לחברות תוכנה (הי, את זה אני הצעתי !) ? מיילים, מדדי סיבוכיות קוד, כמה קוד מכסים הטסטים, כמות שעות דיבוג, כמות ההערות בקוד, כמות האיתחולים מחדש של שרתים, כמה ישיבות יש בשבוע, כמה זמן לוקח לגלות שהקוד שבור, כמה רועשת סביבת העבודה, האם אתם משתמשים בכלים הכי טובים וכו' וכו'. גם לג'ואל ספולסקי יש מה לומר בעניין.
קצרים
- שפה חדשה - JuliaLang, טובה בעיקר לחישובים מתימטיים, טובה גם למעבדה וגם לפרודקשיין. ממש האישה המושלמת.
- אתר מגניב שנותן את כל המידע שהוא יכול להסיק לגבי הטכנולוגיות שאיתן נבנים אתרים ספציפיים: builtwith.com
- Less - פלטפורמה להקלה על העבודה עם CSS
הקובץ נמצא כאן האזנה נעימה
תודה רבה ליותם אורון על התקצור!
כמה מילות הבהרה בקשר למדדי נחשלות. נחשלות, או Backwardness, מייצגת בעצם כמה אנחנו רחוקים ממה שקורה היום, מהצורה שבה עובדים היום (אגב, הדוגמה של הצבא הגרמני באה במאמר שדיבר על צה"ל ועל זה שמדד שנחשלות שלו הוא כמות השיריון - יענו, טנקים - שיש לצה"ל. כמה מרגיע). כשחושבים על זה ככה, אין בעצם מדדי נחשלות שמחזיקים מעמד לאורך זמן. גם זה עניין יחסי. מדד אחד כזה היום, לדוגמה, הוא כמות הקוד שמפותח Inhouse לעומת כמות הקוד הפתוח שבו החברה משתמשת. לפני 15 שנים המדד הזה היה לא רלוונטי לחלוטין, היום כולם עובדים עם קוד פתוח.
השבמחקהרעיון הוא לחשוב גם בכיוון הזה, כל הזמן לשים לב מה קורה בסביבה הרלוונטית לתחום ולחברה (CI ו-CD הם מושגים רלוונטיים לחברות SaaS, אבל אין להם משמעות לחברות שמוכרות רישיונות של תוכנה).
יותם.
פרק מעניין ונושא חשוב. אני נתקבל בהתלבטויות בנושא צורת הקוד, פשטות, קריאות וכמובן ביצועים בצורה יומיומית.
השבמחקנושא שעלה רק בקצרה בפרק הוא שימוש בספריות או Framework על מנת לפשט את הקוד. במקרה של Framework תמיד יש tradeoff בין לכתוב משהו לבד ולכאורה להבין הכל לבין להשתמש במשהו קיים ולהתמודד עם עקומת למידה. מנסיון שימוש בframework קיים כמעט תמיד עדיף כי הזמן שלוקח ללמוד משהו בדרך כלל קצר יותר מלגלות ולפתור את כל הבעיות מהתחלה.
אצלינו משתמשים בCode Review ככלי חשוב לשמירה על איכות הקוד, הצורה שלו ולימוד משותף של נושאים.
בקשר לנושא השני של נחשלות לא מפתיע שאין מדדים כמותיים כי הנושא אינו מוגדר היטב ויש לדעתי אינטרס לאנשים או חברות לשמור על הנושא מעומעם משום שמה שנחשף ממנו בדרך כלל הן בעיות. אני אשמח לשמוע עוד דברים בנושא הזה ולהעמיד את עצמי במבחן, התוצאה תיהיה מעניינת גם אם לא נעימה.
תודה על הפרק,
עידו
הפעם נבצר ממני להשתתף אבל שמעתי את הפרק ורציתי להוסיף מדד נחשלות עכשוי:
השבמחקכמה אנשים צריך לעבור בין בעית פרודקשן ועד הבן אדם שיכול לתקן אותה.
Ori you probably mean the metric of MTTR (Mean Time To Repair)
השבמחקAnother one I forgot to mention is the Bus Factor
השבמחקhttp://en.wikipedia.org/wiki/Bus_factor
יש הרצאה מאירת עיניים של Rich Hickey (אבא של Clojure) על פשטות. הוא נותן הגדרה אובייקטיבית, מבדיל בין פשוט לבין קל, ומציע דרכים איך להקל על כתיבת קוד פשוט (בהתאם להגדרתו).
השבמחקhttp://www.infoq.com/presentations/Simple-Made-Easy