חוכמת ארכיטקט תכנה במהירות האימייל

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

קח נשימה, ממי מתקתק תשובות בפסים קצרים – מוכן?

ממי, מה המומחיות שלך?

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

ממה אתה מתלהב במיוחד?

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

מה האתגר הנוכחי שאתה מתודד איתו?

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

מדובר ביישום שאמור לעבוד בסביבת רשת בעייתית ביותר, עם נפחי תעבורה שיכולים להגיע עד 64Kb, ורשת עם ניתוקים רבים. היינו צריכים לבחור את רכיב ה- DTO שלנו, כאשר ההתלבטות היתה בין Dataset, Entity Framework ו- NHibernate. הבחירה נפלה בסופו של דבר על Typed Dataset בגלל יכולת ניהול הנתונים הפנימית המתקדמת שלו, אבל היינו צריכים להתמודד עם נפח העברת הנתונים ובעיות Interoperabilty שהוא יוצר. הפתרון הנבחר היה יצירת שכבת Translator בצמוד ל- Service Interface שממיר את ה- Dataset לרכיב DataContract רזה מאוד, וכך השגנו שתי ציפורים – ירידה (עד כ- 50%!) בנפח המידע, ויכולת Interoperabilty מתקדמת.

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

מה שעשינו היה לנסות לבחור את הפתרון בעל הסיכון הנמוך ביותר ועם מירב התכונות שרצינו. השתמשנו במנגנון ה- Serialization  המובנה ב- .NET על מנת להעביר את הנתונים מה- DS ל- DTO, ובהרחבה לכלי ה- XSD על מנת ליצור את ה- DTO Class.

מה התכונות הנדרשות כדי להצליח ביעוץ?

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

איך אתה ממליץ לפתח את היכולות?

פשוט להתאמן. לעשות את זה שוב ושוב ושוב עד שזה הופך להיות טבע שני.

למה אתה אוהב להיות יועץ?

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

למה אתה לא אוהב להיות יועץ?

אני לא אוהב את העובדה שלעתים אני לא נשאר בפרוייקט עד הסוף שלו ולא יכול לראות את הארכיטקטורה שתכננתי יוצאת אל הפועל.

תן לי לסיום שלום המלצות ליועץ צעיר וכמה לינקים שאתה אוהב בתור Resourceים

המלצות:

1. אף פעם אל תניח שאתה יודע הכל. מכל אחד ומכל מערכת יש מה ללמוד.

2. אין צורך לאמץ באופן אוטומטי טכנולוגיות חדשות שיוצאות. החלטה על טכנולוגיות צריכה להיות מושפעת בראש ובראשונה מהתועלת האמיתית שהלקוח יפיק מהן.

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

קישורים – האמת שיש מספר אתרים קבועים שאני משתמש בהם, אבל האתר שנותן לי הכי הרבה השראה הוא:

www.thedailywtf.com

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

שמי אליק לוין ואני מתרכז ב- Security and Performance באפליקציות Net.

בזמני הפנוי אני בלוגר שרוף.

This post is made with PracticeThis.com plugin for Windows Live Writer