פיתוח תוכנה באקסל
תוכנת אקסל נועדה בעיקר עבור בניית מחשבונים, סימולטורים, יצור של דוחות גמישים וגרפים, אך למרות שתוכנת אקסל נועדה בעיקר עבור משימות אלו, משתמשי אקסל משתמשים באקסל בצורות נוספות ומגוונות מאוד כמו: קבצים שמכילים גיליונות שמטרתן הזנת מידע, תיעוד, גיבוי, כלי להעברת מידע בין תוכנות ומסד נתונים שטוח, ובנושאים מגוונים כמעט על כל תחום אפשרי, כמו ביטוח, פנסיה, נדלן, רפואה, מחקר, סקרים, תעופה, שוק ההון, פיננסים ועוד.
הכוח של אקסל הוא גם החולשה שלו
ניתן להמשיל קובץ אקסל לדף נייר חלק, מותר לכתוב מה שרוצים, לחשב איך שרוצים, אין ביקורת על המשתמש ואין חוקים.
מצד אחד ניתן לומר שזה מצוין, מאחר ויש חופש למשתמש לבנות את הקבצים שלו כמו שהוא צריך מבלי מגבלות ולמעשה זה מה שגורם לאקסל להיות כל כך פופולרי ומגוון באופן השימוש שלו, אך מצד שני זה גם מאוד מסוכן, מאחר והמשתמש יכול לבנות כלים רבי עוצמה ללא מסגרת מגבלות שתואמות את העסק שלו, כך שטעויות אנוש עלולות לשבש את כל התוצאות שהתקבלו.
למעשה ניתן להמשיל את הרעיון על כל מערכת חוקית שקיימת בעולם, למשל, דמיינו כמה נחמד היה יכול להיות אם לא היו חוקי תנועה, משמע חופש מוחלט לעשות מה שרוצים בכביש, אין רמזור שיעצור אותך, אין מגבלת מהירות שתאיט אותך ואין תמרורי ״אין כניסה״ מרגיזים בדיוק ברחוב שאתה צריך להיכנס אליו, יכלה להיות מציאות כזאת, אך כולנו מבינים שעדיף ״לשלם״ מחיר על מגבלות, בכדי לשמור על החיים עצמם, כלומר עצם קיומם של חוקי התנועה אומר, שעל כף המוזניים, הבטיחות חשובה יותר מחופש תנועה מוחלט בכביש.
אז מה חשוב בבניית אקסל חכם ?
בכדי שפרויקט יצליח, ישנם שלושה נושאים עיקריים סופר חשובים שבלעדיהם הפרויקט יכשל או לכול הפחות יחשב כפרויקט לא מוצלח.
שלושת הנושאים הם:
- אמינות
- גמישות לשינויים
- ביצועים
אמינות
אמינות זה הנושא החשוב ביותר בפרויקט שלכם, אמינות משמע שהמידע שנמצא במערכת הוא תקין ללא שגיאות.
רוב הלקוחות שמזמינים פרויקטים נוטים לחשוב שהחלק המסובך בפרויקט שלהם הוא חישובים כאלו ואחרים, אך ברוב המקרים החלק הקשה ביותר לפיתוח במערכת, זה העיסוק בלשמור בכל רגע נתון על כל חלקי המערכת כיחידה אחת שעובדת לפי כללים ברורים שתואמים את ההתנהלות העסקית.
ישנם כללים רבים שחובה לשמור עליהם בכדי שהמידע שמוצג למשתמש יהיה אמין, מספר דוגמאות:
- סוג נתונים – אם מדובר במערכת שכוללת הזנת מידע מהמשתמש, אז יש לבדוק כל נתון שמוזן על ידי המשתמש שהוא תואם את סוג המידע שלו המערכת מצפה, כלומר שדה מסוג תאריך, חובה שהמשתמש יזין תאריך ולא ערך אחר, שדה מספרי יהיה מספר, אחוז יהיה אחוז, טקסט יהיה טקסט וכו׳…
- שדות חובה – בכל מערכת שכוללת הזנת מידע יש שדות שחובה להזין אותם, שבלעדיהם המידע לא יהיה תקין והנזק בחסרון המידע עלול להיות גדול.
למשל אם אנחנו מזינים מידע שמתעד מכירת מכוניות בכדי שבסופו של דבר נוכל לקבל דוח של סך המכירות התקופתי של העסק, במידה ולא תהיה בדיקה שאכן הוזן ערך עבור ״סכום המכירה״ ונתון זה ישכח, תוצאות הדוחות יהיו שגויות, על כן חובה ליצור אילוץ שהמשתמש לא יוכל להזין מידע ללא שדות חובה. - מניעת הזנת שורות זהות – בטבלאות רבות שמזינים אליהם מידע היינו מצפים שתהיה לנו שורה אחת ייחודית לכול פרט בטבלה.
למשל אם יש לנו טבלת לקוחות ויש לנו שדה ת.ז של לקוח, הרי שוודאי היינו רוצים למנוע הזנה כפולה של אותו לקוח, על ידי בדיקה לפני ההזנה של ״האם מספר הת.ז כבר קיים בטבלה ?״ במידה וכן נודיע שלקוח זה כבר קיים במערכת. - הזנת מידע שתואם את חוקי העסק – יש לבדוק שהמשתמש הזין נתונים שתואמים את החוקים העסקיים, למשל אם מדובר במערכת שדורשת הזנת נתונים של לקוחות שמעוניינים לקבל הצעת מחיר לביטוח רכב והמשתמש אמור להזין תאריך לידה ופרטים נוספים כלשהם, אחד הכללים של העסק שהוא כפוף לחוק בישראל, משמע, הגיל המינימלי להוצאת רישיון נהיגה הוא 17, הרי שחייבת להיות ביקורת שאם המשתמש ניסה להזין תאריך לידה של לקוח שהגיל שלו יוצא קטן מ 17 הרי ודאי שלא ניתן לבטח אותו מאחר ולא יכול להיות לו בכלל רישיון נהיגה, אם לא תהיה מניעה כזאת, המשתמש יוכל להפיק ביטוח שסותר את החוק.
- שלמות המידע – רוב המערכות כוללות טבלאות שבדרך כלל מקושרות בניהם על ידי שדות כלשהן. למשל טבלת לקוחות וטבלת הזמנות.
למשל, מה יקרה לטבלת ההזמנות, אם ארצה לעדכן בטבלת הלקוחות את שם הלקוח מ-״אבי לוי״ ל-״אבי לוי בע״מ״ והוא כבר כתוב פעמים רבות בטבלת ההזמנות ? האם אצטרך לעדכן בכל מקום שמופיע השם ״אבי לוי״ ? ומה אם הוא מופיע בטבלאות רבות אלפי פעמים ? כמובן שבמערכת מקצועית, ראוי שהשם התעדכן אוטומטית בכל טבלה או דוח שהוא מופיע במערכת, אחרת אנחנו עלולים למצוא את עצמנו עם שמות שונים מפוזרים ברחבי המערכת ללא יכולת לדעת את המשמעות המערכתית שלהם. - היררכיה של שדות (רמות) – ישנן מערכות רבות שנדרש בהן ניהול היררכיה של שדות, למשל, מערכת שכוללת מחלקות ועובדים ששיכים למחלקות מסוימות. במערכת מסוג זה, ראוי שאבחר מתוך רשימה את המחלקה הרצויה ובשדה העובד יפתח לי רשימה רק עם שמות העובדים ששיכים למחלקה שנבחרה, כל זאת בכדי למנוע את האפשרות של בחירת צרוף מחלקה עם עובד שאינו שייך למחלקה.
- טעינת מידע מקובץ חיצוני – טעינת קובץ חיצוני, דורש בדיקות מידע זהות לבדיקות הנדרשות במקרה של הזנת מידע באופן ידני.
- טרנזקציות – אוסף של פעולות שצריכות להתבצע בשיטת "הכול או כלום". לדוגמה, תחשבו על הפעולות שצריכות להתבצע כאשר מבצעים פקודה של העברה בנקאית, פעולה ראשונה צריכה להפחית את הסכום שנשלח מהעו"ש ופעולה שנייה צריכה לשלוח כסף לזיכוי חשבון אחר, חישבו מה יקרה אם פעולת ההפחתה מהעו"ש בוצעה ובדיוק באותה שנייה שפעולת השליחה אמורה להתבצע, משהו במחשבי הבנק השתבש (הפסקת חשמל או קריסת השרת למשל), במקרה כזה ירד לנו הסכום מהחשבון אבל הצד השני יטען שלא קיבל כסף.
יש אין ספור דוגמאות לדברים שדורשים טרנזקציות, כמו מכירת מוצר והורדה שלו מהמלאי במחסן, העברת בעלות רכב, מכירת כרטיסים לסרט וכו'…
אם אתם שואלים את עצמכם, ״כל הכללים האלה כאלה חשובים ?״
אז התשובה היא: כן ! מאוד ! ללא הכללים הללו, זה עניין של זמן עד שהמערכת תאבד את הקשר שלה עם המציאות וככול שהיא מורכבת יותר ככה זה יקרה מהר, מאחר ומערכות מחשוב סובלות מאוד מתופעת "אפקט הפרפר", תקלה במקום אחד של המערכת יכולה לגרום לשגיאות קשות במקומות אחרים.
גמישות לשינויים ותוספות
אם אתם מתכננים מערכת שתשמש אתכם לאורך זמן, הסיכוי שתזדקקו לשינויים הוא גבוה.
לפעמים השינויים נובעים מרצון להוסיף פונקציונליות חדשה למערכת, לפעמים זה נובע משינויים רגולטורים כפויים, לפעמים שינויי חוקים בעסק עצמו ולפעמים התיאבון גדל ורוצים להוסיף עוד פונקציונליות במערכת, תהיה הסיבה אשר תהיה, שינויים לרוב הם בלתי נמנעים.
ישנן כללים רבים ונוקשים כיצד לעבוד נכון בכדי לפתח קבצים שהיו גמישים לשינויים, כמובן שככול שהפרויקט גדול יותר, כך מפתח המערכת יצטרך לעבוד קשה יותר בכדי שמלאכת הגמישות לשינויים תהיה קלה יותר.
במערכות מורכבות, פעמים רבות, מפתחים מגיעים למצב שהם לא יודעים מה יקרה לפונקציונליות מסוימת במערכת, אם הם יעדכנו נושא אחר שעלול להשפיע עליו, מצב מסוג זה הוא מצב שעלול להביא לדרך ללא מוצא, שיש להימנע ממנה.
ביצועים
אז נניח והשקענו הון עבור פיתוח מערכת עם רמת אמינות גבוהה מאוד ותשתית מצוינת לשינויים ותחזוקה, אבל אחרי כל פקודה שמתבצעת יש זמן המתנה ארוך… לא כיף במיוחד.
אז כאשר אומרים "ביצועים" הכוונה לזמן תגובה של המערכת עבור הבקשות שלי.
נושא של ביצועים הוא לא רלוונטי לכול פרויקט, ישנם פרויקטים רבים שלא משנה טיבו של המתכנת וטכניקות העבודה שלו, הוא לא אמור להיתקל בבעיות ביצועים, אבל ישנם פרויקטים שנושא הביצועים הוא קריטי, לרוב נושא של ביצועים יהיה רלוונטי כאשר יש דרישה לעבודה עם כמות גדולה של מידע או חישובים (אלגוריתמים) ארוכים ומורכבים.
בנושא זה בדיוק כמו בנושאים הקודמים ישנה חשיבות גדולה לטיב המתכנת והניסיון שלו, מאחר וצריך להכיר טכניקות עבודה רבות שדרכן ניתן להגיע לשיפור משמעותי של ביצועים.
האם אני צריך מתכנת אקסל ?
רצוי שכול אחד ידע איך משתמשים באקסל, מי ברמה כזו ומי ברמה אחרת, כול שימוש הוא מבורך, אך אם אתה מפתח קובץ חכם שאמור לספק פיתרון עבור נושא חשוב, עליך לעשות כל שביכולתך שקובץ האקסל שאתה בונה יהיה אמין ואיכותי.
במידה ואתה מנהל קובץ עם טבלה אחת, עם מספר מועט של עמודות ואתה מנהל את הקובץ בעצמך וגם אתה מכיר על בוריה כל שורה שהוזנה לקובץ, יתכן ואין צורך לדאוג, מאחר והסיכוי שלך להזין מידע שגוי לטבלה אחת פשוטה אינו גבוה, הבעיה מתחילה כאשר אנחנו נדרשים לנהל מידע רב, שמתפרס על טבלאות רבות, כאשר לכול טבלה חוקים משלה והעלילה מסתבכת יותר, אם יותר ממשתמש אחד אמור לעבוד על הקובץ ואם שאר המשתמשים גם עובדים בו זמנית, שלא מכירים כל חוק קטן בעסק ועלולים להזין מידע שסותר את החוקים של העסק, במצב כזה, האמינות של המערכת מוטלת בספק וכשאין ביטחון במערכת שעובדים איתה ומקבלים החלטות חשובות לפיה, אין למערכת זו שום זכות קיום, מאחר והנזק שהיא עלולה להסב גדול מהתועלת.