בתשובה לNik The Greek, 07/02/04 12:54
הפתרון הסופי 195717
הפרויקטים שאני יכול למנות הם כלל לא כושלים ומהווים דוגמת נגד מצוינת. בין השאר אפשר למנות כאן את פריהנד (בין דור המתכנתים מאלטסיס לדור המתכנתים ממקרומדיה – > שתי תוכנות שונות), קלאריס אימיילר (המתכנת הראשי עזב, הפרויקט מת... ונולד מחדש כאאוטלוק-אקספרס, עם אותו מתכנת ראשי), ניסוס רייטר (קלאסיק), פוטושופ (בין הדור שעד גרסה 2.0 לדור שאחרי – שוב, שתי תוכנות נפרדות), אפל וורקס, וכן הלאה.

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

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

מנקודת המבט של ניהול פרוייקט, הגישה על פיה קוד קריא מועיל לתחזוקתו היא מאד נאיבית. מן הסתם בעייתו העיקרית של מתכנת חדש שמקבל קוד קיים אינה זיהוי שמות המשתנים או הפונקציות. קוד מסחרי לא צריך להיות מעורפל בכוונה (obfuscated), אבל "קריאות" צריכה להיות הקריטריון *האחרון* שנלקח בחשבון כאשר מתכנתנים.
הפתרון הסופי 195753
יעילות היא תוצר של עיצוב טוב ואופטימייזר. שני דברים שלא קשורים באופן מהותי לתכנות עצמו.
בקוד יפה, אגב, אני בכלל לא מתכוון רק לקוד קריא. זה רק חלק מהעניין. קוד יפה, אלגנטי, זה קוד שהוא בראש ובראשונה קל לתחזוקה. זה הרי כל הקטע, שתכנות זה כבר לא איזה פרויקט אישי הנדסי שמצריך זכרון מעולה ויכולת לראות את כל המערכת בכל רגע נתון למול עיניך. תכנות זה מתודולוגיה.
כשאני מראיין תוכניתן הדבר הראשון שמעניין אותי זה הגישה המתודולוגית והאסתטית שלו לקוד, זה אומר עליו הכל. זה יותר חשוב מניסיון, הכרת השפה - הכל. תוכניתן טוב יכול להגיע לתחום שחדש לו לחלוטין ולהתחיל לתכנת בשפה שהוא לא מכיר, כמתחילן, ולעשות זאת בצורה נכונה. הדבר הכי טוב שאפשר לעשות כדי להעריך תוכניתן זה לשבת לידו כ 20 דקות ולראות איך הוא מממש איזה משימה תיכנותית יחסית טריביאלית. לא חוכמה לשאול אותו מה הדרך היעילה ביותר לעשות X, כי אין שום סיבה בעולם שהוא יצליח לעלות עליה בניסיון הראשון. מה שחשוב זה שהוא עובד נכון, כותב קוד יפה, שקל אח"כ לשפר אותו וכו'.
הרבה יותר חשוב מהלשאיר מוצר מוגמר על השולחן זה להשאיר את סביבת העבודה מסודרת ונקיה לבא אחריך. כל מוצר בסופו של דבר נבנה, כל גרסה נגמרת ומה שנשאר ביד זה הבלאגן או הסדר שהפועלים השאירו. עם הבלאגן או הסדר צריך ללכת לגרסה הבאה. ואפרופו הדיון המקורי, זה בדיוק מה שהתכוונתי כשאמרתי שפרוייקט מנוהל נכון הוא כזה שתחלופת כ"א בו היא כמה שפחות כואבת.
אומר שוב, תכנות זה משמעת. יצירתיות ויעילות מופלאה הם מצרכים חשובים בתחום העיצוב, לא בתכנות. תכנות זה הוצאה לפועל של עיצוב, וככזה הדבר החשוב ביותר בו זה שהעבודה תזרום.
ולגבי הקוד המכוער של חלק מהפרוקייטים בsource forge, זה לא אומר כלום. שיהיה ברור, _רב_ הקוד שנכתב הוא מכוער לאללה, בלי קשר לopen source. זה פשוט המצב. רוב האנשים שעוסקים בתכנות הם לא תוכניתנים "באמת", הם סתם עובדים בתוכנה. אם כבר, source forge מתאפיין בפרוייקטים קטנטנים שלא דורשים יותר מדי מומחיות אלא רק רעיון טוב ויכולת ביצוע בינונית. source forge _מלא_ בפרוייקטים שלא נגמרו ואל הגיעו לשום מקום, ואלו שכן הצליחו להתפרסם אחרי כמה עשרות מיני גרסאות, לא עשו זאת בזכות קוד יפה אלא בזכות רעיון חכם. התוצאה היא שהם נכתבים מחדש אלף פעם בכל גרסה, כל פעם בשפה אחרת (כי יש תחלופה די זריזה של תוכניתנים), בעוד שלו היו מנוהלים מלכתחילה בצורה נורמלית היו מציגים הספק הרבה יותר מרשים. (לא שאין שם פרוייקטים מנוהלים נכון, יש ועוד איך והיה לי את העונג האישי לקחת חלק פה ושם, אבל הרוב הוא סתם בינוני, כמו בכל מקום.)
הפתרון הסופי 195754
שכחתי להגיב על הנקודה הכי מעצבנת בהערה שלך: "קוד לא נועד לבני אדם, הוא נועד למחשב?" אתה צוחק?? קוד מכונה נועד למחשב, קוד שפה נועד לבני אדם בראש ובראשונה! אתה שוכח מי משרת פה את מי. קוד אמור להביע את העיצוב, לא לרצות את הקומפיילר או המעבד. פי אלף יותר חשוב שהקוד יהיה יפה (במיוחד קריא) מאשר שיהיה יעיל. יעילות אפשר לשפר. קוד מכוער אפשר רק לזרוק.
הפתרון הסופי 195757
"תיק עיצוב" נועד לבני אדם. וקוד נועד *למחשב*. מה לא ברור? אם היית יכול להזין את תיק העיצוב לקומפיילר ולקבל תוכנה - אשריך. בעולם האמיתי צריך לתרגם את העברית והציורים המטופשים לשפה שמחשבים (קומפיילרים) מבינים. התרגום הזה, שהוא כנראה החלק הכי מסובך ויצירתי בפיתוח, זה בדיוק החלק של הקידוד. העיצוב (כתהליך נפרד, לא העיצוב האמיתי שנעשה תוך כדי הקידוד) בסך הכל מטיל עוד כמה אילוצים על המתכנתים, לטובת האינטגרטור (שגם הוא, בסופו של דבר, מתכנת).

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

אני אולי לא מבין למה אתה מתכוון בקוד "יפה". קוד "טוב" בעיני הוא מינימליסטי (מנצל את מלוא הכלים של השפה, לא מכיל פעולות מיותרות ברמת שפת-על), יעיל (לא מכיל פעולות מיותרות ברמת שפת מכונה) וגמיש (מודולורי. קל לשנות את הפונקציונלית, בגבולות אפיון הפרוייקט, במינימום שינויים בקוד). קוד שמקיים את שלושת הדברים האלה (ומבטיח תהליך פיתוח בדיקות חלק עד כמה שאפשר, וכידוע - *תמיד* יש שינויים בדרישות תוך כדי הפיתוח, ותמיד מעגל התיקונים-בדיקות עד לשחרור המוצר הוא החלק הבעייתי והארוך ביותר) בדרך כלל מאד לא "קריא" (במובן שקל להבין אותו בקריאה שטחית).
הפתרון הסופי 195786
אקסטרים פרוג' זה מתודולוגיה מאוד מגוונת, אני לא מסכים עם כל מה שנאמר שם. הגישה שאומרת שיש לתכנת את "המינימום שעובד" לא מקובלת עלי.
יצא לך לעבוד פעם עם Rose? זה שופך לך קוד VB מתוך עיצוב UML. אני מכיר חברה שעבדה כך. התוכניתנים פעלו כמו drones שמילאו את המעט החסר בין תחילת הפונקציה וסופה. 90% מהפרויקט היה תוצר ישיר של עיצוב. לא שזה _ה_דרך לתכנות, זה דווקא מאוד חריג, אבל עיצוב ותכנון מוקדם זה לא גישה דינוזאורית ולא בטיח. מי שלא מעצב משלם אח"כ בקידוד מחדש. עיצוב נכון זו לא פריוילגיה של מי שלא צריך לעמוד בלו"ז צפוף, להיפך הוא זה שמאפשר לאותם אנשים לעמוד בלו"ז.

לגבי מה שאמרת שיכולת ההבעה של הקוד לא מכוסה ע"י העיצוב, זה כבר לא נכון. היום כמעט כל השפות הם interchangable? לכל אחת יש את הנישה שלה, ויש גם תחרות החלק מהנישות, אבל בתכלס כל מה שניתן לכתוב ב c++ אפשר לכתוב גפ בליספ או vb. תסתכל על .net למשל, זה מדגים בצורה נפלאה איך בחירה של שפה זה לא יותר מחירה של כלי.
נניח שאנחנו עובדים בפרוקייט c++י. ברמת הצוות מתקבלת ההחלטה איך מנהלים זכרון, מה סגנון הטקסט (מבחינת צורה והערות), מה מדיניות טיפול בשגיאות, מה מדיניות ירושה, שימוש בגלובליים, תכנון הידרים, מדיניות לוגים, איך ניגשים לDB, באיזה ספריות רשת משתמשים. הכל הכל הרי נקבע (או צריך להקבע) ברמת העיצוב. מה נשאר למתכנת לעשות? לממש. ולעשות את זה בצורה שקל יהיה לראות כיצד העיצוב של המערכת בא לידי ביטוי. הגישה שלמתכנת יש קארד בלאנש לעשות מה בזין שלו כל עוד זה עובד ויש מספיק הערות פשוט לא מחזיקה מים. שעה של תכנון עדיפה על יום של עבודה, וזה עוד יחס נדיב...
הפתרון הסופי 195791
בוודאי שיצא לי לעבוד עם Rose, ולמעשה זו דוגמא מצויינת: אני מאמין שמדרך הטבע, אלה שעומדים מאחורי התוכנה יודעים די והותר על עיצוב תוכנה (ואם זכרוני אינו מטעני, GoF בכבודתם ובעצמם קשורים ל-Rational), ולמרות זאת, כל מי שאי פעם שיחק איתה 10 דקות למד בדרך הקשה עד כמה המימוש שלה גרוע. ואתה עוד מספר שיש מישהו שבאמת משתמש בפיצ'ר הקיקיוני של תרגום דיאגרמות לקוד? אני מוכן להמר על מיטב כספי שהמוצר הסופי שאותה חברה חסרת אחריות שחררה גרוע מעבר לכל דמיון (חיזוק להשערה: הם כותבים ב-VB).

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

ברור ש*חישובית* כל שפות התכנות שקולות. אבל מנקודת מבט של מתדולוגיה או יעילות - הן בפירוש לא. Interchangeable? אני לא עבדתי מעולם על תוכנה שהיה אפשר לתכנתה ב-VB באותה מידה שהיה אפשר ב-++C, ועל תוכנה שהיה אפשר לתכנת ב-++C באותה מידה שהיה אפשר לתכנת ב-C. וזה עוד בלי להכנס לשיקולי אסתטיקה וכבוד עצמי...

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

השקילות של שפות התכנות היא בכלל לא במובן החישובי. כל דבר ניתן היום לתכנת בכל שפה. נניח שיש לך ספריות מקומפלות רק ל C++, אבל את הGUI וכל מיני דברים אחרים אין לך כוונה לכתוב ב C++, אז עוטפים ומסתדרים. קונסטריינטס מהבחינה הזו הם לא כזה בעיה. ברוב המקרים בחירת השפה היא תוצר של כוח האדם ולא להיפך, עד כמה שזה מאכזב לשמוע. והזלזול שלך בVB לא במקום, זו סביבת פיתוח עם ה User base הכי גדול (וא כמעט הכי גדול) מכולן. כל דבר ניתן לכתוב עם VB, ובמיוחד עכשיו עם .net, בדיוק בגלל שהframework שלהם עובד עם ה CLR לכל שפה. והרשימה של השפות בפעם האחרונה שבדקתי הייתה ארוכה ומרשימה.
אין שום ספק שלכל שפה יש את הפורטה שלה אבל, כפי שאמרתי, כל ההחלטות המעניינות מתקבלות ברמה גבוהה יותר.
ולא טענתי שתוכניתנים לא צריכים להשתתף בעיצוב, להיפך. אלא שזה שלב נפרד. כמו כן, אני מסכים שלא ניתן לתכנן _הכל_ מראש, אבל ברגע שעולות סוגיות בעייתיות פותרים אותן ברמת החלטה עיצובית ולא ברמת התוכניתן. אי אפשר שלכל אחד בצוות יהיה קוד משלו לתקשורת, לטיפול בשגיאות וכו'. "או, רגע הקוד הזה פה מעיף exception, טוב אז אני אטפל בהן ככה וככה..." זה לא רציני. סוגיות שכאלה הן קריטיות לעיצוב וההחלטות לא שייכות לתוכניתן ככזה, אלא למעצב. אלו דברים שצריכים להקבע ברמת מדיניות ולהיכתב פעם אחת. לכן, אלא אם כן אתה כותב איזה ספריית קוד ואז הדגש על השפה עצמה הוא המירבי, רוב התכנות שנעשה הוא רק מימוש.
בכלל רוב התכנות האפליקטיבי הוא יותר חיווט של דברים קיימים מאשר פיתוח מקורי. 99% מכל פרויקט זה לחבר דברים קיימים ביחד ורק השארית היא איזה אלגוריתם או פרוטוקול מקורי. זה בדיוק הסיבה שהדגש בתכנות צריך להיות על מתודולוגיה ולא על מומחיות מקסימלית ביעילות וכו'. יעילות תמיד אפשר לשפר, כאמור.
הפתרון הסופי 196078
בטכניון ישנם שני קורסים העובדים לפי עקרון התכנון בנפרד מן התכנות. אלה פרוייקטים שנתיים: בסמסטר הראשון עובדים על תכנון ועיצוב, בסמסטר השני על כתיבה, הידור, וניפוי שגיאות.

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

חזרה לעמוד הראשי המאמר המלא

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