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

כשהבעיות הופכות יותר מורכבות האימות נהיה קשה יותר אבל הרבה פעמים עדיין אפשרי. אם יש לך בעיה בקוד מקבילי שנובעת מ Race Condition בין התהליכונים השונים אז צריך יותר להתאמץ כדי לראות את הבעיה בסביבת בדיקות ואולי להוסיף המתנות יזומות כדי שמקרה הקצה באמת יקרה יותר פעמים. או אם יש לכם בעיית ביצועים בשרת רק במצב של עומס מסוים אז צריך להתאמץ ולסמלץ את אותו העומס בסביבת הבדיקות כדי שנוכל לבדוק אם השינוי שלנו פותר את הבעיה.

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

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