ארכיון

ארכיון הכותב

כך החזרתי מכשיר מייזו U20 תמורת סכום מלא

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

אמ;לק

קניתי סמארטפון מייזו U20, והצלחתי להחזיר ל״באג״ תמורת החזר כספי מלא, למעט פחת של 7%.

ולעניין עצמו

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

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

עד ש..

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

זה גם ככה מבאס לקום בבוקר, אז חצי שעה מוקדם מדי, למה??

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

תחנה ראשונה: גוגל

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

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

ושיניתי גם הגדרות גלובליות במכשיר (בגדול: להעדיף ביצועים על פני חיי סוללה).

ולצערי, זה לא עבד. כלום לא עבד. האפליקציה עדיין הופעלה מוקדם מדי.

והקטע הוא שהשעון המעורר המובנה במכשיר, שהוא לא אפליקציה צד שלישי, עובד מצוין. אבל אין לו פיצ׳רים כמו אפליקציה צד שלישי.

תחנה שניה: עוד אפליקציות

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

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

תחנה שלישית: התמיכה של ״באג״

אוי, ״באג״, ״באג״. באמת באג.

כמה שיחות עם התמיכה הטכנית ועם שירות הלקוחות שלהם, וכמה הם כשלו במתן תמיכה טכנית ובמתן שירות…

כמה מהבעיות של ״באג״:

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

בנוסף לזה, כשביקשתי איזה מספר מזהה לפניה שלי לתמיכה הטכנית – לא היה כזה.

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

כל פניה שלי לשירות הלקוחות של ״באג״ היא כזו של יחס מזלזל כלפי הלקוח. יוצא דופן הוא מנהל שירות הלקוחות הארצי (מיד ארחיב).

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

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

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

סליחה? ״לפנים משורת הדין״?

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

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

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

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

תחנה רביעית: ניצחתי את ״באג״

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

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

אחרי משא ומתן, סיכמנו שהשריטה היא 7% פחת, שזה אומר 70 ש״ח על חשבוני.

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

מסקנות

  1. שווה להתעקש
  2. עדיף לעבוד במיילים מול תמיכה טכנית ומול שירות לקוחות, ככה יש תיעוד לכל דבר.
  3. אם יש למישהו מכשיר שכזה, הוא יכול בכיף להחזיר ל״באג״ ולקבל החזר, הבעיה עדיין קיימת
  4. אני, אישית, לא מתכוון לקנות ב״באג״ מכשיר שאולי אי פעם יצטרך תמיכה טכנית. התמיכה הטכנית שלהם עלובה, ושירות הלקוחות מזעזע.

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

קטגוריות:כללי, שופינג תגיות:

שוב על enum

2 ספטמבר, 2016 5 תגובות

כבר יצא לי לכתוב בעבר על שימוש לא נכון ב enum.

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

מצד אחד, מאוד נוח (ומפתה) דווקא כן לעטוף ערימה של קבועים ב enum, כי זה מעלה את הפרודוקטיביות כאשר משתמשים ב IDE כמו Visual Studio או IntelliJ Idea. שם כל מנגנוני ההשלמה האוטומטית פועלים יפה.

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

הבעיה

במקום לנפנף בידיים, אני אסביר ע"י קוד (ב Java, שבה אני מתכנת כיום).

נניח שיש לנו את ה enum הבא:

ויש לנו בקוד תנאי כזה:

עכשיו, בגלל שזה enum, אז נכון לזמן כתיבת הקוד, אם התנאי מתקיים, כלומר x הוא אכן Green, אז הבלוק של ה else לא יתבצע. כלומר, וזה ניואנס קריטי: הקוד של ה else יתבצע רק אם x הוא White או אם x הוא Blue.

ובכן, אם נוסיף עכשיו ערך חדש ל enum שלנו, נניח Brown:

התוכנית שלנו רצה, ועכשיו ערכו של x הוא Brown.

האם הקוד של ה else יתבצע?

ברור שיתבצע, הרי x איננו Green.

אבל ראינו קודם, לפני השינוי של ה enum, שהקוד של ה else אמור להתבצע רק במקרה ש x הוא White או Blue.

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

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

זה כל הסיפור.

כאמור, enum אמור להתייחס לקבוצה סגורה של ערכים, שמאוד לא סביר שתשתנה. כמו שמתכנת אחד (הי אסף!) אמר לי: אי אפשר להוסיף עוד יום בשבוע.

שינוי של enum עלול לשבור נכונות של קוד.

פשרות

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

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

פשרה ראשונה – ליצור קבועים שלא דרך enum

ב Java זה די פשוט: יוצרים public static final ובזה תמה יצירת קבוע סטטי.

מה הרווחנו:

  • קוד נכון יותר, שפתוח לשינויים
  • השלמה אוטומטית

מה איבדנו:

  • את היכולת לעבור על כל הקבועים האלה (אם ממש רוצים – פתיר ע"י מעטפת ב class יחיד ומעבר ע"י reflection).

פשרה שניה – ליצור enum עם חשיפה מינימלית

אפשר ליצור enum שיהיה private ברמת ה class (או ה package), ואז הסיכון של שבירת הקוד מצטמצם לטווח ההכרה של ה enum שיצרנו.

מה הרווחנו:

  • את כל היתרונות של enum: השלמה אוטומטית, מעבר על הערכים

מה הפסדנו:

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

סיכום

עבודה נכונה עם enum – מתחילה עם הבנה טובה ויסודית של הקונספט עצמו.

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

כאשר עובדים עם enum שעוטף נתונים, מסתכנים בשבירת לוגיקה של קוד.

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

קידוד נעים!

קטגוריות:תכנות תגיות:
Quantcast