راهنمای توسعه دهندگان جاوا در آینده. شرکت - قسمت 1

«به این دستاوردهای فناوری که ساخته‌اید خیلی مغرور نباشید. توانایی نابود کردن یک سیاره در مقایسه با قدرت نیرو چیزی نیست." - دارث ویدر در ستاره مرگ.

مقدمه

احتمالاً دو بخش بعدی از سری مقالات برای بسیاری مورد انتظارترین و دلایل خوبی است. چه چیزی وجود دارد، فراتر از افق، فراتر از جاوای خالص؟ توسعه دهندگان جاوا در هر پروژه چه چیزی تنفس می کنند؟ این را یک راهنمای واقعی و کامل خودآموز برای هر مهندس متوسطی که زبان برنامه نویسی اصلی آنها جاوا است در نظر بگیرید. من قصد دارم تا حد امکان میانگین بیمارستان را پوشش دهم و نه تنها محبوب ترین چارچوب ها، بلکه راه حل هایی را که در حال حاضر مرتبط تلقی می شوند، شرح دهم. طبیعتا ابزارهای زیادی وجود دارد و درک اینکه کدام مهمترین و بهترین هستند راهی است به ناکجاآباد. هر یک از شما به بخش «شغل» در DOU نگاه کردید و مجموعه‌ای از فناوری‌ها را پیدا کردید که دائماً از یک شغل به جای خالی تکرار می‌شوند. من می دانم که توصیف همه چیز غیرممکن است، اما ارائه یک چارچوب کلی خوب است، بنابراین بیایید سعی کنیم این جهت را دنبال کنیم. به نوعی در گذشته، در یکی از پروژه ها، شرمساری نسبتاً جالبی رخ داد، که، به نظر من، هر از گاهی برای بسیاری در یک منطقه یا آن منطقه به طور مداوم تکرار می شد و می شود. وظیفه ضمیمه کردن یک رندر از یک صفحه HTML به عملکرد تمام شده صرفاً برای نشان دادن وضعیت موجودیت های جداگانه تنظیم شده بود. در نتیجه، همکارم تصمیم گرفت برگ آویشن فنری را بچسباند، که بخشی از وابستگی‌های اصلی خود اسپرینگ را در زمانی که هیچ‌کس از Spring استفاده نمی‌کرد، کشید. و این همه برای یک صفحه معمولی است که به سادگی وضعیت 2-3 نهاد را نشان می دهد. "من هرگز فایده زیادی در استفاده از دو شمشیر نوری ندیده ام... به نظر من این یک خودنمایی است" - اوبی وان کنوبی. از یک طرف، توسعه دهنده مشکل را در سریع ترین زمان ممکن حل کرد، چارچوبی را نصب کرد که با آن تجربه استفاده از آن را داشت و در عرض چند ساعت آن را در پروژه ادغام کرد. اما از طرف دیگر، حجم برنامه ما افزایش یافته است، بنابراین سؤال ساده این است: آیا او کار را درست انجام داده است؟ برای چنین کارهای اتمی، وقتی مطمئن باشید که این Thimeleaf/Spring MVC و غیره بزرگتر است. هیچ جا استفاده نمیشه بهتره اصلا استفاده نکنید. من همیشه از عباراتی مانند "اوه! بله، ما در اینجا از Hibernate استفاده کردیم! ببینید، همه چیز عالی است، ORM!» و وقتی از این سوال منطقی پرسیده شد که آیا می‌توان با JDBC معمولی اینجا کنار آمد، شانه‌هایشان را بالا انداختند. یک معماری معمولی وجود دارد که باید ساده باشد، باید با ترس با آن برخورد کرد، نه با چارچوب های مد روز و فوق مدرن. همانطور که اوبی وان در بالا گفت، این چیزی بیش از خودنمایی نیست، اگرچه لازم است بدانید که چگونه از آنها استفاده کنید. به نظر من جوان جاوائی بدشانس تر از همه است - این همه مشخصات، این همه کتابخانه که نیاز به مطالعه دارند. جاوا EE به تنهایی دارای اسناد از طریق سقف است. این سوال پیش می آید که یک مبتدی باید چه کاری را انجام دهد، در مرحله بعد چه چیزی را یاد بگیرد، پس از هورستمن چه کاری باید انجام دهد؟ پاسخ ساده: متأسفانه با افراد زیادی آشنا می شوید. و ما نه با چارچوب های تجاری، بلکه با چیزهای ضروری تری شروع خواهیم کرد.

سیستم های عامل

لینوکس

علاوه بر ویندوز و/یا یوسمیتی دنج، باید با لبخند دستان خود را به سمت لینوکس دراز کنید. برای برخی از پروژه ها، کافی است کاربر باشید و بدانید که چگونه از خط فرمان استفاده کنید، برای دیگران - خیلی بیشتر. کدام راه بهتر است؟ به سادگی هزاران کتاب/آموزش در اینترنت وجود دارد. با نصب اوبونتو یا هر توزیع دیگری که دوست دارید شروع کنید و سعی کنید تا یکی دو ماه آینده از آن به عنوان سیستم عامل اصلی خود استفاده کنید. اگر شروع به یادگیری جاوا در لینوکس با کامپایل و دستکاری فایل ها با استفاده از ترمینال کنید، بسیار بهتر خواهد بود. خط فرمان لینوکس توسط ویلیام شاتز . این کتاب را نه به عنوان یک رمان "50 سایه خاکستری"، بلکه به عنوان یک دوره تعاملی کامل بخوانید - یک ترمینال باز کنید و بعد از نویسنده تکرار کنید. آیا اصول اولیه و نحوه عملکرد لینوکس را می خواهید؟ بیایید درس علوم کامپیوتر و سیستم عامل را نخوانیم - این در قسمت بعدی است. به edx.org بروید و دوره آسان Introduction to Linux را امتحان کنید . همچنین کتابی از مجموعه فوق الذکر چگونه لینوکس کار می کند: آنچه که هر ابرکاربر باید بداند توسط برایان وارد وجود دارد . یک نشریه نسبتا مصور که به شبکه، دستگاه ها و مدیریت منابع توجه دارد. برو جلو؟ یه کتاب عالی هست که اتفاقا من یه جایی اینجا دارم... آره (گرد و غبار تکون میخوره)... اینجا هست! یونیکس و لینوکس: راهنمای مدیر سیستم اوی نمت. کتابچه راهنمای بسیار بزرگ، به خوبی ترجمه شده است. صادقانه بگویم، من شخصاً به آن تسلط نداشتم، اما اصول اولیه مدیریت (بخش اول) را خیلی دوست داشتم. به طور طبیعی، شما نمی توانید اسکریپت Shell را نادیده بگیرید. بهتر است همه اینها را در عمل امتحان کنید، اما از کتاب‌ها می‌توانید به آموزش برنامه‌نویسی پوسته bash: Unix Shell توسط کامرون نیوهام نگاه کنید. چنین حجم عظیمی از ادبیات در لینوکس/یونیکس را نمی توان به طور کامل پوشش داد، به خصوص در این مقاله، که لینوکس در پس زمینه است. همکار من در محل کار، که در این مورد سگ را خورد، یک چیز نسبتاً کاربردی توصیه کرد: ArchLinux را دانلود کنید و سعی کنید آن را راه اندازی کنید. در این فرآیند شما بیشترین چیزی را که من نمی خواهم یاد خواهید گرفت!

پنجره ها

در رزومه برنامه نویسان ستونی وجود دارد: "ویندوز بیش از 10 سال تجربه دارد." البته من به شما تبریک می گویم که از 10 سالگی روی ویندوز کانتر بازی می کنید، اما از شما می خواهم که در مصاحبه پیشاپیش خود را سوراخ نکنید، زیرا در پروژه ای که از نزدیک با آن کار می کنید IIS، batch/powershell، خدای نکرده رجیستری، مصاحبه واقعا سخت نخواهد بود و علاوه بر پوزخند مقابل فرد نشسته. لیدا شما نیز یک دوز تحقیر دریافت خواهید کرد. آیا به این نیاز دارید؟ پاسخ خود را نشان می دهد. ویندوز دزدی خود را از تورنت کنار بگذارید و سعی کنید آن را روی نوعی ماشین مجازی ویندوز سرور نصب کنید. آن را نه تنها از سمت کاربر و نصب JAVA_HOME مطالعه کنید. در این راستا راهنمای تقریبا کاملی در قالب کتاب Mastering Windows Server 2012 R2 اثر Mark Minasi وجود دارد . به عنوان مثال، اگر از PowerShell استفاده می کنید، کتاب عالی Windows PowerShell in Action نوشته Manning توسط Bruce Payette را بررسی کنید . من درک می کنم که رفتن از طریق 1000 صفحه غیرممکن است، اما حداقل می توانید آن را به عنوان یک مرجع نزد خود نگه دارید. به نظر من هیچ چیز دیگری لازم نیست. در نتیجه به خلأهای دانش خود در استفاده از ویندوز توجه کنید و اطلاعات مورد نظر خود را در اینترنت جستجو کنید.

ساخت ابزار

ماون

مهمترین چیزی که در Maven باید فهمید چیست؟ در اینجا اولین مراحل و وظایف آمده است:

1. یاد بگیرید که Maven در هر مرحله چه می کند، حتی می توانید آن را حفظ کنید. این تقریباً 80٪ موفقیت است و به شما تصویر واضحی می دهد.
2. پروژه های sandbox خود را به صورت محلی با یک سیستم چند ماژول، با مدیریت وابستگی صریح ایجاد کنید. سعی کنید کتابخانه های شخص ثالث را پیوست کنید، سعی کنید با استفاده از آنها چیزی ایجاد کنید.
3. با پروفایل بازی کنید
4. درک مدیریت افزونه ها و مطالعه لیست محبوب ترین افزونه ها در وب سایت رسمی.
5. بررسی کنید که چگونه می توانید از maven در پروژه خود به بهترین شکل استفاده کنید. به عنوان مثال، ساخت های موازی می توانند زمان ساخت را به میزان قابل توجهی کاهش دهند.

برای یک شیرجه سریع، به نسخه روسی وب سایت Apache Maven بروید ، چند آموزش را در گوگل جستجو کنید. با این حال، ویرایش سوم یکی از کتاب های اصلی Maven منتشر نخواهد شد. تاکنون این نسخه دوم Sonatype's Maven: The Definitive Guide است . برای سطح پیشرفته، ایجاد پلاگین خود مناسب است. نگران نباشید که چه نوع پلاگینی باید ایجاد کنید، زیرا بسیاری از آنها در حال حاضر وجود دارند! سعی کنید نوعی آنالوگ ایجاد کنید، مراحل را به صورت دو و دو مطالعه کنید.

ANT

این ابزار بسیار ساده تر به نظر می رسد، بنابراین چیز زیادی برای یادگیری در اینجا وجود ندارد. هنوز پروژه هایی وجود دارد که ANT تنها ابزار ساخت است. این کاملاً طبیعی است: ANT خود را به عنوان یک ابزار ساخت ساده و سرراست در زمینه مدیریت وظایف کوچک اتمی (وظایف مورچه) ثابت کرده است. البته پلاگین های زیادی در اینجا وجود دارد، درست مانند Maven. برای شروع کار با ANT، موارد زیر را انجام دهید:

• سعی کنید فایل ها و پوشه ها را دستکاری کنید
• اجرای دستورات مختلف برای اجرای وظایف بر این اساس وابستگی ها و اولویت وظایف را در ANT یاد بگیرید.
• باز کردن بسته و/یا بایگانی فشرده. در وظایف، سعی کنید با محتویات آرشیو و غیره بازی کنید.

نیازی به ارائه یک سری منابع برای یادگیری ANT نیست. برای یک شیرجه کم و بیش عمیق، صفحه رسمی مورچه آپاچی کافی است. ( ant.apache.org ) و کتاب های مورچه در عمل نوشته استیو لاگرن .

گریدل

برای من، Gradle بیشتر به ANT نزدیک است تا Maven، اما کاملاً می توان آن را برادر ناتنی این دو مرد نامید. چرخه حیاتی شبیه به Maven و انعطاف پذیری همان وظایفی دارد که ANT دارد. خوب، مهم ترین چیز این است که Gradle از XML استفاده نمی کند و علاوه بر این، اگر کم و بیش با Groovy آشنایی دارید، می توانید هر کاری که می خواهید با آن انجام دهید. به طور کلی، یک چیز بسیار خوشمزه است. از استفاده از Ant/Maven/Gradle در زمینه IDE خود نترسید. این ابزارها به شدت در Eclipse/IDEA ادغام شده اند و استفاده از این ابزارها در زمینه IDE بسیار راحت است.

یکپارچه سازی مداوم

تئوری

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

جنکینز

جنکینز با نام مستعار هادسون برنامه باز، دوستانه، آسان برای استفاده. برای آشنایی بیشتر با جنکینز، موارد زیر را امتحان کنید:

1. آن را در رایانه خود دانلود کنید. JDK، Maven، ANT و هر آنچه برای پروژه نیاز دارید را نصب و پیکربندی کنید.
2. اولین Job را ایجاد کنید و مکان پروژه خود را مشخص کنید، به عنوان مثال، pom.xml اصلی. آن را اجرا کنید، مطمئن شوید که یک نوع آزمایش دارید تا به وضوح قابل مشاهده باشد.
3. یاد بگیرید که پروژه خود را با تنظیمات و گزینه های مختلف اجرا کنید.
4. پلاگین های مختلف را ضمیمه کنید و ببینید که چگونه در ارتباط با پروژه شما کار می کنند.
5. ایجاد محرک برای مشاغل مختلف. یک خط لوله کوچک ایجاد کنید.
6. DSL را کاوش کنید و سعی کنید آن را با جنکینز ادغام کنید.
7. یک Slave را از رایانه دیگری تنظیم کنید و/یا آن را به یک ماشین معمولی برای اجرای بیلدها تبدیل کنید.
8. ساخت های شبانه ایجاد کنید.

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

تیم سیتی

بله، TeamCity رایگان نیست، اما ببینید چقدر خوب در اکوسیستم محصولات JetBrains ادغام شده است. Intellij Idea و TeamCity یک اتحادیه عالی هستند. به طور کلی، اگر قبلاً با جنکینز آشنا هستید، TeamCity برای شما یک جنگل تاریک نخواهد بود و بالعکس. به جای برده - عوامل، همان ماشه ها و غیره. اما برخلاف جنکینز، TeamCity دارای ویژگی‌های شگفت‌انگیزی مانند اجرای از راه دور، که به عنوان commit از پیش آزمایش‌شده نیز شناخته می‌شود، آمارهای بصری بسیار بیشتر و موارد دیگر را دارد. من راهنمای کاربر در YouTube را که خود JetBrains ساخته است بسیار دوست دارم ( راهنمای کاربر TeamCity (قسمت 1 از 9) - مقدمه ). به نظر من TeamCity بصری است و مستندات آن از استاندارد بالایی برخوردار است. اما اگر فکر می کنید کتابی وجود دارد که ارزش بررسی دارد، لطفاً آن را در نظرات بگذارید. البته، من فقط بخش کوچکی از این سیستم های CI را لیست کرده ام، اما ما همه چیز را در محدوده محدود داریم. احتمالاً بهترین راهنمای یادگیری، تمرین است. آن را روی کامپیوترم نصب کردم، راه اندازی کردم، بیلدها را خراب/بازیابی کردم و به رختخواب رفتم. و سپس با خیال راحت می توانید کتاب رکورد را برای من بیاورید (اگر بخواهید :).

سیستم کنترل نسخه

صحبت زیاد در مورد VCS فایده ای ندارد. این چیزی است که باید باشد و بدون آن مدیریت پروژه مانند دوران مزوزوئیک خواهد بود. مشابه سیستم های CI، بیایید به دو مورد از محبوب ترین راه حل ها نگاه کنیم: Git و SVN.

Git

Git ما ثابت کرده است که یک سیستم کنترل نسخه توزیع شده پایدار است. از اینجا شروع به یادگیری کنید و تمام فصل ها را با Git که قبلاً پیکربندی شده است مرور کنید. سپس مجموعه ای شگفت انگیز از آموزش های تعاملی از Code School وجود دارد. همچنین یک راهنمای کوتاه از آنها به نام Try Git: Code School وجود دارد . از کتاب‌هایی که می‌توانم نسخه Control with Git نوشته Jon Loeliger را توصیه کنم اگر به لاک پشت عادت دارید (TortoiseSVN، یادداشت نویسنده) و از کنسول می ترسید، البته می توانید TortoiseGit آنالوگ آن را دانلود کنید، اما، به نظر من، بسیار دلپذیرتر و از نظر زیبایی دلپذیر راه حل محصول Atlassian - SourceTreeApp است. شما می توانید با مخازن راه دور تمرین کنید، زیرا سرویس های میزبان کافی در اینترنت وجود دارد. اگر می خواهید، به صورت محلی تمرین کنید. نه؟ سپس یک حساب کاربری در GitHub ایجاد کنید و در حالت کامل کار کنید: چند commit انجام دهید، پروژه منبع باز را فورک کنید، چند ادغام بین شاخه ها و غیره انجام دهید.

SVN

یکی دیگر از VCS به همان اندازه محبوب SVN است. این سیستم نمی تواند از توزیع به خود ببالد. هر یک از آنها رویکردهای خاص خود را دارند، جوانب مثبت و منفی خود را دارند. مکالمه جالب بین یک تازه کار و یک کاربر SVN را حتما بخوانید . یک کتاب رایگان از سایت read-bean.com با ترجمه روسی وجود دارد . یک دوره آموزشی کوچک از TutorialsPoint نیز بسیار مفید خواهد بود . وب سایت رسمی آپاچی subversion.apache.org را از دست ندهید . جالب ترین مشتری برای من TortoiseSVN فوق الذکر است. در میان کتاب ها می توان به موارد زیر اشاره کرد: نسخه کنترل با براندازی اثر مایکل پیلاتو . من آن را دوست داشتم زیرا به مدیریت خود سرور SVN توجه می کند. امیدوارم نکات اصلی را از دست ندهم.

ابزار تست

ایده خوبی خواهد بود که در پروژه های کوچک سندباکس خود بفهمید که تست های واحد، ادغام و تست رگرسیون چیست. JUnit تئوری تست های واحد به خوبی در کتاب های مقاله قبلی توضیح داده شده است. به طور خاص، Clean Code حتی جونیت را به عنوان یکی از کتابخانه های محبوب در این زمینه توصیف می کند. اما وقتی صحبت از JUnit به‌طور خاص می‌شود، یک کتاب کوچک عالی به نام آزمایش واحد عملی با JUnit و Mockito توسط Tomek Kaszanowski وجود دارد البته، چیزهای بیشتری از JUnit و Mockito در آن وجود دارد. در اینجا نویسنده Matchers را معرفی می‌کند، نمونه‌هایی از تست‌های پارامتری شده را ارائه می‌دهد و به طور خلاصه به TDD می‌پردازد. کتابی هم هست که به تازگی منتشر شده است. این تست عملی واحد در جاوا 8 توسط جف لانگر است. نویسنده Hamcrest را معرفی می کند، بهترین روش ها و البته جاوا 8 را توضیح می دهد. می توانید با خیال راحت بعد از کتاب Tomek بخوانید. به هر حال، در مورد TDD. من نمی‌خواهم در مورد اینکه آیا ارزش استفاده از آن‌ها را دارد، خوب یا بد، و اینکه آیا مشتریان به آن‌ها نیاز دارند یا خیر، صحبت کنم. فقط به یاد داشته باشید: کار در TDD تازگی ندارد و بسیاری از پروژه ها از این روش استفاده می کنند و برای بسیاری از افراد این تنها قانون غیرقابل انکار است. در تئوری، شما می توانید کلاسیک را بخوانید. کنت بک - توسعه مبتنی بر آزمایش: با مثال . چیزی که من بیشتر از همه دوست داشتم، قسمت مربوط به الگوهای TDD بود. با کمال تعجب، یک دوره اول شخص خوب - Let's Play TDD (200 ویدیو!) در یوتیوب وجود دارد. بحث خود فاولر در مورد اینکه آیا استفاده از TDD ارزش دارد یا نه، طراحی را خراب می کند یا نه، جالب نیست . فقط این را یک بار برای همیشه به خاطر بسپارید: TDD طراحی بدی ایجاد نمی کند، شما آن را ایجاد می کنید. اگر از BDD بیشتر استفاده می کنید (یکی با دیگری تداخل ندارد) و به عنوان مثال، از Cucumber در یک پروژه استفاده می کنید، پس این یک صفحه کمی متفاوت است. کتاب خوبی در این زمینه Manning BDD in Action: Behavior-driven Development برای کل چرخه عمر نرم افزار نوشته جان فرگوسن اسمارت است . به هر حال، جان فرگوسن اسمارت به طور فعال این موضوع را برای توده ها تبلیغ می کند. اگر شما یک اسکرام مستر یا PM هستید که در نهایت به چشمانش آسیبی نمی رساند، اما از دیدن تست های زمانی-اگر-آنگاه لذت می برد، پس حتما جان را در توییتر دنبال کنید . در مورد Cucumber، به پیاده سازی جاوا در وب سایت رسمی نگاه کنید و کتاب The Cucumber Book: Behavior-Driven Development نوشته مت وین را بخوانید .

کتابخانه های شخص ثالث

مهم است که بتوانید در صورت لزوم از کتابخانه های محبوب استفاده کنید - آنها زندگی روزمره هر توسعه دهنده جاوا را ساده می کنند. راه حل های محبوب شامل موارد زیر است: Joda Time. پیشنهاد می کند تا تاریخ و زمان نامناسب بومی را به طور کامل با JodaTime راحت تر جایگزین کند. اینجا یک مرجع خوب است . لطفاً توجه داشته باشید که اگر قبلاً از جاوا 8 استفاده می کنید، JodaTime چندان کمکی نخواهد کرد. واقعیت این است که API جدید DateTime به طور کامل جایگزین این کتابخانه شده است و حتی در برخی جاها هوشمندانه کپی و پیست شده است. طبق مقاله خود نویسنده ، هر کلاس Joda را می توان به راحتی با یک آنالوگ از java.time جایگزین کرد. گواوا گوگل. از بسیاری جهات، جاوا 8 حتی جایگزین گواوا می شود. همان Objects، Stream API، Java Predicate و خیلی چیزهای دیگر پیشنهاد می کند که آن را جایگزین کنید و اصلاً از آن استفاده نکنید. تکرار می کنم، اگر جاوا 8 ندارید، هیچ چیز بهتر از این راهنما و دستان مستقیم شما نیست.

آپاچی کامانز

مقابله با این هیولا چندان آسان نیست: حدود 40 کتابخانه برای همه موارد، از اعتبار سنجی معروف commons.lang تا xml، از DBUtils تا commons.io . طبیعتاً نیازی نیست که با همه چیز آشنا شوید، اما همراه داشتن کتاب‌ها و آموزش‌های کتاب آشپزی مفید خواهد بود. به عنوان مثال، برای درک اینکه آپاچی کامانز چیست، می توانید کتاب آشپزی جاکارتا کامانز نوشته تیموتی اوبرین را بررسی کنید.

نتیجه

Enterprise به قدری وسیع است که شروع به بحث در مورد JavaEE و سایر چارچوب‌ها بدون همه چیزهایی که این Enterprise را احاطه کرده است احمقانه است. بنابراین، در قسمت دوم به هر یک از لایه‌های معماری چند لایه، خدمات و غیره می‌پردازیم. از توجه شما بسیار سپاسگزارم. پایان قسمت اول. قسمت های قبلی سریال:

1. راهنمای توسعه دهندگان جاوا در آینده. مبانی جاوا
2. راهنمای توسعه دهندگان جاوا در آینده. کد شیک

اصلی با DOU