DCSIMG
כלי הפיתוח שאתם פשוט חייבים - הבלוג הפתוח למנהל הפיתוח

הבלוג הפתוח למנהל הפיתוח

מנהל פיתוח תוכנה? זה המקום שלך ללמוד וללמד

על הבלוג

נתקלת פעם באתגרים כמנהל פיתוח? התמודדת עם ניהול אנשים? טיפלת בפרויקטים מורכבים בתחום פיתוח התוכנה? עמדת (פחות או יותר) בלו"ז מאתגר על מנת להביא מערכת לייצור? נדרשת לבחור ארכיטקטורה, כלי פיתוח ו/או סביבת פיתוח? התנסית בהטמעה של מתודולגיות פיתוח מתקדמות כגון Agile ו -SCRUM? התלבטת היכן למקם את צוותי הבדיקות? עמדת באתגרים של התאמת כיוון לאור שינוי בהיבטים העסקיים? אם ענית על אחת מהשאלות הללו בחיוב, ואתה משמש בתפקיד בכיר בעולם פיתוח התוכנה, יש סיכוי טוב שהבלוג הזה יעניין אותך. אנחנו נקדיש זמן ומחשבה לדון בסוגיות אלו ואחרות על בסיס הנסיון האישי שלי, שלכם ושל עמיתינו למקצוע. למה הבלוג הפתוח? כי נסיון של אדם לא מספיק כדי ללמוד ממנו, לכן גם אתם מוזמנים לתרום אם בצורה של תגובות לפוסטים ואם ע"י פוסטים אורחים. מה לגבי ההמשך? כולי תקווה כי בעתיד ניתן יהיה לארוז את תכני הבלוג ותכנים נוספים בתצורה מובנית יותר בצורה של ספר. Follow MosheKaplan on Twitter

כלי הפיתוח שאתם פשוט חייבים

רגע לפני שאנחנו יוצאים לקרב המכריע רצוי מאוד לוודא שכולם עשו את ההכנות הרצויות, כדי שלא נגלה באמצע הדרך שהמימיות ריקות. גם בעולם פיתוח התוכנה צריך לבצע את ההכנות הללו. אמנם מדי פעם תמצאו חבורה מצומצמת של יוצאי ממר"ם או 8200 שמצליחים לעשות קפיצה קוואנטית ולשנות את התעשייה, אבל גם הם בד"כ הגיעו עם הרגלים ותשתיות מוכנות מהבית.
 
 הכי מוכנים שאפשר
 
אז מה צריך להכין?
  1. Source Control: המקום שבו ישמר הנכס החשוב ביותר שלכם אחרי האנשים. הכלים המובילים היום הם TFS בעולם המיקרוסופט, SVN בעולם שאינו מיקרוסופט (וגם לא מעט מפתחי .Net נהנים פחות או יותר להשתמש בו) ו - Git הכוכב העולה החדש המגיע מעולם הפיתוח המבוזר של הקוד הפתוח. כמובן שיש כלים נוספים בינהם כלי Rational.
  2. כלי ניהול משימות: המקום שבו תרשמו את המשימות שלכם. הכלי הבסיסי ביותר שכולכם תחזרו אליו (או תתחילו איתו) כששום דבר לא יעבוד: הלוח המחיק או ה - White Board. מלבדו ישנם כלים רבים המתחלקים לשלושה סוגים:
    1. כלים הכוללים תמיכה בניהול תהליך ניפוי הבאגים (Bugzilla ו - Trac).
    2. כלים עם אוריאנטציה של ניהול משימות כדוגמת BaseCampHQ (מוגש בהמלצה חמה).
    3. כלים שמשתלבים בסביבת הפיתוח כדוגמת ה - TFS של מיקרוסופט וה - Rational של IBM.
  3. סביבת הפיתוח: לכל שפה ולכל מפתח יש סביבת העבודה המועדפת עליו, ולכן אני אמנע מלהמליץ לכם במה לבחור. עם זאת ישנם תוספים רבים שמאוד מומלצים כדי לשפר את איכות הקוד ומהירות הכתיבה שלו. לדוגמה למפתחי .Net השימוש ב -  Resharper הוא הכרח ותצטרכו לפתוח את הכיס בשבילו.
  4. Unit Tests: כתבתם קוד? רצוי מאוד שתהיה לכם סביבה מסודרת לכתיבת בדיקות יחידה (וגם בדיקות נרחבות יותר במקרה הצורך). מימוש טוב של בדיקות אלו יאפשר לכם לבצע אוטומציה מלאה לקוד ולזהות שבירה שלו (ולחסוך הרבה שעות שינה וכאבי לב). הסביבה הנפוצה ביותר בתחום היא משפחת ה - XUnit הכוללת את JUnit ל - Java, ה - NUnit לעולם ה - .Net ו - SimpleTest לעולם ה - PHP. ההמלצה שלי: אל תחפשו בכלל פתרון אחר למשפחה הזאת. טיפ למתקדמים: תוכלו לשלב פתרונות Mock המסמלצים מוצרים חיצוניים כמו בסיסי נתונים על מנת לבודד את בדיקות היחידה שלכם. אחת החברות המובילות בשוק זה היא TypeMock הישראלית.
  5. Code Review Procedures: רגע לפני שאתם מכניסים את הקוד לתוך כלי ניהול התצורה שבחרתם, מומלץ מאוד שכל שורת קוד ששונתה תעבור לפחות עין בוחנת נוספת. איך עושים את זה? ראו את הפוסט אז מה היה לנו?
  6. Continuous Integration: או בקיצור CI: אחרי שכתבתם קוד מסודר, הטמעתם מערכת ניהול תצורה ויש לכם אפילו 100% כיסוי עם בדיקות אוטומטיות, למה לא לדאוג שהגרסה האחרונה שנמצאת במערכת בקרת התצורה תקינה ואין בה באגים? למה לחכות עד לסיום הגרסה ובדיקות האינטגרציה? בחירה בכלי מתאים כדוגמת TeamCity, FinalBuilder או Jenkins (לשעבר Hudson) יעשו את העבודה. הכלים הללו יודעים לזהות ביצוע Commit במערכת ה - Source Control שלכם, למשוך את הקוד, לבצע Build ואפילו להריץ את כל (או חלק מ)בדיקות האוטומציה שלכם. המתקדמים ביניכם יוכלו לשלב גם Build לילי עם בדיקות מסיביות יותר כדוגמת בדיקות עומסים. רוצים להוציא מהם עוד? הכלים הללו גם יודעים לאתחל את בסיס הנתונים ואפילו לממש את השלב הבא: Continuous Deployment שיביא את הקוד שלכם ממש אל המשתמשים.
  7. Continuous Deployment: או בקיצור CD: מימשתם את התהליך שבודק את הקוד? נותנים שירות ללקוחות שלכם (לדוגמה מערכת SaaS)? פתרונות ה - CD לוקחים אתכם צעד אחד קדימה, ומתקינים את הקוד בשידור חי אצל המשתמשים שלכם. עם קצת מיומנות ובטחון תגיעו לעד עשרות התקנות בייצור ביום! הכלים שישמשו אתכם למהלך הם Selenium, BuildBot, Atlassian Bamboo, Apache ZooKeeper, Capistrano, LinkedIn/Glu (ותודה לישי סמיט)
  8. Logging/Tracing/Analytics: מעלים את הקוד לייצור? רוצים לדעת מה הולך שמה? רוצים לראות איזה Exceptions עפו? במה משתמשים באמת משתמשים ובמה לא? מבחר כלים ואמצעים יעמדו לרשותכם:
    1. Logging/Tracing: הכלי הבסיסי ביותר, שילוב של API חיצוני בתוך הקוד יאפשר לכם לתפוס שגיאות או לציין נקודות משמעותיות בתוך הקוד ולרשום אותן החוצה לעיון מאוחר יותר. השליטים הבלתי מעורערים בתחום הזה הם כלי ה - Log4X וביניהם Log4J ו - Log4Net. המלצה חמה: אם המערכת שלכם גדולה, אל תתפתו לשמור את קבצי ה - Log בבסיס הנתונים עצמו. הסיבה לכך היא שזהו מתכון בטוח לבעיות ביצועים בייצור, ולטבלאות שיהיה קשה מאוד לתשאל אותן במקרה הצורך. התחליף המומלץ הוא שמירת הנתונים לדיסק ושימוש בכלי MapReduce ובראשם ה - Hadoop לביצוע אנליזות.
    2. Analytics: רוצים לדעת איפה המשתמשים שלכם? כמה זמן הם בכל עמוד? ומה המסלול האהוב עליהם? Google Analytics החינמי הוא הכלי הבסיסי ביותר והנפוץ ביותר בתחום. אם אתם רוצים לדעת אינפורציה נוספת תוכלו לעשות שימוש בכלים נוספים שכל אחד מהם מביא את היכולות שלו:
      1. מפות חום: רוצים לדעת על מה המשתמש מסתכל? איפה הוא מתמקד במסך? איך הוא מטייל בעמוד? ClickTale ישמחו לעזור לכם בנושא.
      2. היזון חוזר? בשוק כלי Feedback רבים, המאפשרים לכם לקבל סיוע בזמן אמת מהמשתמשים שלכם, מתלונות ועד להמלצות. בין הכלים המובילים: Kampyle, GetSatisfaction ו - uservoice. תוכלו להשתמש בכלים הללו גם כדי לתעדף תכונות חדשות במוצר בשיתוף הקהילה וגם כדי לייצר קהילת משתמשים מסביב למוצר.
      3. רוצים לדעת מטריקות מדויקות עבור כל משתמש: totango של גיא נירפז תשמח לעזור לכם בקרוב.
  9. ניטור סביבת הייצור: שתי משפחות מוצרי הניטור הנפוצות ביותר כיום בתחום האינטרנט (ולא רק לניטור של ה - CPU Utilization אלא גם כמה Signups לדקה יש במערכת) הם Nagios ו - Zabbix. המערכות הללו ידאגו שתתעוררו באמצע הלילה אם עשיתם שטויות במהלך היום...
ומה עכשיו?
בהנחה שאתם כבר יודעים מה האסטרטגיה שלכם וזאת בהחלט לא מילה גסה, כל מה שנותר עכשיו הוא לבחור את טקטיקת הפיתוח: איך אתם הולכים לפתח? איך אתם הולכים לבדוק? וכמה מהר המוצר יגיע ללקוחות שלכם. על השיטות הללו ובינהן SCRUM, Agile ו - Continuous Deployment נדבר בפוסטים הבאים.
 
השורה התחתונה
תבחרו את הכלים הטובים ביותר לאנשים שלכם כדי שברגע האמת הם לא ילחמו בידיים. עם זאת מומלץ להטמיע את המוצרים בהדרגה לפי רמת המיומנות של האנשים על מנת למנוע מצב שבו אתם מטמיעים כלים בלבד במקום לפתח.
 
יש לכם כלי מומלץ? יש לכם המלצות נוספות? עברתם חוויה כואבת במיוחד שאתם רוצים לשתף? זה המקום...
 
נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!
 
ממשיכים לפתח,
משה קפלן Follow MosheKaplan on Twitter
 
נ.ב ביום שלישי הקרוב, בשעה 18:00 יערך מפגש אלפאגיקס ה - 9. אם אתם מהנדסי תוכנה (וסביר להניח שזה המצב אם אתם קוראים את הפוסט הזה) ומעניין אתכם איך עובד שיווק באינטרנט, איך זה משפיע על צורת הפיתוח שלכם ואיך בעצם עושים כסף מהקוד שלכם, אתם מוזמנים להצטרף. בתוכנית: איך עושים SEO ואיך זה משפיע על הקוד, איך עושים A/B Testing וסיפור אמיתי על איך מצליחים לשווק אפליקציה ב - AppStore.
האירוע עלינו, והאוכל עליכם, אם זה מעניין אתכם תעשו RSVP באירוע בפייסבוק.
שלכם,
אנשי האלפאגיקס. תודה לכל מי שהשתתף! וידאו ומצגות יועלו בקרוב :-)
 
עדכונים ותגובות של קוראים
הטיפ של
ליאור קסוס
Redmine הוא כלי מדהים (מבוסס רובי) אשר מנהל משימות, וויקי וניהול קבצים פר פרויקט. לכלי אינטגרציה מעולה ל - source control – גיט וכדומה, עם יכולת לראות Commits ו - Diff וויזואלי של ההבדלים בין גרסאות.
אנו עובדים עם רדמיין כבר יותר מ - 3 שנים. לאחרונה הרצאתי על מספר פלאגינים מתקדמים שלו ועל השימוש שלנו בהם בדרופלקון בשיקאגו – מומלץ!
 
הטיפ של ישי סמיט
בנוגע ל - Continuous Deployment כלים רלונטיים הם Apache ZooKeeper, Capistrano ו - LinkedIn/Glu.
כלים כמו Puppet ו - Chef הם עבור קונפיגורציה של מכונות והם לא דינמיים מספיק עבור CD. לא ניתן לבנות בעזרתם מערבת הגנה חיסונית גמישה מספיק לפריסה בקצבים גבוהים.
 
הטיפ של מאור
רצוי לשים לב לכלי Review Board (ביחוד בקבוצות מבוזרות) לצרכי Code Review. פרטים מלאים על הכלי וסרטון בפוסט אז מה היה לנו?
 
ועוד כמה מילים על מוצרי ה - Source Control בתגובה לשאלה מה ההבדלים בין Git, Mercurial  ו - SVN
ההבדלים בין Git לבין Mercurial קטנים יחסית. לעומת ההבדלים בינם ל – SVN משמעותיים יחסית וזאת מכיוון ש - SVN עובד בצורה מרכזית, ואילו האחרים בתצורה מבוזרת. למרות זאת במאמר מוסגר אני אומר שפרויקט האחרון שניהלתי, בחרנו לעשות שימוש בפתרון מבוסס SVN שהיה דומה מאוד למהותו לקונספט של Git (כל אחת מהמפתחים עובד על Branch משלו שאליו הוא מבצע Commit לכל אורך הדרך גם אם הפתרון לא יציב. רק לאחר שהתכונה החדשה או תיקון הקוד בשלים הם מאוחדים לתוך ה – Trunk). היתרון הגדול לצורה המבוזרת היא היכולת של כל מפתח לבנות לעצמו ארגז חול שבו הוא יכול להרוס את הקוד כאוות נפשו, ורק כשהעסק בשל להכניס את זה לייצור. מתלבטים
ישנם מספר פוסטים טובים על הנושא, כולל פוסט על ניהול קוד מבוזר של זהר ארד שכתב גם פוסט מצוין על כלי ניהול פרויקטים.
ישנם מספר מקומות שמשתמשים בארץ ב – Mercurial, אבל Git באופן עקרוני נכנס יותר טוב לתעשייה, ולכן הייתי ממליץ לך לבחור בין SVN ל – Git.
 

תוכן התגובה

רן בר-זיק כתב/ה:

פוסט מעניין מאד. בתחום הקוד הפתוח לא רבים משתמשים ב-Unit testing וחבל.

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

# March 31, 2011 12:22 PM

Moshe Kaplan כתב/ה:

שלום רן,

בנושא הדוקיומנטציה, זה בהחלט כלי מצויין.

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

בנושא הקוד הפתוח ו - Unit Testing. הכלים קיימים (SimpleTest למשל שהזכרתי בבלוג, אבל יש גם אחרים כמו ב - Ruby שזה מובנה ממש בשפה) ולכן היחידים שאנחנו יכולים לבוא אליהם בטענות זה אנחנו :-)

ממשיכים לפתח,

משה קפלן

# March 31, 2011 1:12 PM

?????? ???????????? ???????? ???????????? ?????????? | Newsgeek כתב/ה:

Pingback from  ?????? ???????????? ???????? ???????????? ?????????? | Newsgeek

# April 2, 2011 12:31 PM

ripper234 כתב/ה:

פוסט מעולה, קצת מזכיר לי פוסט דומה שכתבתי בנושא מזמן - ripper234.com/.../this-comes-before-your-business-logic

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

# April 9, 2011 12:04 PM

Moshe Kaplan כתב/ה:

שלום רון,

קודם כל תודה, ואכן הפוסט שצרפת מצויין,

כנה דגשים טובים שציינת:

1. בחרתם כלי ניהול קוד: תדאגו שכל הקוד יהיה בו, ולא יסתובב במקומות אחרים

2. תשתית IT בסיסית: אני ממליץ על הפתרון של גוגל: דוא"ל, מסמכים (גם לתיעוד וגם לנהלים, שכולם יכולים לערוך בלי לנעול אף אחד) ויומן בלי העלויות (ובעיקר כאב הראש) של מנהל רשת צמוד. אם אתם צריכים שרת קבצים ממש, תבדקו את הפתרון של DropBox.

ממשיכים לפתח,

משה קפלן

# April 9, 2011 1:06 PM

שחר מור כתב/ה:

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

תודה!

# April 9, 2011 9:16 PM

Moshe Kaplan כתב/ה:

שלום שחר,

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

אם אתה רוצה דגשים נוספים, אנא הגדר אותם בצורה יותר מפורטת,

ממשיכים לפתח,

משה קפלן

# April 10, 2011 12:35 AM

תמיר כתב/ה:

ובכל זאת, כמה הערות:

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

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

כמו כן אני ממליץ לנסות את הכלים החדשים של Rational - ובמיוחד RTC Team Concert . מדובר בכלי רציני וחינמי לעד 10 מפתחים (אך ללא תמיכה!). מה שיפה זה שהוא כולל כבר את יכולות 1,2,6 שציין למעלה משה, וניתן גם להוסיף יכולות נוספות ע"י חיבור למערכות אחרות (מנסיון אישי).

אפשר ליצור איתי קשר לשאלות - מבטיח להשתדל לענות :)

# April 12, 2011 11:17 PM

Moshe Kaplan כתב/ה:

שלם תמיר,

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

כלים אינטרנטיים, Open Source ושירותים מפעילים את חברות האינטרנט הגדולות בעולם שהם גם בתי התוכנה הגדולים בעולם היום.

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

ממשיכים לפתח,

משה קפלן

# April 13, 2011 2:23 PM

תמיר כתב/ה:

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

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

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

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

אגב - תמיכה מקצועית זה לא רק יעוץ, אלא גם הצהרה של "הנהלת" המוצר על road map קדימה, תיעוד מסודר של היכולות, הבאגים, מתן best practices וכד'. אני מניח שתסכים איתי שלא כל הכלים החינמיים מספקים את זה.

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

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

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

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

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

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

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

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

בידידות,

תמיר גפן

GoMidjets

# April 14, 2011 12:45 AM

Moshe Kaplan כתב/ה:

הי תמיר,

תודה על התגובה המפורטת!

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

אני רק יכול להסכים, גם אם תשקיעו בכל הכלים שיש, ולא תלמדו להוציא מהם את המירב, תגיעו למצבים המתוארים,

תודה שוב,

ממשיכים לפתח,

משה קפלן

# April 14, 2011 5:30 PM

ליאור כתב/ה:

תמיר,

לפעמים התמיכה הלא מקצועית לכאורה של פרויקטי קוד פתוח.

טובה בסדרי גודל על תמיכה "מקצועית" של חברה מסחרית.

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

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

# May 16, 2011 9:30 AM

Moshe Kaplan כתב/ה:

ליאור,

אני בהחלט מסכים,

למרות שלא צריך לזלזל גם בחברות המסחריות :-)

ממשיכים לפתח,

משה קפלן

# May 16, 2011 11:02 AM

הבלוג הפתוח למנהל הפיתוח כתב/ה:

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

# June 30, 2011 11:55 PM

הבלוג הפתוח למנהל הפיתוח כתב/ה:

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

# July 1, 2011 12:00 AM

מאור כתב/ה:

מבחינת Code Review

אני ממליץ בחום על Review Board

כלי מבוסס WEB... מתממשק ל SVN (אני מניח שגם ל GIT) בצורה מצויינת

מאפשר לבצע Review כולל מתן הערות השוואה בין ריוויסיות של אותו שינוי וכן הלאה.

פשוט תענוג של כלי

# July 5, 2011 6:02 PM

Moshe Kaplan כתב/ה:

שלום מאור,

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

ממשיכים לפתח,

משה קפלן

# July 5, 2011 8:31 PM

קורא כתב/ה:

פוסט טוב!

# July 6, 2011 12:34 PM

Moshe Kaplan כתב/ה:

תודה!

ממשיכים לפתח,

משה קפלן

# July 6, 2011 12:50 PM

הבלוג הפתוח למנהל הפיתוח כתב/ה:

לפני כשבועיים ערכתי במסגרת ה - Expert Days סמינר על ארכיטקטורה של מערכות וביצועים שלהן ורציתי לשתף אתכם

# August 1, 2011 1:02 AM

הבלוג הפתוח למנהל הפיתוח כתב/ה:

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

# August 31, 2011 11:59 PM
שלח תגובה

(שדה חובה)  

(שדה חובה)  

(אופציונלי)

(שדה חובה) 

Please add 4 and 5 and type the answer here:


Enter the numbers above: