מה לא צריך מומחה IT לעשות בשנת 2020?

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

אבל הם לא שאלו על כוח המשיכה

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

אין צורך ללכת ל-IT אם הכל בסדר

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

החלפת ערימה אחר ערימה היא רק בזבוז זמן

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

אין צורך לעמוד על שלך ולהפוך ברונזה

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

הראש שלך טוב, תמיד טוב

אל תחשוב בראש של אחרים, שלך זה יותר טוב. למרבה הצער, יש מפתחים שיושבים ומחכים עד שהם מקבלים משימה לקוד מהשגיאה הקודמת ועד הסוף, מבלי לנסות לתרום משהו משלהם לפרויקט, לפתח פונקציה חדשה, לבדוק אותה ולהציע אותה לייצור. למה לטרוח כשיש ראש צוות או מנהל חברה שיחליט הכל בעצמם? אם אתה מזהה את עצמך, אז יש לנו חדשות רעות: עמדה פסיבית לא תעזור לא בקריירה שלך ולא בהתפתחות. יש לך הזדמנות לנסות את כוחך כמהנדס פיתוח, ולא קודן, בפרויקט קרבי אמיתי ולהבין לאן ללכת, מה חסר, אבל אתה מעדיף להשקיע את זמנך במשהו אחר ולעשות בדיוק "מכאן ועד עַכשָׁיו." אנשים כאלה שורדים יותר ויותר ב-IT המודרנית, יוצאים מהאנימציה מושעית. 

משתמשים הם אנשים נוראיים

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

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

 

תפסיקו לגוגל!

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

אמון אבל אמת

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

בצע גיבויים!

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

תפסיק להביא את שלך לרעת הפרויקט

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

לא קוד, אלא צרור עצבים

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

שמור על זה פשוט, טיפש

שמור על הקוד, הפתרונות והפרויקטים שלך פשוטים. אין צורך לגדר מבנה מורכב ולייצר גופים ללא משמעות מיוחדת. ככל שהקוד שלך מורכב יותר, כך תהפוך להיות בן ערובה שלו - יהיה לך קשה ככל האפשר לתחזק ולפתח אותו. כמובן, עקרון KISS המפורסם ("Keep it simple, stupid") לא תמיד מתאים, אבל הוא נוצר מסיבה כלשהי: הפשטות והאלגנטיות של הקוד הם המפתח ליישום המוצלח שלו ולשימוש חוזר בו.

הגן על עצמך

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

אל תירקו בבאר

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

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

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

באהבה,
צוות סטודיו למפתחים של RegionSoft

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

מקור: www.habr.com