למה הכלי לבניית אפליקציות עם בינה מלאכותית מראה לכם נתונים מזויפים קודם (ולמה זה הצעד הנכון)

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

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

מה “נתונים מזויפים קודם” באמת אומר

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

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

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

למה הסדר הזה עובד טוב יותר עם בינה מלאכותית

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

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

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

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

על מה להסתכל כשהנתונים המזויפים על המסך

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

כמה דוגמאות למה לשים לב:

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

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

למה הסדר חשוב למה שמגיע אחר כך

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

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

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

בדיקה קטנה שאתם יכולים להריץ

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

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

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