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

זה ממש מתסכל :x

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

יש לי מבנה קבוע למערכות ב-PHP (ככה שאין ממש "וויכוח פנימי" בנושא), אבל אני בכל מקרה משתדל לא להשתמש בשפה הזאת כשיש ברירה

לאו דווקא PHP, אלא כל מערכת שבונים בכל שפה.

אבל נניח PHP, אז למה דוקא MVC זה המודול הפופולרי ביותר?
לענ"ד הוא לא טוב מספיק, הוא לא בנוי נכון, יש שימוש במחלקות שלא לצורך.
מצד שני מה שנדמה, בינתיים, כ-הכי טוב, נראה גם מסורבל יחסית ולא מקובל, שזה השיטה הפרוצדוראלית ("הכל עם פונקציות" \ anti-OOP).
מצד שלישי, במקרים שונים - בלי פונקציות כלל אולי יהיה עדיף...

האם אתה שואל באיזו דרך לממש את האלגוריתם שלך?

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

או שמא האתגר שלך הוא באיזה אלגוריתם בכלל להשתמש על מנת לפתור את הבעיה?

ואולי אתה מתלבט מה לממש בעצמך ומה להעביר למערכות צד-ג' שיבצעו עבורך?


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

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

או כמו שאמר פעם סיני חכם: "האוייב של הטוב הוא המצויין"

_________________________________________________

אזהרה: משרד הבריאות קובע כי העישון מזיק לבריאות !
תראו, אפילו החייזר נהיה ירוק מזה

מנהל פורום מדע בדיוני ופנטסיה ופורום מדע טכנולוגיה וטבע בפרש

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

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

ציטוט:

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

ציטוט:

או כמו שאמר פעם סיני חכם: "האוייב של הטוב הוא המצויין"

אכן זה משפט שממומש אצלי כל הזמן...

---
הדגש הוא על תיכנון מערכת שתהיה בנויה בצורה נכונה.

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

זה באמת מתסכל, כי את כל הידע שאני צריך יש לי כבר מזמן.

אפשר קישור למדריך?

אני משתמש באתר הזה בסעיף של Game Engine. הקוד שלו לא הכי טוב, אבל בינתיים איך שהוא מסדר את כל המערכת נראה לי בסדר גמור (במיוחד כי כבר הבארתי שלי אין שמץ של מושג איך עושים דברים כאלה).
אה ועם זה לא ברור עדיין, זה לC++.

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

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

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

בברכה, מתן.
www.MatanNarkiss.com

לא מכיר UML.
סליחה אם הטעתי: לא התכוונתי שצריך לשכוח לגמרי מ-OOP, אלא התכוונתי שיש מקרים שבהם אנשים משתמשים בתכונות ה-OOP של השפה כשלמעשה אין שום צורך.
דוגמא מעולם ה-Web: אפליקציית PHP שרובה המוחלט בנויה ממחלקות, כשמכל מחלקה מייצרים instance אחד, או לפעמים לא מייצרים כלל ואז ניגשים למאפייניה בצורה הסטטית ( :: ).
בלי קשר אם זה יותר יעיל או נוח - האם זה בנוי נכון?
אני חושב שבעקבות בנייה נכונה, לבסוף בתמונה הגדולה הקוד יהיה יעיל ונוח יותר לקריאה ופיתוח בעתיד.

ציטוט:

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

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

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

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

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

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

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

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

בברכה, מתן.
www.MatanNarkiss.com