בתשובה לאייל קורא, 07/02/04 23:45
 |
|
 |
||
|
||||
 |
שכחתי להגיב על הנקודה הכי מעצבנת בהערה שלך: "קוד לא נועד לבני אדם, הוא נועד למחשב?" אתה צוחק?? קוד מכונה נועד למחשב, קוד שפה נועד לבני אדם בראש ובראשונה! אתה שוכח מי משרת פה את מי. קוד אמור להביע את העיצוב, לא לרצות את הקומפיילר או המעבד. פי אלף יותר חשוב שהקוד יהיה יפה (במיוחד קריא) מאשר שיהיה יעיל. יעילות אפשר לשפר. קוד מכוער אפשר רק לזרוק. |  |
 |
 |
|
|
|
||
|
||||
|
"תיק עיצוב" נועד לבני אדם. וקוד נועד *למחשב*. מה לא ברור? אם היית יכול להזין את תיק העיצוב לקומפיילר ולקבל תוכנה - אשריך. בעולם האמיתי צריך לתרגם את העברית והציורים המטופשים לשפה שמחשבים (קומפיילרים) מבינים. התרגום הזה, שהוא כנראה החלק הכי מסובך ויצירתי בפיתוח, זה בדיוק החלק של הקידוד. העיצוב (כתהליך נפרד, לא העיצוב האמיתי שנעשה תוך כדי הקידוד) בסך הכל מטיל עוד כמה אילוצים על המתכנתים, לטובת האינטגרטור (שגם הוא, בסופו של דבר, מתכנת). "קוד אמור להביע את העיצוב"? העיצוב לא מכסה אפילו עשירית מעושר ההבעה שיש לקוד. אתה מציג כאן גישה דינוזארית במיוחד. באקסטרים פרוגרמינג, למשל (אתה העלית את המתולוגיה הזו בדיון הזה, לא?) מתבססים בדיוק על זה. מעצבים "עשרים שניות" קדימה, ורק אחרי הקידוד, משנים את העיצוב בהתאם. אי אפשר לעצב (לעצב *באמת*) "באוויר" בלי לקודד בפועל במקביל. זו חישוביות אלמנטרית. אני אולי לא מבין למה אתה מתכוון בקוד "יפה". קוד "טוב" בעיני הוא מינימליסטי (מנצל את מלוא הכלים של השפה, לא מכיל פעולות מיותרות ברמת שפת-על), יעיל (לא מכיל פעולות מיותרות ברמת שפת מכונה) וגמיש (מודולורי. קל לשנות את הפונקציונלית, בגבולות אפיון הפרוייקט, במינימום שינויים בקוד). קוד שמקיים את שלושת הדברים האלה (ומבטיח תהליך פיתוח בדיקות חלק עד כמה שאפשר, וכידוע - *תמיד* יש שינויים בדרישות תוך כדי הפיתוח, ותמיד מעגל התיקונים-בדיקות עד לשחרור המוצר הוא החלק הבעייתי והארוך ביותר) בדרך כלל מאד לא "קריא" (במובן שקל להבין אותו בקריאה שטחית). |
|
|
|
|
|
|
||
|
||||
|
אקסטרים פרוג' זה מתודולוגיה מאוד מגוונת, אני לא מסכים עם כל מה שנאמר שם. הגישה שאומרת שיש לתכנת את "המינימום שעובד" לא מקובלת עלי. יצא לך לעבוד פעם עם Rose? זה שופך לך קוד VB מתוך עיצוב UML. אני מכיר חברה שעבדה כך. התוכניתנים פעלו כמו drones שמילאו את המעט החסר בין תחילת הפונקציה וסופה. 90% מהפרויקט היה תוצר ישיר של עיצוב. לא שזה _ה_דרך לתכנות, זה דווקא מאוד חריג, אבל עיצוב ותכנון מוקדם זה לא גישה דינוזאורית ולא בטיח. מי שלא מעצב משלם אח"כ בקידוד מחדש. עיצוב נכון זו לא פריוילגיה של מי שלא צריך לעמוד בלו"ז צפוף, להיפך הוא זה שמאפשר לאותם אנשים לעמוד בלו"ז. לגבי מה שאמרת שיכולת ההבעה של הקוד לא מכוסה ע"י העיצוב, זה כבר לא נכון. היום כמעט כל השפות הם interchangable? לכל אחת יש את הנישה שלה, ויש גם תחרות החלק מהנישות, אבל בתכלס כל מה שניתן לכתוב ב c++ אפשר לכתוב גפ בליספ או vb. תסתכל על .net למשל, זה מדגים בצורה נפלאה איך בחירה של שפה זה לא יותר מחירה של כלי. נניח שאנחנו עובדים בפרוקייט c++י. ברמת הצוות מתקבלת ההחלטה איך מנהלים זכרון, מה סגנון הטקסט (מבחינת צורה והערות), מה מדיניות טיפול בשגיאות, מה מדיניות ירושה, שימוש בגלובליים, תכנון הידרים, מדיניות לוגים, איך ניגשים לDB, באיזה ספריות רשת משתמשים. הכל הכל הרי נקבע (או צריך להקבע) ברמת העיצוב. מה נשאר למתכנת לעשות? לממש. ולעשות את זה בצורה שקל יהיה לראות כיצד העיצוב של המערכת בא לידי ביטוי. הגישה שלמתכנת יש קארד בלאנש לעשות מה בזין שלו כל עוד זה עובד ויש מספיק הערות פשוט לא מחזיקה מים. שעה של תכנון עדיפה על יום של עבודה, וזה עוד יחס נדיב... |
|
|
|
|
|
|
||
|
||||
|
בוודאי שיצא לי לעבוד עם Rose, ולמעשה זו דוגמא מצויינת: אני מאמין שמדרך הטבע, אלה שעומדים מאחורי התוכנה יודעים די והותר על עיצוב תוכנה (ואם זכרוני אינו מטעני, GoF בכבודתם ובעצמם קשורים ל-Rational), ולמרות זאת, כל מי שאי פעם שיחק איתה 10 דקות למד בדרך הקשה עד כמה המימוש שלה גרוע. ואתה עוד מספר שיש מישהו שבאמת משתמש בפיצ'ר הקיקיוני של תרגום דיאגרמות לקוד? אני מוכן להמר על מיטב כספי שהמוצר הסופי שאותה חברה חסרת אחריות שחררה גרוע מעבר לכל דמיון (חיזוק להשערה: הם כותבים ב-VB). אני לא טוען שעיצוב תוכנה זה תהליך מיותר, חס ושלום. אני טוען שעיצוב הוא חלק בלתי נפרד מהקידוד, ושתהליך עיצוב *טוב* איזמורפי לגמרי לקידוד, ולכן ההפרדה בינהם מיותרת. קידוד זה לא רק "שפיכת קוד". בעוד שעיצוב - במובן בו אתה מתייחס אליו - מדבר במונחים של תהליכים, וישויות ויחסים בינהן - קידוד מכיר במגבלות ויתרונות ספציפיים של סביבת הפיתוח, ומתייחס גם אליהם. לעיתים (לעיתים? תמיד!) יש לכך השפעה גם על הדרך בה המודלים השונים בתוכנית יתקשרו ביניהן, ועל ישויות נוספות (או מיותרות) שכדאי או לא כדאי לממש. ברור ש*חישובית* כל שפות התכנות שקולות. אבל מנקודת מבט של מתדולוגיה או יעילות - הן בפירוש לא. Interchangeable? אני לא עבדתי מעולם על תוכנה שהיה אפשר לתכנתה ב-VB באותה מידה שהיה אפשר ב-++C, ועל תוכנה שהיה אפשר לתכנת ב-++C באותה מידה שהיה אפשר לתכנת ב-C. וזה עוד בלי להכנס לשיקולי אסתטיקה וכבוד עצמי... הקידוד והעיצוב צריכים להעשות על ידי כל הצוות (ובפרט על ידי המתכנת והרש"צ), ובאותו זמן. ההפרדה היא מלאכותית. מניסיוני תמיד כשניסו קודם לעצב הכל, ואז לקודד הכל (כבר שנים שלא ראיתי את זה קורה) - אף פעם העיצוב והקוד המוגמר לא היו קשורים במיוחד (תמיד באשמת העיצוב, אף פעם לא באשמת המעצב). |
|
|
|
|
|
|
||
|
||||
|
כמו שאמרתי, לעבוד עם הקוד שרוז שופך זה באמת קיצוני. וכן, החברה ההיא נכשלה (אם כי יותר מסיבות אחרות). השקילות של שפות התכנות היא בכלל לא במובן החישובי. כל דבר ניתן היום לתכנת בכל שפה. נניח שיש לך ספריות מקומפלות רק ל C++, אבל את הGUI וכל מיני דברים אחרים אין לך כוונה לכתוב ב C++, אז עוטפים ומסתדרים. קונסטריינטס מהבחינה הזו הם לא כזה בעיה. ברוב המקרים בחירת השפה היא תוצר של כוח האדם ולא להיפך, עד כמה שזה מאכזב לשמוע. והזלזול שלך בVB לא במקום, זו סביבת פיתוח עם ה User base הכי גדול (וא כמעט הכי גדול) מכולן. כל דבר ניתן לכתוב עם VB, ובמיוחד עכשיו עם .net, בדיוק בגלל שהframework שלהם עובד עם ה CLR לכל שפה. והרשימה של השפות בפעם האחרונה שבדקתי הייתה ארוכה ומרשימה. אין שום ספק שלכל שפה יש את הפורטה שלה אבל, כפי שאמרתי, כל ההחלטות המעניינות מתקבלות ברמה גבוהה יותר. ולא טענתי שתוכניתנים לא צריכים להשתתף בעיצוב, להיפך. אלא שזה שלב נפרד. כמו כן, אני מסכים שלא ניתן לתכנן _הכל_ מראש, אבל ברגע שעולות סוגיות בעייתיות פותרים אותן ברמת החלטה עיצובית ולא ברמת התוכניתן. אי אפשר שלכל אחד בצוות יהיה קוד משלו לתקשורת, לטיפול בשגיאות וכו'. "או, רגע הקוד הזה פה מעיף exception, טוב אז אני אטפל בהן ככה וככה..." זה לא רציני. סוגיות שכאלה הן קריטיות לעיצוב וההחלטות לא שייכות לתוכניתן ככזה, אלא למעצב. אלו דברים שצריכים להקבע ברמת מדיניות ולהיכתב פעם אחת. לכן, אלא אם כן אתה כותב איזה ספריית קוד ואז הדגש על השפה עצמה הוא המירבי, רוב התכנות שנעשה הוא רק מימוש. בכלל רוב התכנות האפליקטיבי הוא יותר חיווט של דברים קיימים מאשר פיתוח מקורי. 99% מכל פרויקט זה לחבר דברים קיימים ביחד ורק השארית היא איזה אלגוריתם או פרוטוקול מקורי. זה בדיוק הסיבה שהדגש בתכנות צריך להיות על מתודולוגיה ולא על מומחיות מקסימלית ביעילות וכו'. יעילות תמיד אפשר לשפר, כאמור. |
|
|
|
|
|
|
||
|
||||
|
בטכניון ישנם שני קורסים העובדים לפי עקרון התכנון בנפרד מן התכנות. אלה פרוייקטים שנתיים: בסמסטר הראשון עובדים על תכנון ועיצוב, בסמסטר השני על כתיבה, הידור, וניפוי שגיאות. אין לי יותר פרטים לספק לך. |
|
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |