وظایف معمول یک توسعه دهنده جاوا در یک پروژه

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

1. طراحی راه حل های جدید

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

2. نوشتن عملکرد جدید

این مرحله - اجرای عملکرد جدید - به طور منطقی پس از مرحله قبلی دنبال می شود. تمام کارهای مربوط به یک پروژه به وظایفی در Jira تقسیم می شود که سپس بر اساس حجم کاری آنها به توسعه دهندگان داده می شود. رویکردهای متفاوتی برای این فرآیند وجود دارد که به عنوان «روش‌شناسی» شناخته می‌شوند، که می‌توانید با جزئیات بیشتر در این مقاله در CodeGym بخوانید . به عنوان یک قاعده، وظایف یک تخمین دارند ، که زمان پیش بینی شده برای تکمیل آنها است. این یا توسط شما، توسعه دهنده هنگام دریافت کار، یا توسط سرپرست تیم، یا در طول برنامه ریزی، به طور جمعی توسط تیم توسعه تنظیم می شود. این حدس زمان بسیار به ندرت دقیق است، زیرا عوامل مختلف زیادی بر توسعه نرم افزار تأثیر می گذارد. به عنوان مثال، اینکه یک برنامه نویس با فناوری مربوطه آشنا یا ناآشنا باشد، تجربه کلی او، مشکلات غیرقابل پیش بینی مختلف و غیره. بنابراین، اگر در زمان کدنویسی به تمام تخمین های زمان خود نرسیدید، این پایان دنیا نیست. اینها فقط برآوردهای کلی هستند. گفتنی است، همه پروژه ها نیاز به تخمین زمان ندارند. من شخصاً زندگی بدون آن را بسیار آسان‌تر می‌دانم، به خصوص وقتی که نخست وزیر روزی چند بار با این سؤال که "تخمین زمان شما کجاست؟" بنابراین، یک کار دریافت می‌کنید، قابلیت‌های لازم را می‌نویسید، آن را به شاخه اصلی در GIT فشار می‌دهید و سپس وضعیت وظیفه را روی " آماده برای بررسی " در Jira تنظیم می‌کنید و دعا می‌کنید که تغییرات کد شما برای بازنگری همراه با نظرات.

3. تست های نوشتاری

بازبین، یعنی شخصی که کد شما را بررسی می‌کند، عملکردی را که پیاده‌سازی کرده‌اید دوست دارد، اما او یک سوال از شما دارد: تست‌های مرتبط کجا هستند؟ بنابراین او کار را برای تجدید نظر به شما می فرستد. تست ها بخش ضروری هر برنامه جاوا هستند. با اجرای تست ها می توانید فورا مکان هایی را که اپلیکیشن به درستی کار نمی کند شناسایی کنید. به عنوان مثال، یک توسعه دهنده تغییراتی را در قسمتی از سیستم ایجاد می کند که منجر به تغییر رفتار در قسمت دیگر می شود، اما هنگام کدنویسی متوجه این موضوع نشد. با اجرای تست‌ها، او می‌تواند ببیند که برخی از تست‌ها شکست خورده‌اند، به این معنی که آنها نتایج مورد انتظار را تولید نکرده‌اند. این به او می گوید که چیزی در جای دیگری از سیستم خراب است. با دانستن این موضوع، او تغییرات قطعی را در سرور انجام نمی دهد و در عوض به کار بر روی اشکال زدایی کد خود ادامه می دهد. بله، تعداد کمی از توسعه دهندگان عاشق نوشتن تست هستند، اما مزایایی که برای توسعه نرم افزار به ارمغان می آورند را نمی توان انکار کرد. خود مشتریان اغلب سطح پوشش آزمایشی را که می خواهند حفظ کنند (به عنوان مثال 80٪) نشان می دهند. این بدان معناست که شما باید انواع مختلف تست ها را بدانید و بتوانید آنها را بنویسید. توسعه دهندگان جاوا عمدتاً تست های واحد و تست های یکپارچه سازی را می نویسند، در حالی که آزمایش های گسترده تر (پایان به انتها) توسط کارشناسان QA و تست اتوماسیون انجام می شود.

4. پیدا کردن و رفع اشکال

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

5. بررسی کد

همانطور که در بالا ذکر شد، به محض تکمیل یک کار، باید برای بررسی ارسال شود. اگر بازبینی را بگذراند، به شعبه اصلی می رود. در غیر این صورت، با نظراتی که باید به آنها رسیدگی شود، به توسعه دهنده بازگردانده می شود. البته، می‌دانید که کد شما توسط توسعه‌دهندگان همکار بررسی می‌شود، نه با قدرت بالا. با این حال، همه مجاز به انجام بازبینی کد نیستند - فقط با تجربه ترین توسعه دهندگان که با تمرینات دنیای واقعی سخت شده اند، می توانند تفاوت بین کد خوب و کد بد را تشخیص دهند. بررسی کد معمولاً با استفاده از ابزار کمکی مانند Crucible انجام می شود . بازبین‌ها کد را مرور می‌کنند و در صورت لزوم، نظرات خود را در مورد برخی خطوط می‌نویسند. انواع نظرات می تواند وجود داشته باشد. مثلا بعضی ها انتقادی هستند. اگر به آنها رسیدگی نشود، بازبینی کننده اجازه نمی دهد کد متعهد شود. نظرات دیگر، مثلاً، صرفاً اظهاراتی در مورد رویکرد انتخاب شده است. توسعه‌دهنده می‌تواند به آن‌ها گوش دهد، توجه داشته باشد یا نادیده بگیرد. یک تیم می‌تواند قوانین و رویه‌های خود را برای بازبینی کد ایجاد کند، درباره اینکه چه چیزی ارزش توجه دارد و چه چیزی نه، چه بازه زمانی باید برای تکمیل بازبینی کد اختصاص داده شود و غیره توافق کنند. تجربه به تنهایی برای انجام بازبینی کافی نیست: شما هنوز نیاز به رشد زیادی در مهارت های فنی خود و خواندن کتاب های مختلف دارید (مثلاً "Clean Code").

6. تحلیل کد

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

7. کد Refactoring

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

8. نوشتن اسناد

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

9. جلسات مختلف

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

10. انجام/گذراندن مصاحبه

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