בתשובה לNik The Greek, 06/02/04 11:18
 |
|
 |
||
|
||||
 |
המשרה של הגב' חדד, אם להזכיר, לא הייתה בתחום התיכנות אלא של מנהל חשבונות ראשית. לעניין עצמו, המעסיקים אינם מסכנים, אך הם בעלי זכויות לא פחות מהמועסקים. אחת מהזכויות הללו היא היכולת לבחור גם את מי לא להעסיק. הערה בצד: ברוב המקרים כמות הזמן הנדרשת כדי לרכוש התמצאות בקוד קשורה בהיקפו ומורכבותו, לא רק בכמות ההערות שבו. השתלטות על קוד בהיקף גדול, במיוחד כזה השייך לפרויקט עצמאי, תיקח זמן רב גם אם הוא תוחזק למופת. |
 |
 |
 |
|
|
|
||
|
||||
|
לקוד טוב באמת אין כמעט זמן למידה. עיצוב זה דבר אחג, אלגוריתמים זה דבר שני וקוד זה דבר שלישי. להכיר את העיצוב של התוכנה צריך כל אחד בחברה (כמעט), את האלגוריתמים צריכים להכיר כל מי שבצוות או במדור הרלוונטי, הקוד צריך להיות נהיר מספיק כדי שניתן יהיה פשוט לקרוא אותו. בעיות חפיפה רציניות הן תמיד סימן היכר של ניהול לא נכון. | |
|
|
|
|
|
||
|
||||
|
שאתה מדבר שטויות. פונקציית התועלת של תוכנה אינה מגיעה בהכרח למקסימום (בעצם, כמעט אף פעם לא) כשהיא מפותחת באופן אותו אתה מתאר וישנם שיקולים רבים אותם צריך המנהל לקחת בחשבון חוץ מנהירות הקוד. |
|
|
|
|
|
|
||
|
||||
|
ומתי אמרתי שקוד הוא השיקול היחיד? קרא שוב. | |
|
|
|
|
|
||
|
||||
|
אפשר לשאול למה אתה לא עונה לתגובה 195461 שלי ? מתקבל אצלי הרושם שיש בדיוק דבר אחד שמעניין אותך - נשים בהריון. זה נכון ? |
|
|
|
|
|
|
||
|
||||
|
לכל קוד, טוב או רע, יש זמן למידה והוא עשוי להיות לעתים ארוך מאוד. אני יכול למנות לך מספר פרויקטים משמעותיים ואיכותיים שהתפגרו עם היעלם הכותב המקורי של הקוד. מתכנתים מוכשרים הם הרבה דברים, אבל לא בהכרח (ולרוב, ממש לא) כאלו הכותבים קוד בהיר ופשוט לקריאה. למעשה, אפילו לכותבי הקוד המקורי עצמם נדרש זמן מה כדי להבין אותו אם הם התרחקו מהפרויקט לפרק זמן ממושך, לא כל שכן לאחרים שאינם מודעים לתפישות ולאילוצים. חוץ מזה, קוד שכותבים ב''צוות'' או ב''מדור'' הוא בדרך כלל פיסה פשטנית למדי של קוד שבאמת אין צורך בהכשרה ממושכת כדי להבינו. |
|
|
|
|
|
|
||
|
||||
|
הפרויקטים אותם אתה יכול למנות הם פרויקטים כושלים. איזו מין דוגמת נגד הם מהווים בדיוק? >> "מתכנתים מוכשרים הם הרבה דברים, אבל לא בהכרח (ולרוב, ממש לא) כאלו הכותבים קוד בהיר ופשוט לקריאה" אז זהו שלא. זוהי מנטליות קידוד של ה 80's שפסה לה מן העולם, תודה לאל, וכיום היא נחלת ידם רק של מעט תוכניתני פורטרן שתקועים עדיין באיזה כור גרעיני סובייטי מתקופת המלחמה הקרה. מי שלא כותב קוד יפה הוא תוכניתן גרוע. נקודה. מה שכתבת על "קוד של צוות" זה סתם מגוחך, אין לי איך להתייחס לזה אחרת. |
|
|
|
|
|
|
||
|
||||
|
אני חייב לציין שאופי הדיון שלך מרשים. ללא ספק גרמת להרבה אנשים כאן לחשוב. על "שירות דוב" שמעת ? (ואני לא מתכוון לזה שנותן כאן העורך הראשי). |
|
|
|
|
|
|
||
|
||||
|
האם אתר האייל הקורא יושב על שרת דוב? | |
|
|
|
|
|
||
|
||||
|
הפרויקטים שאני יכול למנות הם כלל לא כושלים ומהווים דוגמת נגד מצוינת. בין השאר אפשר למנות כאן את פריהנד (בין דור המתכנתים מאלטסיס לדור המתכנתים ממקרומדיה – > שתי תוכנות שונות), קלאריס אימיילר (המתכנת הראשי עזב, הפרויקט מת... ונולד מחדש כאאוטלוק-אקספרס, עם אותו מתכנת ראשי), ניסוס רייטר (קלאסיק), פוטושופ (בין הדור שעד גרסה 2.0 לדור שאחרי – שוב, שתי תוכנות נפרדות), אפל וורקס, וכן הלאה. אם אתה חושב שמי שלא כותב קוד יפה הוא מתכנת גרוע, אני מציע לך לערוך ביקור קצר, להוריד ולעיין בכל פרויקטי הקוד המאוכסנים בסורס-פורג'. יש לי הרבה הסתייגויות מאיכות הקוד שקהילת הקוד הפתוח מפיקה, אבל לקרוא לכל המתכנתים שם גרועים רק משום שהקוד הוא לעתים קרובות סלט – זו אמירה לא מבוססת. לגבי פסקתך האחרונה – הפוסל במומו פוסל. |
|
|
|
|
|
|
||
|
||||
|
אתה מתווכח איתי כאילו שזה עניין של מציאות סטטיסטית. מתכנת שהקוד שלו לא יפה הוא לא מתכנת טוב, וזה לפי ההגדרה. אם אתה לא מוכן לקבל את ההגדרה, כלומר לדעתך מקצוע התכנות הוא כזה שיופי הקוד הוא מרכיב לא מהותי/הכרחי לתכנות איכותי אז בוא נסכים שאנחנו לא מסכימים. ולא הבנתי לפי איזה מום אני פוסל ומה זה אומר עלי? שהקוד שלי לא יפה? זה כבר ממש מגוחך... אין יפה כמו הקוד שלי. |
|
|
|
|
|
|
||
|
||||
|
קוד לא נועד לבני אדם, הוא נועד למחשב. מתכנת טוב כותב יעיל וגמיש, לא קריא - והדברים בפירוש נוטים לבוא האחד על חשבון השני. מנקודת המבט של ניהול פרוייקט, הגישה על פיה קוד קריא מועיל לתחזוקתו היא מאד נאיבית. מן הסתם בעייתו העיקרית של מתכנת חדש שמקבל קוד קיים אינה זיהוי שמות המשתנים או הפונקציות. קוד מסחרי לא צריך להיות מעורפל בכוונה (obfuscated), אבל "קריאות" צריכה להיות הקריטריון *האחרון* שנלקח בחשבון כאשר מתכנתנים. |
|
|
|
|
|
|
||
|
||||
|
יעילות היא תוצר של עיצוב טוב ואופטימייזר. שני דברים שלא קשורים באופן מהותי לתכנות עצמו. בקוד יפה, אגב, אני בכלל לא מתכוון רק לקוד קריא. זה רק חלק מהעניין. קוד יפה, אלגנטי, זה קוד שהוא בראש ובראשונה קל לתחזוקה. זה הרי כל הקטע, שתכנות זה כבר לא איזה פרויקט אישי הנדסי שמצריך זכרון מעולה ויכולת לראות את כל המערכת בכל רגע נתון למול עיניך. תכנות זה מתודולוגיה. כשאני מראיין תוכניתן הדבר הראשון שמעניין אותי זה הגישה המתודולוגית והאסתטית שלו לקוד, זה אומר עליו הכל. זה יותר חשוב מניסיון, הכרת השפה - הכל. תוכניתן טוב יכול להגיע לתחום שחדש לו לחלוטין ולהתחיל לתכנת בשפה שהוא לא מכיר, כמתחילן, ולעשות זאת בצורה נכונה. הדבר הכי טוב שאפשר לעשות כדי להעריך תוכניתן זה לשבת לידו כ 20 דקות ולראות איך הוא מממש איזה משימה תיכנותית יחסית טריביאלית. לא חוכמה לשאול אותו מה הדרך היעילה ביותר לעשות X, כי אין שום סיבה בעולם שהוא יצליח לעלות עליה בניסיון הראשון. מה שחשוב זה שהוא עובד נכון, כותב קוד יפה, שקל אח"כ לשפר אותו וכו'. הרבה יותר חשוב מהלשאיר מוצר מוגמר על השולחן זה להשאיר את סביבת העבודה מסודרת ונקיה לבא אחריך. כל מוצר בסופו של דבר נבנה, כל גרסה נגמרת ומה שנשאר ביד זה הבלאגן או הסדר שהפועלים השאירו. עם הבלאגן או הסדר צריך ללכת לגרסה הבאה. ואפרופו הדיון המקורי, זה בדיוק מה שהתכוונתי כשאמרתי שפרוייקט מנוהל נכון הוא כזה שתחלופת כ"א בו היא כמה שפחות כואבת. אומר שוב, תכנות זה משמעת. יצירתיות ויעילות מופלאה הם מצרכים חשובים בתחום העיצוב, לא בתכנות. תכנות זה הוצאה לפועל של עיצוב, וככזה הדבר החשוב ביותר בו זה שהעבודה תזרום. ולגבי הקוד המכוער של חלק מהפרוקייטים בsource forge, זה לא אומר כלום. שיהיה ברור, _רב_ הקוד שנכתב הוא מכוער לאללה, בלי קשר לopen source. זה פשוט המצב. רוב האנשים שעוסקים בתכנות הם לא תוכניתנים "באמת", הם סתם עובדים בתוכנה. אם כבר, source forge מתאפיין בפרוייקטים קטנטנים שלא דורשים יותר מדי מומחיות אלא רק רעיון טוב ויכולת ביצוע בינונית. source forge _מלא_ בפרוייקטים שלא נגמרו ואל הגיעו לשום מקום, ואלו שכן הצליחו להתפרסם אחרי כמה עשרות מיני גרסאות, לא עשו זאת בזכות קוד יפה אלא בזכות רעיון חכם. התוצאה היא שהם נכתבים מחדש אלף פעם בכל גרסה, כל פעם בשפה אחרת (כי יש תחלופה די זריזה של תוכניתנים), בעוד שלו היו מנוהלים מלכתחילה בצורה נורמלית היו מציגים הספק הרבה יותר מרשים. (לא שאין שם פרוייקטים מנוהלים נכון, יש ועוד איך והיה לי את העונג האישי לקחת חלק פה ושם, אבל הרוב הוא סתם בינוני, כמו בכל מקום.) |
|
|
|
|
|
|
||
|
||||
|
שכחתי להגיב על הנקודה הכי מעצבנת בהערה שלך: "קוד לא נועד לבני אדם, הוא נועד למחשב?" אתה צוחק?? קוד מכונה נועד למחשב, קוד שפה נועד לבני אדם בראש ובראשונה! אתה שוכח מי משרת פה את מי. קוד אמור להביע את העיצוב, לא לרצות את הקומפיילר או המעבד. פי אלף יותר חשוב שהקוד יהיה יפה (במיוחד קריא) מאשר שיהיה יעיל. יעילות אפשר לשפר. קוד מכוער אפשר רק לזרוק. | |
|
|
|
|
|
||
|
||||
|
"תיק עיצוב" נועד לבני אדם. וקוד נועד *למחשב*. מה לא ברור? אם היית יכול להזין את תיק העיצוב לקומפיילר ולקבל תוכנה - אשריך. בעולם האמיתי צריך לתרגם את העברית והציורים המטופשים לשפה שמחשבים (קומפיילרים) מבינים. התרגום הזה, שהוא כנראה החלק הכי מסובך ויצירתי בפיתוח, זה בדיוק החלק של הקידוד. העיצוב (כתהליך נפרד, לא העיצוב האמיתי שנעשה תוך כדי הקידוד) בסך הכל מטיל עוד כמה אילוצים על המתכנתים, לטובת האינטגרטור (שגם הוא, בסופו של דבר, מתכנת). "קוד אמור להביע את העיצוב"? העיצוב לא מכסה אפילו עשירית מעושר ההבעה שיש לקוד. אתה מציג כאן גישה דינוזארית במיוחד. באקסטרים פרוגרמינג, למשל (אתה העלית את המתולוגיה הזו בדיון הזה, לא?) מתבססים בדיוק על זה. מעצבים "עשרים שניות" קדימה, ורק אחרי הקידוד, משנים את העיצוב בהתאם. אי אפשר לעצב (לעצב *באמת*) "באוויר" בלי לקודד בפועל במקביל. זו חישוביות אלמנטרית. אני אולי לא מבין למה אתה מתכוון בקוד "יפה". קוד "טוב" בעיני הוא מינימליסטי (מנצל את מלוא הכלים של השפה, לא מכיל פעולות מיותרות ברמת שפת-על), יעיל (לא מכיל פעולות מיותרות ברמת שפת מכונה) וגמיש (מודולורי. קל לשנות את הפונקציונלית, בגבולות אפיון הפרוייקט, במינימום שינויים בקוד). קוד שמקיים את שלושת הדברים האלה (ומבטיח תהליך פיתוח בדיקות חלק עד כמה שאפשר, וכידוע - *תמיד* יש שינויים בדרישות תוך כדי הפיתוח, ותמיד מעגל התיקונים-בדיקות עד לשחרור המוצר הוא החלק הבעייתי והארוך ביותר) בדרך כלל מאד לא "קריא" (במובן שקל להבין אותו בקריאה שטחית). |
|
|
|
|
|
|
||
|
||||
|
אקסטרים פרוג' זה מתודולוגיה מאוד מגוונת, אני לא מסכים עם כל מה שנאמר שם. הגישה שאומרת שיש לתכנת את "המינימום שעובד" לא מקובלת עלי. יצא לך לעבוד פעם עם 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% מכל פרויקט זה לחבר דברים קיימים ביחד ורק השארית היא איזה אלגוריתם או פרוטוקול מקורי. זה בדיוק הסיבה שהדגש בתכנות צריך להיות על מתודולוגיה ולא על מומחיות מקסימלית ביעילות וכו'. יעילות תמיד אפשר לשפר, כאמור. |
|
|
|
|
|
|
||
|
||||
|
בטכניון ישנם שני קורסים העובדים לפי עקרון התכנון בנפרד מן התכנות. אלה פרוייקטים שנתיים: בסמסטר הראשון עובדים על תכנון ועיצוב, בסמסטר השני על כתיבה, הידור, וניפוי שגיאות. אין לי יותר פרטים לספק לך. |
|
|
|
|
|
|
||
|
||||
|
מה שאני עושה הוא פשוט להצביע על העובדות הפשוטות: א. רוב התוכנות האיכותיות והמשמעותיות נכתבו ונכתבות על ידי צוותים מצומצמים ביותר (לא ידוע לי על אף מקרה של תוכנה חשובה או חדשנית שנכתבה על-ידי צוות שגודלו עולה על 4-5 אנשים). אצל אלו, נהירות הקוד וקלות העברתו לידי אדם אחר אינה השיקול העיקרי של הכותבים והדבר אינו הופך את הקוד שלהם לרע או אותם למתכנתים רעים. ב. במקרים רבים כאשר בסיס הקוד רחב, למידתו דורשת זמן ממושך גם אם הוא נהיר וברור. האם אתה מכיר מישהו שמסוגל להכנס לעבודה על בסיס קוד של, נאמר, עשרים אלף שורות ביום אחד? |
|
|
|
| חזרה לעמוד הראשי |  |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |