1
00:00:00,009 --> 00:00:02,400
וייב קודינג זה קצת כמו לבנות בית לבד.

2
00:00:02,559 --> 00:00:03,000
דבר ראשון

3
00:00:03,039 --> 00:00:07,960
מורידים את הדלת עם פטיש, אחר כך אומרים לו לפתוח חלון, ואז להזיז אותו.

4
00:00:08,319 --> 00:00:11,989
בצהריים, אתה שוכח איפה החלון כי הזזת אותו כל כך הרבה פעמים.

5
00:00:12,640 --> 00:00:16,120
הקצב מרגיש לך איטי אז אתה פותח עוד כמה חלונות במקביל.

6
00:00:16,639 --> 00:00:20,920
למחרת מגיע חשמלאי לחבר תריס גלילה ומקבל חום.

7
00:00:21,120 --> 00:00:25,040
מבקש שרטוטים ומקבל רשימת TODO מלפני שבוע.

8
00:00:25,440 --> 00:00:32,470
אשתך בכלל לא הייתה מעורבת בתהליך. השיפוץ מסתיים, אבל אף חברה לא רוצה לבטח את הבית.

9
00:00:32,479 --> 00:00:36,319
אתה משלם כפול לאדריכלית וצוות שיבנו הכל מאפס.

10
00:00:37,229 --> 00:00:43,909
ככה היה נראה וייב בימים הראשונים. אז הוסיפו לו מצב plan, שמעודד אותך לתכנן, לתת

11
00:00:43,909 --> 00:00:49,509
לו את כל הקונטקסט, לפני שהוא כותב שורת קוד אחת. זה עבד, לרוב, אבל הוייב

12
00:00:49,509 --> 00:00:57,110
אוהב לרצות. מה ששכחת בתכנון הוא השלים לבד. מה שהשתמע לשני פנים הוא החליט בעצמו.

13
00:00:57,110 --> 00:01:03,750
אז הוסיפו לו מצב אינטראקטיבי, כזה שמשלים פערים, ששואל אותך (וגם ממליץ) על דרך מועדפת.

14
00:01:04,154 --> 00:01:05,495
זה הרגיש מעולה.

15
00:01:05,684 --> 00:01:10,735
ארכיטקט תוכנה שמוודא יסודות טובים, שיש לו ראיה מלאה על הפרוייקט.

16
00:01:11,565 --> 00:01:12,404
עכשיו אפשר לקודד.

17
00:01:12,644 --> 00:01:13,135
וכן,

18
00:01:13,525 --> 00:01:19,925
מערכות ואתרים בגודל סביר, סקריפטים מורכבים, עבדו, לפעמים בניסיון הראשון, ב-one-shot.

19
00:01:20,830 --> 00:01:24,309
הבעיה חזרה שהיית צריך לעשות שינויים בקוד. היא מעולם

20
00:01:24,309 --> 00:01:27,470
לא הייתה בעיה של יכולות, אלא בעיית זיכרון.

21
00:01:28,029 --> 00:01:30,690
ה-plan היפה שעשית - נזנח,

22
00:01:31,480 --> 00:01:33,900
או כי שכחת לעדכן אותו בכל שינוי מהותי,

23
00:01:34,150 --> 00:01:38,019
שכחת להכליל אותו בכל פרומפט או זכרת להכליל אותו

24
00:01:38,029 --> 00:01:39,860
אבל חלון הקונטקסט נגמר.

25
00:01:40,629 --> 00:01:43,510
מחוללי קוד מוגבלים בטקסט שהם יכולים לעבד.

26
00:01:43,949 --> 00:01:48,910
אז התחלת ביום ראשון עם תוכנית סדורה ו-2 בקשות לשינויים, שהפכו

27
00:01:48,910 --> 00:01:54,459
ל-20, עכשיו המודל רואה 20 בקשות ואת תוכנית המקור הוא ניקה.

28
00:01:55,339 --> 00:02:01,330
מתכנתים הבינו שיש בעיה בחלון אז הם ניסו את ג׳מיני פרו ו-GPT מקס ואז סופר-מקס -

29
00:02:01,660 --> 00:02:04,919
פלסטר שלא רק זלל את הטוקנים החודשיים תוך דקות,

30
00:02:05,260 --> 00:02:06,940
גם לא פתר שום בעיה -

31
00:02:07,339 --> 00:02:12,139
מודלים פשוט דולפים והוזים ככל שיש להם יותר טקסט בזיכרון.

32
00:02:12,820 --> 00:02:15,490
זה אולי נסלח כשאתה מבקש תקציר למאמר,

33
00:02:16,380 --> 00:02:17,660
אבל בתוכנה זה הרסני.

34
00:02:18,509 --> 00:02:24,710
באותו הזמן בערך, הלכנו כמו כבשים ל-MMMMCP, ספריית כלים שהבטיחה להשאיר אותנו

35
00:02:25,820 --> 00:02:27,440
ב-IDE, לגשת בשבילנו לדאטהבייס,

36
00:02:27,619 --> 00:02:31,710
ל-figma, לגיטהאב ולהביא לנו עוד קונטקסט. סטנדרט

37
00:02:31,710 --> 00:02:36,110
רעשני מאוד, איטי ובזבזני שמילא הרבה מהחלון.

38
00:02:36,589 --> 00:02:44,429
כך יצא ש-20 שרתי MCP - תפסו רבע מהחלון רק על הגדרות, וגם בלבלו את המודל בנחיצות שלהם.

39
00:02:45,539 --> 00:02:48,979
וייב קודינג דור 2 היה spec-driven.

40
00:02:49,259 --> 00:02:52,449
מה אם במקום לדחוף את התוכנית המלאה לזיכרון,

41
00:02:52,740 --> 00:02:54,080
נשים אותה בקובץ.

42
00:02:54,339 --> 00:02:57,699
ומה אם במקום קובץ גדול, נפרק למשימות קטנות.

43
00:02:58,300 --> 00:03:02,440
Taskmaster AI של הקנדי אייל טולדנו הייתה

44
00:03:02,440 --> 00:03:07,300
ה-framework הראשון, לדעתי, שהציע פתרון לבעית הקונטקסט.

45
00:03:07,740 --> 00:03:11,309
אם אני יכול לבקש מ-Cursor לעבוד רק על משימה אחת בכל פעם,

46
00:03:11,580 --> 00:03:14,300
אז החלון שלו מתנקה בכל הרצה.

47
00:03:14,740 --> 00:03:19,350
אם אני יכול לומר ל-Taskmaster לסמן את המשימה כהושלמה,

48
00:03:19,699 --> 00:03:25,539
אני יכול לחזור לשפץ את הבית במשך ימים או שבועות בלי שהמצב ייצא משליטה.

49
00:03:26,550 --> 00:03:29,630
אבל לקח עוד כמה חודשים להבין איך להסביר

50
00:03:29,630 --> 00:03:34,210
ל-Cursor מהי משימה מושלמת, ומהי ה-definition of done.

51
00:03:34,899 --> 00:03:38,350
באותו הזמן קלוד קוד, סייען קוד שחי ומריץ פקודות

52
00:03:38,350 --> 00:03:44,139
בטרמינל, וגם skills, קובץ הוראות לתהליכים, הפכו מאוד פופולריים.

53
00:03:44,149 --> 00:03:49,029
מה אם במקום להקיא עוד ועוד קוד, נבקש מהסייען לכתוב

54
00:03:49,029 --> 00:03:54,070
טסט לכל משימה, ורק כשהטסט יעבור, נמשיך למשימה הבאה?

55
00:03:55,020 --> 00:03:56,089
זה פתר שני דברים -

56
00:03:56,100 --> 00:04:03,289
גם מילא את הקוד בטסטים שבודקים אוטומטית מקרי קצה, וגם מנע מהסייען ספירלה של טעויות.

57
00:04:03,619 --> 00:04:10,929
הטסטים האלה הפכו לחלק מהקודבייס, ונפחו בו ביטחון. המתכנתים הבינו טוב יותר מה הם,

58
00:04:11,619 --> 00:04:17,119
כלומר הסייען, כתב, וגם לו - היה עוד קוד להסיק ממנו למשימות הבאות.

59
00:04:17,619 --> 00:04:20,220
אפשר להתווכח על האיכות אבל וייב קודינג Made

60
00:04:20,220 --> 00:04:22,750
Test Driven Development או TDD, Great Again.

61
00:04:24,760 --> 00:04:29,739
היה מרתק לצפות בריצה של Taskmaster, ועוד חקיינים אחרים, אבל מיקרוסופט

62
00:04:29,739 --> 00:04:35,140
הייתה נחושה לנצח במירוץ הזה. עם Github Speckit היא עשתה שני

63
00:04:35,140 --> 00:04:41,299
דברים נכון - תמיכה ב-20 סייעני קוד בהתקנה אחת, והכנסה של עוד

64
00:04:41,299 --> 00:04:46,140
קצת סדר, אולי יותר מדי סדר, לתהליך. אני מתרגם מה-README:

65
00:04:47,040 --> 00:04:49,200
״במשך עשורים הקוד היה המלך.

66
00:04:49,510 --> 00:04:50,000
ה-Specים,

67
00:04:50,160 --> 00:04:54,040
ההנחיות ננטשו ברגע שעבודת הקידוד האמיתית החלה.

68
00:04:54,519 --> 00:04:56,959
Spec-Driven Development הופך את המשוואה -

69
00:04:57,239 --> 00:04:58,920
ההנחיות הופכות להוראות,

70
00:05:00,290 --> 00:05:01,859
לעובדות, ומיושמות כלשונן״.

71
00:05:02,850 --> 00:05:03,320
אמרתי

72
00:05:03,329 --> 00:05:06,929
אולי קצת יותר מדי סדר. ב-Spec Kit צריך להגדיר Constitution,

73
00:05:07,089 --> 00:05:10,190
סט חוקים והחלטות שרלוונטיות לכל הפרוייקט,

74
00:05:10,529 --> 00:05:11,010
למשל:

75
00:05:11,290 --> 00:05:13,769
חווית משתמש אחידה וריספונסיבית,

76
00:05:14,130 --> 00:05:17,809
קוד שיעמוד ברמת אבטחה וביצועים, ושיהיה TDD.

77
00:05:18,649 --> 00:05:26,609
בשלב השני מגדירים Spec. לא לכל הפרוייקט אלא ברמת הפיצ׳ר - מה אתה רוצה להשיג, ולמה, אבל לא איך.

78
00:05:26,609 --> 00:05:30,170
למשל - עבור חנות וירטואלית אני רוצה ממשק אדמין עם

79
00:05:30,170 --> 00:05:33,529
3 רמות של הרשאה (מנהל, עוזר מנהל וקופאי), שיוכלו

80
00:05:33,529 --> 00:05:36,570
לבצע שינויים, וכל פעולה תישמר לצורך ביקורת, ולכל משתמש

81
00:05:36,570 --> 00:05:40,809
יהיה פרופיל עם הגדרות אישיות. Speckit לא רוצה שתגדיר

82
00:05:40,809 --> 00:05:47,489
שום דבר טכני כאן, זה שלב שנועד למנהלי מוצר, כזה שישרוד גם החלפה של כל הסטאק הטכנולוגי.

83
00:05:48,260 --> 00:05:55,660
הוא אמור להכיל עשרות user stories, ו-acceptance criteria ו-edge cases, אבל אנחנו מתכנתים עסוקים.

84
00:05:55,660 --> 00:06:01,140
Speckit יבנה את המסמך הקפדני הזה בשבילך גם אם תזין אותו בכמה פסקאות.

85
00:06:02,119 --> 00:06:04,109
לשלב הזה יש כמה תוצאות:

86
00:06:04,119 --> 00:06:10,160
ספריה חדשה תחת specs עם שם הפיצ׳ר וגם branch חדש ב-git, וגם שאלות הבהרה.

87
00:06:10,839 --> 00:06:16,670
התשובות שתיתן הופכות להיות חלק מה-spec ומניעות את השלב השלישי - Plan -

88
00:06:16,679 --> 00:06:21,339
את האיך. כאן מצופה ממך לצלול כמה שיותר טכנית.

89
00:06:21,679 --> 00:06:23,230
איפה מתנהלות הטבלאות?

90
00:06:23,279 --> 00:06:23,829
Postgres או

91
00:06:23,839 --> 00:06:24,519
Mongo?

92
00:06:24,559 --> 00:06:25,600
איך לגשת אליהם?

93
00:06:26,079 --> 00:06:27,190
raw או orm?

94
00:06:27,200 --> 00:06:28,730
האם להוסיף שכבת קאשינג?

95
00:06:28,760 --> 00:06:31,000
האם להשתמש בספריית ספציפית?

96
00:06:31,549 --> 00:06:32,220
השלב הזה,

97
00:06:32,230 --> 00:06:32,589
ושוב

98
00:06:32,630 --> 00:06:34,510
זה בסדר לא לדעת הכל,

99
00:06:34,950 --> 00:06:36,739
מייצר עוד כמה קבצים:

100
00:06:37,109 --> 00:06:43,869
קובץ research, שבו המודל מסביר את השיקולים לכל החלטה טכנית שהוא לקח, והאלטרנטיבות שנדחו.

101
00:06:44,769 --> 00:06:50,510
קבצי data model שמתארים את החוזים והסכמות שבה יתקשרו שירותים,

102
00:06:50,510 --> 00:06:54,989
וקובץ plan שמחבר את ה-user stories עם ההחלטות הטכניות,

103
00:06:55,029 --> 00:06:59,809
מסדר גאנט הגיוני של פיתוח, ומוודא שכל ההחלטות

104
00:07:00,269 --> 00:07:01,589
(טכניות ולא טכניות)

105
00:07:01,869 --> 00:07:04,670
עומדות בקנה אחד עקרונות הפרוייקט,

106
00:07:05,149 --> 00:07:08,029
אותה constitution שהגדרנו בשלב הראשון.

107
00:07:08,929 --> 00:07:13,630
השלב הרביעי הוא פריטת התוכנית ל-tasks, ומיספור אוטומטי שלהם ל-1,

108
00:07:13,839 --> 00:07:13,850
2,

109
00:07:14,519 --> 00:07:19,059
3 ואז 3.1 וגם סימון של חלקן עם האות P,

110
00:07:19,450 --> 00:07:25,109
מה שיאפשר לשלב הסופי והאחרון, implement, ליישם אותם בצורה מקבילית.

111
00:07:26,040 --> 00:07:28,839
בעצם כל התורה היא שמהלך החשיבה,

112
00:07:28,880 --> 00:07:34,160
התכנון וגם הביצוע של המודל, או התערבות שלך בתהליך - ממוסמכת.

113
00:07:34,670 --> 00:07:38,040
זה מאפשר לאחרים להבין מה ביקשת שיצר כל כך הרבה

114
00:07:38,040 --> 00:07:43,839
קוד, ומה המודל הבין שגרם לו לייצר משימות, ובגלל שזה קבצים

115
00:07:43,839 --> 00:07:49,279
בפורמט Markdown, אתה יותר ממוזמן לצפות בהם או לערוך. Spec-Driven

116
00:07:49,279 --> 00:07:55,709
הופך מתכנתים לארכיטקטים ומנהלי מוצר, או מנהלי מוצר למתכנתים.

117
00:07:56,420 --> 00:08:02,220
הבנתי של-Product Managers יש title חדש והם, כולנו עכשיו, Product Builders.

118
00:08:03,440 --> 00:08:05,239
ל-Speckit יש עקומת למידה

119
00:08:05,320 --> 00:08:09,839
והוא רחוק מלהיות מושלם, אבל הוא וייב קוד ראשון שעושה סדר,

120
00:08:09,959 --> 00:08:13,880
עובד במגוון של סביבות וניתן להתאמה מלאה.

121
00:08:14,440 --> 00:08:17,440
תיכף אספר מה עשיתי כדי לבנות כלי טוב יותר,

122
00:08:17,760 --> 00:08:20,510
אבל קודם כל נבין מה פחות עובד ב-Speckit:

123
00:08:21,059 --> 00:08:26,799
הוא מתבסס על קבצים שאמנם זמינים בקודבייס לכל חבר צוות, אבל חברי צוות לא

124
00:08:26,799 --> 00:08:32,039
חולקים את הקודבייס שלהם בכל דקה. אם אני מתחיל לעבוד על מודול מסוים, או שאני

125
00:08:32,039 --> 00:08:36,679
רוצה חוות דעת עליו לפני שהוא יורד לביצוע, אני צריך לתאם את זה כדי

126
00:08:36,679 --> 00:08:43,200
לא לדרוך על הענפים שקולגה שלי פתח. זה לא בלתי אפשרי זה פשוט מעצבן.

127
00:08:43,780 --> 00:08:47,700
לא ברור באיזה קונטקסט חיצוני פיצ׳ר חדש משתמש.

128
00:08:48,380 --> 00:08:50,369
אם אני רוצה לקשר פיצ׳רים דומים,

129
00:08:50,380 --> 00:08:56,820
לקשר אתרים חיצוניים או להוסיף תמונות וסקיצות - אין לי דרך קלה לעשות את זה.

130
00:08:57,450 --> 00:09:00,619
ההפרדה בין spec ל-plan היא גם מעצבנת.

131
00:09:00,780 --> 00:09:05,900
לפעמים קל יותר להסביר פיצ׳ר עם סכמה של sql או הסבר טכני או איזה פסאודו-קוד.

132
00:09:06,419 --> 00:09:09,210
לפעמים אתה מהרהר על ההליך התכנוני,

133
00:09:09,570 --> 00:09:13,760
ולא בטוח אם המחשבות שלך צריכות להיות ב-spec או ב-plan.

134
00:09:14,780 --> 00:09:17,119
ה-taskים ממוספרים וזה אחלה,

135
00:09:17,130 --> 00:09:22,679
אבל כשהיישום מסתבך, המספרים שלהם זזים, וגם ההערות שהם מוסיפים לקוד.

136
00:09:22,909 --> 00:09:25,570
זה יוצר המון שינויים שהם רעש.

137
00:09:26,169 --> 00:09:29,840
גם היישום והבדיקות קורים במחשב שלך.

138
00:09:30,090 --> 00:09:32,650
ביקשת לעשות implementation ל-10 משימות,

139
00:09:32,969 --> 00:09:34,750
הלכת לקפה וטורטית?

140
00:09:35,289 --> 00:09:39,450
יכול להיות שקלוד ייכנס למצב שינה או יחכה לך לאישור.

141
00:09:39,900 --> 00:09:41,679
ביטלת את הצורך באישור?

142
00:09:42,039 --> 00:09:47,239
קלוד רץ עם הרשאות המשתמש שלך ויש לו גישה למשאבים שלך ושל החברה.

143
00:09:48,130 --> 00:09:51,030
זה בסדר אם הוא יעשה drop table ל-postgres מקומי,

144
00:09:51,549 --> 00:09:54,229
פחות כיף אם זה יקרה על RDS בפרודקשן.

145
00:09:55,469 --> 00:09:57,340
אין מעקב מסודר אחר עלויות.

146
00:09:57,789 --> 00:10:02,049
מתישהו אעשה פרק על כלכלת הטוקנים והדרכים לחסוך

147
00:10:02,049 --> 00:10:06,549
כש-100 או 1000 מתכנתים צורכים אסימונים כמו אוויר לנשימה.

148
00:10:07,190 --> 00:10:07,950
והכי מוזר -

149
00:10:08,109 --> 00:10:10,590
אתה מוצא עצמך חי בשלוש מקומות.

150
00:10:10,669 --> 00:10:12,340
משרבט הנחיות ב-IDE,

151
00:10:12,789 --> 00:10:16,429
מריץ פקודות בטרמינל ועובר על PRים בגיטהאב.

152
00:10:17,359 --> 00:10:19,869
אז בניתי את spec-agent.

153
00:10:19,880 --> 00:10:24,039
מערכת שחיה רק בגיטהאב, שהיא ה-single source of truth של

154
00:10:24,039 --> 00:10:29,799
הפרוייקט, מעודכנת בזמן אמת לכולם, גם ללא מתכנתים. בלי לדחוף ובלי

155
00:10:29,799 --> 00:10:35,000
למשוך. שכל פיצ׳ר הוא בעצם github issue, שכל חבר צוות יכול

156
00:10:35,000 --> 00:10:40,320
להוסיף הערות ותמונות, ומתי שמוכנים מוסיפים ל-issue לייבל של plan,

157
00:10:40,979 --> 00:10:45,989
מה שמטריג github action שמריץ דוקר קונטיינר בענן.

158
00:10:46,299 --> 00:10:50,979
הקונטיינר הזה לוקח עותק של כל הקודבייס, כולל הקונטקסט

159
00:10:50,979 --> 00:10:55,260
מכל ה-issue, כולל תמונות והוא מריץ claude או gemini או

160
00:10:55,260 --> 00:10:59,700
codex בדיוק כמו שהייתי עושה בעצמי. הוא ישאל שאלות ואז

161
00:10:59,700 --> 00:11:05,369
יפתח sub-tasks, שמקושרים ל-parent issue, ויתייג אותם ב-conventional commits -

162
00:11:06,169 --> 00:11:07,489
פיץ׳ ל-feature חדש,

163
00:11:08,010 --> 00:11:08,890
fix לתיקון,

164
00:11:09,010 --> 00:11:09,770
test לבדיקות,

165
00:11:09,849 --> 00:11:16,049
doc לדוקומנטציה. ובגלל שאלו issues חיים ונושמים, אפשר לערוך או

166
00:11:16,049 --> 00:11:18,789
לסגור אותם אם לא צריך, או קלטו את זה,

167
00:11:19,090 --> 00:11:22,119
להעביר אותם לבן אדם, חי ונושם.

168
00:11:23,080 --> 00:11:26,669
כשמוכנים, מוסיפים ל-issue לייבל של work,

169
00:11:27,409 --> 00:11:30,590
מה שמטריג שוב קונטיינר, שרץ עם כל התלויות,

170
00:11:30,669 --> 00:11:35,309
למשל postgres, בסביבה נקייה ורעננה בכל הרצה,

171
00:11:35,710 --> 00:11:38,270
בלי גישה לשום משאב ארגוני.

172
00:11:39,489 --> 00:11:45,010
כל issue ייצור בסוף PR אחד, שבו כל משימה היא commit בפני עצמה.

173
00:11:45,049 --> 00:11:48,409
על ה-PR הזה עובר קודם סייען, איך לא,

174
00:11:48,820 --> 00:11:53,169
אבל רק בן אדם יכול לאשר ולמזג את הקוד לפרודקשן.

175
00:11:53,809 --> 00:11:59,929
סביבה אחת, ממשק אחד ותהליך שכל כולו קורה בגיטהאב.

176
00:12:00,789 --> 00:12:07,179
אם זה נשמע לכם כמו Copilot Workspace או Devin או Open SWE (מפרק 19) אז כן.

177
00:12:07,179 --> 00:12:11,179
הם בהחלט השראה. אבל Copilot Workspace הספיק כבר להיסגר

178
00:12:11,179 --> 00:12:15,539
פעמיים ובאחרים אין שליטה מלאה בספק או במודל.

179
00:12:16,169 --> 00:12:25,429
מה שיצרתי בעצם היא שכבה רזה שמעבירה קונטקסט מגיטהאב לכלי טרמינל שהם הטובים בתחומם.

180
00:12:25,840 --> 00:12:30,380
הבחירה בקלוד קוד, ג׳מיני CLI או codex היא לרוב בחירה במודל,

181
00:12:30,719 --> 00:12:33,039
אבל קידוד מוצלח הוא לא רק מודל,

182
00:12:33,159 --> 00:12:36,719
היא הדרך שבה הכלים האלה תוקפים את הבעיה,

183
00:12:37,239 --> 00:12:38,599
יודעים לחפש עוד קבצים,

184
00:12:38,640 --> 00:12:39,919
מנסים כמה מסלולים,

185
00:12:40,280 --> 00:12:45,150
מתווכחים ובודקים את עצמם, ואת היכולות האלה לא מקבלים

186
00:12:45,450 --> 00:12:46,739
אם שולחים את הקונטקסט ל-API.

187
00:12:48,590 --> 00:12:49,890
הייתה חשובה לי הגמישות -

188
00:12:50,130 --> 00:12:52,369
אפשר להחליט איזה מודל מבצע את ה-plan

189
00:12:52,450 --> 00:12:53,770
(למשל claude opus)

190
00:12:54,409 --> 00:12:55,169
איזה את ה-work

191
00:12:55,250 --> 00:12:58,880
(למשל claude opus), ודרך איזה ספק

192
00:12:58,929 --> 00:13:02,250
(למשל AWS Bedrock), וגם השקיפות -

193
00:13:02,330 --> 00:13:04,919
כמה טוקנים in ו-out לקחה כל משימה,

194
00:13:04,929 --> 00:13:11,090
כמה כסף וכמה זמן, היות וגם גיטהאב גובה גרושים לפי זמן ריצה, בערך 36 סנט, לשעה.

195
00:13:13,890 --> 00:13:18,460
יש גם אפשרות לעצור את המשימה כשהיא עלתה מעל תקציב מסוים.

196
00:13:19,520 --> 00:13:22,000
ועוד קצת גמישות - כיוון שכל ה-issues,

197
00:13:22,039 --> 00:13:22,679
כל ההרצות,

198
00:13:22,719 --> 00:13:26,789
כל האקשנים חיים בגיטהאב, אפשר לתכנת on-the-go,

199
00:13:26,799 --> 00:13:29,229
להתקדם במשימות בלי לפתוח מחשב,

200
00:13:29,479 --> 00:13:33,679
להוסיף taskים ולערוך taskים בדיוק כמו שהיית מדבר עם הצוות.

201
00:13:33,679 --> 00:13:38,919
במייל, אפליקציה או לוח משימות או Kanban תחת Github Projects.

202
00:13:40,150 --> 00:13:40,429
תראו,

203
00:13:40,590 --> 00:13:47,950
עברנו כברת דרך מוייב קוד שלא ממש עובד, לוויב שעושה מחקר ומסביר את תהליך החשיבה.

204
00:13:47,950 --> 00:13:52,989
מוייב קוד שלא יודע להתמודד עם קוד קיים, לוויב שמנהל את מסמכי ה-spec של עצמו.

205
00:13:53,799 --> 00:14:00,020
אני אישית נפעם מהעומק שאפשר להגיע איתו בשיחה על ארכיטקטורה, וגם מהחלטות

206
00:14:00,020 --> 00:14:06,200
הקוד שהוא עושה. אני בעיקר נרגש מהכיף שהוא מחזיר לתכנות ומחדוות העשייה.

207
00:14:06,260 --> 00:14:09,260
ההרגשה היא שהכל אפשרי.

208
00:14:10,200 --> 00:14:16,239
באמת שאין זמן טוב יותר להיות מתכנת, ואין זמן בעייתי יותר להיות ג׳וניור.

209
00:14:16,359 --> 00:14:18,640
להם אני מציע:

210
00:14:19,039 --> 00:14:20,599
אל תתרגשו מכל צעצוע.

211
00:14:20,640 --> 00:14:21,440
גם לא משלי.

212
00:14:21,840 --> 00:14:24,719
עשרות אלפי אנשים עסוקים בלמכור לכם אתים,

213
00:14:25,229 --> 00:14:25,809
בא׳,

214
00:14:26,049 --> 00:14:27,489
לכתוב קוד מהר יותר,

215
00:14:27,969 --> 00:14:28,770
בזול יותר,

216
00:14:28,849 --> 00:14:29,890
במקביל יותר.

217
00:14:30,130 --> 00:14:32,010
אתם לא מפספסים כלום

218
00:14:32,570 --> 00:14:36,080
אבל כן כדאי לעבוד על ה-setup שלכם.

219
00:14:36,090 --> 00:14:42,049
מה הופך אתכם לפרודקטיבים, וזה setup שנראה אחרת אם אתה מקודד לבד

220
00:14:42,590 --> 00:14:43,369
או בצוות.

221
00:14:43,890 --> 00:14:46,890
העצה השניה היא להתעמק בבסיס.

222
00:14:47,090 --> 00:14:51,650
הדבר העיקרי שוייב עדיין לא מתעדף זה ביצועים.

223
00:14:51,770 --> 00:14:56,880
זה הבנה שבחירה טכנולוגית כשאין יוזרים תעקוץ אותך בישבן

224
00:14:56,890 --> 00:14:58,599
ביוזר ה-100, או ה-100 אלף.

225
00:14:59,210 --> 00:15:01,609
קח את הזמן ללמוד יסודות של תכנות,

226
00:15:02,010 --> 00:15:02,609
תשתית,

227
00:15:02,929 --> 00:15:03,809
ארכיטקטורה.

228
00:15:05,049 --> 00:15:07,609
העצה השלישית היא לאהוב את זה.

229
00:15:07,770 --> 00:15:08,609
את הטראפיק

230
00:15:08,690 --> 00:15:09,609
אם אתה באדטק,

231
00:15:09,690 --> 00:15:10,690
את מסלול הכסף

232
00:15:10,770 --> 00:15:11,570
אם אתה בפינטק,

233
00:15:11,650 --> 00:15:12,409
את ה-posture

234
00:15:12,450 --> 00:15:13,369
אם אתה בסייבר,

235
00:15:13,650 --> 00:15:14,250
את הלוח

236
00:15:14,289 --> 00:15:15,049
אם אתה במאנדיי,

237
00:15:15,090 --> 00:15:15,809
את ה-commute

238
00:15:16,010 --> 00:15:17,010
אם אתה בוויקס.

239
00:15:17,369 --> 00:15:19,039
אם תאהב מה שאתה עושה,

240
00:15:19,609 --> 00:15:25,570
תוכל לכתוב specים שהם שיר אהבה, והסייען יאהב אותך בחזרה.

241
00:15:26,559 --> 00:15:27,570
עד הפעם הבאה,

242
00:15:27,719 --> 00:15:29,919
תהיו טובים ותמשיכו להיות סקרנים.

243
00:15:30,239 --> 00:15:30,559
יאללה

244
00:15:30,599 --> 00:15:30,729
ביי.