• בלוג
  • חמישה פיצ'רים שעדיף ליישם לפני שהמערכת שלכם הופכת פופולרית

חמישה פיצ'רים שעדיף ליישם לפני שהמערכת שלכם הופכת פופולרית

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

1. מערכת ניהול המאפשרת "התחברות" למשתמש פעיל

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

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

2. מערכת מעקב אחרי אירועים ונתונים היסטוריים

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

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

3. סט בדיקות מערכת מקיף

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

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

4. תרגום

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

5. פריסה עולמית והקמה מהירה של שרתים

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

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