15 راهکار برای ارتقا برنامه ‌نویسان  تازه کار و جونیور (Junior)

15 راهکار برای ارتقا برنامه ‌نویسان تازه کار و جونیور (Junior)

یکی از سوالات و چالش‌هایی که شاید برنامه نویسان یا اطرافیان آن‌ها با آن مواجه شوند، سطح‌بندی آنان و نحوه‌ی ارتقا سطح از جونیور (Junior) به حرفه‌ای یا همان سینیور (Senior) است. در این مقاله قصد داریم 15 راهکار برای ارتقا برنامه نویسان تازه‌کار و کم تجربه پیشنهاد دهیم.

از  Stack Overflow استفاده کنید.

زمانی که در ابتدای مسیر برنامه‌نویسی قرار دارید و تجربه‌ی کمی دارید می‌توانید برای رفع برخی از ابهامات و چالش‌های خود از Stack Overflow  استفاده کنید و از تجربیات و راهنمایی سایرین بهره ببرید. اما فراموش نکنید برای آموزش اصول و یادگیری عمق مفاهیم و ابزار، این سایت پیشنهاد نمی‌شود. شاید خواندن مطالب آموزشی اصولی متنی یا دیدن ویدیو‌های آموزشی کمی سخت و زمان گیر باشد اما بدون آن‌ها نمی‌توانید به درک صحیح برسید.

وسعت دید خود را بیشتر کنید.

سعی کنید به کد خود نگاه وسیعی داشته باشید و اصطلاحا روی آن زوم نکنید. 

یک توسعه دهنده‌ی با تجربه، ابعاد وسیع تری را در کار خود می‌بیند و به ابعاد و عوارض جانبی کار خود نیز فکر می‌کند. علاوه بر این به این فکر می‌کند که همخوانی بین کد با بخش‌های دیگر سیستم برقرار باشد ودر صورت ممکن، در بخش های دیگر سیستم قابل استفاده باشد و در نهایت حفظ و پشتیبانی آن‌ها نیز آسان باشد. 

کیفیت کار خود را ضمانت کنید.

بررسی کیفیت کد در توسعه‌ی نرم افزار امری ضروری است که برخی موارد به صورت خودکار و برخی موارد به صورت دستی انجام می‌شود. بنابراین در فرآیند توسعه‌ی محصول، به کیفیت فنی کد خود اهمیت دهید و قبل از آن که در محصول اصلی اعمال شود، کیفیت کافی و صحت عملکرد آن را تضمین کنید. این کار ضمن افزایش دقت و مهارت‌تان، از خطاهای احتمالی محصول و هدر رفت زمان برای اصلاح کد نیز جلوگیری می کند و مانع از ایجاد استهلاک در کار تیم فنی می‌شود. 

اگر به تنهایی کار می‌کنید فراموش نکنید در صورتی که خودتان ایرادات کارتان را اصلاح نکنید، شخص دیگری متوجه آن نخواهد شد و این امر می‌تواند برای محصول نهایی فاجعه‌بار باشد.

دنیای اطراف کار خود را نادیده نگیرید.

برای شناختن محیط کار خود و کلیات محصولی که روی آن کار می‌کنید وقت بگذارید. اگر زمینه فکری و درک درستی از کسب‌وکار، صنعت یا سازمانی که در آن کار می‌کنید نداشته باشید، ممکن است در نهایت فیچرهایی خلق کنید که کاربران به آن‌ها نیازی ندارند. از سوی دیگر ممکن است در شرایط متفاوت و زمان‌های حساس، نتوانید نسبت به اولویت کارها و نیازمندی‌های استراتژیک سازمانی، درک درست و به موقعی داشته باشید.

تست نویسی، سیستم ایمنی کار و راهنمای مسیر خواهد بود.

تست نویسی برای توسعه‌دهندگان جوان بسیار مهم است، به‌ویژه زمانی که در یک تیم کار می‌کنید یا در پشتیبانی یک سیستم بزرگ‌ با چندین توسعه‌دهنده مشارکت می‌کنید. تست‌ها روشی عالی برای تسهیل پیاده‌سازی هستند، اما مهم‌تر از آن برای توسعه‌دهندگان جوان، تست‌ نویسی، شبکه ایمنی موثری در کار ایجاد می‌کنند و امنیت شغلی توسعه دهنده را در پی خواهند داشت. تست نویسی خوب، خرابکاری‌های احتمالی را فاش می کند و به کمک انجام منظم و دقیق آن می‌توانید مطمئن شوید کاری که انجام داده‌اید عوارض جانبی ناخواسته نداشته است. فراموش نکنید که تست‌های موفق، اعتماد به نفس شما را برای بهبود و ارتقای کد و درنهایت محصول، بالا می‌ برد. حتی اگر به صورت انفرادی هم کار می‌کنید، باید تست نویسی را جدی بگیرید.

نگرانی های خود را از هم جدا کنید.

فرقی نمی کند با زبان‌های برنامه‌نویسی شی‌گرا کار می‌کنید یا زبان‌های برنامه‌نویسی تابعی؛ تفکیک صحیح نگرانی‌ها نشانه‌دهنده‌ی یک توسعه‌دهنده‌ی ماهر است. توسعه‌دهندگان با تجربه، غریزه‌ای برای شناسایی نگرانی‌های جداگانه و مرزهای بین آن‌ها دارند. منظور از «نگرانی» در این زمینه، یعنی:

  • محدوده‌ی  پاسخگویی کد
  • محدوده‌ی تمرکز در کد
  • یا "کار" خاصی که کد انجام می دهد.

یک ترفند مفید برای شناسایی محدوده های جداگانه مسئولیت‌ها، «AND Test» است: اگر زمانی که یک فایل یا کلاس را در کد خود توصیف می‌کنید، باید از کلمه «AND» استفاده کنید، احتمالاً مسئولیت‌هایی را شناسایی کرده‌اید که می‌توانند (و احتمالاً باید) جدا شود.

مثال:

  • کلاس Conference مسئول برنامه‌ریزی و نمایش جدول زمانی کنفرانس است (در آزمون AND مردود شد).

در عوض:

  • کلاس ConferenceScheduler وظیفه برنامه ریزی کنفرانس‌ها را بر عهده دارد.
  • SchedulePresenter  مسئول ارائه برنامه ها است.

وقتی کد خود را به این شکل تقسیم می کنید، ممکن است به فایل هایی برسید که کاملاً مختصر هستند (حتی کمتر از 50 خط). این یعنی برنامه‌ای متشکل از کلاس‌های کوچک که به خوبی با هم کار می‌کنند. 

روش های کوتاه بنویسید.

یکی از راه‌های نزدیک شدن به این موضوع این است که اجازه دهید پیاده‌سازی شما به عنوان یک روش طولانی شروع شود، سپس آن را به روش‌های Private  تقسیم کنید که یک مرحله را انجام می‌دهند و آنچه را که انجام می‌شود ثبت کنید.

در اینجا یک مثال در روبی ذکر شده. می‌خواهیم روشی را call کنیم که برای ما یک پیتزای خوشمزه با افزودنی‌های انتخابی می‌سازد، چیزی شبیه به:

def make_pizza_with(toppings)
  preheat_oven
  divide_and_roll_dough
  add_toppings(toppings)
  bake_pizza
  slice_and_serve
end

متد make_pizza_with تعدادی روش دیگر را اصطلاحا Call می‌کند که هر کدام یک مرحله را در فرآیند انجام می‌دهند. به عنوان مثال:

def preheat_oven(temperature, time)
  walk_to_oven
  turn_on_oven
  turn_dial_to(temperature)
  set_timer_for(time)

می‌توانید به راحتی روش make_pizza_with را در این سطح از جزئیات سطوح پایین پیاده‌سازی کنید، مراحل جداگانه را حذف کنید و در عوض تمام جزئیات مختلف مورد نیاز برای تهیه یک پیتزا، مانند راه رفتن به سمت فر، بیرون آوردن مواد از یخچال، یا گرفتن پیتزا را مستقیما به کار ببرید. دستور العملی که به این شکل نوشته شود بسیار آزاردهنده خواهد بود. پس بدانید که با مدیریت این نکته، کد شما خواناتر و نگهداری آن آسان تر خواهد بود.

اما چه زمانی قسمت‌‌هایی از یک روش بزرگ را به روش های کوچک‌تر تبدیل می کنید؟ اغلب، وقتی جایی باید یک کامنت (comment) بنویسید تا توضیح دهید که چه بخشی از کد شما چه کاری انجام می‌دهد، آنجاست که باید آن را در یک روش جداگانه استخراج کنید.

به دنبال انتقاد سازنده باشید.

مورد ستایش قرار گرفتن، برای هرکسی می‌تواند خوشایند باشد و البته باعث افزایش انگیزه و توان او شود. اما گاهی اوقات لازم است که انتقاداتی را بشنوید که شما را به سمت رفع ایرادات و بهبود کار سوق دهد.

ساده‌ترین راه برای دریافت انتقاد سازنده، درخواست آن است. از کسی که با شما کار کرده یا کد شما را دیده است در مورد کارتان نظر بخواهید. اگر بازخورد سازنده بخواهید، دیگران به احتمال زیاد به چیزی برای گفتن فکر می کنند، حتی اگر آن‌قدرها هم مهم نباشد. اگر این شخص وقت خود را برای ارائه بازخورد به شما اختصاص می دهد، به این معنی است که او به پیشرفت شما اهمیت می دهد. 

جمع آوری بازخورد برای توسعه‌دهندگانی که به تنهایی کار می‌کنند می‌تواند دشوارتر باشد. در صورت امکان، راه‌هایی برای برنامه‌نویسی با دیگران پیدا کنید، حتی اگر در حد کدنویسی دوستانه با چند دوست باشد.

یک راهنما (Mentor) پیدا کنید.

چه در کار کردن به صورت تیمی و چه به صورت انفرادی، یک مربی فنی می تواند به شما کمک کند تا مهارت های خود را سریعتر رشد دهید و از اشتباهات رایج جلوگیری کنید. یک مربی فنی که دانش و تجربه‌ی مناسبی برای ارائه‌ی موثر به شما داشته باشد.

شما همیشه مسئول انجام کارهای اساسی خواهید بود، اما اگر می‌خواهید مطمئن شوید که از اهدافتان منحرف نمی‌شوید، باید کسی را داشته باشید که بتواند بر کاری که انجام می‌دهید و مسیری که طی می‌کنید، نظارت داشته باشد.

با text editor یا IDE خود دوست شوید و میانبرهای صفحه کلید آن را بشناسید.

مانند چکش آهنگر، میکروسکوپ دانشمند یا تخته سیاه معلم، ویرایشگر متن (یا IDE) شما ابزاری ضروری برای کار شماست. خیلی مهم نیست که کدام ویرایشگر یا IDE را انتخاب کنید اما باید برای شناخت ابزار خود وقت بگذارید تا بتوانید با سرعت و مهارت بالا از قدرت آن بهره ببرید.  

برنامه را با توسعه دهندگان با تجربه تر پیش ببرید.

برنامه نویسی دونفره با توسعه دهندگان با تجربه تر می تواند دلهره آور باشد. آن‌ها به احتمال زیاد در بسیاری از کارها مانند نوشتن کد، حل مشکلات و خطایابی، از شما سریع‌تر هستند. با این حال، از این همکاری، چیزهای زیادی یاد خواهید گرفت. گاهی اوقات کار کردن بر روی مشکلات به تنهایی، می‌تواند آسان‌تر یا لذت بخش‌تر باشد، اما ممکن است بار آموزشی نداشته باشد.

به برنامه نویسان ارشد اطراف خود و همچنین سایر جونیورها گوش دهید و به آنها احترام بگذارید.

آلانا جورج یک توسعه دهنده در ThoughtWorks و از مربیان سابق دانشگاه ThoughtWorks است. او می‌گوید: «من دیده‌ام که مردم به سایر افراد با تجربه اطراف خود احترام می‌گذارند، اما به افراد جوان‌تر و به ظاهر کم تجربه‌تر  اهمیت نمی‌دهند. به یاد داشته باشید که می‌توانید از همه اطرافیان خود یاد بگیرید. توسعه نرم افزار یک حوزه‌ی عظیم است و هر کسی چیزی برای آموزش به شما دارد.»

به جای کامنت گذاری، نام خوب برای متغیرهای خود انتخاب کنید.

استفاده از کامنت به طور مداوم توسعه دهندگان نرم افزار را از هم جدا می کند. برخی از کامنت مناسب قدردانی می کنند، در حالی که برخی دیگر آنها را تقریباً غیر ضروری می دانند. برای هر دو طرف بحث وجود دارد، اما در هر صورت، لحظاتی که وسوسه می‌شوید یک کامنت بنویسید، فرصت خوبی برای مکث و تأمل است و سؤالات زیر را از خود بپرسید:

  • آیا این نشانه این است که اجرای من پیچیده است یا خواندن آن دشوار است؟
  • به جای نوشتن کامنت برای توضیح اینکه کد چه کار می کند، آیا می توانم کد را در یک متغیر، متد یا تابع جداگانه با یک نام توصیفی بیرون بکشم؟
  • آیا واقعاً در اینجا به کامنت نیاز دارم یا فقط چیزهای بدیهی را بیان می کنم؟

جهل خود را هر روز برملا کنید.

توسعه نرم افزار وسیع و چند وجهی است. حتی توسعه‌دهندگان نرم‌افزار با تجربه هم نمی‌توانند همه چیز را بدانند. بهترین راه برای افزایش سرعت به دست آوردن دانش، افشای جهل خود است.

حداقل یک بار در روز در مورد اصطلاح یا فناوری که درک نمی‌کنید می‌شنوید یا می‌خوانید. سر تکان ندهید و وانمود نکنید که متوجه می شوید. بپرسید. اگر صحبت نکنید، فرصتی برای یادگیری را از دست داده‌اید. اغلب با سابقه‌ترین و باتجربه‌ترین توسعه‌دهندگان (خصوصا زمانی که چیزی را نمی‌فهمند)، راحت‌تر اعتراف می‌کنند که اشتباهی مرتکب شده‌اند. آلانا جورج می‌گوید: «بسیاری از مردم می‌ترسند که احمق به نظر برسند یا نادانی خود را آشکار کنند، اما این کاری است که شما باید انجام دهید تا یاد بگیرید» بنابراین سؤال بپرسید، مسائل را روشن کنید و سپس بررسی کنید که درک‌تان درست است.

پروژه های جانبی داشته باشید.

پروژه های جانبی، زمین بازی شما هستند؛ مکانی برای دنبال کردن علایق و آزمایش ابزارهای جدید بدون ضرب الاجل‌های سخت یا ریسک بالا. برای توسعه دهندگان جوان، پروژه‌های جانبی یک راه عالی برای پر کردن شکاف های دانش، ایجاد تجربه، تصمیم گیری و مقابله با پیامدهای خوب و بد کار است.

پروژه های جانبی شما نیازی به بزرگ یا چشمگیر بودن ندارند. در واقع، پروژه‌های جانبی که می‌توانید در یک روز کاری یا کمتر به پایان برسانید ایده آل هستند. آن‌قدر کوچک هستند که دلهره‌آور نباشند، اما به اندازه‌ای بزرگ هستند که بتوانند چیز مفیدی را انجام دهند. اگر برای ایده‌ی انجام پروژه کوچک دچار مشکل شدید، سعی کنید یک مشکل کوچک در زندگی خود را با یک راه حل فنی حل کنید. 

در دنیای برنامه‌نویسی، چه چیزی بیشتر به شما کمک کرده تا پیشرفت کنید؟ نکات خود را در نظرات به اشتراک بگذارید.

از بهترین نوشته‌های کاربران سکان آکادمی در سکان پلاس