בתחילת הפיתוח של הפרוייקט שלנו הגדרנו בsolution אחד את הפרויקטים השונים כאשר היה פרויקט WEB ולכל שיכבה היה פרויקט משלה בנוסף הגדרנו פרויקט infrastructure שהכיל קוד שלא היה קשור ספציפית לפרויקט שלנו, לאחר שהצוות התחיל לפתח מערכת נוספת במקביל.
הוחלט להוציא את התשתיות של שני הפרויקטים לsolution נפרד ושני המערכות יבצעו reference לפרויקטי התשתית.
ובאמת זה מה שעשינו והגדלנו והוספנו רישום אוטומטי לGAC של DLL התשתית בשביל למנוע בלגן עם ריבוי גרסאות והעתקות של הDLLים. ואז ביום בהיר(למרות שהיה יום גשום נהוג לכתוב יום בהיר) ניסיתי לבצע דבאג למתודה שכרגע סיימתי לכתוב, אני רגיל לכתוב את המתודה ולהשתמש בה מתוך הפרויקט עצמו ואז ולבצע בדיקות למתודה דרך המערכת ולבצע דבאג עם צריך. אבל אבוי אני מנסה לבצע step into ולא מצליח.
לאחר כמה דקות של מחשבה הבנתי שאני לא יכול לבצע step into בגלל שלDLL אין קובץ PDB שיאפשר ביצוע דבאג, אבל מה עושים שאלתי קודם את עצמי ואחר כך את שותפי לדרך שני ואבי, וקיבלתי את התשובה הברורה לך יואב לך על האינטרנט ומצא תשובתך,
וכך עשיתי באינטרנט מצאתי משהו שנתקל בדיוק באותה הבעיה והוא מציע להעתיק את קובץ הPDB לתוך הספרייה המתאימה בGAC הפתרון הזה יגרום לזה שכשהVS ינסה לדבאג הוא ימצא את הקובץ הPDB ואת קובץ הDLL ביחד.
אבל הפתרון הזה דורש ממני להוסיף פעולת העתקה ידנית של קובץ באירוע post build, לאחר מחשבה נוספת הבנתי שיש פתרון פשוט בהרבה כל מה שצריך לעשות זה, מתי שרוצים לדבאג לבצע העתקה של קובץ הPDB והDLL לספריית הBIN של הפרויקט ואז הDLL יטען משם ולא מהGAC ובסיום הדבאג למחוק את הקבצים מהBIN ולהמשיך לעבוד מול הGAC.
לפני כ4 חודשים עברתי לצוות שמפתח מערכות GIS על גבי התשתיות של חברת ESRI. אנחנו בפרויקט שלנו עובדים מול הArcGis Server שהוא מוצר הדגל של ESRI, הAPI לכל הפעולות נקרא Arc Objects שזה בעצם אוסף של רכיבי COM שחיים על השרת ומאפשרים לך לעשות כמעט הכל מול כלי ESRI.
במסגרת החפיפה העבירו לי ולחברי לצוות סדנה שעסקה בכתיבת קוד Arc Objects בNET.
מרבית הסדנה עסקה בכמה שלא נוח לעבוד עם Arc Objects ודאגו להזכיר לנו שאי אפשר לבצע new למחלקות של Arc Object וחייבים לבצע יצירה של אובייקטים ע"י קריאה לServerContext.CreateObject, לי בתור תוכניתן asp החתימה נראתה מוכרת כי היא הייתה בדיוק כמו בעבודה מול רכיבי COM בASP, אבל למרות זאת אני מעדין לעבודStrong typed.
בתיעוד של ESRI ראיתי שהמתודה מקבלת מחרוזת שמזהה את סוג האובייקט esriGeomerty.Point או esriCatro.Map וכו'... ראיתי שטעויות בהפעלת הפונקציה לא משפיעות על קומפילציה ולכן אני הולך לבזבז הרבה מאוד זמן על התעסקות מרגיזה עם מחרוזות מציקות.
אז התחלתי לחפש פתרון לבעיה, הפתרונות שאני מצאתי הם:
- להגדיר enum עבור האובייקטים שאנחנו משתמשים בהם ביום יום ובכך להוריד את הצורך בהקלדה חוזרת שלהם.
- לעטוף את המתודה CreateObject באובייקט משלי שידע לקבל טיפוס נתונים ויתפקד כמו new.
לאחר בחינה קצרה החלטתי ללכת על הפתרון השני והגדרתי מחלקה גנרית עם מתודה בחתימה הבאה:
T ArcObjectFactory.CreateObject<T>();
כאשר T הוא טיפוס הנתונים שאנחנו רוצים ליצור.
המתודה תבצע את הבניה של המחרוזת עבור T ואחרי זה תבצע הפעלה של CreateObject.
בניית המחלקה הסתיימה לפני כ4 חודשים מאז אני מתכנת מול ArcObjects ואני יכול להגיד שאין לי מושג איך הייתי מסתדר בלי זה. אני כותב קוד קריאה יותר מהר יותר ומתעסק יותר בבעיות האמיתיות של הקוד ולא במלחמות במחרוזות.
לפני שבוע קיבלתי טלפון בעצבים מאחד המפתחים בצוות שעובד מול כלי ESRI, הוא אמר שהוא לא מוצא בשום מקום את המחלקה ArcObjectFactory מסתבר שהוא קיבל קוד לכתוב בArcObjects וכתבו לו להשתמש בArcObjectFactory אבל הוא לא מצא אותו בEDN וגם לא בMSDN אז הוא הלך לGOOGLE אבל גם שם הוא לא מצא אותו אז אני מבטיח לך יוסי מהיום הArcObjectFactory מופיע באינטרנט.
אחת הבעיות בעבודה בצוות זה שמשהו צריך לקרוא את הקוד שלך.
הרבה נכתב על כללים לכתיבת קוד קריאה, אני תמיד מנסה לכתוב קוד ברור אבל מאז ומעולם אני כותב בשגיאות כתיב, לי זה לא מפריע כי אני מבין מה שאני כותב אבל לא כולם כמוני.
בצוות הקודם שלי שגיאות הכתיב שלי הפריעו מאוד לחברי הצוות, אז הייתי מחזיק תמיד WORD פתוח ובודק שם את המילים שלא הייתי בטוח בהם, אבל זה לא הספיק בגלל שלא תמיד הייתי בודק בWORD והיו חיבורים מילים שהWORD לא ידע לפרק.
ואז באחד הערבים הקרים החלטתי לכתוב את הAdd in הראשון שלי לVS היה ברור לי שאני רוצה להשתמש במנוע של הWORD בשביל לבדוק את השגיאות ושאני רוצה לבצע שבירה של מילים לפי כללי הNaming הסטנדרטים.
אז התחלתי בהוספת reference לרכיב הcom של WORD 11, ובגלל שלא ראיתי תיעוד נורמלי, אז התחלתי לעבור על רשימת המתודות ומצאתי את GetSpellingSuggestions שמקבלת בערך 20 פרמטרים שונים ומחזירה את הצעות לתיקון של המילה המועברת.
ואז פניתי למשימה של שבירת המילים בגלל שWORD יודע לקבל מילה בודדת, אז קודם כל שברתי את הטקסט לפי רווחים ו"_" ועבור כל מילה ביצעתי שבירה לפי אותיות גדולות קטנות, כל זה טוב ויפה אבל לא מספיק כי זה חלק מAdd in לVS אז בתוך הקוד של Add in הוספתי את הקוד לקריאה של הטקסט המסומן ע"י הקוד הבאה:
string selectedText = ((TextSelection)_applicationObject.ActiveDocument.Selection).Text;
ואז כל מה שנשאר לי זה לחבר את הכל ביחד וקיבלתי את התוסף המושלם לVS שבודק לי את השגיאות ועוזר לחבריו הצוות שלי לקרוא את הקוד שלי.
לסיכום אני ממליץ לכל אחד ממכם לנסות לעבוד מול API של הWORD אתם תמצאו שם מתודות מעניינות כמו Dummy ועוד...
בעולם שבו הזמן שמוקדש למשימות קידוד הולך ויורד היכולת לשפר את סביבת העבודה שלנו, מאפשר לנו להגיע לתוצר איכותי בלו"ז קצר.
ולנסות לכתוב Add in ל VS.
מצורף הפרוייקט כהשראה למה שאפשר לעשות בVS.