הבלוג של ינון פרק

איך לא טיפלנו בזה כשזה רק התחיל? נו זה ברור-

• בהתחלה זה לא נראה כזה ביג דיל

• היה נדמה שתמיד אפשר לשנות בעתיד

• רצינו לעלות לאוויר

• רצינו להתקדם בפיצ'רים יותר חשובים

• זה לא היה שווה את המאמץ

ועכשיו? עכשיו מאוחר מדי: יש כבר לקוחות שמכירים את כתובת ה IP שלנו ומסתמכים עליה; הנתונים ב DB כבר שמורים בצורה מסוימת ויש יותר מדי שורות בשביל להתחיל להעתיק לטבלה חדשה; הקוד כבר הועתק ברחבי המערכת; יש יותר מדי פיצ'רים ולא ברור איפה מתחילים לכתוב בדיקות.

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

לא, זו לא שגיאת כתיב בכותרת - אכן יש מערכת ענן חינמית לגמרי בשם deta שכוללת גם בסיס נתונים וגם אפשרות לכתוב קוד ווב ב Python או Node.JS. הלכתי לשחק עם ה API שלהם כדי לראות מה אפשר לקבל בלי לשלם.

בכתיבת קוד בדיקה תקופה ארוכה שאני מעדיף להשתמש בערך ההחזר של render במקום ב screen הגלובאלי בעת כתיבת הבדיקות, כלומר אני מעדיף את הגירסה הזאת:

import { render } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  const screen = render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).not.toBeInTheDocument();
});

על פני:

import { screen, render } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).not.toBeInTheDocument();
});

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

בתקופה האחרונה העדפה זו נהייתה קשה יותר לביצוע בגלל ש create-react-app כולל הגדרות eslint שממליצות בדיוק על ההיפך, כלומר על הגישה השניה. ההסבר שלהם כאן: https://github.com/testing-library/eslint-plugin-testing-library/blob/main/docs/rules/prefer-screen-queries.md

מה עושים? מתקנים את ה eslint כמובן. בתוך הקובץ package.json של פרויקט create-react-app חדש נוכל למצוא את הבלוק הבא:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },

כל מה שצריך לעשות זה לזהות את שם הכלל מתוך הודעת השגיאה או דף ההסבר על הכלל, במקרה שלנו הכללים הבעייתיים הם testing-library/prefer-screen-queries ו testing-library/render-result-naming-convention ואז מוסיפים בלוק rules ל package.json שמנטרל את שניהם:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ],
    "rules": {
      "testing-library/prefer-screen-queries": "off",
      "testing-library/render-result-naming-convention": "off"
    }
  },

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

נ.ב. אפשר להשתמש בטריק הזה כל פעם שאתם לא מסכימים עם eslint. מותר לחשוב אחרת.

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

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

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

ואותו דבר לגבי הבחירה בין Redux ל MobX, בין ריאקט ל Vue, בין GraphQL ל REST. ובכל זאת נדמה שהאושר הכי גדול שלנו הוא להיתקע על אותן פינות לא חשובות הרבה יותר מדי זמן בתור צורה של הסחת דעת. כאילו הלב רוצה לעשות הכל חוץ מלהתקדם.

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

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

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

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

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

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

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

אבל זו אשליה.

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

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

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

import { useRef } from "react";

export default function App() {
  const inputRef = useRef(null);
  const hasText = inputRef?.current?.value !== "";

  return (
    <div className="App">
      <h1>Write some text to enable the button</h1>
      <input type="text" ref={inputRef} />
      <button 
          disabled={!hasText}
      >Go</button>
      <p>hasText = {hasText}</p>
    </div>
  );
}

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

ב 2008 קניתי את הסמארטפון הראשון שלי כי חשבתי שזו פלטפורמה מלהיבה להרצת קוד - מחשב שזמין בכל מקום, כולל שבב GPS, מצלמה וחיבור קבוע לרשת. זה היה N95 של נוקיה ולקח לי כמעט חצי שנה עד שהבנתי איך שפת המאקרו-אים שהם בנו מעל C++ עובדת והצלחתי לבנות אפליקציה.

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

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

import SwiftUI

struct ContentView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("Turtle Rock... \(count)")
                .font(.title)
                .foregroundColor(.orange)
            .padding()
            Stepper(value: $count, in: 1...10) {
               Text("Hello")
            }
            Button("Click Me", action: {
                self.count += 1
                print("count = \(count)")
            })
        }

    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

בגדול אם תפעילו את הקוד ב XCode הקרוב אליכם תגלו ש:

1. הקוד מציג על המסך טקסט, מתחתיו משהו שנקרא Stepper (תכף ארחיב עליו) ומתחתיו כפתור. בטקסט כתוב המשפט Turtle Rock ואחריו מספר. לחיצה על הכפתור מעלה את המספר ב-1

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

וכמה מילים על הקוד עצמו:

1. ב Swift מה שמופיע על המסך הוא View, ואפשר להגדיר View-ים משלנו. כל View הוא דבר שנקרא struct שזה משהו שהזכיר לי קלאס משפות אחרות. בקוד המודבק יצרתי View בשם ContentView.

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

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

4. אלמנט VStack לוקח את ה View-ים שתתנו לו ומציג אותם על המסך אחד מתחת לשני.

5. אלמנט Text הוא View שמציג טקסט.

6. ה Stepper הוא לדעתי החלק הכי מעניין בקוד. הוא מקבל סוג של "הפניה" למשתנה count כדי שיוכל לשנות את ערכו, ובגלל זה צריך היה לכתוב $count.

7. החלק הקשה היה להריץ את הקוד על הטלפון. היה צריך להתחבר עם ה Apple ID שלי ל XCode, ואחר כך בטלפון להיכנס להגדרות ולסמן שאני מוכן להריץ יישומים שאני כתבתי. לא צריך לשלם לאפל בשביל לכתוב קוד ולהריץ אותו על הטלפון שלכם, אבל בשביל לכתוב ולהפיץ בחנות הם ירצו את ה 99$ לשנה שלהם.

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

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