תוֹכֶן
- 01. קידוד אל תחתוך אותו יותר
- רוחב ועומק
- 02. האזהרה הגדולה
- 03. מה האינטרנט אומר
- להבין את המדיום
- 04. הדברים שאנחנו בונים איתם
- 05. Devops
- להבין את הערימה
- עבודה מסתורית
- כלים שימושיים
- 06. Dev יתקן את זה ... אולי
- ניפוי באגים
- 07. מה המשתמשים רוצים
- שוק תחרותי
- 08. רישום וכתיבה
- 09. תיהנו
- 10. הישאר חד
- אהבתי את זה? תקרא את זה!
מפתחים צריכים להיות יותר מעובדי גרנה המניבים קוד. אנו מצפים ליותר מחיינו הדיגיטליים והבחורים האלה בונים אותם, אז מה צריכים המומחים הטובים ביותר לדעת? הנה הדברים שאני רואה חסרים ליותר מדי מפתחים. זה לא ממצה אבל התכונות האלה הן שהופכות קודן סביר למפתח מדהים.
אבל זה לא דבר אחד, ובעיקר אף פעם לא היכולת לנתח XML או לייעל קוד, זה אוסף מיומנויות מפתיע שלא מלמדים בספרים על כתיבת קוד. הם משהו נוסף.
למה לפרוק ככה? מכיוון שפיתוח חשוב אך מפתחים מוגשים לעתים קרובות מדי לעולם אחר, לא תמיד מעשה ידיהם. זה אף פעם לא עובד. פיתוח - כל דבר טכני - תמיד משגשג כאשר בעלי הידע מבינים יותר מאשר רק את הקוד.
01. קידוד אל תחתוך אותו יותר
אנו נמצאים בעולם בו הקידוד הופך להיות פחות מרשים. כולם בונים אתרים, חלקם מקודדים אבל אתה לא צריך. זה כבר לא רק החנון שיכול ליצור אתרים, אפליקציות ותכונות.
מאז שהאינטרנט הגיע ואנשים יכלו ללמד את עצמם היו מפתחים אוטודידקטיים. אבל אפילו הבוגרים מאוימים. אני מקבל קורות חיים עם אנשים עם תארים במדעי המחשב, קורסים במדעי המחשב, מדיה וקידוד שונים בחגורה אבל עדיין חסר משהו. לפעמים חסר הרבה.
אני לא הראשון שאומר את זה. 'קידוד אל תחתוך את זה יותר' הוא הכותרת של פרק 3 מתוך המתכנת הנלהב, שיחד עם ספרים כגון חשיבה ולמידה פרגמטית לקרוא למתכנתים לשפר את עצמם מעבר לקוד; להפוך לחברים קבועים ואנושיים לחלוטין בצוות.
רוחב ועומק
על המפתחים להיות טובים יותר בשתי דרכים: רוחב ועומק. הם צריכים להבין את רוחב האינטראקציות האנושיות בצוות שלהם ועם הדברים שהם בונים. הם צריכים להבין את עומק המערכת איתם הם עובדים, עד ל- O / S.
ולא רק מפתחים צריכים לקרוא את הדברים האלה. אם אתה עובד עם devs, אני חושב שאתה צריך לצפות ליותר מהם. תגרום להם לשרטט על מה הם מדברים. תביא להם להסביר בעזרת תמונות, חפצים ו (זה עובד) חיתוכים של אנשים בדיוק איך המערכת תהיה עבור בני האדם המשתמשים בה.
02. האזהרה הגדולה
אני הולך לדבר בצורה שלילית על מפתחים, אבל אני חושב שמותר לי כי אני אחד. גם בגלל שלפחות דבר אחד שאני מדבר עליו נכון לגבי רבים מהמפתחים שאני פוגש. למרות שהעבודה שלהם נהדרת והם יודעים את הקוד שלהם, הזמנים הם תחרותיים. אתה צריך שיהיה לך יתרון וזה:
- להיות יותר טכניים
ו
- לִהיוֹת הַרבֵּה אנושי יותר
03. מה האינטרנט אומר
חיפוש אחר 'כישורי פיתוח אתרים חיוניים' מעלה את מה שהיית מצפה. ידע במסגרת, דפדפן x, CSS ו- JS. הם מציגים מסגרות שכדאי להכיר, פלטפורמות שאתה בטח כותב אליהן ומגמות חדשות שאתה צריך לשים עליהן עין.
אלה התקשורת שלנו. הם הדברים שאנחנו בונים איתם אבל הם לא מה שנותן הצלחה בפרויקט. מפתח יכול להבין כל פרט במערכת, לספר לך כל תכונה של ממשק API וטכנולוגיית CSS חדשה, אך עדיין לייצר משהו שאינו שמיש.
להבין את המדיום
מפתחים, כמו כולם, צריכים להבין את המדיום שלהם - אך עליהם גם להבין את הקהל, להיות המשתמשים, הצוות או מפתחים אחרים. עליהם להבין כיצד המדיום שלהם משתלב בעולם (במילים אחרות, סביבת הייצור) ואיזו השפעה יש לו (כיצד אנשים משתמשים בו).
ראיתי את זה מתואר כאדם 'הרחב והעמוק'. רחב כי אתה צריך להבין את העולם כאדם שעובד עם בני אדם אחרים. עמוק מכיוון שאתה זקוק לידע טכני יסודי מתחת לרמת החלק שלך בפרויקט. מפתחים אלו נותנים דחיפה עצומה לפרויקט שלך ומשנים את קצב הפרויקט, שבלעדיו תמצא צוות לא טכני שקוע בפרטים מייגעים שעולים על גדותיהם מצוות הטכנולוגיה.
04. הדברים שאנחנו בונים איתם
לאחרונה רשמתי רשימה של כל מה שאנחנו משתמשים לבניית אתרים, לניהול אירוח ולעשות דברים כדי שאנשים המצטרפים יוכלו לקבל דף רמאות של טכנולוגיות ללמוד בשבועות הראשונים שלהם. לקחנו את זה כקריאה שאנשים מכירים את הדברים האלה, אז כדי לתת למתגייסים חדשים קפיצה, נרשום את כל מה שאנחנו משתמשים בכל יום.
ציפיתי לחצי תריסר טכנולוגיות אבל בסופו של דבר היו לי הרבה יותר. רשימה זו - 'במה אנו משתמשים' - כוללת את ה- CMS הרגילים, שפות התכנות וטכנולוגיות הדפדפן, אך גם חבורה של כלים שהצוות אפילו לא זכר את עצמם השתמש בהם. הכל היה זיכרון שרירים. הקלדת 'git', 'phing', 'thor' בשורת הפקודה, אפילו לא חשבנו שמישהו אולי לא.
בנה כלים; CI; git לבקרת גרסאות היה מובן מאליו, אך במבט לאחור על קורות חיים אלה כמעט ולא הופיעו. הטרנדים האלה יופיעו (והאם זה ציני שלדעתי סוכנויות מסוימות מוסיפות אותם ?!) אך לעתים קרובות ללא ניסיון קונקרטי.
כלים אלה חשובים להאצת פיתוח הפרויקטים, לכן וודא שיש לך מערכת כלים עשירה בהרבה משפתך, CMS ומספר מסגרות. אתה זקוק לפריסה, בדיקה, CI, בקרת גרסאות חזקה (בצוותים - לא לבד), ועליך להבין את מושגי הליבה של אלה ולא רק כמה מדריכים.
05. Devops
כלים וטריקים נוספים אלה משתלבים בצורה מסודרת במה שאנשים מכנים 'devops'. Devops טס מול שני ממגורות מסורתיות: ייצור, אשר שומר על דברים פועלים, ופיתוח, שעושה דברים חדשים (ולעתים קרובות מפסיק את פעולות הדברים). הממגורות מביאות לשני מחנות עם מעט אהדה אחד לשני.
מפתחים ללא ידע בייצור מייצרים לעתים קרובות יותר קוד שאינו מתאים לייצור, על ידי שימוש בתצורה או בתכונות שעדיין לא נמצאות בערמת הייצור. מכיוון שהם לא מודעים לבעיות בסביבת הייצור, הם מקודדים כדי להשלים את התכונה ולא לפרוס אותה לייצור.
הפרטים הקטנים הללו עלולים ליצור עיכובים כואבים, המוחמרים על ידי המגמה למשלוח ניהול השרת לחו"ל.
להבין את הערימה
Devops הוא תחום עצום בפני עצמו, המקיף פריסה מתמשכת והרבה אוטומציה. זהו סיכום גורף, אך הדבר העיקרי שמפתחים צריכים להבין הוא הערימה עליהם הם פועלים. זה לא מספיק להאציל את זה למנהל השרת, אתה צריך להבין את ההשלכות שיש לפלטפורמה על הקוד שלך.
אם אתה עובד על Rails, קרא את קוד Rails ותדע כיצד רובי מבוצע על ידי Apache. אם אתה עובד בג'אווה, דע את אפשרויות התצורה. אם אתה משתמש בפרל, הבן כיצד להתקין מודולי פרל ולהגדיר אותם.
עבודה מסתורית
הרשימה 'במה אנו משתמשים' מכילה המון מהדברים האלה, ומפתחים טובים קופצים על זה כדי להבין איך כל העבודה המסתורית הזו נעשית. וברגע שהם מקבלים את זה, הפריסות עוברות מהר יותר, העבודה נפרסת בצורה חלקה יותר וכולם פשוט מאושרים יותר.
פריסה מתמשכת ושיטות נלוות של devops הופכות להיות סטנדרטיות כל כך שכל מפתח או חברה שלא מתרגלים לכך מגדירים את עצמם להיות עקוף. מישהו אחר יתחיל לעשות את זה ואז הם יהיו מהירים ממך.
כלים שימושיים
חיפוש Google 'devops' נותן לך מושג על הכלים שהחבר'ה האלה משתמשים בהם. זה לא קשור ל- PHP ו- MySQL, או Rails. מדובר במשלוח תוכנה ושמירה על החלקים המסוכנים של פרויקטים ללא סיכון. הם מתרכזים בפריסה, אוטומציה ושמירת הצינור ממפתח לסביבת הייצור פועל מהר ככל האפשר.
תגלה שסגנון פיתוח זה נותן לך מפתחים שעובדים טוב יותר אחד עם השני ועם מחלקות וחברות אחרות. אם הם עובדים עם ממשק API מצד שלישי, הם יבינו את הבעיות שעלולות להופיע בצד השני. כשעובדים עם מנהלי השרתים הם יבינו מה הם צריכים להתקין וידעו איך אתרי התוכנה שלהם בשרתי ייצור. ההפך מזה יכול להיות כואב ...
06. Dev יתקן את זה ... אולי
חיפוש אחר 'כישורי מפתח אתרים חיוניים' מביא תשובה נחמדה מאת מייקל גריר (ה- CTO של ה- Onion) ב- Quora:
- עצלות: מסרב לעשות דבר פעמיים: כותב תסריט או אלגו על כך.
- פחדנות: חושב לבדוק, דאגות מהעומס והשפעת הקוד
- פזיזות: מנסה דברים חדשים כל הזמן, משיק רעיונות באותו יום
פחדנות היא דרך נחמדה לנסח 'תשומת לב לפרטים'. ניפוי באגים ובדיקות הם 99 אחוזים מחייו של מפתח שאיש לא ציין כאשר פגע ב- W3Schools או התחיל את קורס המחשוב 101.
היכולת לתקן אפליקציות דורשת מיומנויות מצוינות בפתרון בעיות, אך לא רק ניפוי קוד. לפעמים הפיתרון למשתמשים שלא יכולים להוריד את החשבוניות שלהם הוא להפוך את הדף להדפסה, במקום להקדיש יום ליצירת קובצי PDF. לפעמים קישור יכול להחליף שבוע של פיתוח, אך פיתרון אלגנטי זה לא יקרה אם המפתחים פותרים בעיות רק על ידי כתיבת שורות קוד רבות.
בדיקה היא נקודת עיוור נפלאה עבור רבים מהמתקדמים, למרות הכלים הרבים שיש. השתמש בבדיקות יחידה, סלניום, בדיקות עומס וכלי פרופיל כגון xhprof. ניתוח מדברים כמו New Relic כדי לשמור על טביעת הרגל של האפליקציה שלך קטנה. שקול את כל זה כחלק מתפקידו של ה- dev: זה הקוד שלך, ודא שאתה יודע שהוא עובד כמתוכנן ולא מקווה שהוא עובד.
ניפוי באגים
ניפוי באגים הוא גם נקודה כואבת. לא כיצד להשתמש בבאגים, אלא כיצד לפתור את הבעיה - אז הייתי מוסיף לרשימה של מייקל גריר:
- חוסר סבלנות: מתעלם באגרסיביות ממידע לא רלוונטי כדי למצוא ולפתור את הבעיה האמיתית
זוהי אבן הפינה של כל טכניקות איתור באגים. התעלמות מהלא רלוונטי ומציאת משמעות ברלוונטי. למרבה הצער, רבים נוטים לפטיש באופן לא עבוד את הלא רלוונטי במשך שעות או ימים, ולתקן בעיה על ידי ניסיון זהה 10 פעמים.
ישנם ספרים רבים (לצערנו, לא זה שהזמנתי למו"ל שלא אזכיר) על ניפוי באגים וכל מפתח צריך לקרוא את כולם. התקן ממש נהדר יכול לפתור את הבעיה במערכת מבלי לראות שורת קוד.
07. מה המשתמשים רוצים
להבין מה האנשים סביבך מנסים לעשות. תיהנו מהקוד - אהבו את האמנות להכניס קבצי CSS בצורה מושלמת, או לייעל אפליקציית מסילה - אך זכרו שהכל למטרה.
מפתחים צריכים להבין את העסק, את התפעול ואת התהליכים העסקיים מכיוון שהדברים שלהם עוזרים לנהל אותו. מכשירים עם ידע זה מסוגלים לבנות תוכנות ואפליקציות המסייעות למשתמשים, אך לעתים קרובות הם נראים פרודוקטיביים בצורה יוצאת דופן. זה יכול להיות בגלל הקלדה מהירה של התאורה שלהם או ידע מדהים על הערימה, אך סביר יותר שזה בגלל הידע שלהם לגבי מה המשתמשים רוצים.
שוק תחרותי
אם נחזור לנקודה המקורית שלי, שהפיתוח נעשה קל יותר ושוק המפתחים הגדולים הוא תחרותי יותר לכל מפתח שמסוגל להבין את הדרישות העסקיות ולהביא משהו מצוין שיעמוד בהם יהיה בעל יתרון. להבין את השוק, הלקוחות ולמה הם אנשים נפרדים מכסף, כל זה עוזר.
הבן את הנתונים וכיצד הם ישתנו עם הזמן. בראש המפתח הם צריכים לקבוע טכנולוגיות חדשות עם האתגרים שיש לכם היום או רואים שהם מגיעים. בדרך זו, כאשר אתה מציע רעיון חדש ומהודר למנכ"ל או ללקוח זה יתבסס על מה שהלקוחות באמת רוצים ותקבל את התקציב / זמן עליו. (לעומת זאת, הדבר הגרוע ביותר שיש לחזות בו הוא מפתחים שמרפאים את הטכנולוגיה החביבה עליהם כפתרון לכל מחלותינו.)
למפתחים יש שליטה רבה - האם הם צריכים לדעת מה משמעות כל תחום במסד הנתונים עבור משתמש הקצה? אם נשנה את הנתונים, מה יראו המשתמשים? האם יש דרך טובה יותר לעזור למשתמשים? לעתים קרובות מדי השקפתם של מנהלי DB היא שהעולם הוא שיקוף רע של מסד הנתונים שלהם במקום שמאגר הנתונים שלהם הוא ייצוג רע של העולם האמיתי. העולם מבולגן ומלא במפתיע מקרי קצה. להתמודד עם זה, מנהלי DB.
08. רישום וכתיבה
ציור הוא הדרך הישירה ביותר לתקשר איך הדברים יהיו. מפתחים חייבים להיות מסוגלים לצייר את רעיונותיהם על מחצבי לוח, נייר ובירה.
מפתחים חייבים להיות מסוגלים לאב טיפוס על נייר, להדפיס צילומי מסך ולשרבט עליהם רק כדי לתקשר את כוונתם. אל תסמוך על המפתח שמהנהן, אומר שהוא מבין ופותח את העורך שלהם.
נכשל בזול: הקידוד הטוב ביותר מתחיל בציור כאב טיפוס מהיר. נכשל בתדירות גבוהה יותר וודא שכל המפתחים סביבך עושים את אותו הדבר כמו שיש סיכוי גבוה יותר שתצליח ככה.
09. תיהנו
ומה אם אתה צריך להשקיע 10 שעות בפתרון בעיה על ידי העברת קישור מסביב? תהנה מזה - גם אם זה רק האתגר לעבור את העבודה.
הגישה הגרועה ביותר מצד מפתחים (או מישהו) היא אדישות כלפי מה שהצוות מנסה להשיג. למרבה הצער זה נפוץ, מכיוון שמפתחים רואים את עצמם מחוץ לתוצאות שהצוות משיג. (המתכנת הנלהב מעלה את השאלה, 'כמה כיף אתה יכול לעשות את העבודה שלך?' - נסה את זה.)
והיה מוכן להראות את עבודתך כיוון שההפך הוא: אל תרחיב לאחר שניסית כמה מדריכים בנושא רובי ל'חוויה של רובי '!
פיתוח אתרים ואפליקציות הוא עדיין מקצוע צעיר, אך מערך המיומנויות שצריך מאוד להתפתח, מתרחב. כל אחד אמור לצפות ליותר ממפתחים מכיוון שככל שכולנו מוקדם יותר יוצאים מהחדר האחורי הנורא ונשתלב בתהליך היצירה כך התוצאות יהיו טובות יותר.
10. הישאר חד
כדי להעלות את זה לסיבוב 10 נחמד אוסיף דבר אחרון אחד. הישאר חד. מצא תחרות. כל דבר מהסוג הגרוע ביותר הוא דבר בבידוד.
"תמיד תהיה הבחור הגרוע ביותר בכל להקה בה אתה נמצא."
הגרועים ביותר - באמת, הגרועים ביותר - מתכנתים, קודנים, מעצבים לומדים את הדברים שלהם ונחים על זרי הדפנה. בלי קוצב לב, קל מדי להאט ובלי לראות תחרות נהיה הרגל לראות את עצמך מעל הממוצע.
אז, תהיו הגרועים ביותר שתוכלו למצוא טוב יותר. הצטרף לפרויקטים מחוץ לעבודה, תרום וחפש משוב וביקורת מכיוון שככל שתקבל יותר ביקורת, כך פחות אנשים יתנו לך בעתיד. כשאתה מנחש מה הם רוצים יותר טוב ממה שהם, אז אתה מפתח הנינג'ה שכולם רוצים.
דן פרוסט הוא מנהל טכני של חברת האינטרנט 3EV בשירות מלא, שותף רשמי ב- AWS. הוא עובד בפיתוח CMS ובפיתוח אפליקציות אינטרנט מזה שבע שנים.
אהבתי את זה? תקרא את זה!
- כיצד לבנות אפליקציה
- גופני האינטרנט החינמיים הטובים ביותר עבור מעצבים
- גלה מה הבא למציאות רבודה
