JavaRush /وبلاگ جاوا /Random-FA /این ترفند، یا نحوه یافتن شغل به عنوان یک توسعه دهنده جاوا...
Юрий
مرحله
Москва

این ترفند، یا نحوه یافتن شغل به عنوان یک توسعه دهنده جاوای متوسط بدون تجربه در جاوا

در گروه منتشر شد
با سلام خدمت تمامی دانشجویان و متخصصین جاوا. شاید داستان من نمونه ای باشد برای برخی از نحوه انجام آن، و برای برخی دیگر - چگونه آن را انجام ندهید. 19 اکتبر 2021 است و امروز یک دوره آزمایشی (3 ماهه) را به عنوان توسعه دهنده میانی جاوا در یک شرکت بزرگ به پایان رساندم. من هیچ تجربه قبلی در توسعه جاوا نداشتم. تا 4 ژوئن 2020، من چیزی در مورد جاوا نمی دانستم. وقتی به عنوان جاوایست استخدام شدم، قول دادم که اگر دوره آزمایشی را پشت سر بگذارم، یک داستان موفقیت خواهم نوشت. این مقاله به دو بخش منطقی تقسیم می شود: پیشینه شغلی ( فصل 1-5، غیر مرتبط با جاوا).، اما در آن می توانید در مورد شغل خود دانش کسب کنید). جاوائی شدن (فصل 6-9 - یادگیری جاوا، مصاحبه، استخدام، اولین تجربه واقعی). <h3>فصل 1. اقتصاددان</h3>برای اینکه بفهمم با چه سطحی از دانش وارد JavaRush شده ام، باید یک یادداشت بیوگرافی درباره خودم ارائه دهم. 2013، نوامبر، 8 صبح. من در یک کافی شاپ در تاگانکا نشسته ام و دستورالعمل های SQL را تکرار می کنم. یک ساعت دیگر مصاحبه ای برای سمت اقتصاددان برجسته در بخش مالی بانک دارم. این تنها مصاحبه ای است که من به آن دعوت شدم و باید 100 درصد آن را انجام دهم. به خاطر او از سن پترزبورگ پرواز کردم و نزد اقوام در آشپزخانه ماندم تا پس انداز کوچک خود را خرج نکنم. 30 دقیقه می گذرد، پنکیک با ژامبون و پنیر خورده می شود و باید به سمت رویای عزیزمان حرکت کنیم. اما همه چیز می لرزد. اگر در مصاحبه شکست بخورم چه؟ باشه، نبود. به بانک می روم، کارت دریافت می کنم و منتظر مصاحبه شوندگانم در اتاق جلسه هستم. زمان برای مدت بسیار طولانی می گذرد. یک مرد حدوداً 35 ساله و یک زن هم سن وارد می شوند. آنها خود را معرفی می کنند و می خواهند در مورد خودشان به شما بگویند: "یوری، خوشحال کننده است." من 21 ساله هستم، در دانشگاهی در سن پترزبورگ به صورت پاره وقت تحصیل می کنم، 3 ماه به عنوان عابر بانک کار کردم. متوجه شدم که این چیزی نیست که من برای آن درس خوانده ام، شروع به نگاه کردن به بازار کار کردم و دیدم که در مسکو اقتصاددانان SQL را به عنوان یک نیاز دارند. بنابراین من آن را مطالعه کردم، به دوره‌های آموزشی رفتم (MS SQL Administration - این چیزی بود که داشتم، این همان چیزی است که برای آن رفتم)، و شما با من تماس گرفتید. آنها در مورد شرکت، کاری که انجام می دهند صحبت می کنند (بیشتر کلمات نامفهوم هستند)، و سپس از شما می خواهند که یک تست بدهید. این آزمون دارای 3 سوال در مورد SQL است: 1. با دادن یک جدول، تمام رکوردها را با id = 10 بیرون بیاورید. 3. دپارتمان ها را گروه بندی کنید و تعداد کارمندان را برای هر بخش بدهید. بسیار شرم آور است که این درخواست ها را می نویسم. این با بحث در مورد انتظارات من از شغل دنبال می شود. و آنها این جمله جادویی را به من می گویند: "از شما برای مصاحبه متشکرم، ما با شما تماس خواهیم گرفت." یک هفته می گذرد و به من پیشنهاد می کنند که با آنها سرکار بیایم. سرخوشی، شوک، شادی! و برای چه پولی: 70 هزار روبل در دست! بله، من ثروتمند خواهم شد! من به مسکو می آیم، مستقر می شوم، یک اتاق در مرکز اجاره می کنم. روزهای اول سرخوشی است. پس از 10 روز، درک شروع می شود: کجا آمده ام؟ من اصلا هیچی نمیفهمم! باید هر ماه برای کل بانک گزارش مدیریت تهیه می کردم. طبیعتاً برای من مثل شما خواننده عزیز بود. من اصطلاحات اعتبار بین بانکی، سوآپ، تخصیص هزینه، هزینه ها و غیره را به عنوان طلسم در لاتین درک کردم. در طول راه، من باید به جنبه فنی موضوع تسلط داشتم: MS Access (همه گزارش‌ها در آنجا از طریق VBA انجام می‌شد)، MS SQL (به‌عنوان یک ذخیره‌سازی جدید، به جای Access)، اوراکل (که در ابتدا اوراکل نامیدم، و باعث هیستریک شد. در بین برنامه نویسان). و ناگهان متوجه شدم که جنبه فنی برای من بسیار جالب تر است. تلاش هایی برای ایجاد پرس و جوهای پیچیده وجود دارد (در نتیجه، پایگاه داده از اسکریپت های من آویزان می شود، و مدیران خشمگین سعی می کنند بفهمند چه کسی این کار را انجام داده است). اما کار اصلی مالی است، که تازه شروع به عصبانی کردن من کرد بعد از یک ماه و نیم، من در حال نوشتن نامه استعفا هستم، زیرا نمی توانم نتیجه ای بدهم (و راستش را بخواهید واقعاً از من انتظاری نداشتند). رئیس اداره مالی آن را پاره می‌کند و می‌گوید: «خودت را خسته نکن». یک ماه بعد، من دوباره بیانیه ای می نویسم و ​​رئیس بخش که از چنین گستاخی شوکه شده بود (که بعداً رئیس هیئت مدیره بانک شد) با گیجی شدید امضا می کند: آن مرد 21 ساله است، بدون بالاتر. آموزش و پرورش، هم حقوق و هم امانت می دادند، اما او این گونه رفتار می کند. دلایل اخراج دو عامل دیگر بود: رئیسی که نمی توانستم با گستاخی اش واکنش آرامی نشان دهم و صندلی ناراحت کننده ای که کمرم از آن درد می گرفت. این فوق العاده خنده دار است، اما این انگیزه است. وقتی ترک کردم، فکر می‌کردم که حالا راحت‌تر هم می‌شوم. اما آنجا نبود. <h3>فصل 2. 70 مصاحبه</h3>با خروج از بانک، نفس عمیقی کشیدم. "من آن را به این ترتیب ترتیب خواهم داد، همه مات و مبهوت خواهند شد." مصاحبه ها تعیین شده بود، حقوق آنها بیشتر بود و به نظر می رسید نیازی به گزارشگری نباشد. 4 مصاحبه هست و هیچکس مرا استخدام نمی کند. 5، 6 مصاحبه - همان چیز. من با دختری در یک اتاق اجاره ای زندگی می کردم و او شغلی پیدا کرد و می توانست کمبود درآمد من را پوشش دهد. اما هنوز نمی‌دانستم تا کی درآمدی ندارم. من به مصاحبه رفتم (کارهای خالی یک تحلیلگر)، و آنها عمدتاً در مورد SQL و VBA سؤال کردند. برای کسانی که آگاه نیستند، VBA یک زبان برنامه نویسی در Excel، Access و سایر محصولات MS Office است. 10 مصاحبه برگزار می شود - هیچ چیز. 20، 30 - هیچی. همه از نداشتن تجربه و تحصیلات عالی خجالت می کشند (که به نظر من یک چیز کوچک است). 40 مصاحبه، و ناامیدی شروع به خزش می کند. در طول دوره 55-60 مصاحبه شروع به مطالعه 1C می کنم. دختری که قبلاً همسر شده است ، می خواهد به سن پترزبورگ برود ، زیرا حداقل خانه خود را در آنجا دارد. و در هفتادمین مصاحبه، به مبلغ 50000 روبل در یک شرکت کوچک در منطقه صنعتی سنت پترزبورگ به عنوان مدیر پایگاه داده 1C (با امید به تبدیل شدن به یک توسعه دهنده 1C) دعوت شدم. حالا این رشد شغلی است! <h3>فصل 3. بازگشت افسانه</h3>از پنجره یک مینی بوس (حمل و نقل شرکتی) در منطقه صنعتی خاکستری سن پترزبورگ به بیرون نگاه کردم و یک ساعت و چهل و یک طرفه سفر کردم، متوجه شدم که نمی توانم اینطور زندگی کن علاقه به 1C با اولین لمس سیستم خودنویس ناپدید شد. برنامه ای لازم بود. و او بالغ شد: عصرها SQL را مطالعه می کرد و در همان زمان سایت کار شناخته شده را زیر نظر داشت. محرک نهایی برای اخراج این وضعیت بود: مدیر کل نمی خواست به من اجازه دهد به یک تعطیلات برنامه ریزی شده بروم ، اگرچه بلیط ها قبلاً خریداری شده بود. پس از تعطیلات، یک درخواست می نویسم و ​​دوباره رزومه خود را برای مشاغل خالی مسکو ارسال می کنم. یک بار دیگر به من پیشنهاد مصاحبه در یک بانک بزرگ در زمان مسکو می شود. دوباره به آشپزخانه اقوامم می آیم و برای مصاحبه می روم. وقتی hr آدرس را نوشت، نمی‌توانستم چشمانم را باور کنم - این ساختمانی بود که آرزوی کار کردن در آن را داشتم (در زمان آخرین اقامت من در مسکو، این ساختمان تازه در حال ساخت بود). این سمت، متخصص ارشد پشتیبانی سیستم های اطلاعاتی نامیده شد. به دفتر می روم مردی حدوداً 30 ساله با یک کت و شلوار جین شیک از من استقبال کرد. به طبقه پانزدهم رفتیم و وقتی چشم‌انداز شهر را دیدم، نفسم بند آمد: تمام ساختمان‌های بلند استالینی نمایان بودند. کل سبک ساختمان بسیار مدرن بود: در دفتر رئیس یخچال های شراب، آکواریوم های شیک، نقاشی یک زن برهنه به سبک سیاه و سفید وجود داشت. این باعث یک اثر "وای" شد. مکالمه با رئیس طبق معمول اتفاق نیفتاد: حدود 40 دقیقه او در مورد آنچه در بانک اتفاق می افتاد صحبت کرد. من چیزی نفهمیدم اما سرم را تکان دادم. وقتی پرسیدم: از کی شروع به پرسیدن از من می کنی؟ حواسش نبود یک بار دیگر، به سوال من "مصاحبه فنی کی است؟"، پاسخ این بود که "بله، ما شما را به هر حال استخدام می کنیم، اگر از عهده آن بر نیاید، شما را اخراج می کنیم." با لبخند گفته شد و فهمیدم همه چیز، رویا دوباره محقق شده است! <h3>فصل 4. پیدا کردن خود در فناوری اطلاعات </h3> وقتی به مکان جدید رسیدم، فهمیدم که چرا آنها فوراً مرا استخدام کردند. من یک پرتره معمولی از یک کارمند بخش را توصیف خواهم کرد: میانگین سنی 55 ساله، مسکووی، تحصیلات دانشگاه دولتی مسکو، کار در یک موسسه تحقیقات دفاعی در زمان شوروی، و انتقال به بخش بانکی در دهه 90، برای 20 سال در اینجا کار کرده است. سال ها نیمی مرد و نیمی زن هستند. آنها وارد ناهماهنگی کامل با فضای داخلی اطراف شدند. ما درگیر حفظ برنامه های گزارش دهی برای حسابداری بودیم. به طور طبیعی، همه اینها در اسکریپت های VBA و SQL باستانی بود که توسط توسعه دهندگان در اواخر دهه 90 و اوایل دهه 2000 نوشته شده بودند. سال 2015 بود و اتوماسیون از طریق MS Access بود. یعنی به شدت ضعیف به نظر می رسید. اما یک تفاوت ظریف وجود داشت - آنها آنچه را که مشتری (حسابداری) می خواست ارائه کردند. و دقیقا به موقع و به شکل مورد نیاز. فقط آنها می دانستند که چگونه کار می کند، و حتی اونوتول هم نمی توانست پیچیدگی پیشرفت آنها را تصور کند. و هر مدیر فناوری اطلاعات، حتی با بیشترین تمایل، نمی توانست آنها را اخراج کند - حسابدار ارشد به هیئت مدیره بانک رفت و از هر کارمندی که در خدمت منافع بخش حسابداری بود دفاع کرد. مدیر از من می خواست که نقش یک اسب تروا را بازی کنم: همه پیشرفت های آنها را مطالعه کردم و سپس داده ها را به سیستم جدید منتقل کردم. سپس می توان کارمندان قدیمی را اخراج کرد و من را به سیستم جدید منتقل کرد. ابتدا به فرآیندهای آنها پرداختم و به کد VBA نگاه کردم. به تدریج خواندن کد VBA را یاد گرفتم. یک سال بعد من قبلاً می دانستم چگونه خود کد را بنویسم. کار معمولی: با دادن یک پایگاه داده، داده ها را از آن استخراج کرده و در قالب خاصی در اکسل قرار دهید. اکنون، همانطور که زادورنوف گفت، یک نفس عمیق بکشید: تمام گزارشات بخش (و این 50 گزارش روزانه، 20 گزارش ماهانه است!) به صورت دستی اجرا می شد! کارل، می فهمی که مردم در 50 گزارش هر روز با دست خود تاریخ را به +1 تغییر می دهند! می نشینند 1-10 دقیقه منتظر نتیجه یک گزارش می شوند و دیگری راه اندازی می کنند! ضمن اینکه گزارش های روزانه باید سر ساعت مشخصی راه اندازی شوند و خدای نکرده دیر بیایید! آنها نه تنها گزارش می دهند، بلکه به صورت دستی رویه ها را در پایگاه داده بدون استفاده از متغیرها اجرا می کنند! یعنی به جای استفاده از متغیر @startDate = '2015-01-01'، همان تاریخ را در 20 مکان به صورت دستی تغییر می دهند! بعد از دیدن همه اینها، شروع به یادگیری پایتون کردم، و همراه با VBA، SQL و Task Scheduler، همه اینها را در دو سال خودکار کردم. نه تنها خودکار، بلکه بسیاری از گزارش‌ها را نیز تسریع کرد: اگر MS Access + VBA را به نفع MS SQL + TSQL رها کنید، می‌توانید به افزایش چند برابری بهره‌وری دست یابید. رکورد من تسریع در ایجاد گزارش است100یک بار! اما همکاران من از چنین اتوماسیونی به شدت ناراضی بودند، بنابراین من را دشمن مردم اعلام کردند (آنها می خواستند تا زمان بازنشستگی ساکت بنشینند). زمان گذشت و انتقال داده ها با موفقیت انجام شد. مدیر برای من خیلی ارزش قائل بود: اگر در ابتدای کارم ساعت 8 صبح سر کار می آمدم، پس از مدتی می توانستم در هر زمان تا ساعت 12:00 بیایم، افزایش مداوم حقوق و موقعیت، پرداخت برای کار در تعطیلات آخر هفته بیشتر از دو برابر مقدار، تاکسی در خانه اگر دیر سر کار بودید، ارتباطات سیار، به طور خلاصه - نخبگان! <h3>فصل 5. قفس طلایی</h3>ناگهان بعد از 3.5 سال مدیریت جدید فناوری اطلاعات میاد و میگه سیستمی که داده ها رو به اون منتقل کردم دیگه لازم نیست. اما سیستم قدیمی باقی خواهد ماند. مدیر من در حال بالا رفتن از نردبان شغلی است و از من دعوت می کند که به بخش پیشرفته تر منتقل شوم. در جلسه ای با رئیس بخش مترقی، متوجه شدم که پشته فناوری این بخش برای من ناشناخته است: اوراکل، دات نت، سی شارپ، لینوکس و غیره + ضدیت نسبت به رئیس بالقوه. به مدیرم می گویم که به بخش مترقی علاقه ای ندارم و او به راحتی مرا فراموش می کند. و سپس این سوال مطرح می شود: بعد چه باید کرد؟ درآمد از قبل مناسب بود، جونیور توسعه من را برای آن حقوق استخدام نمی کرد. بعد از فکر کردن به مهارت هایم، متوجه شدم که باید به سمت یادگیری ماشین بروم. همه چیز جالب بود تا اولین برخورد با آمار ریاضی که فقط باعث انزجار موسسه شد. همین، شش ماه بی حوصلگی! زمان گذشت و یک روز در حین پیاده روی به وب سایتی فکر کردم که رستوران های خوبی را روی نقشه مسکو نمایش می دهد. شروع به یادگیری HTML، CSS، JS کرد. من 3 ماه را صرف مطالعه کردم؛ دانش ایجاد یک وب سایت کامل را نداشتم، اما می توانستم آن را در محل کار تمرین کنم. ایده ای متولد شد: ایجاد یک پورتال برای حسابداران به طوری که آنها بتوانند هر گزارشی را برای خود با استفاده از یک دکمه دانلود کنند. 2 ماه طول کشید تا پورتال ایجاد شود و برنامه وب SPA (برنامه کاربردی تک صفحه ای) در React js با باطن Node.js متولد شد. Back اسکریپت های SQL را اجرا کرد (من در مورد چارچوب هایی مانند Hibernate اطلاعی نداشتم)، Python را راه اندازی کرد و اطلاعات اضافی را در MongoDb ذخیره کرد (مثلاً در مورد کاربران سایت). از نظر خارجی، سایت بسیار مناسب به نظر می رسید (بوت استرپ 4، انیمیشن مد روز). من هنوز به این پروژه افتخار می کنم. اما وقتی کدم را به توسعه‌دهندگان وب بانک نشان دادم، متحیر شدند. نه یک کلاس از خودتان! فقط ویژگی ها، فقط هاردکور! آنها از من تمجید کردند، اما گفتند که برای تبدیل شدن به یک توسعه دهنده میدل فول استک هنوز باید زیاد مطالعه کنم. من سعی کردم به عنوان یک تحلیلگر شغلی پیدا کنم، اما هیچ پیشنهاد خاصی وجود نداشت. فکر می کنم: من آنجا نبودم، رزومه خود را از یک توسعه دهنده فول استک ارسال می کنم. تماس ها آمد، اما در طول مصاحبه ها من مانند تخته سه لا بر فراز پاریس پرواز کردم: به عنوان مثال، من نمی دانستم HashMap، HashSet چیست و چرا به آنها نیاز است. کوچکترین ایده ای در مورد OOP، الگوهای برنامه نویسی، الگوریتم ها، تست، Git وجود نداشت. احساس شرم را که مدت ها فراموش شده بود به خاطر جهل از چیزهای اساسی به یاد آوردم. ناگهان پیشنهادی برای شغلی به عنوان رئیس تجزیه و تحلیل مشتری در یک شرکت مالی ارائه می شود. یک هفته قبل از تعطیلی کشور به دلیل همه گیری. در یک شرکت مالی مشغول به کار شدم، اما یک احساس دوگانه وجود داشت: از یک طرف، حقوق بالا گرم بود، از طرف دیگر، حداقل پیشرفت در بخش فنی وجود داشت. یک هفته از نصب دستگاه و معرفی ریموت کار گذشت. از آنجایی که روزهای غیر کاری در بخش مالی صدق نمی کرد، طبق معمول کار می کردیم. معلوم شد که رئیس جدید یک فرد بسیار دیوانه است: او پیشنهاد داد فیس بوک را خراش دهد، شبکه های عصبی خود را برای مطالعه مشتریان (بدون دانشمند داده در کارکنان) ایجاد کند. به کارمندان جدید پیشنهاد شد که پایتون را در یک هفته یاد بگیرند و غیره. روزهای مرخصی بدون حقوق عادی شد. ترک کار احمقانه بود: در طول یک بیماری همه گیر کجا شغل پیدا می کنید؟ اما صبر بعد از 2 ماه که اعلام شد پاداش سه ماهه نخواهد بود لبریز شد. نکته ظریف این است که وقتی در مورد حقوق به توافق رسیدیم، در زمان استخدام، hr گفت که حقوق به دستمزد (60٪) و پاداش سه ماهه (40٪) تقسیم می شود که همیشه پرداخت می شود. مشخص شد که انتخاب اشتباهی انجام شده است و باید شروع به جستجوی شغل جدید کنیم. <h3>فصل 6. شروع به تسلط بر جاوا</h3>یک روز خوب در ماه مه دعوت نامه ای برای مصاحبه برای جای خالی "توسعه دهنده" دریافت کردم. یک شرکت در صنعت بیمه به فردی که محصولات بیمه را توسعه دهد نیاز دارد. تجربه برنامه نویسی مورد نیاز است، اما از آنجایی که این یک توسعه "بی نظیر" شرکت است، نیازی به زبان خاصی نیست. Git و غیره نیز مورد نیاز است. دو روز دیگر مصاحبه گذاشتم و در اوقات فراغت اصول Git را مطالعه کردم. در طول مصاحبه از من در مورد Python، JS، Git، SQL پرسیده شد. من به همه چیز پاسخ دادم به جز مفهوم "بارگذاری بیش از حد روش" و در عرض 2 هفته به کار دعوت شدم. معلوم شد که این شرکت مدت ها پیش سیستم را خریداری کرده بود. نوشته شده در جاوا (جلو و پشت)، که با آن می توانید بدون دانستن زبان برنامه نویسی (به طور دقیق تر، با استفاده از زبان برنامه نویسی داخلی Jelly) فرآیندهای تجاری ایجاد کنید. به نظر خوب است، اما در واقع همه چیز تحریف شده بود. انحراف غزلی: هر فناوری دوران و مقیاس خاص خود را دارد. انجام تمام گزارشات در سال 2000 فقط در اکسل جالب است. انجام همین کار در سال 2021 خیلی خوب نیست. یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید از سوی دیگر، حداقل توسعه در بخش فنی وجود خواهد داشت. یک هفته از نصب دستگاه و معرفی ریموت کار گذشت. از آنجایی که روزهای غیر کاری در بخش مالی صدق نمی کرد، طبق معمول کار می کردیم. معلوم شد که رئیس جدید یک فرد بسیار دیوانه است: او پیشنهاد داد فیس بوک را خراش دهد، شبکه های عصبی خود را برای مطالعه مشتریان (بدون دانشمند داده در کارکنان) ایجاد کند. به کارمندان جدید پیشنهاد شد که پایتون را در یک هفته یاد بگیرند و غیره. روزهای مرخصی بدون حقوق عادی شد. ترک کار احمقانه بود: در طول یک بیماری همه گیر کجا شغل پیدا می کنید؟ اما صبر بعد از 2 ماه که اعلام شد پاداش سه ماهه نخواهد بود لبریز شد. نکته ظریف این است که وقتی در مورد حقوق به توافق رسیدیم، در زمان استخدام، hr گفت که حقوق به دستمزد (60٪) و پاداش سه ماهه (40٪) تقسیم می شود که همیشه پرداخت می شود. مشخص شد که انتخاب اشتباهی انجام شده است و باید شروع به جستجوی شغل جدید کنیم. <h3>فصل 6. شروع به تسلط بر جاوا</h3>یک روز خوب در ماه مه دعوت نامه ای برای مصاحبه برای جای خالی "توسعه دهنده" دریافت کردم. یک شرکت در صنعت بیمه به فردی که محصولات بیمه را توسعه دهد نیاز دارد. تجربه برنامه نویسی مورد نیاز است، اما از آنجایی که این یک توسعه "بی نظیر" شرکت است، نیازی به زبان خاصی نیست. Git و غیره نیز مورد نیاز است. دو روز دیگر مصاحبه گذاشتم و در اوقات فراغت اصول Git را مطالعه کردم. در طول مصاحبه از من در مورد Python، JS، Git، SQL پرسیده شد. من به همه چیز پاسخ دادم به جز مفهوم "بارگذاری بیش از حد روش" و در عرض 2 هفته به کار دعوت شدم. معلوم شد که این شرکت مدت ها پیش سیستم را خریداری کرده بود. نوشته شده در جاوا (جلو و پشت)، که با آن می توانید بدون دانستن زبان برنامه نویسی (به طور دقیق تر، با استفاده از زبان برنامه نویسی داخلی Jelly) فرآیندهای تجاری ایجاد کنید. به نظر خوب است، اما در واقع همه چیز تحریف شده بود. انحراف غزلی: هر فناوری دوران و مقیاس خاص خود را دارد. انجام تمام گزارشات در سال 2000 فقط در اکسل جالب است. انجام همین کار در سال 2021 خیلی خوب نیست. یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید از سوی دیگر، حداقل توسعه در بخش فنی وجود خواهد داشت. یک هفته از نصب دستگاه و معرفی ریموت کار گذشت. از آنجایی که روزهای غیر کاری در بخش مالی صدق نمی کرد، طبق معمول کار می کردیم. معلوم شد که رئیس جدید یک فرد بسیار دیوانه است: او پیشنهاد داد فیس بوک را خراش دهد، شبکه های عصبی خود را برای مطالعه مشتریان (بدون دانشمند داده در کارکنان) ایجاد کند. به کارمندان جدید پیشنهاد شد که پایتون را در یک هفته یاد بگیرند و غیره. روزهای مرخصی بدون حقوق عادی شد. ترک کار احمقانه بود: در طول یک بیماری همه گیر کجا شغل پیدا می کنید؟ اما صبر بعد از 2 ماه که اعلام شد پاداش سه ماهه نخواهد بود لبریز شد. نکته ظریف این است که وقتی در مورد حقوق به توافق رسیدیم، در زمان استخدام، hr گفت که حقوق به دستمزد (60٪) و پاداش سه ماهه (40٪) تقسیم می شود که همیشه پرداخت می شود. مشخص شد که انتخاب اشتباهی انجام شده است و باید شروع به جستجوی شغل جدید کنیم. <h3>فصل 6. شروع به تسلط بر جاوا</h3>یک روز خوب در ماه مه دعوت نامه ای برای مصاحبه برای جای خالی "توسعه دهنده" دریافت کردم. یک شرکت در صنعت بیمه به فردی که محصولات بیمه را توسعه دهد نیاز دارد. تجربه برنامه نویسی مورد نیاز است، اما از آنجایی که این یک توسعه "بی نظیر" شرکت است، نیازی به زبان خاصی نیست. Git و غیره نیز مورد نیاز است. دو روز دیگر مصاحبه گذاشتم و در اوقات فراغت اصول Git را مطالعه کردم. در طول مصاحبه از من در مورد Python، JS، Git، SQL پرسیده شد. من به همه چیز پاسخ دادم به جز مفهوم "بارگذاری بیش از حد روش" و در عرض 2 هفته به کار دعوت شدم. معلوم شد که این شرکت مدت ها پیش سیستم را خریداری کرده بود. نوشته شده در جاوا (جلو و پشت)، که با آن می توانید بدون دانستن زبان برنامه نویسی (به طور دقیق تر، با استفاده از زبان برنامه نویسی داخلی Jelly) فرآیندهای تجاری ایجاد کنید. به نظر خوب است، اما در واقع همه چیز تحریف شده بود. انحراف غزلی: هر فناوری دوران و مقیاس خاص خود را دارد. انجام تمام گزارشات در سال 2000 فقط در اکسل جالب است. انجام همین کار در سال 2021 خیلی خوب نیست. یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید شبکه های عصبی خود را برای مطالعه مشتریان (بدون دانشمند داده در کارکنان) ایجاد کنید. به کارمندان جدید پیشنهاد شد که پایتون را در یک هفته یاد بگیرند و غیره. روزهای مرخصی بدون حقوق عادی شد. ترک کار احمقانه بود: در طول یک بیماری همه گیر کجا شغل پیدا می کنید؟ اما صبر بعد از 2 ماه که اعلام شد پاداش سه ماهه نخواهد بود لبریز شد. نکته ظریف این است که وقتی در مورد حقوق به توافق رسیدیم، در زمان استخدام، hr گفت که حقوق به دستمزد (60٪) و پاداش سه ماهه (40٪) تقسیم می شود که همیشه پرداخت می شود. مشخص شد که انتخاب اشتباهی انجام شده است و باید شروع به جستجوی شغل جدید کنیم. <h3>فصل 6. شروع به تسلط بر جاوا</h3>یک روز خوب در ماه مه دعوت نامه ای برای مصاحبه برای جای خالی "توسعه دهنده" دریافت کردم. یک شرکت در صنعت بیمه به فردی که محصولات بیمه را توسعه دهد نیاز دارد. تجربه برنامه نویسی مورد نیاز است، اما از آنجایی که این یک توسعه "بی نظیر" شرکت است، نیازی به زبان خاصی نیست. Git و غیره نیز مورد نیاز است. دو روز دیگر مصاحبه گذاشتم و در اوقات فراغت اصول Git را مطالعه کردم. در طول مصاحبه از من در مورد Python، JS، Git، SQL پرسیده شد. من به همه چیز پاسخ دادم به جز مفهوم "بارگذاری بیش از حد روش" و در عرض 2 هفته به کار دعوت شدم. معلوم شد که این شرکت مدت ها پیش سیستم را خریداری کرده بود. نوشته شده در جاوا (جلو و پشت)، که با آن می توانید بدون دانستن زبان برنامه نویسی (به طور دقیق تر، با استفاده از زبان برنامه نویسی داخلی Jelly) فرآیندهای تجاری ایجاد کنید. به نظر خوب است، اما در واقع همه چیز تحریف شده بود. انحراف غزلی: هر فناوری دوران و مقیاس خاص خود را دارد. انجام تمام گزارشات در سال 2000 فقط در اکسل جالب است. انجام همین کار در سال 2021 خیلی خوب نیست. یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید شبکه های عصبی خود را برای مطالعه مشتریان (بدون دانشمند داده در کارکنان) ایجاد کنید. به کارمندان جدید پیشنهاد شد که پایتون را در یک هفته یاد بگیرند و غیره. روزهای مرخصی بدون حقوق عادی شد. ترک کار احمقانه بود: در طول یک بیماری همه گیر کجا شغل پیدا می کنید؟ اما صبر بعد از 2 ماه که اعلام شد پاداش سه ماهه نخواهد بود لبریز شد. نکته ظریف این است که وقتی در مورد حقوق به توافق رسیدیم، در زمان استخدام، hr گفت که حقوق به دستمزد (60٪) و پاداش سه ماهه (40٪) تقسیم می شود که همیشه پرداخت می شود. مشخص شد که انتخاب اشتباهی انجام شده است و باید شروع به جستجوی شغل جدید کنیم. <h3>فصل 6. شروع به تسلط بر جاوا</h3>یک روز خوب در ماه مه دعوت نامه ای برای مصاحبه برای جای خالی "توسعه دهنده" دریافت کردم. یک شرکت در صنعت بیمه به فردی که محصولات بیمه را توسعه دهد نیاز دارد. تجربه برنامه نویسی مورد نیاز است، اما از آنجایی که این یک توسعه "بی نظیر" شرکت است، نیازی به زبان خاصی نیست. Git و غیره نیز مورد نیاز است. دو روز دیگر مصاحبه گذاشتم و در اوقات فراغت اصول Git را مطالعه کردم. در طول مصاحبه از من در مورد Python، JS، Git، SQL پرسیده شد. من به همه چیز پاسخ دادم به جز مفهوم "بارگذاری بیش از حد روش" و در عرض 2 هفته به کار دعوت شدم. معلوم شد که این شرکت مدت ها پیش سیستم را خریداری کرده بود. نوشته شده در جاوا (جلو و پشت)، که با آن می توانید بدون دانستن زبان برنامه نویسی (به طور دقیق تر، با استفاده از زبان برنامه نویسی داخلی Jelly) فرآیندهای تجاری ایجاد کنید. به نظر خوب است، اما در واقع همه چیز تحریف شده بود. انحراف غزلی: هر فناوری دوران و مقیاس خاص خود را دارد. انجام تمام گزارشات در سال 2000 فقط در اکسل جالب است. انجام همین کار در سال 2021 خیلی خوب نیست. یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید <h3>فصل 6. شروع به تسلط بر جاوا</h3>یک روز خوب در ماه مه دعوت نامه ای برای مصاحبه برای جای خالی "توسعه دهنده" دریافت کردم. یک شرکت در صنعت بیمه به فردی که محصولات بیمه را توسعه دهد نیاز دارد. تجربه برنامه نویسی مورد نیاز است، اما از آنجایی که این یک توسعه "بی نظیر" شرکت است، نیازی به زبان خاصی نیست. Git و غیره نیز مورد نیاز است. دو روز دیگر مصاحبه گذاشتم و در اوقات فراغت اصول Git را مطالعه کردم. در طول مصاحبه از من در مورد Python، JS، Git، SQL پرسیده شد. من به همه چیز پاسخ دادم به جز مفهوم "بارگذاری بیش از حد روش" و در عرض 2 هفته به کار دعوت شدم. معلوم شد که این شرکت مدت ها پیش سیستم را خریداری کرده بود. نوشته شده در جاوا (جلو و پشت)، که با آن می توانید بدون دانستن زبان برنامه نویسی (به طور دقیق تر، با استفاده از زبان برنامه نویسی داخلی Jelly) فرآیندهای تجاری ایجاد کنید. به نظر خوب است، اما در واقع همه چیز تحریف شده بود. انحراف غزلی: هر فناوری دوران و مقیاس خاص خود را دارد. انجام تمام گزارشات در سال 2000 فقط در اکسل جالب است. انجام همین کار در سال 2021 خیلی خوب نیست. یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید <h3>فصل 6. شروع به تسلط بر جاوا</h3>یک روز خوب در ماه مه دعوت نامه ای برای مصاحبه برای جای خالی "توسعه دهنده" دریافت کردم. یک شرکت در صنعت بیمه به فردی که محصولات بیمه را توسعه دهد نیاز دارد. تجربه برنامه نویسی مورد نیاز است، اما از آنجایی که این یک توسعه "بی نظیر" شرکت است، نیازی به زبان خاصی نیست. Git و غیره نیز مورد نیاز است. دو روز دیگر مصاحبه گذاشتم و در اوقات فراغت اصول Git را مطالعه کردم. در طول مصاحبه از من در مورد Python، JS، Git، SQL پرسیده شد. من به همه چیز پاسخ دادم به جز مفهوم "بارگذاری بیش از حد روش" و در عرض 2 هفته به کار دعوت شدم. معلوم شد که این شرکت مدت ها پیش سیستم را خریداری کرده بود. نوشته شده در جاوا (جلو و پشت)، که با آن می توانید بدون دانستن زبان برنامه نویسی (به طور دقیق تر، با استفاده از زبان برنامه نویسی داخلی Jelly) فرآیندهای تجاری ایجاد کنید. به نظر خوب است، اما در واقع همه چیز تحریف شده بود. انحراف غزلی: هر فناوری دوران و مقیاس خاص خود را دارد. انجام تمام گزارشات در سال 2000 فقط در اکسل جالب است. انجام همین کار در سال 2021 خیلی خوب نیست. یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنید یک وب سایت شرکتی با HTML خالص در سال 1999 جالب بود، اما نه در سال 2021. بنابراین، فناوری که این شرکت در زمان ایجاد خود (2005) استفاده کرد بسیار جالب بود - جاوا هم مسئول بخش سرور و هم بخش مشتری (به اصطلاح صفحات سرولت جاوا) بود. علاوه بر این، اگر یک فرآیند تجاری جدید ایجاد کنید (که رابط کاربری خاص خود را دارد)، در داخل پایگاه داده ذخیره می شود، نه در کد موجود در یک فایل. برای درک اینکه چقدر این کار ناخوشایند است، تصور کنید که کد جاوا را در Intellij idea می‌نویسید، آن را در پایگاه داده ذخیره می‌کنید و سپس. وقتی می خواهید کد خود را اجرا کنید، هسته برنامه به پایگاه داده می رود و کد شما را از آنجا می خواند. بر این اساس، شما نمی توانید به طور کامل برنامه خود را اشکال زدایی کنید. نکته 1: وقتی می خواهید کدی را به testbench ارسال کنید، باید ایجاد کنیدSQL скрипт، که حاوی کد شما خواهد بود. ناخوشایند، اما قابل تحمل؟ Zest #2: پایگاه داده شامل بیش از 200 جدول است که با یکدیگر ارتباط دارند. این بدان معنی است که شما باید بدانید کد خود را در کدام جداول قرار دهید و کدام موجودیت ها باید در جداول دیگر ایجاد شوند. خروجی یک اسکریپت SQL با طول ~ 1000 خط است. این واقعا منزجر کننده است. مراقب میراث باشید خلاصه که متوجه شدم همه چیز در جاوا است، به JavaRush رفتم (بالاخره به موضوع سایت رسیدیم!). ژوئن-ژوئیه 2020. 10 سطح اول به سرعت (شاید یک ماه) بسته شد، زیرا اساساً هیچ چیز جدیدی وجود نداشت. سپس سرعت کاهش یافت. جولای-اکتبر 2020. سطوح 10-20 بسته شد. اکتبر-مارس 2021. سطوح 20-30 بسته شد. اکنون سرگرمی شروع می شود: در مارس 2021، من شروع به بررسی جاهای خالی جاوا کردم و متوجه شدم که کلمات ناآشنا زیادی در آنجا وجود دارد. نوعی Spring، SpringBoot، Hibernate، JUnit. با خرید دوره های ویدیویی در یک وب سایت معروف، بهار را لمس کردم و فکر کردم که اکنون همه چیز را می دانم و می توانم انجام دهم. بعد از آن با دوره TopJava توسط Grigory Kislin آشنا شدم. در وب سایت او می توانید سعی کنید یک کار آزمایشی را انجام دهید و اگر موفق شدید، می توانید دوره را بگذرانید. در این دوره شما یک وب اپلیکیشن کامل ایجاد می کنید و حتی آن را در اینترنت منتشر می کنید. با این پول به شما یک بررسی (بررسی کد توسط یک برنامه نویس با تجربه تر) می دهند، بازخورد می دهند و در صورت بروز مشکل به شما راهنمایی می کنند. به تکلیف 3 رسیدم و ترک کردم. دلیل ساده است: آنها چیزهای زیادی از شما می خواهند، اما هیچ دانشی به شما نمی دهند. الزامات تکالیف بسیار گیج کننده است. اطلاعات به شدت متناقض ارائه شده است. به نظر ذهنی من، این دوره توسط توسعه دهندگان نسبتاً با تجربه که از زبان های مشابه دیگر آمده اند مورد نیاز است. زیرا در دوره او عملاً هیچ توضیحی در مورد فناوری هایی که او می خواهد از آنها استفاده کند وجود ندارد. همچنین باید Git را به خوبی بشناسید (همه چیز به مخزن شخصی شما ارسال می شود). در پایان آوریل 2021، من یک رزومه برای یک توسعه دهنده جاوا (با حقوق مورد نظر در سطح + متوسط) ارسال می کنم که در آن نشان می دهم که در آخرین شغلم در جاوا برنامه نویسی کردم (دروغ گفتم). در همان روز، بانک درخواستی برای موقعیت توسعه دهنده جاوا دریافت می کند. <h3>فصل 7. مصاحبه های جاوا و تقویت مهارت</h3>بنابراین، برنامه چه بود؟ من باید حقوق خوبی بگیرم، زیرا قبلاً به زندگی با درآمد قابل توجه + وام عادت کرده ام. بنابراین، پست های جوان برای من مناسب نیست. شما باید یک شغل وسط پیدا کنید. اما چه کسی من را بدون تجربه استخدام می کند؟ این تصمیم طبیعی بود: سوابق استخدامی من می گوید که یک سال به عنوان توسعه دهنده و 4 سال دیگر به عنوان کارشناس در بخش فناوری اطلاعات در سمت قبلی ام کار کردم. بنابراین، من می گویم که من یک سال است که در جاوا توسعه می دهم. و اگر در مورد محصولات جدید بپرسند، می گویم که جاوای قدیمی (7) آنجا بود و چیزی را پشتیبانی نمی کرد. قبل از اولین مصاحبه (از راه دور) من عصبی بودم. من تجربه ندارم، دانش بسیار کمی دارم و پول زیادی می خواهم. من فکر می کنم: اهمیت نده، تجربه منفی نیز تجربه است. من از طریق اسکایپ تماس می‌گیرم و دو رئیس بخش با من مصاحبه خواهند کرد. که بیشتر غمگینم کرد سوالات شروع شد: OOP، دستگاه HashMap، جریان ها، ساختارهای داده، Spring، Hibernate، AOP چیست. و اگر قبل از اسپینگ کم و بیش قابل تحمل بود، در بهار کاملاً از بین رفت. مردم از من می پرسند: اگر واقعاً آن را نمی دانی، چگونه در بهار پیشرفت کردی؟ من: من آن را کپی کردم، پیست کردم، کار می کند و از این بابت ممنون. این پاسخ آنها را سرگرم کرد. سپس آنها در مورد SQL پرسیدند که در آن من مانند اردک به آب بودم. بعد Git بود و یک سوال در مورد rebase، cherry-pick (که من هم نمی دانستم) و در مورد JS تمام شد، زیرا در رزومه من ذکر شده بود. در آنجا نیز یک شکست کامل رخ داد، زیرا آنها در مورد OOP JS سؤال کردند. بر اساس نتایج مصاحبه، مشخص شد که دانش من comme il faut نیست، و بنابراین من واجد شرایط این شغل نیستم. عصر اچ آر می نویسد کاندیداتوری من تایید شده و حاضرند با من تماس بگیرند. من در واقع در مک دونالد در یک همبرگر خفه شدم. من خوشحال بودم، اما بعد از 3 روز HR گزارش داد که آنها نامزد دیگری را انتخاب کرده اند. برای اولین بار در تجربه من، یک پیشنهاد پس گرفته شد. پس از اولین مصاحبه در جاوا، بازی خود را افزایش دادم: دوره ای را در Git از Colt Steele در یک سایت معروف برای فروش دوره های ویدیویی گذراندم (و کاملاً آن را کامل کردم!). این تصور من را از Git تغییر داد. بعد، من یک دوره (درخشان) از زائور ترگلوف در مورد Spring+Hibernate گذراندم. طرح آموزشی: من آن را مانند ویدیو تماشا می‌کنم، همین کار را در رایانه‌ام انجام می‌دهم، اما متغیرها و کلاس‌ها را متفاوت نام‌گذاری می‌کنم تا احمقانه کد شخص دیگری را کپی نکنم. من تمام کارهایم را در Github خود آپلود می کنم (از این طریق Git را تمرین می کنم). اواسط ماه مه بود و تماس ها از ساعت شروع شد. شروع کردیم به برنامه ریزی مصاحبه ها یکی یکی. بسیاری از دعوت‌نامه‌ها به دلایل زیر لغو می‌شدند: HR توضیحات رزومه من را نخواند و من را به یک موقعیت ارشد دعوت کرد. همچنین شایان ذکر است که یک گروه منابع انسانی جداگانه ذکر شود: کسانی که جاوا را با جاوا اسکریپت اشتباه می گیرند. به همین دلیل است که در عنوان رزومه خود توسعه دهنده جاوای میانی نوشتم. <h3>فصل 8. فهرست سوالات معمولی و نحوه انجام مصاحبه</h3>من شروع به مصاحبه کردم و به تدریج مجموعه ای از سوالات اساسی را در وسط تشکیل دادم. مورد نیاز: 0. OOP - تعریف، در مورد هر اصل OOP صحبت کنید (+ یک مثال از زندگی واقعی بیاورید). 1. برابر و هش کد - قرارداد (رابطه) بین آنها چیست؟ 2. HashMap - چگونه بفهمیم یک شی به کدام سطل می رود، برخورد چیست، داده ها در چه ساختار داده ای در HashMap ذخیره می شوند، اندازه استاندارد، چگونه تعداد سطل ها افزایش می یابد. 3. جریان - چه نوع عملیات، چه تفاوتی بین آنها وجود دارد، مثالی از هر نوع عملیات ارائه دهید. 4. استخر رشته، استخر عدد صحیح - چیست؟ 5. پشته، پشته - چیست، تفاوت چیست؟ 6. تفاوت بین Runnable، Thread، Future. 7. فرار، اتمی. 8. جامد، بوسه، خشک - تعاریف، نمونه هایی از زندگی واقعی. 9. دسترسی به اصلاح کننده ها در جاوا. 10. تفاوت بین یک کلاس انتزاعی و یک رابط چیست؟ آیا رابط کاربری می تواند خصوصی باشد؟ 11. رابط های کاربردی. 12. تمام متدهای Object را فهرست کنید و بگویید چرا به آنها نیاز است. ویژگی های روش کلون 13. سریال سازی و سریال زدایی چیست. 14. گرفتن با منابع را امتحان کنید - توصیف کنید که چیست، با استفاده از رابط Closeable به آن بگویید. 15. تفاوت بین نهایی، در نهایت، نهایی؟ 16. اضافه بار، غلبه بر روش تفاوت است. 17. چرا String تغییرناپذیر شد، در مورد StringBuilder و StringBuffer به ما بگویید. 18. پیچیدگی زمانی O(1)، پیچیدگی حافظه چیست. 19. ساختارهای داده: صحبت در مورد نقشه، مجموعه، صف، deque، لیست و اجرای آنها در جاوا (treeMap، hashSet، hashMap، arrayList، linkedList، priorityQueue، blockingQueue)، توصیف پیچیدگی (بدترین، متوسط، بهترین) درج، جستجو، حذف یک عنصر در هر ساختار. 20. انواع داده های اولیه در جاوا. چرا هر یک از آنها مورد نیاز است؟ 21. انواع خطاها. موارد استثناء علامت خورده و بدون علامت. 22. JVM, JRE, JDK چیست؟ 23. با چه مجموعه دارانی کار کردید؟ Maven - ساخت چرخه زندگی. 24. Spring - Ioc Definitions، Di، Bean Lifecycle، Context، @Bean Annotations، @Configuration، @Autowired، @Advice، @Aspect، @Service، @Repository. 25. ژنریک - تعریف حد پایین و بالایی چیست؟ 26. الگوهای برنامه نویسی - حداقل Singleton (تمایل به گفتن اینکه چرا گاهی اوقات این یک ضد الگو است) + سازنده، آداپتور، کارخانه، دکوراتور، Proxt. مطلوب: 26. تست - انواع تست ها که کتابخانه ها (JUnit) با آنها کار شده است. Mock, Stab, Spy چیست؟ 27. بوت بهار - چرا به آن نیاز است، آمادگی برای ساخت اپلیکیشن SpringBoot به صورت آنلاین. 28. Hibernate - چرا مورد نیاز است، Entity، ستون پیوستن، بارگذاری تنبل در مقابل مشتاق، سطوح کش (سخت). 29. استراحت بهار - چرا به آن نیاز است، چگونه @post، @get endpoints ایجاد کنیم. چگونه پارامترها/ بدنه درخواست را بخوانیم؟ چگونه با فرمت json ارسال کنیم؟ 30. ساختارهای داده - درختان، انواع آنها. 31. الگوریتم ها - انواع مرتب سازی. علاوه بر جاوا، ممکن است بپرسند: 1. (الزامی!) Git - چرا به آن نیاز است، عملیات ادغام، تغییر پایه، cherry-pick، push، pull، commit، log، پرداخت، شاخه، بازنشانی، برگرداندن، تازه کردن. 2.SQL - توانایی نوشتن یک پرس و جو: پیوستن دو جدول به یک (پیوستن داخلی، پیوستن به سمت چپ). 3. پایگاه‌های داده - 3 فرم معمولی، فهرست (چرا به آنها نیاز است، انواع)، کلید اصلی، کلید خارجی چگونه یک مصاحبه از راه دور معمولی انجام می‌شود: hr پیوندی را برای بزرگ‌نمایی ارسال می‌کند (Skype، Google Meeting). در یک زمان مشخص شما وصل می شوید و از 1 تا 3 نفر در آنجا هستند (کارشناس فنی، رئیس، ساعت). در موارد خاص سرسخت تا 8 نفر. اول از خودت میگی، بعد قسمت فنی، بعد یه داستان در مورد جای خالی و خداحافظی (میگن کی باهات تماس میگیرن یا مراحل بعدی چیه). در حین خداحافظی، می توانید در مورد دانش بازخورد بخواهید. پرسیدم: می‌توانی در حین پاسخ‌های من به من بگوئید کجای گوش‌هایت درد می‌کند؟ بسیاری از مردم پاسخ می دهند، اما آماده رد شدن باشید. در طول مصاحبه آنها ارزیابی می کنند: 1. توانایی شما در بیان افکار و دانش زبان روسی (من موردی را می شناسم که یک نامزد به دلیل دانش ضعیف زبان روسی رد شده است). 2. تجربه قبلی (ممکن است با دقت بپرسند که در آخرین کار خود چه کرده اید). 3. واکنش کافی در زمانی که به شما فشار وارد می شود (یک مصاحبه بود که مردم شروع به بی احترامی کردند: نادیده گرفتن پاسخ های من، تلاش برای القای مواضع خود و غیره. من 15 دقیقه بعد از شروع مصاحبه را تمام کردم و آنها: مصاحبه پر استرسی بود!) 4. سطح دانش شما. من در اینجا به جزئیات بیشتری خواهم پرداخت. دانستن تعاریف یک موضوع تنها 10 درصد از آن چیزی است که از شما انتظار می رود. درک نحوه عملکرد آن (حداقل در سطح بالا) ضروری است. تمایل به توضیح در چه مرحله ای از توسعه شما این یا آن راه حل را انتخاب می کنید. این خیلی مهمتر از دقت تعریف شماست. این پایان نامه را با استفاده از دو مثال تحلیل خواهم کرد. مثال اول: در طی یک مصاحبه از من در مورد HashMap پرسیده شد، و من این تعریف را ارائه کردم: "این یک ساختار داده است که بسته های کلیدی و ارزشی را ذخیره می کند." سپس مصاحبه کننده پرسید: تفاوت با TreeMap چیست؟ پاسخ: تفاوت این است که هش مپ کلید را هش می کند و به دلیل هش شدن، دسترسی سریع است. مصاحبه کننده بلافاصله خواست که ساختار داخلی HashMap را به ما بگوید، و در همان زمان در مورد هش کد و معادل ها پرسید. و تا زمانی که از پاسخ قانع شوید یا متوقف شوید عمیق تر خواهد شد. من فقط پس از 2 ماه مصاحبه و یک دوره در مورد ساختارهای داده در hexlet یاد گرفتم که در مورد HashMap به درستی پاسخ دهم. مثال دوم: مفهوم SOLID. از من می خواهند که تعریفی را که حفظ کرده ام ارائه دهم. اما به محض اینکه به نمونه های زندگی واقعی رسید، مشکلات شروع شد. Внимание!اگر نمی دانید، پس آن را اختراع نکنید، اما این را بگویید: من این موضوع را نمی دانم، اما می توانم فرض کنم که اینطور کار می کند. بسیاری از کارشناسان فنی وقتی کسی بدعت می گوید که انگار موضوع را می فهمد، خشمگین می شوند. 5. میزان اشتیاق شما در طول بحث شغلی. از شما انتظار می رود که علاقه مند باشید و در مورد جای خالی سوال بپرسید (نه فقط آنهایی که ساخته شده اند). 6. گاهی اوقات طنز (فقط در مورد موضوع) و علایق مشترک به شما در برقراری ارتباط کمک می کند. با خیال راحت در مورد سرگرمی های خود صحبت کنید؛ شاید مصاحبه شونده نیز عاشق دوتا/فوتبال/فانتزی باشد. و این یک امتیاز مثبت برای شما به عنوان یک نامزد است. من مواردی را می شناسم که جامعه ای از علاقه مندی ها چشم خود را به روی آموزش فنی ضعیف مصاحبه گر بسته است (تو یک پسر معمولی هستی، ما به تو آموزش خواهیم داد). <h3>فصل 9. یافتن شغل، غسل تعمید آتش</h3>مصاحبه ها از اواخر آوریل تا اواسط ژوئیه انجام شد. اولین مصاحبه ها شرم آور بود، اما به تدریج وضعیت تا حد قابل قبولی بهبود یافت. مطالعه سوالات متداول و بازخورد خود را احساس می کرد. 25 مصاحبه اول ناموفق بود. پس از این، لحظات ناامیدی آغاز شد. احساسات: اگر مرا برای آن حقوق استخدام نکنند، چه؟ ناگهان همه چیز شروع به تیراندازی کرد: در عرض یک هفته، سه شرکت پیشنهادات خود را ارائه کردند. من شرکتی را انتخاب کردم که مشخصات آن را می دانستم، به علاوه حقوق خوب و فرصت کار از راه دور وجود داشت. در طول مصاحبه من حدود 30 سوال در مورد Java core و Spring از من پرسیده شد که 97٪ آنها را درست پاسخ دادم. بعد از آن با مقامات بالاتر ارتباط برقرار شد و بعد از 1.5 هفته با آنها کار کردم. اول از همه، وقتی به هر کاری می‌رسید، شروع به دسترسی به تمام سیستم‌های لازم و نصب ابزارهای مورد نیاز خود می‌کنید. یک هفته و نیم طول کشید و اولین وظیفه به من داده شد: تغییر متن ثابت در کلاس. وقتی پروژه را باز کردم، احساس بیماری کردم: ماژول های زیادی در یک پروژه وجود داشت، کلاس های زیادی، تست ها و غیره. در این مرحله من گم شدم، اما توسعه دهنده دوم به من کمک کرد و مرا به سرعت رساند. این اشکال در 10 دقیقه برطرف شد، در Git منتشر شد، یک درخواست کشش (یک درخواست برای ادغام دو شعبه که سایر توسعه دهندگان کد شما را بررسی می کنند) انجام شد و سپس در شاخه اصلی ادغام شد. معلوم شد که همه چیز چندان دشوار نیست. تا اولین کار تمام عیار ... در زمان برنامه ریزی وظایف برای دو هفته آینده به من گفتند: شما با یک سیستم دیگر که در OpenShift قرار دارد یکپارچه سازی می کنید. اینجاست که همه چیز واقعاً ترسناک شد: OpenShift مجموعه کاملی از فناوری‌ها است: Docker، Kubernetes، Linux، و غیره. عرق سرد از پشتم جاری شد: خوب، من به عنوان جاویست کار می کردم. بلافاصله پس از جلسه، با توسعه دهنده تماس گرفتم که به من اطمینان داد: آداپتورهای این سیستم نوشته شده بود و کافی بود کلاس های خاصی را به پروژه من وارد کنم و پس از آن می توانستم با خیال راحت از ادغام استفاده کنم. دوباره سرگرم‌کننده شد، تا زمانی که توسعه‌دهنده یک ادغام معمولی را نشان داد: من بیش از 20 کلاس را دیدم که برای ادغام مشابه ایجاد شده‌اند. علاوه بر این، حاشیه نویسی های دیده نشده قبلی @Value، @Builder، @NoArgsConstructor، @Getter مورد توجه قرار گرفتند. @Sl4f - معلوم شد که پروژه Lombook است (در اینترنت بخوانید). وقتی توسعه دهنده به من توضیح داد که چگونه این کار را انجام دهم، سعی کردم اتصالات همه کلاس ها را بنویسم و ​​هیچ چیز در ذهنم گیر نکرد. شرم آورترین لحظه عدم آگاهی از Intellij Idea بود: نحوه جستجوی جهانی برای یک پروژه، بازآفرینی کد و غیره. پس از انجام این کار، متوجه شدم که چرا OOP مورد نیاز است: برای چنین مقدار زیادی کد، لازم است آن را به کلاس ها تقسیم کنیم. متدهایی که خارج از کلاس استفاده نمی شوند باید خصوصی اعلام شوند تا به طور تصادفی آنها را در کلاس دیگری اجرا نکنید و غیره. پس از نوشتن ادغام خود به صورت قیاس با ادغام دیگری، در مورد وجود CheckStyle - یک پلاگین ویژه که استایل را بررسی می کند مطلع شدم. از کد خود، و تا زمانی که خطاها را برطرف نکنید، نمی توانید پروژه خود را کامپایل کنید (مثلاً فاصله های اضافی، نام متغیرها با حروف بزرگ، نام متغیرها خیلی کوتاه). پس از شکست دادن CheckStyle، کدم را برای بررسی برای توسعه دهندگان ارشد فرستادم و اشتباهاتم را ظرف یک هفته اصلاح کردم. در کل خیلی خوش شانس بودم که در تیمم با توسعه دهنده دوم رابطه خوبی داشتم که خیلی چیزها را توضیح داد. یک ماه بعد از دستگاه، اولین ادغام من روی پایه Integration-Functional راه اندازی شد (کار همه برنامه ها با هم تست شده است) و همه چیز در آنجا کار کرد! پیروزی! وظیفه بعدی ایجاد کلاسی بود که امکان مخفی کردن داده ها توسط کلید در json را فراهم کند. به عنوان مثال: json {text:"JavaRush"} -> پردازش -> {text:"****Rush"} وجود دارد. در اینجا دو عارضه وجود دارد: ممکن است {text:{mytext:"JavaRush"}} تودرتو وجود داشته باشد، و آنچه ناخوشایندتر است، تودرتو در داخل آرایه است: {text: [{mytext: "JavaRush"}، {mytext: "JavaRush" "} ] } (البته باید همه text.mytext را مخفی کنید). حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد منتقل می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و اینکه داده ها را با هر نوع تودرتو به درستی پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. سعی کردم اتصالات همه طبقات را بنویسم و ​​هیچ چیز در ذهنم گیر نکرد. شرم آورترین لحظه عدم آگاهی از Intellij Idea بود: نحوه جستجوی جهانی برای یک پروژه، بازآفرینی کد و غیره. پس از انجام این کار، متوجه شدم که چرا OOP مورد نیاز است: برای چنین مقدار زیادی کد، لازم است آن را به کلاس ها تقسیم کنیم. متدهایی که خارج از کلاس استفاده نمی شوند باید خصوصی اعلام شوند تا به طور تصادفی آنها را در کلاس دیگری اجرا نکنیم و غیره. پس از نوشتن ادغام خود به صورت قیاس با یکپارچه سازی دیگر، در مورد وجود CheckStyle - یک افزونه ویژه که استایل را بررسی می کند، آشنا شدم. از کد خود، و تا زمانی که خطاها را برطرف نکنید، نمی توانید پروژه خود را کامپایل کنید (مثلاً فضاهای اضافی، نام متغیرها با حروف بزرگ، نام متغیرها خیلی کوتاه). پس از شکست دادن CheckStyle، کدم را برای بررسی برای توسعه دهندگان ارشد فرستادم و اشتباهاتم را ظرف یک هفته اصلاح کردم. در کل خیلی خوش شانس بودم که در تیمم با توسعه دهنده دوم رابطه خوبی داشتم که خیلی چیزها را توضیح داد. یک ماه بعد از دستگاه، اولین ادغام من روی پایه Integration-Functional راه اندازی شد (کار همه برنامه ها با هم تست شده است) و همه چیز در آنجا کار کرد! پیروزی! وظیفه بعدی ایجاد کلاسی بود که امکان مخفی کردن داده ها توسط کلید در json را فراهم کند. به عنوان مثال: json {text:"JavaRush"} -> پردازش -> {text:"****Rush"} وجود دارد. در اینجا دو عارضه وجود دارد: ممکن است {text:{mytext:"JavaRush"}} تودرتو وجود داشته باشد، و آنچه ناخوشایندتر است، تودرتو در داخل آرایه است: {text: [{mytext: "JavaRush"}، {mytext: "JavaRush" "} ] } (البته باید همه text.mytext را مخفی کنید). حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد منتقل می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و اینکه داده ها را با هر نوع تودرتو به درستی پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. سعی کردم اتصالات همه طبقات را بنویسم و ​​هیچ چیز در ذهنم گیر نکرد. شرم آورترین لحظه عدم آگاهی از Intellij Idea بود: نحوه جستجوی جهانی برای یک پروژه، بازآفرینی کد و غیره. پس از انجام این کار، متوجه شدم که چرا OOP مورد نیاز است: برای چنین مقدار زیادی کد، لازم است آن را به کلاس ها تقسیم کنیم. متدهایی که خارج از کلاس استفاده نمی شوند باید خصوصی اعلام شوند تا به طور تصادفی آنها را در کلاس دیگری اجرا نکنیم و غیره. پس از نوشتن ادغام خود به صورت قیاس با یکپارچه سازی دیگر، در مورد وجود CheckStyle - یک افزونه ویژه که استایل را بررسی می کند، آشنا شدم. از کد خود، و تا زمانی که خطاها را برطرف نکنید، نمی توانید پروژه خود را کامپایل کنید (مثلاً فضاهای اضافی، نام متغیرها با حروف بزرگ، نام متغیرها خیلی کوتاه). پس از شکست دادن CheckStyle، کدم را برای بررسی برای توسعه دهندگان ارشد فرستادم و اشتباهاتم را ظرف یک هفته اصلاح کردم. در کل خیلی خوش شانس بودم که در تیمم با توسعه دهنده دوم رابطه خوبی داشتم که خیلی چیزها را توضیح داد. یک ماه بعد از دستگاه، اولین ادغام من روی پایه Integration-Functional راه اندازی شد (کار همه برنامه ها با هم تست شده است) و همه چیز در آنجا کار کرد! پیروزی! وظیفه بعدی ایجاد کلاسی بود که امکان مخفی کردن داده ها توسط کلید در json را فراهم کند. به عنوان مثال: json {text:"JavaRush"} -> پردازش -> {text:"****Rush"} وجود دارد. در اینجا دو عارضه وجود دارد: ممکن است {text:{mytext:"JavaRush"}} تودرتو باشد، و آنچه ناخوشایندتر است، تودرتو در داخل آرایه است: {text: [ {mytext: "JavaRush"}، {mytext: "JavaRush" "} ] } (البته باید همه text.mytext را مخفی کنید). حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد ارسال می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و به درستی داده ها را با هر نوع تودرتو پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. برای چنین مقدار زیادی کد، باید آن را به کلاس ها تقسیم کنید. متدهایی که خارج از کلاس استفاده نمی شوند باید خصوصی اعلام شوند تا به طور تصادفی آنها را در کلاس دیگری اجرا نکنیم و غیره. پس از نوشتن ادغام خود به صورت قیاس با یکپارچه سازی دیگر، در مورد وجود CheckStyle - یک افزونه ویژه که استایل را بررسی می کند، آشنا شدم. از کد خود، و تا زمانی که خطاها را برطرف نکنید، نمی توانید پروژه خود را کامپایل کنید (مثلاً فضاهای اضافی، نام متغیرها با حروف بزرگ، نام متغیرها خیلی کوتاه). پس از شکست دادن CheckStyle، کدم را برای بررسی برای توسعه دهندگان ارشد فرستادم و اشتباهاتم را ظرف یک هفته اصلاح کردم. در کل خیلی خوش شانس بودم که در تیمم با توسعه دهنده دوم رابطه خوبی داشتم که خیلی چیزها را توضیح داد. یک ماه بعد از دستگاه، اولین ادغام من روی پایه Integration-Functional راه اندازی شد (کار همه برنامه ها با هم تست شده است) و همه چیز در آنجا کار کرد! پیروزی! وظیفه بعدی ایجاد کلاسی بود که امکان مخفی کردن داده ها توسط کلید در json را فراهم کند. به عنوان مثال: json {text:"JavaRush"} -> پردازش -> {text:"****Rush"} وجود دارد. در اینجا دو عارضه وجود دارد: ممکن است {text:{mytext:"JavaRush"}} تودرتو باشد، و آنچه ناخوشایندتر است، تودرتو در داخل آرایه است: {text: [ {mytext: "JavaRush"}، {mytext: "JavaRush" "} ] } (البته باید همه text.mytext را مخفی کنید). حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد ارسال می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و به درستی داده ها را با هر نوع تودرتو پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. برای چنین مقدار زیادی کد، باید آن را به کلاس ها تقسیم کنید. متدهایی که خارج از کلاس استفاده نمی شوند باید خصوصی اعلام شوند تا به طور تصادفی آنها را در کلاس دیگری اجرا نکنیم و غیره. پس از نوشتن ادغام خود به صورت قیاس با یکپارچه سازی دیگر، در مورد وجود CheckStyle - یک افزونه ویژه که استایل را بررسی می کند، آشنا شدم. از کد خود، و تا زمانی که خطاها را برطرف نکنید، نمی توانید پروژه خود را کامپایل کنید (مثلاً فاصله های اضافی، نام متغیرها با حروف بزرگ، نام متغیرها خیلی کوتاه). پس از شکست دادن CheckStyle، کدم را برای بررسی برای توسعه دهندگان ارشد فرستادم و اشتباهاتم را ظرف یک هفته اصلاح کردم. در کل خیلی خوش شانس بودم که در تیمم با توسعه دهنده دوم رابطه خوبی داشتم که خیلی چیزها را توضیح داد. یک ماه بعد از دستگاه، اولین ادغام من روی پایه Integration-Functional راه اندازی شد (کار همه برنامه ها با هم تست شده است) و همه چیز در آنجا کار کرد! پیروزی! وظیفه بعدی ایجاد کلاسی بود که امکان مخفی کردن داده ها توسط کلید در json را فراهم کند. به عنوان مثال: json {text:"JavaRush"} -> پردازش -> {text:"****Rush"} وجود دارد. در اینجا دو عارضه وجود دارد: ممکن است {text:{mytext:"JavaRush"}} تودرتو وجود داشته باشد، و آنچه ناخوشایندتر است، تودرتو در داخل آرایه است: {text: [{mytext: "JavaRush"}، {mytext: "JavaRush" "} ] } (البته باید همه text.mytext را مخفی کنید). حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد منتقل می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و اینکه داده ها را با هر نوع تودرتو به درستی پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. نام متغیرها خیلی کوتاه هستند). پس از شکست دادن CheckStyle، کدم را برای بررسی برای توسعه دهندگان ارشد فرستادم و اشتباهاتم را ظرف یک هفته اصلاح کردم. در کل خیلی خوش شانس بودم که در تیمم با توسعه دهنده دوم رابطه خوبی داشتم که خیلی چیزها را توضیح داد. یک ماه بعد از دستگاه، اولین ادغام من روی پایه Integration-Functional راه اندازی شد (کار همه برنامه ها با هم تست شده است) و همه چیز در آنجا کار کرد! پیروزی! وظیفه بعدی ایجاد کلاسی بود که امکان مخفی کردن داده ها توسط کلید در json را فراهم کند. به عنوان مثال: json {text:"JavaRush"} -> پردازش -> {text:"****Rush"} وجود دارد. در اینجا دو عارضه وجود دارد: ممکن است {text:{mytext:"JavaRush"}} تودرتو باشد، و آنچه ناخوشایندتر است، تودرتو در داخل آرایه است: {text: [ {mytext: "JavaRush"}، {mytext: "JavaRush" "} ] } (البته باید همه text.mytext را مخفی کنید). حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد ارسال می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و به درستی داده ها را با هر نوع تودرتو پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. نام متغیرها خیلی کوتاه هستند). پس از شکست دادن CheckStyle، کدم را برای بررسی برای توسعه دهندگان ارشد فرستادم و اشتباهاتم را ظرف یک هفته اصلاح کردم. در کل خیلی خوش شانس بودم که در تیمم با توسعه دهنده دوم رابطه خوبی داشتم که خیلی چیزها را توضیح داد. یک ماه بعد از دستگاه، اولین ادغام من روی پایه Integration-Functional راه اندازی شد (کار همه برنامه ها با هم تست شده است) و همه چیز در آنجا کار کرد! پیروزی! وظیفه بعدی ایجاد کلاسی بود که امکان مخفی کردن داده ها توسط کلید در json را فراهم کند. به عنوان مثال: json {text:"JavaRush"} -> پردازش -> {text:"****Rush"} وجود دارد. در اینجا دو عارضه وجود دارد: ممکن است {text:{mytext:"JavaRush"}} تودرتو باشد، و آنچه ناخوشایندتر است، تودرتو در داخل آرایه است: {text: [ {mytext: "JavaRush"}، {mytext: "JavaRush" "} ] } (البته باید همه text.mytext را مخفی کنید). حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد ارسال می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و به درستی داده ها را با هر نوع تودرتو پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد ارسال می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و به درستی داده ها را با هر نوع تودرتو پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد. حل این مشکل بسیار دشوار بود، اما من آن را انجام دادم! در اینجا توسعه دهنده دوم می گوید: این توسعه را با آزمایشات پوشش دهید. گیجی در چشم ها بود. اینگونه بود که با کتابخانه JUnit در مبارزات آشنا شدم. ماهیت تست واحد: شما داده های ورودی دارید، آن را به یک متد منتقل می کنید و داده های دریافتی را با نتیجه صحیح مقایسه می کنید (یک متغیر با نتیجه صحیح ایجاد کنید). من 11 مورد را برای کتابخانه خود نوشتم، که در آنها بررسی کردم که برنامه با یک NullPointException خراب نمی شود و اینکه داده ها را با هر نوع تودرتو به درستی پنهان می کند. پس از انجام این کار، یک ادغام جدید به من داده شد که ویژگی آن به شرح زیر بود: باید یک Spring Bean را از یک کتابخانه خارجی صادر می کردم. در این مرحله، من مشتری دائمی وب سایت Stack OverFlow شدم. یک بار حتی یک توسعه دهنده رسمی Spring پاسخ داد. پس از اجرای این ادغام، دوره آزمایشی من به پایان رسید. رئیس گذراندن دوره آزمایشی را به من تبریک گفت و من شروع به نوشتن این مقاله کردم. در مجموع نوشتن این مقاله 8 ساعت طول کشید) از توجه شما متشکرم، امیدوارم مطلب مفید بوده باشد.
نظرات
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION