راهنمای شغلی برنامه‌نویسان تازه‌کار (جونیور)
اگر در حال آموختن کدنویسی و ساخت اولین برنامه خود هستید یا این‌که در اولین شغل خود به‌عنوان توسعه‌دهنده نرم‌افزار فعالیت دارید، یا قصد دارید برای اولین بار وارد این صنعت شوید، توجه به نکات زیر کمک می‌کند وظایف خود را به بهترین شکل انجام دهید و ارتقاء شغلی دور از دسترس نباشد.
اسناد رسمی به‌جای Stack Overflow
وقتی برای اولین بار آموختن کدنویسی را آغاز می‌کنید، سایت استک اورفلو (Stack Overflow) بهترین دوست شما است که به بهشت برنامه‌نویسان معروف است. این سایت یک مرجع پرسش‌و‌پاسخ تخصصی در زمینه برنامه‌نویسی است و با کمک آن می‌توانید در کمتر از یک دقیقه پاسخ‌های مختلفی برای پرسش‌های‌تان به‌دست آورید. استک اورفلو به شما امکان می‌دهد تا زمانی که دچار تردید هستید یا با باگ‌ها روبرو می‌شوید و نمی‌دانید چگونه آن‌ها را برطرف کنید، کارتان را پیش ببرید. اما آمارها نشان می‌دهند توسعهدهندگان باتجربه (سنیور) کمتر برای یافتن پاسخ خود به سراغ استک اورفلو میروند و ترجیح می‌دهند در مورد زبان یا ابزاری که استفاده می‌کنند به مستندات رسمی مراجعه کنند.
بیشتر اوقات دلیل استفاده از سایت استک اورفلو، عدم درک کافی از فناوری‌ای است که با آن کار می‌کنید. استفاده از این سایت در کوتاه‌مدت می‌تواند مفید باشد، اما اگر دانش عمیق در ارتباط با ابزار یا زبانی ندارید، پاسخ‌های استک اورفلو کلید حل مشکل نیستند و باید از مراجع رسمی برای شناخت بهتر ابزاری استفاده کنید که با آن کار می‌کنید.
گرچه برقراری ارتباط با جامعه بزرگ‌تر و استفاده از نمونه کدها یا یافتن راه‌حل‌هایی کاربردی از برخی جهات می‌تواند خوب باشد، اما درک شما از زبان یا ابزاری که با آن کار می‌کنید، مهم‌تر است. شاید خواندن اسناد کمی خسته‌کننده باشد، اما برای به‌دست آوردن درک واقعی از زبان یا چارچوبی که با آن سروکار دارید مهم است.
دید خود را وسیع‌تر کنید
به‌طور معمول، توسعهدهندگان تازه‌کار هنگام کار با یک سیستم، تنها روی همان موضوع متمرکز می‌شوند، در حالی‌که دید توسعهدهندگان باتجربه وسیع‌تر است. مدتی طول می‌‌کشد تا توسعهدهندگان باتجربه درباره اثرات جانبی بالقوه کاری که انجام می‌دهند و نحوه انطباق آن با سیستم فکر کنند. توسعهدهندگان تازه‌کار باید حین کار به‌یاد داشته باشند که زاویه دید خود را گسترش دهند و به این فکر کنند که چگونه کد خود را در چارچوب سیستم به‌عنوان یک کل قرار دهند.
کیفیت کار (QA) خود را تضمین کنید
اکثر تیم‌ها ترکیبی از تست‌های خودکار یا دستی دارند تا اطمینان حاصل کنند که ویژگی‌های جدید می‌توانند الزامات را برآورده کنند و از کیفیت بالایی برخوردار هستند و هیچ‌یک از عملکردهای موجود را نقض نمی‌کنند.
در محیط‌های چابک (Agile) هنگامی‌که کارها عقب می‌افتد، مشکل ضدالگو به‌وجود می‌آید (یعنی از مرحله در حال توسعه، به مرحله تضمین کیفیت بازبینی و دوباره به مرحله در حال توسعه وارد می‌شوید). این مشکل زمانی اتفاق می‌افتد که توسعه‌دهنده معیارهای پذیرش را درک نکرده یا آن‌را برآورده نکرده است؛ یعنی به‌درستی به فهرست کارهایی که باید انجام شوند تا کار به‌سرانجام برسند دقت نکرده است.
قبل از آن‌که کار شما به مرحله بازبینی بکشد، با انجام آزمایش‌های دقیق می‌توانید کیفیت کار خود را بالا ببرید. با در نظر گرفتن سناریوهای آزمایشی زمان کار اعضای تیم خود را به‌حداقل برسانید و از به تعویق افتادن کارتان جلوگیری کنید. اگر هم تنها کار می‌کنید، مباحث QA کمک می‌کنند پروژه‌ها را سریع‌تر انجام دهید.
دنیای پیرامون حرفه خود را نادیده نگیرید
خیلی زود متوجه می‌شوید که درک چرایی کاری که انجام می‌دهید مهم‌تر از نحوه انجام آن است. اگر درک درستی از کسب‌وکار، صنعت یا سازمانی ندارید که در آن کار می‌کنید، ممکن است در نهایت چیزهایی تولید کنید که مردم به آن‌ها نیاز ندارند یا از آن‌ها استفاده نخواهند کرد. بخش قابل‌توجه اشتباهات توسعهدهندگان تازه‌کار به‌دلیل سوء تفاهم یا فرضیات آن‌ها در مورد حوزه‌ای است که در آن کار می‌کنند.
تست‌ها، سوپاپ اطمینان و قطب‌نمای شما هستند
نوشتن تست برای توسعهدهندگان تازه‌کار مهم است؛ به‌ویژه زمانی‌که در یک تیم کار می‌کنند یا در حفظ و نگه‌داری یک سیستم بزرگ‌تر که توسط چند توسعه‌دهنده طراحی می‌شود، مشارکت دارند. تست‌ها یک شیوه عالی هستند تا بتوانید مشکلات کدها را ارزیابی کنید و آسیب‌پذیری‌ها را شناسایی کنید. سعی کنید مجموعه تست‌های خود را در فواصل زمانی مختلف اجرا کنید تا مطمئن شوید که از مشکلات ناخواسته در امان هستیدو متوجه شوید کدها باید چه تغییراتی کنند. اگر به‌تنهایی کار می‌کنید و هنوز تست نمی‌نویسید، ارزشش را دارد بخشی از وقت خود را صرف تست‌نویسی در زبان انتخابی کنید.
تفکیک نگرانی‌ها
تفکیک نگرانی‌ها یا پیروی از اصل SOC می‌تواند از نشانه‌های یک توسعه‌دهنده ماهر باشد. SOC یک اصل مهم در برنامه‌ریزی و طراحی برای جداسازی برنامه به بخش‌های مجزا است؛ به‌طوری‌که هر بخش به یک نگرانی می‌پردازد. توسعهدهندگان باتجربه، غریزه شناسایی نگرانی‌های مجزا و مرزبندی بین آن‌ها را دارند. با این‌حال، نگرانی در این حوزه به چه معنا است؟ نگرانی (Concern) مجموعه‌ای از اطلاعات است که می‌تواند بر کد برنامه کامپیوتری اثر بگذارد.
توسعهدهندگان تازه‌کار اغلب برای شناسایی و جداسازی نگرانی‌های مختلف تلاش می‌کنند. یک قانون خوبی که می‌توانید داشته باشید این است که یک فایل برای هر حوزه از مسئولیت در کد ایجاد کنید.
یک ترفند مفید برای شناسایی حوزه‌های مجزا در مسئولیت‌ها، AND Test است. اگر زمانی‌که یک فایل یا یک کلاس را در کد خود توصیف می‌کنید به استفاده از کلمه AND نیاز پیدا کردید، به‌احتمال زیاد مسئولیت‌هایی را شناسایی کرده‌اید که می‌توانند از هم مجزا باشند. به این مثال توجه کنید:
- The Conference class is responsible for scheduling AND displaying conference timetables. (Fails the AND test).
یعنی کلاس Conference مسئول برنامه‌ریزی و نمایش جدول زمانی کنفرانس است. (در تست AND مردود می‌شود)
در مقابل:
- The ConferenceScheduler class is responsible for scheduling conferences.
- The SchedulePresenter is responsible for presenting schedules.
- یعنی کلاس ConferenceScheduler مسئول زمان‌بندی کنفرانس است.
- SchedulePresenter مسئول ارائه برنامه‌ها است.
وقتی کد خود را به این شکل تقسیم می‌کنید، ممکن است در نهایت به فایل‌هایی برسید که مختصر و فشرده و شاید کمتر از 50 خط کد باشند. به احتمال زیاد کار کردن با اپلیکیشینی که از کلاس‌های کوچک تشکیل شده که همگی به‌خوبی با هم کار می‌کنند، آسان‌تر از کار کردن با یک اپلیکیشن یکپارچه شامل چند کلاس بزرگ است که هر کدام کارهای متفاوتی را انجام می‌دهند.
متدهای کوتاه بنویسید
توسعهدهندگان تازه‌کار در کدهای خود با مشکل code smell روبرو هستند؛ به این معنا که متدها یا توابع طولانی می‌نویسند. دومین مشکل، عدم پیروی از الگوهای رایج نام‌گذاری که بیان‌گر کاری که متد انجام می‌دهد، است. ترکیب این دو اشتباه باعث می‌شود تا کدهای زیاد و با کیفیت پایینی داشته باشید. در واقع، تلاش برای درک یک متد طولانی و پیچیده که زنجیره‌ای از رویدادها را برای دستیابی به نتیجه نهایی فعال می‌کند، کار جالبی نیست. برای آن‌که مشکل فوق را حل کنید، ابتدا یک متد طولانی بنویسید، سپس آن‌را به متدهای خصوصی تقسیم کنید که هر کدام یک مرحله را اجرا می‌کنند و در انتها همه‌چیز را مستندسازی کنید.
به این مثال در زبان برنامه‌نویسی روبی توجه کنید. می‌خواهیم امکان فراخواندن متدی را داشته باشیم که با تاپینگ‌ها و چاشنی‌های انتخابی ما یک پیتزای خوشمزه درست می‌کند:
- def make_pizza_with(toppings)
- preheat_oven
- divide_and_roll_dough
- add_toppings(toppings)
- bake_pizza
- slice_and_serve
- end
متد make_pizza_with، متدهای دیگر را نیز فرا می‌خواند که هر کدام یک مرحله را در این فرآیند به‌اجرا در می‌آورند. هر کدام از این متدها شامل مجموعه مراحل فرعی خود هستند که آن‌ها را تکمیل می‌کنند، به‌عنوان مثال:
- def preheat_oven(temperature, time)
- walk_to_oven
- turn_on_oven
- turn_dial_to(temperature)
- set_timer_for(time)
شما می‌توانید به‌راحتی متد make_pizza_with را در این سطح پایین از جزئیات پیاده‌سازی کنید، مراحل جداگانه را حذف کنید و در عوض تمام جزئیات مختلف که برای تهیه یک پیتزا لازم هستند، مانند رفتن به سمت فر، بیرون آوردن مواد از یخچال، یا خارج کردن سینی مخصوص پیتزا از کابینت را اضافه کنید. با این حال، نوشتن یک دستورالعمل این‌چنینی، آزاردهنده است. به‌عنوان یک خواننده، ما به مراحل سطح بالا در یک فرآیند علاقه‌مند هستیم، نه همه جزئیات. اگر به روشی مشابه با متدهای خود رفتار کنید، کد شما خواناتر و نگه‌داری آن آسان‌تر خواهد بود.
اما چه زمانی قسمت‌هایی از یک متد بزرگ را به متدهای کوچک‌تر تقسیم کنیم؟ اغلب، زمانی متوجه این موضوع می‌شوید که مجبور هستید نظری را بنویسید تا توضیح دهد هر یک از بخش‌های کد شما چه کاری انجام می‌دهند. در این حالت باید متد بزرگ را به متدهای کوچک‌تر بشکنید.
به‌دنبال انتقادهای سازنده باشید
تعریف و تمجید چیزی است که همه دوست داریم و به ما انرژی می‌دهد تا کارمان را ادامه دهیم. علاوه بر اهمیتی که تعریف و تمجیدها دارند، انتقادهای سازنده برای کمک به پیشرفت شما به‌عنوان یک توسعه‌دهنده ضروری هستند. شما به‌عنوان یک توسعه‌دهنده تازه‌کار، هنوز نکات زیادی را باید یاد بگیرید و انتقاد سازنده می‌تواند کمک کند تا حوزه‌هایی را شناسایی کنید که رویکرد و کدهای شما را بهبود می‌بخشند. اگر با توسعهدهندگان دیگری کار می‌کنید که Pull Requestهای شما را بررسی می‌کنند، احتمالاً بازخوردهای منظمی در مورد کد خود به‌صورت خط به خط دریافت می‌کنید، اما ممکن است بازخوردهای مربوط به رویکرد کلی‌تان برای حل مسائل یا مهارتهای دیگر مانند نحوه کار با اعضای تیم را از دست بدهید. اگر در تیمی کار می‌کنید که گردش کار توسعه متفاوتی دارد، مانند برنامه‌نویسی دونفره، بازخوردهای طرف مقابل کمک می‌کنند کدنویسی بهتری انجام دهید.
یک مربی پیدا کنید
یک مربی فنی می‌تواند به شما کمک کند تا مهارتهای خود را سریع‌تر ارتقاء دهید و اشتباهات رایج را انجام ندهید. سوال این است که چگونه می‌توانید یک مربی پیدا کنید؟ خیلی به‌ندرت پیش می‌آید که به سراغ همکار یا دوستی برویم و بگوییم که آیا مربی من می‌شوی؟ نی آشیکوی تته (Nii Ashikwei Tetteh) توسعه‌دهنده نرم‌افزار می‌گوید: «ما در حال انجام کارهایی هستیم که چند دهه قبل آغاز شده‌اند و خیلی‌ها زودتر از ما این‌کار را انجام داده‌اند و دانش زیادی در این زمینه دارند. مسئولیت زیرسازی‌ها و کارهای پایه برعهده شما خواهد بود، اما اگر می‌خواهید مطمئن شوید که از اهدافتان منحرف نمی‌شوید، باید کسی را داشته باشید که بتواند در مسیری که می‌روید و کاری که انجام می‌دهید نظارت عینی داشته باشد.»
با ویرایشگر متن/IDE خود آشنا شوید و میانبرهای صفحه‌کلید آن‌را بشناسید
همانند چکش برای آهنگر، میکروسکوپ برای دانشمند یا تخته سیاه برای معلم، ویرایشگر متن یا محیط توسعه یکپارچه (IDE) یک ابزار لازم برای کار شما است. اگر با ابزاری که انتخاب می‌کنید، راحت و سریع هستید، هوشمندتر کار می‌کنید و دیگر توسعهدهندگان از کار با شما لذت می‌برند. احتمالا تا به حال با کسی برنامه‌نویسی کرده‌اید که با ویرایشگر خود راحت نیست و متوجه شده‌اید که این‌کار چقدر می‌تواند ناامیدکننده و آزاردهنده باشد.
خیلی مهم نیست کدام IDE را به‌عنوان ابزار کدنویسی خود انتخاب می‌کنید. اگر روی یادگیری جنبه‌های مختلف یک ابزار کار کنید، سرعت کدنویسی‌تان چند برابر بیشتر می‌شود. اگر از یک IDE مدرن مانند Eclipse یا IntelliJ و یک زبان ثابت مانند جاوا استفاده می‌کنید، IDE پیشنهادات زیادی را در جهت بهبود کدها ارائه می‌دهد، مانند ویژگی‌ها و متدهای استفاده‌نشده یا عباراتی که می‌توانند ساده‌سازی شوند؛ به این پیشنهادها دقت کنید.
برنامه‌نویسی دو نفره با توسعهدهندگان با‌تجربه‌تر انجام دهید
برنامه‌نویسی دو نفره (Pair Programming) با توسعهدهندگان باتجربه می‌تواند دلهره‌آور باشد. آن‌ها در نوشتن کد، حل مسائل و شناسایی باگ‌ها و خطاها از شما سریع‌تر هستند. در این حالت مسئولیت شما Driving یعنی کنترل صفحه‌کلید است. در حالی‌که توسعه‌دهنده باتجربه هدایت‌گری (Navigator) را برعهده دارد؛ یعنی عقب می‌نشیند و هدایت می‌کند. برنامه‌نویسی دو نفره نکات ارزشمندی به شما می‌آموزد. گاهی‌اوقات به‌تنهایی کار کردن می‌تواند آسان‌تر یا لذت‌بخش‌تر باشد، اما ممکن است کمک چندانی به یادگیری شما نکند.
کم‌دانشی یا بی‌دانشی خود را بپذیرد
توسعه نرم‌افزار یک زمینه وسیع و چند‌وجهی است که با حوزه‌های زیادی مرتبط است. تقریباً در هر زیرمجموعه‌ای از توسعه نرم‌افزار، متخصصانی وجود دارند، از پایگاه‌های داده گرفته تا امنیت و بهینه‌سازی عملکرد. توسعهدهندگان باتجربه نرم‌افزار همه نکات را نمی‌دانند و به احتمال زیاد به‌عنوان یک توسعه‌دهنده تازه‌کار، نکات زیادی باقی مانده است که باید یاد بگیرید. بهترین راه برای افزودن به دانش خود این است که ابتدا کم‌دانشی یا بی‌دانشی خود را بپذیرید. شاید هر روز نام اصطلاحات یا فناوری‌هایی را بشنوید یا بخوانید که هیچ درکی از آن‌ها ندارید. در این‌صورت، سر تکان ندهید و وانمود کنید که متوجه می‌شوید؛ بلکه سوال کنید. اگر در مورد آن صحبت نکنید، فرصت یادگیری را از دست می‌دهید. احتمالاً متوجه شده‌اید که اغلب توسعهدهندگان با‌سابقه و باتجربه، راحت‌تر به اشتباهی که مرتکب شده‌اند یا چیزی که متوجه نمی‌شوند، اعتراف می‌کنند. بسیاری از مردم می‌ترسند ناآگاهی یا بی‌اطلاعی خود را آشکار کنند، اما این کاری است که شما باید انجام دهید تا یاد بگیرید؛ بنابراین سؤال بپرسید تا مسائل برای شما روشن شوند.
پروژه‌های جانبی داشته باشید
پروژه‌های جانبی زمین بازی شما هستند. مکانی هستند برای دنبال کردن علایق و آزمایش ابزارهای جدید بدون آن‌که با ضرب‌الاجل‌های سخت یا ریسک‌های بالا همراه باشند. برای توسعهدهندگان تازه‌کار، پروژه‌های جانبی یک روش عالی برای پر کردن خلاءهای دانشی، تجربه‌اندوزی، تصمیم‌گیری، و شناسایی نکات مفید است. نیازی نیست پروژه‌های جانبی بزرگ یا چشم‌گیر باشند. در واقع، پروژه‌هایی که بتوانید در یک روز کاری یا کمتر به‌پایان برسانید ایده‌آل هستند.
از تجربه برنامه‌نویسان باتجربه اطراف خود و سایر برنامه‌نویسان کم‌تجربه استفاده کنید
اغلب دیده می‌شود که آدم‌ها به افراد باتجربه اطرافشان احترام می‌گذارند، اما به برنامه‌نویسان جوان و بی‌تجربه بی‌احترامی می‌کنند یا فکر می‌کنند که آن‌ها به اندازه خودشان نمی‌دانند و درک نمی‌کنند. به‌یاد داشته باشید که شما می‌توانید از همه اطرافیان خود یاد بگیرید. توسعه نرم‌افزار یک حوزه وسیع است و هر کسی چیزهایی برای آموختن به شما دارد.
