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

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

1. توسعه راه حل های جدید

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

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

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

3. نوشتن تست برای عملکرد

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

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

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

5. بررسی کد

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

6. تحلیل کد

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

7. بازآفرینی کد

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

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

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

9. شرکت در راهپیمایی های مختلف

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

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

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