תומרקוד

פעמים רבות כשאנחנו מתחילים פרויקט איננו יודעים מה יהיה גודלו הסופי, כמה מחלקות הוא יכיל, ואיך יראו התלויות. לפעמים, כמה שלא ננסה לתכנן את הכל מראש, נגיע למצב בו אנחנו רוצים להפריד חלק מה-codebase שלנו לפרויקט נפרד. הסיבות לכך יכולות להיות: 1. ניסיון לשמירה על single responsibility principle (כן, הוא לא נכון רק לפונקציות ומחלקות) 2. עובדים על הפרויקט כבר יותר מדי אנשים וביצוע פעולות גיט מרובות לאותו פרויקט על ידי הרבה אנשים יכול ליצור לא מעט צרות וקונפליקטים. 3. לפעמים, בתוך באותה חברה נרצה שמספר צוותים יעבדו על (או ישתמשו ב) אותו פרויקט. 4. במקרים מסוימים אפילו נרצה לקחת חלק קטן מהקוד שלנו (לדוגמה פעולות אוטומציה נפוצות) ולהוציא ל open source. מטרת הפוסט הזה הוא להציג שלושה נושאים: הראשון - הפרדת הפרויקט לתתי פרויקטים  השני - מתי נרצה להשתמש ב submodules? השלישי - צריכת תתי הפרויקטים באמצעות git submodules. הערת צד: אינני הולך לדבר על מימוש ההפרדה עצמה, הפוסט מניח שהקורא יודע לפתוח פרויקט, להזיז קבצים אל הפרויקט החדש ולדחוף אותו ל source control. איך מ

בחמש השנים שאני כותב קוד, יצא לי לקרוא לא מעט קוד רע ולכתוב אפילו יותר קוד רע. אם אני צריך לקחת את כל חתיכות הקוד הרעות שכתבתי ולמצוא מה משותף לכולן - כנראה שהתשובה תהיה כמות הפרטים בשכבות האבסטרקציה העליונות. מטרת הפוסט הקרוב היא להעביר באופן קצר וקולע, מה היא הדרך היחידה בעיני לכתוב קוד טוב ואיך לגרום לזה לקרות כמעט כמו קסם. ראשית לפני שאתם קוראים - חשוב שתדעו, אני לא מחדש שום דבר בפוסט הזה. כל מה שאני הולך להגיד ומרבית התורה מבחינתי בנוגע לפיתוח תוכנה מונחית עצמים כבר רשומה בפוסט על top-down programming ובפוסטים על solid principles . אמנם בחרתי לפוסט הזה כותרת מפוצצת ומתלהמת, אבל ברור לי שהעולם הוא לא שחור ולבן ולכל כלל יש יוצא מן הכלל. אבל מבחינתי צריכה להיות סיבה מאוד טובה על מנת לצאת מן הכלל. עם הזמן וההתפתחות שלי בתור מפתח תוכנה למדתי עוד ועוד קונספטים של פיתוח מונחה עצמים והיום הם כולם מתחברים יחד באופן כמעט מושלם. ראיתי כמעט כל הרצאה וקראתי כמעט כל ספר של uncle bob , קראתי את כל המאמרים באתר של martin fowler , והיום, כשאני רואה קוד, באופן כמעט אוטומטי אני שם לב האם משהו ״מוזר