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

פיתוח אפליקציית פתקים to do: היכן נשברת הלוגיקה

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

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

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

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

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

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

מה נותנת עבודת ליבה מחדש: סנכרון, חיפוש, עמידות

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

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

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

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

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

פורמטים למימוש: בונה, פלטפורמת ענן או קוד עצמאי

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

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

שלבי העבודה: ניתוח תרחישים, סכימת נתונים, בדיקה

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

1. ביקורת האפליקציה הנוכחית. מנתחים את סכימת אחסון הפתקים, היסטוריית המיגרציות וטיפול בעריכות ללא רשת. התוצר — רשימה של מקומות שבהם רשומות מוכפלות, נמחקות או נעלמות.
2. ניתוח תרחישים. קלט מהיר, צ'ק-ליסטים, תזכורות, קבצים מצורפים, חיפוש, מחיקה עם שחזור, עריכה בשני מכשירים בו-זמנית. לכל תרחיש — עדיפות וסימן "הנתונים חשובים יותר מהמהירות".
3. סכימת אחסון פתקים וסנכרון. מגדירים מבנה של ישויות, תוויות גרסאות וכלל מיזוג: מה מנצח בקונפליקט, איך מסומנת מחיקה, איך נשמר סדר הפריטים ברשימה.
4. תוכנית עבודה לשדרוג. פורסים את השינויים לפי סדר עם תאימות לאחור: קודם הרחבת הסכימה, אחר כך הלוגיקה, ואחר כך הממשק.
5. מימוש ומיגרציות. המעבר למבנה החדש נעשה בלי אובדן רשומות ומאפשר חזרה לגרסת האפליקציה הקודמת.
6. בדיקת סנכרון לפני שחרור. מריצים אובדן רשת, עריכה בו-זמנית, כניסה חוזרת ושחזור מגיבוי, ומשווים מספר רשומות וטקסט לפני ואחרי ההחלפה.
7. מסירה ומעקב. מוסרים תיעוד לסכימה, הוראות חזרה לאחור ומוני שגיאות החלפה, שמראים שהשחרור עבר כשורה.

חפצי מסירה: קוד מקור, בילדים, סכימת נתונים, נהלים

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

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

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

מקרה בוחן: האפליקציה הפסיקה לאבד עריכות ללא רשת

לקוח הגיע עם האפליקציה Заметки+ — פתקים ורשימות מטלות אצל עשרות אלפי משתמשים, ואובדן עריכות קבוע. פתק שנערך ברכבת התחתית ובטאבלט, בעת הסנכרון מחק גרסה מוקדמת יותר: פער גרסאות זוהה ב-6-8% מהסשנים ביום, ושחזור אחרי תקלת סנכרון ארך בתמיכה עד כמה שעות של בדיקה ידנית.

מה שינו

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

לאחר השדרוג, שיעור הסשנים עם פער גרסאות ירד ל-0.3%, מספר קונפליקטי העריכה לאלף סנכרונים — מ-74 ל-4, והשחזור לאחר תקלה הצטמצם משעות לדקות, ובמקרה טיפוסי נסגר בלי מעורבות התמיכה.

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

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

במה שונה רשימת מטלות אישית ממערכת משימות צוותית?

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

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

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

שאלות טכניות נפוצות לפני תחילת העבודה

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

מה קורה בעריכה משני מכשירים?

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

איך מעבירים פתקים משירות אחר?

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

האם פתקים ישרדו תקלת מכשיר?

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

איך בנויות תזכורות וקבצים מצורפים?

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

נדון במשימה: מה נדרש להערכה ולתוכנית

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

מה לשלוח להערכה:

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

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