من تقریباً برای انتخاب عکس العمل در برنامه سازمانی خود اخراج شدم

تابستان 2018 است. رئیس من ، آدریان ، از من می خواهد که در تماس اسکایپ با جیمز ، مدیر ارشد مالی یک شرکت بزرگ کانادایی ، به او ملحق شوم. در حالی که با یکدیگر آشنا می شویم ، متوجه می شوم که جیمز یک پسر باهوش و جاه طلبی بزرگ است. چشم انداز او انتقال یک برنامه WPF دسک تاپ عظیم به وب در فضای ابری است.

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

من و آدریان رویکرد استاندارد را برای این وضعیت دنبال می کنیم. چند تماس دیگر داریم و سپس مرحله کشف را شروع می کنیم که در آن سعی می کنیم تصویر بزرگ را درک کنیم و الزامات غیر عملکردی را پیدا کنیم. اینها نکات اصلی است که باید روی آنها متمرکز شویم:

یک برنامه بزرگ - بیش از 220 صفحه که بیشتر آنها صفحه های نگهداری و حدود 20٪ آنها بسیار سفارشی هستند.

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

معماری مدولار به چندین تیم اجازه می دهد تا همزمان روی پروژه کار کنند.

پروژه چند ساله با گذشت زمان ویژگی های جدید اضافه خواهد شد.

نیازی به پشتیبانی آفلاین نیست.

پردازش سریع برای اعضای جدید تیم ، به ویژه برای توسعه دهندگان .NET که روی برنامه دسک تاپ قدیمی کار می کنند.

به عنوان یک معمار ، نقش من ایجاد یک پیشنهاد فنی است که شامل جزئیات معماری ، روش ، نقشه راه ، دستورالعمل ها و مهمتر از همه ، پشته فناوری مورد استفاده باشد.

جیمز چندین بار اشاره کرد که او می خواهد یک فناوری ضد آینده داشته باشد ، و او طرفدار انگولار نیست زیرا بعد از منسوخ شدن AngularJS از شهرت بدی برخوردار است.

من قبلاً چند پروژه کوچک و متوسط ​​را با استفاده از Angular و React با موفقیت اجرا کرده بودم ، بنابراین واقعاً به هیچ یک وابسته نیستم. احساس می کنم هرکدام می توانند کار را انجام دهند.

برای این پروژه ، من React را با Redux انتخاب کردم ... که دو سال بعد پشیمان خواهم شد.

ما یک تیم متشکل از سه توسعه دهنده را برای کار بر روی اثبات مفهوم تعیین کردیم و پس از دو ماه ، این یک موفقیت است. رابط کاربری فوق العاده پاسخگو ، زمان ساخت بسیار سریع و سرعت توسعه بالا. همه خوشحالند.

سد راه شماره 1: توسعه دهندگان NET به تیم بپیوندند

بعد از اثبات مفهوم ، زمان آن فرا رسیده است که توسعه دهندگان تیم برون سپاری مشتری به ما بپیوندند. ما هنوز جلسات اشتراک دانش را آغاز نکرده بودیم و CTO برای من ایمیلی ارسال می کند که می گوید: "سلام ، رضوان. ما واقعاً باید فردا با تیم برون سپاری من دیدار کنیم. "

ما آن جلسه را داریم و سرپرستی فنی با س questionsالات و راه حل ها در کمین من است:

"تزریق وابستگی کجاست؟ منظورت از "نیازی به یکی نیست" چیست؟ در اینجا یکی وجود دارد: InversifyJS! "

"اجزای عملکردی؟ نه نه نه. ما آنها را دوست نداریم بیایید از م componentsلفه های کلاس استفاده کنیم! "

"چرا این توابع فقط در اطراف آویزان هستند و چرا که در کلاسهای خدماتی کپسوله نشده اند تا آنها را ثابت کنند؟"

"سیاست امتحان مجدد API کجاست؟ بیایید یکی را با استفاده از PollyJS پیاده سازی کنیم. "

"چرا وقتی که نام کلاس PascalCase است ، نام پرونده ها تیز هستند؟ این باید نام کلاس را منعکس کند ، بنابراین از این پس ، آنها را نام می بریم SomePageComponent.tsx. "

و موردی که بیشتر مرا آزار می دهد: "چگونه می توانم آن را با استفاده از Visual Studio و نه از Visual Studio Code اجرا کنم؟"

برای من روشن است آنها می خواهند از دستورالعمل های .NET و الگوهای طراحی در React استفاده کنند. من بارها شاهد چنین اتفاقی بوده ام - توسعه دهندگانی که برای سازگاری با روش فناوری جدید کار سختی دارند. بنابراین من نمی خواهم وارد بحث شوم که چرا این الگوهای غیرمعمول React است.

اما در این حالت CTO از تیم وی پشتیبانی می کند که این طبیعی است. او فقط دو ماه من را می شناخت ، در حالی که سالها با تیمش کار می کرد. من باید سازش کنم و با پیشنهادات آنها موافقت کنم.

من تازه فهمیدم که React توسعه دهنده پسند Java یا .NET نیست. Angular به دلیل الگوهای مشابه طراحی در این مورد انتخاب بهتری بود.

سد راه شماره 2: هرگز فقط واکنش نشان نمی دهد

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

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

از کدام روتر باید استفاده کرد؟

علاوه بر Redux ، از چه مواردی برای اقدامات async استفاده کنیم؟ تنه؟ حماسه؟

آیا باید از Axios استفاده کنیم یا از fetchAPI مرورگر؟

فرم های Redux ، Formiq یا فرم نهایی؟

اجزای سبک ، makeStyle ، SASS یا CSS ساده؟

کتابخانه بین المللی شدن؟

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

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

و من حتی زمانی را که هر توسعه دهنده برای یادگیری تمام کتابخانه های شخص ثالث صرف می کند ، در نظر نمی گیرم. من هرگز دو پروژه React با همان وابستگی ها ، ساختار پروژه و دستورالعمل ها را ندیدم. این بدان معناست که دانش از پروژه به پروژه دیگر قابل انتقال نیست ، همانطور که در Angular یا Vue قابل مشاهده است.

بعد از این سه هفته که هیچ پیشرفتی در اجرای داستان های کاربردی کاربر نداشته اید ، CTO نگران است.

سد راه شماره 3: قلاب های واکنشی محبوب می شوند

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

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

همه کتابخانه های شخص ثالثی که ما از آنها استفاده می کنیم پشتیبانی از Hooks را اضافه کرده اند و به نظر می رسد کل دنیای React به آن سمت می رود. خب ما باید چی کار کنیم؟ آیا باید از دستورالعمل های اصلی کدگذاری عدول کنیم و روش سوم اجرای م componentsلفه ها را اضافه کنیم؟ هیچ راهی برای بازگشت و انتقال صفحات و اجزای موجود به Hooks وجود ندارد!

این تیم طرفدار استفاده از Redux Hooks است زیرا نیازی به استفاده از Redux connect()و جدا کردن اجزای تخلیه از ظروف نیست. این منطقی است و ما توافق می کنیم که از این پس ، صفحات و اجزای جدید از Hooks استفاده کنند. قدیمی ها را همانطور که هست خواهیم گذاشت.

و اینگونه است که در نهایت به سه روش انجام کار دست می یابیم. دیگر هیچ قوامی وجود ندارد.

برای بدتر کردن اوضاع ، برخی از توسعه دهندگان ایده استفاده نکردن از Redux را useStateبه جای آن شروع می کنند. این بدان معناست که ما ایده داشتن یک کشور واحد جهانی را به هم خواهیم زد.

Suspenseهنوز هم یک ویژگی تجربی است. من نگران این هستم که وقتی آزاد شود چه اتفاقی می افتد.

سد راه 4: توسعه در حال کند شدن است

هنگامی که ما تنظیمات ادغام مداوم را انجام دادیم ، ساخت حدود سه دقیقه به طول انجامید npm install. اما اکنون بعد از یک سال ، حدود 15 دقیقه طول می کشد.

ما همچنین مجبور شدیم Node.js را برای افزایش RAM به 4 گیگابایت پیکربندی کنیم زیرا 2 گیگابایت دیگر کافی نیست. این مسئله بزرگی نیست. آنچه نگران کننده است این است که توسعه دهندگان شکایت کرده اند که ساخت بسیار طولانی شده است ، بارگیری مجدد پس از 45-60 دقیقه توسعه متوقف می شود و شروع مجدد بیش از پنج دقیقه طول می کشد - به ویژه برای کسانی که دارای سیستم عامل ویندوز هستند (سیستم های لینوکس ظاهرا برای Node.js بسیار سریعتر هستند). گاهی اوقات ، آنها مجبورند به node_modulesطور کامل حذف شوند و دوباره وابستگی ها را بارگیری کنند زیرا در غیر این صورت به سادگی کار نخواهد کرد.

وقتی بیش از 1200 وابستگی node_modulesبا مجموع 600 مگابایت حجم وجود دارد ، چه انتظاری می توانید داشته باشید ؟

برای یک برنامه سازمانی ، همه چیز در مورد هزینه است. فرض کنیم یک توسعه دهنده مجبور است شش بار در روز با نرخ ساعتی 40 دلار در ساعت راه اندازی مجدد کند. شش بار در روز x پنج دقیقه x 240 روز در سال x 40 دلار در ساعت x هشت توسعه دهنده = 38،400 دلار در سال. این مبلغ زیادی برای یک شرکت نیست ، اما پاداش سالانه خوبی برای حامیان مالی پروژه می دهد. به هر حال ، این با تسلا مدل 3 کاملاً جدید برابر است.

سد راه شماره 5: Redux-Saga به آرامی می میرد

اکثر توسعه دهندگان با من مخالف هستند ، اما من احساس می کنم که بخش عمده ای از منطق تجارت در داخل اقدامات Redynux async است. بیشتر اوقات ، این تنها مکانی است که می توانید اعتبار سنجی ، تماس های API ، مدیریت خطا ، ایجاد جهش های redux یا ایجاد توستر اعلان را انجام دهید. اگر اینها منطبق بر تجارت در برنامه های پیشخوان محسوب نمی شوند ، پس چیست؟

ما از Redux-Saga استفاده می کنیم ، که تصمیم ضعیفی بود زیرا به پیچیدگی غیرضروری می افزاید. Thunk به اندازه کافی خوب بود

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

توسعه دهندگان به سه دلیل React را دوست دارند: سادگی ، انعطاف پذیری و اکوسیستم. تیم React از تجربه ایده های جدید لذت می برند ، اما این باعث نابودی اکوسیستم می شود! آنها باید شجاع باشند و مقصر آن را بپذیرند!

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

اکنون سپتامبر 2020 است و من تصمیم دارم React-Saga را در نتایج ارزیابی ریسک برای کمیته راهبری فنی قرار دهم.

از آنجا که 30٪ از منطق کسب و کار در داخل حماسه ها بود ، من آن را به عنوان یک ریسک بالا مشخص کردم. آن زمان بود که CTO عصبانیت خود را از دست داد و من را به دلیل تصمیمات ضعیف هنگام شروع پروژه مقصر دانست.

این فقط جرقه ای بود که مدیر محصول به آن نیاز داشت. او از این فرصت به عنوان فرصتی برای شروع پرسیدن سوالاتی مانند:

"چرا ما باید این همه وقت را برای ارتقا کتابخانه ها صرف کنیم؟"

"چرا توسعه در حال کند شدن است؟"

"چرا برنامه حشره دار و ناپایدار شد؟"

اوضاع به سطح مدیریت افزایش می یابد. من ساعتهای زیادی را به دنبال شواهدی می گذرانم که ثابت کند ما در آن زمان بهترین تصمیمات را گرفته ایم - نه روشی که می خواهم آخر هفته خود را سپری کنم.

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

نتیجه

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