מתי "לכתוב את זה לבד" הופך לחוב טכני?
נתון קוד HTML/JavaScript שמציג תיבת קלט ואת מספר התווים בתיבה:
<input type="text" id="input" />
<p id="count">0</p>
input.addEventListener('input', (e) => {
count.textContent = e.target.value.length;
})
ואנחנו רוצים שמספר התווים יתעדכן רק פעם אחת אחרי שמשתמש מפסיק להקליד לשניה או שתיים. אפשר לכתוב לבד פיתרון:
let timeout = null;
input.addEventListener('input', (e) => {
clearTimeout(timeout);
timeout = setTimeout(() => {
count.textContent = e.target.value.length;
}, 500);
})
ויש לנו פיתרון מקומי שקצת מלכלך את הקוד אבל אני יכול לחיות איתו.
אבל אז יגיע מישהו שיחשוב שאולי יש פה בעיה כללית יותר וש timeout הוא משתנה גלובאלי ויהיה עדיף בהרבה לסגור את כל הלכלוך הזה בפונקציה:
input.addEventListener('input', debounce((e) => {
count.textContent = e.target.value.length;
}, 500));
function debounce(f, ms) {
let timeout = null;
return (...args) => {
clearTimeout(timeout);
timeout = setTimeout(() => {
f(...args);
}, ms);
}
}
והנה החוב הטכני שלנו.
מקוד קצר שאפשר להבין אנחנו צריכים לתחזק אבסטרקציה. ואבסטרקציה תמיד תהיה יותר מסובכת מפיתרון נקודתי כי צריך לחשוב מי עוד יכול להפעיל את הפונקציה debounce, מה הציפיות שלהם, איזה באגים יש או אין באבסטרקציה זו. ברור גם שלבחור שם טעון כמו debounce זו בעיה כי אם ההתנהגות שכתבתי לא זהה בדיוק ל debounce שכולם מכירים התפר יגרום לבאגים שקשה למצוא.
והאתגר הוא שוב AI. כי לפני AI היה ברור שאם אני צריך debounce כדאי לי להתקין את lodash והיה ברור איפה אני שומר כל אבסטרקציה בפרויקט וזה ידע שדאגנו להעביר בין מפתחים שונים בפרויקט. היום AI שמח לכתוב מחדש את debounce או פונקציות דומות כל פעם שהוא כותב פיצ'ר, ואנחנו צריכים להיות ערניים ולנקות אחריו. חוב טכני הוא אף פעם לא רעיון טוב, והעלות של חוב טכני אף פעם לא היתה בזמן הכתיבה שלו אלא בזמן התחזוקה.
נ.ב. היום בעשר וובינר מודלים חופשיים ומקומיים. אם יש לכם שעה פנויה שווה לקפוץ ולגלות על יתרונות הפרטיות והמחיר של מודלים כאלה. אם אין לכם עדיין את הלינק לזום אפשר להירשם כאן: https://www.tocode.co.il/talking_ai