תכנות - ליאור שיאון – קיים משמע אני חושב

מתכנת מעל גיל 45? הסתבכת

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

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

הבעיה עם אנשי תוכנה מבוגרים לא פשוטה. היא קשורה, בין השאר, לעובדה שהתחום שלנו כולו הוא צעיר, משתנה מאוד, וחוקים כללים עדיין לא ברורים בו. האם נסיון של עשרות שנים רלוונטי תמיד בעולם של פרדיגמות משתנות? מהי החשיבות של עדכנות מיידית בטכנולוגיות חדשות, ומהי החשיבות (במיוחד בעולם הווב) של שימוש אישי בשירותים חדשים (האם תוכל להיות מתכנת טוב אם אתה לא משתמש בפייסבוק? אם לא ראית את טרנטייבל?) – ואולי החשוב ביותר: בעולם הסטארטאפים המשתנה הדגש על חברתיות, כיף בעבודה ושיטות ניהול חדשות הוא גדול מאוד – האם באמת התירוץ הקבוע של "חוסר התאמה לאופי החברה" הוא כל כך לא רלוונטי?

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

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

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

חשיבות הכיסוי (coverage) בבדיקות התוכנה – ואיך עושים את זה בד'נגו

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

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

מהן בדיקות כיסוי (coverage)

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

חשוב לציין כמה נקודות קטנות בקשר לבדיקות האלה:

קשה מאוד להגיע ל100% בדיקות, ומעט מאוד אנשים חושבים שזה היעד. יש תלות מסויימת בקוד הספציפי שלכם, אבל קטנה מאוד – אני ממליץ לנסות להגיע לפחות ל70% כיסוי, ולא לנסות להלחם יותר מדי על ה10% האחרונים.
בדיקות קוד צד לקוח בעתיות יותר ואני לא הולך להתיחס אליהן בפוסט הזה (במיוחד כי הדגש כרגע הוא על django)
התירוץ החוזר הוא ש"הקוד שלנו שונה כי xyz, ולכן קשה בהרבה להגיע לכיסוי טוב". החליפו את xyz בדברים כמו "הוא מערב הרבה מודולים שונים", "אי אפשר להגיע לבדיקה של כל פינה", "יש לנו הרבה יותר נקודות קצה", והחביב עלי: "הקוד שלנו מאוד שונה כי הוא פועל על שילוב מחלקות שונות וקריאות מסובכות, תלויות חצוניות ודברים דומים". יש עוד הרבה כאלה. אל תקשיבו – עוד לא פגשתי קוד שבלתי אפשרי להגיע לאחוזים גבוהים של כיסוי – אם כי פגשתי קוד שהיה צריך לכתוב כמה mockups, נקודות קצה וירוטאליות ועוד משחקים שונים ומשונים.

בדיקות כיסוי בdjango

בדיקות הכיסוי בdjango במוססות על בדיקות כיסוי של נד בצ'לדר (Ned Batchelder) שנמצאות גם כאן או כאן. בחרו את הדרך הנוחה לכם להתקנה:pip install hg+https://bitbucket.org/ned/coveragepy

אוeasy_install coverage

וכדומה. בצורה דומה אפשר לחבר את החבילה לbuildout.

לאחר מכן התקינו את התוסף לdjango:https://bitbucket.org/kmike/django-coverage/src

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

לאחר שהתקנתם, הוספתם את django_coverage לsettingsINSTALLED_APPS, אתם כמעט מוכנים, ויכולים לבדוק את ההתקנה ע"י הרצה של

python manage.py test_coverage

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

בתוך management->commands (הפוסט הקודם מסביר את זה):

from django.core.management.base import AppCommand, BaseCommand[python] from django.core.management.base import AppCommand, BaseCommand from django.core.management import call_command from django.conf import settings class Command(BaseCommand): def handle(self, *args, **options): test_app_path = () for app in settings.MY_INSTALLED_APPS: test_app = app.split('.') if len(test_app) > 1: test_app = (test_app[-1],) else: test_app = (app,) test_app_path += test_app call_command("test_coverage",*test_app_path, **options) [/python]

הוסיפו בsettings שלכם את מיקום יצירת הhtml:

COVERAGE_REPORT_HTML_OUTPUT_DIR כדי לבחור את הספריה ליצירת תוצאות הHTML

קואניי (קואן) פייטון

קואן (Kōan) – הוא "סיפור, דיאלוג, שאלה או אמירה הנוגעת להיסטוריה או למסורת של הזן בודהיז וכוללת אספקטים שאינם מובנים באופן רציונלי, אלא בחשיבה אינטואיטיבית." (מתוך ויקיפידיה בעברית, למרות שהערך באנגלית טוב יותר). אחד הקואנים החביבים עלי ביותר הוא זה של הקול שעושה מחיאת כף יד אחת, מתוך אותה אפיסודה מצויינת של הסימסונים (עונה 2, פרק 6 אם אתם מחפשים).

הקואנים של פייטון (רעיון שבמקור נלקח מרובי למעשה) הם רשימה של 287 קואנים, או למעשה, Unit Test שנכשלים, והמטרה שלהם היא ללמד את השפה דרך הידיים – כדי לעבור את המבחן עליכם "לתקן" את הבדיקות שתעבורנה, וכך אתם לומדים את השפה. רעיון טוב, לא?

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

בהצלחה!