This is the presentation I gave at Sela on 29/10/2018. It covers the importance of clean code and refactoring skills to productivity and business value
26. Important Skills
• Object-Oriented Design
• Clean Code
• Effective use of Exceptions and Logging
• Effective use of: programming language, base-class
libraries, IDE, and even the keyboard…
27. How We Can Improve?
• Awareness
• Code reviews and
pair-programming
• Get assistance…
28. Sela Services
• Planning and implementing gradual
architecture improvement
• Teaching and mentoring:
– Refactoring techniques
– Clean Code
– Effective use of IDE and tools
– Unit tests and TDD
• Helping implement effective code-reviews
• Improving Team and Project productivity
Editor's Notes
באתי מהכיוון של Clean code ו-Unit tests לתחום הבדיקות האוטומטיות. היום אני רוצה לחזור כי לדעתי שם נמצאות הבעיות האמיתיות...
עם זאת, אם לומדים להשקיע את "האנרגיה" הזו בצורה נבונה קצת-קצת לאורך הדרך, אז צריך להשקיע הרבה פחות ממנה בסה"כ.
הבדיקות האוטומטיות אמורות לפתור את הבעיה הזו, אבל הן לא לגמרי מצליחות בגלל שתמיד כמות הבדיקות שצריך עולה...
קוד ספגטי לא קשור הבכרח ל-Goto או למתודות ארוכות ומסובכות (כמובן שגם...), אלא בעיקר לספגטי של תלויות.
אבל אנחנו לא יכולים לזרוק את הישן עדיין...
אבל עד שאנחנו מסיימים, בינתיים אנחנו לא נותנים ערך נוסף ללקוח, ולכן אנחנו לא באמת מקיימים את ההבטחה של אג'ייל. כמובן שלקוח לנו יותר זמן ממה שחשבנו, וברגע שאנחנו עולים לאויר עם הגרסה החדשה, מתגלות הרבה תקלות ובעיות ופערים מול הגרסה הישנה. ואז יש תקופה של תחזוקה של שתי מערכות (הישנה והחדש) זו לצד זו, שלא נוחה לא למפתחים ולא למשתמשים, עד שבהדרגה מצליחים למזג ביניהם.
דוגמאות למעבר בין טכנולוגיות וארכיטקטורות: WinForms WPF Angular React. ארכיטקטורה: Client/Server, 3-tiers, SOA/WCF, SOAP, REST, MicroServices, Containers, ענן וכו' וכו' וכו'...
העניין הוא שבכל טכנולוגיה אפשר להשתמש בצורה טובה יותר או פחות
מה שלא משתנה זה הנדסת תוכנה טובה ומיומנויות!
ואז קל יותר לעבור מטכנולוגיה אחת לשניה בלי לכתוב הכל מחדש.
(איך בדיוק עושים את זה - על כך בהרצאה השניה)
דוגמא: הוכחת נכונות של Merge Sort
ההבדל בין בדיקות לבין הוכחה
כשהקוד נקי יותר, יותר קל להוכיח (אפילו לעצמנו) שהוא נכון
וכשהוא לא, אז אנחנו עוסקים בניסוי וטעיה וזה הרבה פחות יעיל...
למה זה קורה?
לחץ של זמן
חוסר היכרות עם הטכנולוגיה
חוסר היכרות עם ה-Business domain
חוסר מודעות...
חוסר מיומנויות
החוכמה היא לשמור על קוד נקי ולסדר כל הזמן.
Refactoring זה לא לכתוב חלק מחדש!
כן - בהתחלה זה יכול קצת לעכב - אבל אם עושים את זה נכון ומתרגלים לעשות את זה כל הזמן, אז לא רק שנחסך זמן יקר מתישהו בהמשך, אלא גם כשכותבים את הפיצ'ר החדש, הרבה יותר קל לוודא שהוא עובד נכון, הסכוי לבאגים יורד, והזמן שמתבזבז על debugging נחסך.
מאיפה להתחיל?
כל פעם קצת, איפה שנוגעים.
במקום לכתוב מחדש, ניתן לפורר את המונולית, ובהדרגה להחליף את ה"אבנים" הישנות בחדשות
לפעמים כדאי להתחיל מעטיפה חדשה, ובהדרגה לשנות או להחליף חלקים בפנים.
זה מאפשר לנו להמשיך לפתח פיצ'רים חדשים ולשפר את המערכת באופן שיתן למשתמשים ערך מיידי, ולנו פידבק מהיר!
ההשפעה על לקוחות ועל מנהלים היא לטווח הרחוק יותר ומוסוות
קשה למדוד את ההשפעה
כתעשיה, אנחנו רצים כל הזמן אחרי הטכנולוגיות החדשות, בגלל שהחברות הגדולות רוצות למכור לנו אותם...