چرا جاوا در حال مرگ است؟

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

پس چه اتفاقی افتاده؟ پاسخ ساده است: موج فراگیر سرویس های خرد ما را در برگرفته است.

· سهولت مقیاس گذاری

· در دسترس بودن بالا

· کد ساده تر و عدم نگرانی در مورد همزمانی و چند رشته ای بودن

· قابلیت حمل کانتینرها

همه این عوامل ما را بر آن داشت تا کارآیی جاوا (به طور خاص JVM) را زیر سوال ببریم ، البته به معروف ترین چارچوب آن یعنی Springنپردازیم.

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

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

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

در کار جدید من ، این اعتقادات باعث تقویت و بیشتر دردناک تر شدن که می فهمم که این زبان چقدر ناموزون ، تحریک پذیر و پیچیده شده است - که بخشی از آن به دلیل چارچوب های تشریفاتی مانند Spring است.

تشریفات جاوا و Spring

بیایید با چارچوب بدنام Spring شروع کنیم.(Spring framework)

فریمورک Spring به اندازه پنج سال پیش بزرگ و پیچیده است و مملو از حاشیه نویسی های بی حد و حصر است که توسعه دهندگان را هر بار که برای انجام کار نیاز به رحمت آموزش ها یا کد نمونه دارند ، ترک می کند. این کار آن قدر دشوار است که باید مستندات جامع خود Spring را بررسی کنید.

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

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

"محصول ما Project Lombok یک کتابخانه جاوا است که به طور خودکار به ویرایشگر شما متصل می شود و ابزارهایی را ایجاد می کند ، و جاوا شما را ادیت می کند. دیگر هرگز متد getter یا برابر دیگری را ننویسید ، با یک حاشیه نویسی کلاس شما دارای یک سازنده کاملاً برجسته میشود ، متغیرهای ورود به سیستم خودکار را انجام می دهد و موارد دیگر... "

این هدف فشرده سازی کد Java’s ناامیدکننده است و به جای اینکه به خیر عمل کند ، علیه زبان کار می کند.

جاوا به سادگی باید تلاش برای مطابقت با اختصار زبان های اسکریپت را متوقف کند. اولاً ، این ثبات را در کد جاوا قربانی می کند: تصور کنید که فقط برای یافتن همه گیرنده ها و تنظیم کننده های خود به جاوا برگردید (چیزی که قبلاً فهمیدیم برای سیستم خودکار Spring بسیار مهم است) ، اکنون با حاشیه نویسی یک خطی NoArgsConstructor جایگزین می شود. سازگاری در آن کجاست؟

ثانیا ، این به مجموعه پیچیده انتزاعات اضافه می شود. به عنوان مثال ، در اینجا Springمی تواند در پشت صحنه خودکارسازی (bean injections) را تنظیم کند ، اما پس از آن Lombok در متن برنامه کجا زندگی می کند و ارسال پیام بین این دو چگونه تنظیم می شود؟ اگر برای هر یکی از کلاس های خود شش حاشیه نویسی داشته باشم ، چند روال یا کلاس دیگر با این حاشیه نویسی برای انجام این کار ساده ارائه شده است؟ هیچ توسعه دهنده واقعی نمی خواهد این همه کد اضافی در گوشه ها باشد. متأسفانه ، این نوعی از کد جاوا است که پس از سه سال با آن مواجه می شوم. حتی یک چیز تغییر نکرده است. در واقع ، حتی تغییرات اندکی که اتفاق افتاده است ، فقط باعث بدتر شدن آن شده است.

به نظر می رسد تمرکز جاوا هنوز بر روی قوانین احمقانه ای است که تعیین می کنند نام کلاس ها باید چه نوع بسته هایی باشد و آیا متغیرها باید خصوصی یا محافظت شوند. جدی! ، چه کسی اهمیت می دهد؟

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

ساده نگه دارید! ، احمق!

چیزی که در صنعت نرم افزار بارها و بارها می شنوید ، نام اختصاری KISSاست: ساده نگه ش دار ، احمق!. این چیزی است که جاوا اگر می خواهد زنده بماند باید به طور جدی به آن توجه کند.

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

در پایان روز ، همه سرویس ها ، به شکلی یا صورتی ، صرفاً داده ها را با فرمت دیگری (JSON یا XML) پردازش می کنند و سپس آنها را برای پردازش بیشتر به یک پیام مانند Kafka منتقل می کنند. و حتی در یک محیط مسخره ساده از این قبیل ، جاوا و Spring همچنان به سخنان نا همسان نحو کد تشریفاتی ، زمینه های برنامه ، bean injections هایپیچیده ، خودکار ، نگاشت کنندگان POJO ، JVM و لودر کلاس های بدنام ادامه می دهند - همه اینها مقابله با آنها بی معنی است

حکم؟ "ساده باش احمق!"