بک اند و فرانت اند و دیگر هیچ (نحوه ی تعامل و کار تیمی)

https://devrant.com/rants/1128666/frontend-vs-backendیکی از طنز ها و نوستالوژی ها جذاب برای من (و شاید خیلی از برنامه نویسای دیگه) مقایسه ی بک اند و فرانت اند هست...البته من نمی خوام در این نوشته بگم بک اند و فرانت اند و تفاوتشون چیه بلکه هدفم صرفا اشاره به مشکلاتی هست که خودم به عنوان فرانت اند کار (توسعه دهنده ی اندروید) و هم به عنوان بک اند کار (توسعه دهنده Node js) بهش برخورد کردم...و شاید هم بتونم راه حلی ارائه بدم!مدیر پروژه و مدیر عامل صریح و مصممشرکت چابک و یا استارتاپی که برنامه نویس هاش (و کلا کارکنان و نیروی انسانی) ندونن اهداف و مسیر کسب و کار چیه و اونو به خوبی درک نکنن ، به نظرم راه درازی در پیش داره تا موفق بشه. هر ویژگی و قابلیت و یا اصلاح در محصول باید به درستی و با فهم و منطق مشترک به برنامه نویس منتقل بشه تا بتونه کد بزنه. من خودم این تجربه رو داشتم که در یه تیمی فرانت می زدم و نمی دونستم که این فیچر چی هست و چیکار می کنه و الی آخر... (خودتون تا آخر بخونید که چی دراومد و با چه بدبختی به آخر رسید ،‌ طبیعتا همکاری من هم با اون تیم ادامه دار نبود)به نظر من قبل از این که بخوایم در مورد بک اند و فرانت اند صحبت کنیم ، ابتدا باید این مسئله توی استارتاپ (و یا شرکتی که می خواد چابک باشه) حل بشه. به نظر من جزییات ایده و محصول تا حد زیادی قابل اشتراک گذاری با برنامه نویس هست و باید بدونه تا کد بزنه. نگرانی های دزدیده شدن ایده و اینا رو باید ببریم به عهد بوق (منظورم اینه راهکار های دیگه ای هست برای جلوگیری از این تهدید! و نباید به کار تیمی آسیب بزنه)یک مسئله ی پایه ای دیگه هم هست و به نام یکپارچگی تیم ، تغییرات و تصمیمات جدید توسط هر بخشی که گرفته می شه باید به سرعت و شفافیت و با درکی مشترک بین تیم منتشر بشه ، به خصوص بین بک اند و فرانت اند ، یه شعری هم هست در اینباره! (با عرض پوزش از زبان و ادب فارسی)چو عضوی به درد آورد بک اند را / دگر فرانت کار ها را نماد قراربک اند کارا مقدم اند یا فرانت اند؟در اینجا فرض کنید قرار یک قابلیت جدید (مثلا کامنت گذاشتن کاربران) به نرم افزار اضافه بشه ، نحوه ی توسعه به لحاظ ترتیب فعالیت های تیم رو می تونیم به شرح زیر داشته باشیم:۱- اول از همه بک اند و بعدش فرانت اند: وقتی یه مدت نسبتا طولانی بک اند بزنید (مثلا ۶ ماه تا ۱ سال به بالا) تصور فعالیت و حرکت کاربر یه مقدار مشکل می شه و یا ممکنه ملاحظاتی رو در نظر نگیرید در حالی که در فرانت به اون مراحل و فعالیت ها نیاز هست. این فرایند رفت و برگشت باعث دوباره کاری و فرسایش کار می شه و تمرکز تیم کاهش پیدا می کنه ، چیزی که از جهت مدیریت زمان پروژه خیلی مهم هست.۲- اول از همه فرانت اند و بعدش بک اند: در این روش نیز علاوه بر دوباره کاری و اتلاف منابعی که در حالت قبلی هم پیش میاد ، ممکنه با تغییرات وسیع تری مواجه بشیم. عکس زیر به خوبی این مشکل رو توضیح می ده: یه پوسته ی ظاهری که کلی کار داره تا کامل بشه (علاوه بر کد های به درد نخوری که این وسط زده می شه)https://devrant.com/rants/609097/when-frontend-is-ready-before-backend۳- اول پروتوتایپ ساده با مداد و کاغذ (user flow) سپس بک اند و در آخر فرانت اند: این فرایند برای توسعه ی نرم افزار خیلی کارا و بهتر هست (من صرفا چیزی که توی کار دیدم رو بهتون می گم شاید اشتباه باشه از دید مدیریت پروژه) پروتوتایپ ساده باعث می شه بک اند دید نسبتا جامعی پیدا کنه به ملزوماتی که باید ساپورت کنه توی بک اند و API ؛ از طرفی فرانت هم طبق اون پروتوتایپ دیزاین می کنه...همه چیز هماهنگ و عالی جلو می ره. در واقع طبق قانون ۲۰/۸۰ ، ۲۰ درصد زمان گذاشتن و بحث روی پروتوتایپ می تونه ۸۰ درصد روی افزایش سرعت و کارایی و بهره وری کار تیمی بک اند و فرانت اند موثر باشه (یه چیزی مثل تست نویسی و کامنت گذاری توی کد هست که زمان بره و نیازش تنها موقعی حس می شه که یه بار تجربه کنید و ببینید چه تاثیر بالایی داره روی توسعه ی نرم افزار ،‌ البته که خودم هنوز تست نویسی رو تجربه نکردم ... !)به زبان URL با بک اند صحبت کنیدمسئله ی داکیومنت درست کردن برای API خیلی مهمه ... من صرفا نظر خودم رو می گم و ممکنه غلط باشه ... چه از معماری مایکروسرویس استفاده کنید و چه مونولیتیک باشه و یا هر چیز دیگه باید از کد ها و نحوه ی تعامل با هم دیگه سردربیارید. راه حل معمول در اینجا داکیومنت سازی تمیز و دقیق و کامل هست. من برای بک اند Node js خودم از کتابخانه ی apiDoc استفاده می کنم به همراه یه پلاگین کار راه انداز برای vscode به نام ApiDoc Snippets و روش کار خودم اینه که بالای روتر ها طبق فرمت خاصی که گفته کامنت می ذارم و میاد یه داکیومنتیشن html ای تمیز و خوشگل ازش درست می کنه.حالا اگر از نحوه ی درست کردن داکیومنتیشن بگذریم ... تا چه حد باید جزییات رو بگیم و چه مقدار بهینه هست که ما بک اند کارا روی درست کردن داکیومنتیشن وقت بذاریم؟ واقعیت اینه که بیشتر ما آدما از طریق شنیدن و دیدن و آزمایش کردن یاد می گیریم تا خوندن ... در نتیجه داکیومنتیشن هم تا حدی خونده می شه و مورد توجه قرار می گیره و بقیش نادیده گرفته می شه ... به همین سادگی!به نظر من بهترین راه (حداقل برای تیم های استارتاپی و شرکت های چابک) برای سرعت بخشیدن کار تیمی ، یه داکیومنتیشن ساده در حد آدرس و فیلد های اجباری/اختیاری و نمونه های ممکن برای request و response ،‌ و در مقابل ،‌ حالات نحوه ی تعامل و منطق کار رو حضوری یا تلفنی به فرانت اند کارا (یا مدیر تیم فرانت اند) توضیح بدید (این که کدوم فیلد مهمه و این چیه و اون آدرس چرا اسمش اینه و ...) البته فرانت اند لازم نیست از همه چیز بک اند خبردار بشهبد نیست فرانت اند کار با ابزار هایی مثل postman و یا insomnia آشنا باشه تا بتونه خودش به صورت دستی request بفرسته و تست کنه تا با مشاهده و آزمایش طبق روش علمی ، فرضیه ای که توی داکیومنتیشن دیده براش ثابت بشه! و خودم این توصیه رو اکیدا به فرانت اند کارا می کنم و زیرکانه از صحنه خارج می شم!حقیقتا جنس فکر کردن و چالش های فرانت اند و بک اند واقعا متفاوته ولی در عین حال باید همیشه در کنار هم باشن و اوقات لذت بخشی رو از کد زدن و کار تیمی رو تجربه کنن