בלוג היועצים של מיקרוסופט ישראל

תקשורת בין מודולים

[אני מניח שכולכם מכירים את התרשים (ואם לא, כדאי שתכירו) - לקוח מתוך " Architecture and Design Guidelines " באדיבות P&P. ] מכירים ארכיטקטורת שכבות? כמובן! מי לא מכיר? כולנו מכירים ויודעים לדקלם למה יש שכבות, כמה שכבות, איך לממש.... לכולם (אני מקווה) גם ברור שאני לא מאפשר גישה לשכבת ה – DAL ישירות מה – Service Layer או מה – Presentation Layer. (אבל למה? - זהו לא הנושא שעליו אני רוצה לדבר ולכן לא ארחיב...) אז על מה אני רוצה לדבר... נניח (באופן היפוטטי) שיש לי באפליקציה מספר מודולים, נקרא...

מתי לא להשתמש - User Defined Functions - UDF

לכל מי שבא מעולם התכנות (כמוני למשל), שימוש בפונקציות נשמע כצורת הכתיבה הטובה ביותר. יש לכך כמובן הרבה סיבות כגון שימוש חוזר, Encapsulation, פשטות קוד ועוד. אבל, בכתיבה של SQL זה לא תמיד כדאי. אז הנה דוגמא מהחיים (הדוגמאות רצות על AdventureWorks): אנו רוצים לכל ספק את סכום ההזמנות, כמות הפריטים, סכום ממוצע לפריט ומשקל ממוצע לפריט השיטה בעזרת פונקציות: לעבור על טבלת הספקים, ההזמנות ושורות ההזמנה קוד בעזרת פונקציות (הגדרות הפונקציות בנספח): SELECT PV.VendorID, Purchasing.fn_SumQty(PV.VendorID) SumQty...

ארכיטיפ: אפיון פרסונות משתמשים

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

NoSQL – Not only SQL

[אני שמח לארח שנית את שחר בר (ברזניצקי) , ארכיטקט מנוסה בתחום High Scalable Applications.] ממי לביא העלה ב פוסט המצויין שפירסם את הטעות שביצירת סכמת בסיס נתונים "גנרית" על בסיס נתונים רלציוני בעל יכולות ACID. כפי שאני רואה את זה הנושא שממי העלה הוא חלק ממרחב הבעייה הכללי העוסק בשימוש בכלי הנכון למטרה הנכונה. בהקשר של Data bases, או במונח הכללי יותר של data stores, אכן עולה צורך בבסיס נתונים גנרי עבור מערכות. הצורך עצמו לגיטימי בסוגי מערכות רבות ולכן רצוי למצוא עבורו את הפתרון הנכון ביותר...

Brancning & Merging - פוסט המשך

בפוסט האחרון בנושא , עלתה שאלת הצורך ב- branching. פוסט זה דן בשלושה מודלים נפוצים ל- branching. Basic Plan כללי אצבע לבחירת המודל: ­בכל פעם משחררים גרסה אחת ויחידה של המוצר/מערכת ­כל הלקוחות משדרגים באותו הזמן לגרסה החדשה ­כל הבעיות והתוספות יראו אור בגרסה הבאה Development – נועד לעבודה על הגרסה הבאה. ­ ניתן לייצר מס' ענפים ע"פ חלוקה למודולים,יכולות עסקיות, צוותים וכו'. ­ כל ענף הוא ענף מלא של Main. הכוונה היא לא לבצע branching למס' קבצים חלקי. ­ בצע Merge...

Branching & Merging - האם אתה באמת צריך את זה? רוב הסיכוי שכן...

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

שיפור תפוקת צוות הפיתוח ללא עלויות – חלק ב'

בפוסט קודם בנושא, דיברתי על האופציה שבכל פעם שמבצעים checkout יתבצע get latest version, כך שכברירת מחדל תמיד נעבוד על עותק מעודכן של הקובץ. היום אני רוצה לדבר על נושא קצת “מורכב” יותר ויחד עם זאת בעל אפקט רב יותר בעיקר בסביבה בא קיימים מספר צוותים שעובדים על חלקים שונים של אפליקציה. Build & Continuous Integration מה זה Build? כאשר אני מדבר על build אני מתכוון לתהליך Build המנוהל ומטופל ע”י TFS. במה שונה תהליך Build מ – Build שאנחנו מבצעים ב – (Ctrl+F5) Visual Studio? ביצוע ה – (Ctrl+F5) build...

שיפור תפוקת צוות הפיתוח ללא עלויות – חלק א'

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

ארכיטיפ מס’ 3 – תחבר את שיר הנושא, שמור על ארכיטקטורה יציבה

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

ארכיטיפ מס’ 2 – דע מי משתמש קצה של מסמך ארכיטקטורה שלך

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

ארכיטיפ מס' 1 – שאל על נהלים מרכזיים

אחד הפעילויות המרכזיות בבניית הארכיטקטורה (או סקר ארכיטקטורה) היא זיהוי תסריטים/תרחישים מרכזיים. הכללים לזיהוי התרחישים הם פשוטים: תרחיש הכי שכיח, למשל, באתר www.bing.com הוא חיפוש. תרחישים שמערבים הרבה טכנולוגיות או תרחישים מסובכים , לכן הם מהווים סיכון גבוהה. תרחישים שנמצאים בפוקוס של קודקודים – למשל, דוח רווח והפסד שמופק פעם בשנה עבור מנכ”ל. הנה טיפ קטן שיכול לזהות תרחישים קריטיים מרכזיים – שאל על הנהלים המרכזיים. לדוגמה: בבית חולים יש נוהל “מסדר אחיות” בשעה 10:00. בשעה הזו האחיות עוברות בין החולים...