תוציאו הכל (כמעט) לקוד פתוח

את הפוסט הבא קראתי ממש כשיצא.

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

כל מה שלא נוגע ללוגיקה הישירה ולמהות של החברה, יוצא ל-Open Source (קוד פתוח), כל מה שאנחנו נוגעים בו ויכול לתרום לפרויקט המקורי, יוצא גם הוא ל-Open Source.

למשל…
כאשר התחלנו לעבוד עם Resque ממש היה לנו חסר פיצ'ר שיכול להוסיף משימות ל-Queue, מאוד דומה ל-Delayed Jobs.
לכן, כתבנו כזה, הדבר הראשון שעשינו אחרי שכתבנו, היה להוציא את זה ל-Open Source.

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

קישור לפוסט של טום למטה.

Open Source (Almost) Everything.

איך תורמים לשתי קהילות במקביל עם רובי און ריילס?

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

על המיזם החברתי

dollar and Donation Box
המיזם הוא אתר אינטרנט. האתר יאפשר לכול מי שרוצה לגייס כסף לכול מטרה לעשות זאת בקלות.

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

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

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

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

כול מי שתורם יוכל (אם ירצה) לפרסם את התרומה שלו על ה-Wall בפייסבוק ובכך להפיץ את השמועה ולעזור למטרה שהוא בחר בכך שגם החברים שלו יעזרו לאותה המטרה.

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

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

רגע? אין אתרים כאלו?

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

אודות האתר

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

צילומי מסך מה-Mockups

דף פנימי - מטרה, תורמים, שיתוף

דף פנימי - מטרה, תורמים, שיתוף

כניסה לאתר, גם דרך פייסבוק וטוויטר

כניסה לאתר, גם דרך פייסבוק וטוויטר

מה זה קשור לריילס ואיך זה תורם לשתי קהילות?

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

יהיה קוד פתוח?

כן, האתר יהיה בקוד פתוח, כולו יפורסם (גם תו"כ תהליך העבודה) ב-Github ותוכלו להיחשף לקוד שלו ולראות איך אנחנו מתקדמים.

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

מה אנחנו צריכים מכם?

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

שיהיה לכולנו בהצלחה!

החלק הראשון

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

A/B Testing או איך ריילס תעזור לכם להרוויח יותר כסף מהאתר שלכם?

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

  1. יש לכם אתר אינטרנט ואתם רוצים להרוויח ממנו יותר כסף
  2. אתם לא חאפרים ולא בונים אתר אצל חאפרים

טוב, נמשיך?

מהו A/B Testing?

A/B Testing זו בעצם דרך לבדוק את הוריאציות השונות של האפליקציה שלכם ואיך הוריאציות האלה מתפקדות בעיני הגולשים שלכם. מה הייתם אומרים אם הייתי אומר לכם ששינוי כותרת יכול להביא לעלייה של 12% במכירות השבועיות שלכם? מה הייתם אומרים אם הייתי אומר לכם שפונט קטן יותר ושינוי של פסיק בפסקה מסוימת יכול להביא לעליה של 5% נוספים?

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

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

דוגמא ל-A/B Testing במוצר שמכניס מיליונים ויכול להכניס יותר

החבר'ה מ37Signals כתבו פוסט מעלף/מאלף על ניסוי שהם ערכו. הניסוי שהם ערכו דיבר על כותרת ותת כותרת בדף הרשמה לחשבון. זה הכול.
למשל: וריאציה ראשונה
hrhq-signuphead-30day60sec

והוריאציה השנייה
hrhq-signuphead-start30trial

אני יודע, מדגדג לכם על הלשון להגיד שזה לא באמת משנה נכון?

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

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

אבי, אבי, אבי שכנעת אותי, איך אני ממשיך מכאן?

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

אם יש לכם אפליקצית .net או php או אפילו python אפשר כמובן לעשות את זה באמצעות Google Web Optimizer. זה לא סקסי כמו ריילס ולא מובנה בתוך האפליקציה כחלק בלתי נפרד אבל זה כמובן ולידי לגמרי וניתן לביצוע. אפשר גם לבצע את זה באמצעות Google Analytics אבל שוב, זה לא מובנה בתוך האפליקציה ותצטרכו לכתוב הרבה יותר קוד בשביל זה.

אז עם ריילס זה יותר קל?

הכול עם ריילס יותר קל (ונעים ונחמד וכיף :-) )

מה נעשה עכשיו?

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

נתחיל בלייצר אפליקציה שנקרא לה ab_testing.

rails ab_testing

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

הנה הView שלנו:

<% title "Free Sign up" %>

<p>
	Register below to discover the awsomeness of our website
</p>

<p>Already have an account? <%= link_to "Log in", login_path %>.</p>

<% form_for @user do |f| %>
  <%= f.error_messages %>
  <p>
    <%= f.label :username %><br />
    <%= f.text_field :username %>
  </p>
  <p>
    <%= f.label :email, "Email Address" %><br />
    <%= f.text_field :email %>
  </p>
  <p>
    <%= f.label :password %><br />
    <%= f.password_field :password %>
  </p>
  <p>
    <%= f.label :password_confirmation, "Confirm Password" %><br />
    <%= f.password_field :password_confirmation %>
  </p>
  <p><%= f.submit "Sign up" %></p>
<% end %>

וכך זה נראה בדפדפן:
Registration form

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

לבחור את הכלי הנכון

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

הכלי שאנחנו נדבר עליו ונכסה אותו יהיה A/Bingo, זהו בעצם Plugin לרובי און ריילס שמבצע בדיוק את מה שאנחנו צריכים.

התקנה

כול מה שצריך בשביל להתקין את הפלאגין זה כרגיל בריילס, להריץ שורת פקודה:

script/plugin install git://git.bingocardcreator.com/abingo.git

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

script/generate abingo_migration

זה ה-Migration שנוצר לנו כתוצאה מהפקודה:

class AbingoMigration10< ActiveRecord::Migration
  def self.up
    create_table "experiments", :force => true do |t|
      t.string "test_name"
      t.string "status"
      t.timestamps
    end

    add_index "experiments", "test_name"
    #add_index "experiments", "created_on"

    create_table "alternatives", :force => true do |t|
      t.integer :experiment_id
      t.string :content
      t.string :lookup, :limit => 32
      t.integer :weight, :default => 1
      t.integer :participants, :default => 0
      t.integer :conversions, :default => 0
    end

    add_index "alternatives", "experiment_id"
    add_index "alternatives", "lookup"
  end

  def self.down
    drop_table :experiments
    drop_table :alternatives
  end
end

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

rake db:migrate

הגענו לבדיקה הראשונה, יש!

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

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


<% title "Free Sign up" %>

<% if ab_test "signup_paragraph "%>
<p>
 Register below to discover the awsomeness of our website
</p>
<%else%>
<p>
 This is the alternative content
</p>
<%end%>

<p>Already have an account? <%= link_to "Log in", login_path %>.</p>

<% form_for @user do |f| %>
 <%= f.error_messages %>
 <p>
 <%= f.label :username %><br />
 <%= f.text_field :username %>
 </p>
 <p>
 <%= f.label :email, "Email Address" %><br />
 <%= f.text_field :email %>
 </p>
 <p>
 <%= f.label :password %><br />
 <%= f.password_field :password %>
 </p>
 <p>
 <%= f.label :password_confirmation, "Confirm Password" %><br />
 <%= f.password_field :password_confirmation %>
 </p>
 <p><%= f.submit "Sign up" %></p>
<% end %>

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

את השמירה אנחנו נעשה ב-Controller מיד אחרי שמירת המשתמש:

class UsersController < ApplicationController
 def new
 @user = User.new
 end

 def create
 @user = User.new(params[:user])
 if @user.save
 bingo! "signup_paragraph"
 session[:user_id] = @user.id
 flash[:notice] = "You are registered and signed up!"
 redirect_to root_url
 else
 render :action => 'new'
 end
 end
end

אפשר לראות את המתודה שאנחנו משתמשים בה כדי לשמור:

bingo! "signup_paragraph"

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

צפייה בתוצאות המבחן

אנחנו נייצר Controller כדי לצפות בתוצאות:
ֿ

script/generate controller abingo_dashboard

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

כך נראה ה-Controller שלנו:

class AbingoDashboardController < ApplicationController
  include Abingo::Controller::Dashboard
end

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

  map.abingo_stats "/abingo_stats/:action/:id", :controller=> :abingo_dashboard

עכשיו שיש לנו route מוגדר, בואו ונצפה בתוצאות (אם הserver שלכם פועל, צריך לאתחל אותו):
Abingo Stats

סיכום

נגענו בקצה הקרחון של A/B Testing – גם מבחינת הקונספט וגם מבחינת איך לבצע את זה ב-Ruby on Rails. כמובן שיש עוד הרבה אופציות לבחון, ויש אפשרות לאחד מבחנים תחת כותרת מסוימת וכדומה.
יש דרכים לזהות משתמשים רשומים, לעשות Random של האם יוצג או לא ועוד עשרות שיטות שאפשר לבחון כול מקרה לגופו. האפשרויות (כרגיל) הן בלתי מוגבלות.

ללמוד ריילס כמו זומבי

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

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

נכנסים לעולם הריילס?

משיטוט ברשת מצאתי משהו מדליק שאני חושב ששווה לחלוק אותו ומי שרק נכנס לעולם הריילס ימצא אותו מועיל מאוד.
חברת Envy Labs שמפתחת אפליקציות בריילס וגם אחראית לכול ה Video Tutorials באתר הרשמי של Ruby On Rails הוציאה סדרת Video Tutorials חדשה שנקראת Rails For Zombies מדובר על סדרה של Video Tutorials טובים מאוד ואיכותיים מאוד שעוזרים להכנס לעולם של ריילס יותר בקלות מלעבור על מאמרים באורך 20-30 עמודים.

הנה צילום מסך מתוך האתר, אפשר לראות שלא מדובר בVideo סטנדרטי כמו RailsCasts או כול אחד אחר, הגישה היא קצת אחרת :-)

Screen shot 2010-12-07 at 8.40.00 AM

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

חלון שבור

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

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

הקדמה – תאוריית החלון השבור

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

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

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

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

בעקבות הניסוי החוקרים פיתחו את תאוריית החלון השבור, בואו ונבהיר אותה או לפחות ננסה.

בניין מגורים – חלון שבור

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

תיאורית החלון השבור - בניין מגורים

תיאורית החלון השבור - בניין מגורים

אני יודע מה אתם חושבים עכשיו (אני גם קורא מחשבות בזמני הפנוי)…

מה זה קשור לפיתוח תוכנה ואיך זה נוגע לי כמפתח בחיי היומיום?

כן, הכותרת שברה שיאי אורך :-)

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

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

קוד מקור לדוגמא

קוד מקור לדוגמא

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

אילוצים או תירוצים?

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

אבל אם נסתכל אחד לשני (ולעצמנו) בעיניים אנחנו בעצם יודעים שאלה תירוצים ולא סיבות.

מה אפשר לעשות?

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

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

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

לסיום, אני רוצה לצטט את Uncle Bob Martin (ברשותכם כמובן)

No matter who. No matter what. No matter when. Short term.Long term. Any term. Writing good code is ALWAYS faster than writing bad code.

Refactoring should never appear as a task on a schedule, Keeping code clean is just something you do all the time

כרגיל, אשמח לתגובות.

הטעויות הכי נפוצות (וגדולות) בפיתוח אפליקציות פלקס

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

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

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

1. שימוש בflex כדי לבנות אתרי אינטרנט או אפליקציות מדור ישן

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

אני זוכר, בתור ילד צעיר למדתי קראטה, with great power comes great responsibility, אמצו את זה כאשר אתם ניגשים לפתח אפליקציה. אם אין לכם אפליקציה שדורשת ויזואליות מסוימת, אנימציות, עבודה עם datasets גדולים וכו', עדיף שתשתמשו בטכנולוגיות אחרות כמו html, css ואפילו פלאש.

Flash this not that

Flash this not that

אפשר לראות פוסט באנגלית על זה כאן

מקור התמונה The Flash Blog

2. האטת האפליקציה עד כדי זחילה על ידי שימוש ביותר מדי containers

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

השקף הזה מדבר על ריבוי containers. הרבה אנשים שמגיעים מhtml לתוך עולם הפלקס (וזה קורה המון) לא מבינים שcontainer  בפלקס הוא component בפני עצמו שיש מאחוריו עשרות (לעיתים מאות) חישובים של גודל, מיקום, מיקום ילדים, גודל ילדים. ועוד יותר גרוע מזה, ולידציות וinvalidations.

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

אפשר לראות כאן צילום מסך של תחקיר שעשו חברים בקהילה מאתר Inside RIA

צריכת זכרון כאשר יש יותר מדי Containers

צריכת זכרון כאשר יש יותר מדי Containers

ניקח דוגמה שפורסמה בזמנו בYahoo Developer Network (את המאמר המקורי אפשר למצוא כאן, אבל אני מתמצת את עיקרו שרלוונטי לנושא)

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

יותר מדי container באפליקצית flex

יותר מדי container באפליקצית flex

הדרך הראשונה

והקוד:

 <Application layout="absolute">

     <HBox width="100%">

         <Button label="Left"/>

         <Spacer width="100%"/>

         <Button label="Left"/>

     </HBox>

 </Application>
יותר מדי container באפליקצית flex

יותר מדי container באפליקצית flex

שימו לב שיש לנו כאן מספר containers, רובם מיותרים, סבב התיקונים הראשון ועכשיו האפליקציה שלנו נראית כך

הקוד שלנו נראה כך:

 <Application layout="horizontal">

     <Button label="Left"/>

     <Spacer width="100%"/>

     <Button label="Left"/>

 </Application>

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

מספר container נכון באפליקצית flex

מספר container נכון באפליקצית flex

הטיוב האחרון שלנו נראה כך:

והקוד נראה כך:

 <Application layout="absolute">

     <Button label="Left" left="5"/>

     <Button label="Left" right="5"/>

 </Application>

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

3. שימוש בXML

אחד היתרונות הכי גדולים בפלקס זה היכולת של הפריימוורק להתמודד עם XML אבל עדיין בטכנולוגיות של היום יש שיטות כול כך יותר טובות להעביר Data שכל מעבר כזה בין הClient לServer והפוך לוקח הרבה פחות זמן.

XML לא רק לוקח יותר זמן לפרסר אלא לוקח יותר זמן להעביר על הwire ויכול לעלות המון כסף של BandWidth.

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

את האפליקציה הזו אפשר למצוא כאן

דוגמאות לסוגי העברת מידע בין Client לServer

דוגמאות לסוגי העברת מידע בין Client לServer

4. שבירת מוסכמות והרגלי גלישה באינטרנט

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

עם פלקס אפשר להגיע לניווט רגיל לגמרי, אפשר לעשות Bookmark, אפשר להגיע לדף ספציפי עם כתובת ספציפית בלי ליצור SWF's נפרדים, אפשר הכול. כאשר אתן ניגשים לבנות את האפליקציה שלכם, שימו לב לזה, לעשות Deep Linking שיהיה אפשר להגיע לכול חלק מיידית, ללא ניווטים וקליקים מיותרים.

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

5. שימוש מוגזם באנימציות ומעברי עמודים

אני אהיה הראשון שאעמוד לימין הframework והיכולת שלו להתמודד עם משימות גראפיות כבדות, אבל אני גם אהיה הראשון לומר ש"My Account" לא צריך לעוף ב720 מעלות מתוך הקצה הימני של המסך, הוא לא צריך לשנות את הצבע שלו ולא צריך להזיז את הכפתור ב200 קמ"ש אחרי שלחצתי.

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

יודעים מה, כבר עשיתם את זה, תאפשרו למשתמש לכתוב את זה.

כנ"ל עם מוזיקה או Audio Effects.

6. לא לפתח סביבת פיתוח תומכת Craftsmanship או Agile או לא לפתח EcoSystem בכלל

זה נכון לכול טכנולוגיה, בין אם זה flex או אפילו Ruby on rails. לגשת ישירות לפיתוח מבלי להתחשב ולא להנהיג שיטות Tdd/Bdd, Unit Testing, Code Coverage וכו' זה פשוט לא אחראי, זה לא אחראי במיוחד באפליקציות פלקס מכיוון שכשלא עושים את זה, צריכים לבדוק את הכול דרך הUI, לחכות לקומפיילר שירנדר את האפליקציה בכול פעם, זה בזבוז זמן ומשאבים אדירים.

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

הנה כמה:

FlexUnit

FlexMonkey

תפתחו שיטות עבודה איכותיות שמעודדות בדיקות, מעודדות Craftsmanship, מעודדות Clean Code ואחריות מפתחים.

7. לא לעשות שימוש בBuild Machine ובContinuous Integration

היות ואפליקציות Flex עוברות קומפליציה, כלומר מקוד מקור לאפליקציה סגורה, קובץ SWF שיטת הpublish צריכה להיות כזו

תהליך פיתוח ומעבר נכון לProduction

תהליך פיתוח ומעבר נכון לProduction

מה זה אומר בעצם?

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

יעיל נכון?

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

אני חושב שאלה הנקודות העיקריות שעולות לי לראש בשלב זה, אם יהיו דברים נוספים אוסיף אותם לפוסט.

כרגיל, אשמח לשמוע את דעתכם.

האם כול המתכנתים צריכים להיות חברים פעילים בקהילה?

בד"כ בפוסטים שלי, אני נוהג לקבוע קביעות, להגות דעות, וכו'.

היום, הפוסט שלי הוא יותר דיון מכול דבר אחר.

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

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

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

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

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

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

עכשיו לשאלה…

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

אשמח לתגובות ולדיון…

על אמנות ביצירת תוכנה – Software Craftsmanship

לאחרונה חתמתי על המניפסטו של Software Craftsmanship.

הקדמה

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

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

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

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

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

האומנות ביצירת תוכנה, מה זה?

Software Craftsmanship היא מעבר לכול גישה או פילוסופיה, יש לה המון נקודות משותפות עם xp (extreme programming), אבל כפי שכבר אמרתי, זוהי לא מתודולוגיה, היא לא מגדירה עקרונות low level בפיתוח תוכנה כמו tdd או refactoring.

ישנו ספר שעוסק בנושא, אני מאוד ממליץ על קריאה שלו: הנה לינק אליו

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

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

ממשיכים…

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

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

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

ממשיכים…

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

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

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

מהצד השני, אנשים צריכים להבין ולהגדיר את עצמם כ"מתמחים", כן כן, אני יודע, אנחנו ישראלים, אנחנו מומחים בהכול.

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

רגע רגע, אני מתכנת .net, זה רלוונטי לי?

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

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

יש לי צוות של 20, האם אני יכול להגיד שהם עובדים תחת הכללים של software craftsmanship?

לא

האמת, לא

ושוב, לא

כאן, אני מסכים לגמרי עם מי שכתבו את הmanifesto, מדובר על צוותים קטנים בהם יש 1-2 craftsman ועוד 3-4 מתמחים, העבודה בצוותים קטנים מאפשרת להדגיש את העקרונות הנחים בצורה טובה יותר, אין שום בעיה ש20 איש יעבדו כך, אבל הם צריכים להיות מחולקים לצוותים קטנים יותר עם מספר מומחים קטן ומספר מתמחים גדול יותר בכול צות פיתוח קטן.

מה הקשר לדוד בוב?

uncle bob (חפשו בגוגל, אל תהיו עצלנים) הוא אחד הspeakers הטובים ביותר שיש לנו בתחום, הוא הגדיר את הפילוסופיה כ"חזרה לבסיס" או "לעשות את הבחירות הנכונות". בוב אגב, הוא הכותב של הספר clean code (עוד המלצה).

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

סיכום

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

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

כמובן, שאני כאן לכול שאלה ואשמח לעזור, רק תשאירו תגובה ואני אענה

כיצד תהיו מקצוענים בפיתוח תוכנה? חלק 2

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

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

מכונת זמן מישהו?

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

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

בין אם אתם משתמשים בSVN או בGIT, גם אם אתם משתמשים בשרת פנים חברתי או בGoogle Code זה בכלל לא משנה, אתם צריכים להכיר את הכלים לSource Control ולהשתמש בהם. לעשות Commit כשסיימתם וUpdate לפני שאתם מתחילים.

Patching

אם יש לכם "חייזר" (מפתח מחוץ לצוות) שבא לפתור בעיה ספציפית אל תהיו שבויים בלשלוח לו את הקוד התקול ושישלח לכם את הקוד המתוקן, תנו לו את הקוד ושיכתוב Patch, בינתיים אתם תעבדו על דברים אחרים וכשתקבלו את הPatch תכניסו אותו פנימה והכול דבש! :-)

תוודאו מה אתם צריכים לעשות ואז תוודאו שוב

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

לעיתים (די קרובות) אני מקבל תשובה בסגנון "תתחיל לעשות XYZ ואנחנו נעביר דרישות בהמשך".

תסרבו!

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

פעם קיבלתי מייל כזה מלקוח:

אני רוצה שתעשה באתר שאפשר יהיה לשלם
שהתשלום יעבור ללקוח שהגולש בחר באופן אוטומטי

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

תשמרו את הלקוח שלכם מיודע

אם אתם שכירים הלקוח שלכם יכול להיות המנכ"ל של החברה והוא יכול להיות גם הלקוח הסופי, אם אתם פרילנסרים (כמוני) הלקוח שלכם הוא חברה או לקוח סופי אבל זה בכלל לא משנה.

מה הנקודה?

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

נתקלתי פעם בחברה שידעה לקוח (גדול מאוד, פרויקט עצום) על איחור של שבועיים בפרויקט לילה לפני ההשקה, שלוש שעות אחרי שהלקוח הרים כוסית עם הצוות שלו שמחר מרימים את האתר אחרי 4 חודשים של עבודה.
אחרי שבועיים התברר שבכלל הפרויקט מוכן רק ב80%, הפרויקט עלה לאחר 6 חודשים וגם לא גמור.

המנעו מזה! כמו מאש!

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

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

הבנתם? יופי :-)

שירות, שירות, שירות

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

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

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

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

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

תרשום תרשום…

לקוח מדבר אתכם? תהיו עם דף ועט זמינים.
לקוח שולח אליכם מייל עם באג – שלחו אותו למערכת הבאגים שלכם (פירוט בהמשך).

מכירים את המילה "שכחתי", תשכחו אותה :-)

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

GTD – Getting Things Done!

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

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

כיצד תהיו מקצוענים בפיתוח תוכנה?

שלום לכולם,

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

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

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

טוב, נתחיל?

משמעת

נתחיל בכך שבעצם המון מתחיל במשמעת, אנחנו יכולים לדבר ימים ושבועות על עקרונות הOOP על מה זה SOLID או האם כדאי לכתוב בWebForms או ששווה כבר לעבור לMVC אבל האמת היא שלא שם זה מתחיל.

הכול מתחיל במשמעת.

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

זמנים קצרים

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

אל תהיו שבויים

מכירים את זה שאתם לא מתחילים פרויקט בגלל שחסר לכם משהו קטן שהלקוח צריך לספק?

הממ, שקרנים :-)

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

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

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

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

סגור? נמשיך :-)

תמנעו מצימוד

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

זה רע!

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

ארכיטקטורה מסובכת… אוי ואבוי

תמנעו מארכיטקטורה סבוכה, מסובכת, כזו שיש לה תיעוד מסובך ובלתי מובן.

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

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

שיפורים קטנים, קטנים אבל תמיד

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

שימו לעצמכם ביומן כול יום לעשות שיפור בקוד שלכם, תעברו על פרויקטים אקראיים למשך שעה ביום, תשפרו פיסות קוד, תעבירו נתונים לCache במקום בסיסי נתונים, תכתבו string.Format במקום לשרשר String אקראיים.

שיפורים קטנים לאורך זמן יהוו שיפור גדול מאוד בסופו של דבר.

ממה להמנע? להמנע מאוד מלהגיד “אני אכתוב את זה טוב יותר אח”כ”, אתם לעולם לא תעשו את זה.

כתיבה מחדש – אוי ואבוי גדול מאוד

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

תדמיינו אותי בתור המנכ”ל שלכם, אני לעולם לא הייתי מאפשר את זה, לעולם!
זה מטומטם מבחינה תקציבית, תיאורטית, מעשית ועוד הרבה

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

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

אל תכתבו קוד רע

החוק הזה יגרום לכם ללכת ולא לרוץ, תמיד.

אי אפשר למהר בטירוף ולא לכתוב קוד רע.

Uncle Bob נותן כאן בהרצאה שלו השוואה מדהימה שאני רוצה לקחת ממנו ולכתוב אותה כאן.

דמיינו שאתם חווים חוויה חוץ גופנית ועומדים מעל חדר ניתוח בו רופא עורך עליכם ניתוח לב פתוח.
איך הייתם מעדיפים שהרופא יעבוד?

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

כאן מסתיים החלק הראשון, המשך יבוא…

איך אומרים באנגלית Chew on it for a while…