ערב טוב לכולם.

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

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

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

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

תודה רבה מראש.

אני לא ירחיב מטעמים שלי אבל בגדול אלה השלבים

1. ניתוח מערכת (תיק איפיון)

2. עיצוב המערכת (תיק עיצוב)

3. כתיבת הקוד

4. בדיקות מערכת (יחידה ותוכנה)

5. שינוי ושיפור

6. תחזוקה

כמובן שעבודה נכונה כזו דורשת יותר זמן אבל זה ימנע ממך לכתוב כל פעם מ0

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

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

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

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

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

בהצלחה

אוקי סבבה זה אני דיי מבין, אבל לדוגמא למה הכוונה במודול? מה זה בעצם מודול? מה הוא כולל בתוכו?

לדגומא מערכת תגובות יכולה להיחשב כמודול? אם כן האפשרויות שלה יכולות להיות לדוגמא: הוסף תגובה, מחק תגובה, ערוך תגובה?

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

שוב תודה רבה מראש.

לי יש דרך חלוקה משלי למודולים..

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

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

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

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

דוגמה מובהקת לאתר שמשתמש במודולים הוא FACEBOOK, כאשר להן הוא קורא APPLICATIONS, למשל יש לו אפליקציה של תמוונת, אפליקציה של קבוצות, אפליקציה של הודעות וכו'

אני הייתי בבעיה דומה לא מזמן (ועדיין נמצא בעצם).

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

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

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

אני לא ירחיב מטעמים שלי אבל בגדול אלה השלבים

1. ניתוח מערכת (תיק איפיון)

2. עיצוב המערכת (תיק עיצוב)

3. כתיבת הקוד

4. בדיקות מערכת (יחידה ותוכנה)

5. שינוי ושיפור

6. תחזוקה

כמובן שעבודה נכונה כזו דורשת יותר זמן אבל זה ימנע ממך לכתוב כל פעם מ0

מישהו עושה קורס תכנות בצה"ל.. הא?

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

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

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

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

yochze

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

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

Jaman

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

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

Aurora Borealis

חח אז זו הסיבה שהוא לא יכל לפרט יותר

אוקי הבנתי את הרעיון של הוא דיי דומה לרעיון של yochze.

תודה רבה על התגובות, תגובות נוספות יתקבלו בברכה.

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

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

http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

אצטט חלק מהערה של מישהו על הנושא:

I think what Ravi is trying to illustrate (Ravi, do correct me if I am

wrong)is the difference in the quality of thought between the two programmers.

Ron's thought process (as expressed in his writing) is terribly woolly and sloppy (I shudder to think what that kind of sloppy thinking would result in in my field - Physics). He wanders around for a long period of time, without any deep analysis of the problem, falls into all sorts of pits on the way, and finally solves about a quarter of the problem. Ron is thinking like some kind of mad alchemist, throwing random elements into the pot, stoking the fires and waiting to see if the lab to blow up.

Peter's thought process moves implacably from analysis to design to code and back till the *whole problem* is solved.

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

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

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

בגישה שתיארתי אני אכן מכיר את כל הבעיות שיש לפני ואני יוכל (יש לי כלים, אלגוריתמים) לפתור את רובן.

אני לא ממש מבין למה הכוונה ב"בעיה". לבנות אתר יכול להיחשב כ"בעיה"? לדעתי יש לי כמה בעיות במערכת וכאשר כולן יקבלו פתרון אני מקבל מערכת שפועלת.

זה מזכיר לי את אלגוריתם פיינמן לפתרון בעיות בפיסיקה:

1) כתוב את הבעיה.

2) תחשוב ממש הרבה.

3) כתוב את הפתרון.

ברור שהבעיות במערכת שלך יפתרו כאשר אתה מקבל מערכת שפועלת. זה לא קונסטרוקטיבי.

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

בגישה שתיארתי אני אכן מכיר את כל הבעיות שיש לפני ואני יוכל (יש לי כלים, אלגוריתמים) לפתור את רובן.

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

אוקי יש לי הבנה סבירה של מה המערכת צריכה לעשות ואיך היא תעשה את זה.

מה הלאה?

זה לא כ"כ פשוט. זה דווקא תהליך ארוך ומורכב.

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

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

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

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

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

תודה רבה!