وبلاگ افشار محبی

یک زمانی، برنامه ASP.NET تولید می شد که مقدار JavaScript در آن به ده خط هم نمی رسید. این قضیه هم در ASP.NET MVC صادق بود و هم در ASP.NET WebForm و حتی ASP Classic. آن زمان هنوز بحث Front-end developer و Back-end developer به شکل امروزش مطرح نبود. همان کسی که کد CSharp و فرم ASPX و بعدها کنترلر را می نوشت، تگ های HTML و CSS را هم سر هم می کرد و پروژه ادامه پیدا می کرد. البته کار Designer به معنای کسی که روی سر و فرم صفحه وب کار می کرد و به طور خلاصه کسی که CSS و بعدترها Responsive Web Design کار می کرد از همان اولش کمی جدا بود و معمولا آدم مستقلی را طلب می کرد. منتها چون نیاز به این فرد روزمره نبود، اقلا در پروژه های کوچک، تاثیر خیلی عمده ای روی ترکیب تیم نداشت.
اما امروز اوضاع فرق کرده است. ایجاد صفحه وبی که روی همه Browser ها و Resolution ها یکسان به نظر برسد که از بدیهیات شده. از زمانی که Single Page Application ها توسط Gmail و اسلافش باب شد، توسعه وب به طور کامل دو تیکه شد: Back-end developer که توسعه دهنده API و دسترسی به دیتابیس است و معمولاً با تکنولوژی هایی مثل ASP.NET, PHP, Django و Rails و این اواخر Express که عمدتا غیر جاوا اسکریپتی هستند توسعه پیدا می کند و Front-end developer که عملا UI برنامه است و آن چیزی که کاربر نهایی آن را می بیند. از آنجا که بخش زیادی از تعاملات با کاربر به Front یعنی Browser کاربر نهایی منتقل شده بود، بخش سنگینی از برنامه هم باید در فرانت توسعه داده می شد. این یعنی یک سری از فریمورک های مختلف client side مثل Vue.js، نسخ مختلف آنگولار، react.js و غیره پا به میدان گذاشتند. این فریمورک ها عمدتا یا خودشان جاوا اسکریپتی هستند یا این که از یک اسکریپت/زبان واسطه مثل CoffeeScript و TypeScript استفاده می کنند که در نهایت به جاوا اسکریپت ترانسپایل می شوند.
همه این داستان ها منجر به بهبود قابل توجه کیفیت صفحات وب و غنی تر شدن تجربه کاربری شد. اما این بهبود چندان هم کم هزینه نبود. علاوه بر این که تعداد نفرات تیم توسعه وب افزایش پیدا کرد و Developer ها را مجبور کرد که کلی چیز جدید یاد بگیرند، چالش جدیدی را هم ایجاد کرد. افراد تیم تخصصی شدند و هر کسی در کار به خصوصی مهارت پیدا کرد. یک نفر C# و T-SQL و ASP.NET مسلط بود، پس شد Back-end developer. یک نفر دیگر هم JavaScript و HTML و یکی از فریمورک های رایج مثل Angular و React بلد بود، که اون هم شد Front-end developer. به هر کدام از این قسمت ها یک Stack گفتند و داستان جدایی از این همینجا شروع شد.
مرسوم شد که Back-end developer ها کار به کار Front-end developer ها نداشته باشند و بالعکس. در نتیجه جلسات Sprint Planning دو قطبی شد. Front-end developer ها این طرف میز نشستند و Back-end developer ها آن طرف میز. هر Feature یا رفع باگی به عهده دو نفر گذاشته شد. یک نفر که بخش back را درست کند و نفر دیگر که بخش front را پیش ببرد. وابستگی ها عمیق تر شد و مشکل communication که از روز اول کار تیمی وجود داشت، شدیدتر. Back-end developer می گفت من API را مطابق مستندات آماده کرده ام، در حالی که Front-end developer ادعا می کرد که همیشه خطای خانواده 400 می گیرد. بک-اند تست کارش را منوط به داشتن UI می کرد و فرانت-اند هم همیشه از این که API آن طور که باید کار نمی کند می نالید. بعضی وقت ها هر کدام از طرفین کارشان را درست انجام داده بودند ولی همچنان چیزی کار نمی کرد. هیچ کس هم نبود که این کار را به شکل واحد ببیند تا بفهمد مشکل از کجاست. وقتی که هم مشکل کشف می شد، اینقدر بدیهی بود که باعث خجالت بیشتر می شد. یا فرمت استرینگ فیلد time یکی نبود، یک VERB یکسان استفاده نشده بود یا مثل همیشه مشکل Binding وجود داشت. بعضی وقت ها که یکی از طرفین به مرخصی می رفت، آن طرف عملا بیکار می ماند. تازه بگذریم از وقتی که یک نفر از هر کدام از طرفین از تیم خارج می شد و چه مشکلاتی که از این بابت به وجود نمی آمد.
اوضاع خوب تر که نشد هیچ، حتی بدتر هم شد. وقتی که برنامه نویسی اندروید و iOS هم به این ملغمه اضافه شد، دیگر با دو تا استک سر و کار نداشتیم، بلکه شدیم سه تا و بلکه چهار Stack مختلف. این بار تکنولوژی ها واقعا متفاوت تر بودند. برنامه نویسی با جاوا، کاتلین، Objective C و سویفت آن هم با IDE های پر ماجرایی مثل Android Studio و محیط Mac و تحت ساختار اندروید و iOS که مدام هم در حال تغییر هستند کار ساده ای نبوده و نیست.
همه زندگی که اخبار بد نیست که. بالاخره وسط این همه دردسر، یک سری راه حل هایی هم پیدا شد. خدا بیامرزد پدر کسی که را مفهوم Full Stack Developer را ابداع کرد. این نوع توسعه دهنده به کسی گفته می شود که هر کدام را از استک ها را تا اندازه ای مسلط باشد و بتواند به طور هم زمان هر چند طرف قضیه را پوشش دهد. آن اوایل به کسی می گفتند Full Stack Developer که هم Front-end بلد باشد و هم Back-end. اما دنیا که پیشرفت کرد و موبایل های هوشمند که رایج تر شدند، آن ها را هم در بر گرفت. یعنی Full Stack شد کسی که هم Front باشد، هم Back و هم Mobile App. با ظهور این ناجی بزرگ، مشکلات تیم ها کمتر شد. هم مشکل ارتباطی و هم مشکل عدم توازن قوا در طرفین بحث. درست است که Full Stack Developer ممکن است در هیچ کدام از Stack ها به اندازه یک Single Stack Developer تسلط نداشته باشد، اما به عقیده من چون توانست برخی مشکلات قبلی را حل کند، همچنان قابل قبول است. حالا بماند که Full Stack Developer ها چون معمولاً از دنیای Freelancer می آیند، در کار تیمی کمی نیاز به کمک دارند.
این البته پایان ماجرا نیست. با ظهور Full Stack Developer بحث های جدیدی هم مطرح شد. این که حالا توسعه دهنده Full Stack از کجا پیدا کنیم و مهم تر از اون این که Single Stack Developer های حاضر در تیم را چطور تبدیل کنیم به Full Stack Developer. راه متعارفش، یادگیری آن Stack دیگر است. اما خود این راه هم اما و اگر های فراوانی دارد. بک-اندی ها معمولا از زبان های Static Type مثل C# استفاده می کنند. در حالی که فرانت-اندی ها از چیزی مثل جاوا اسکریپت استفاده می کنند که آزادی عمل زیادی به آنها می دهد. سویچ کردن بین این دو تا خودش اولین مشکل است. مشکل بعدی که باید حل شود این است که منحنی یادگیری استک انتخابی باید خیلی کم شیب باشد تا باعث بی انگیزگی افراد نشود. پیچیدگی ابزارها هم گاهی اوقات باعث مشکل می شود. Visual Studio و Android Studio هر کدام یک دوره آموزشی نیاز دارند برای نصب و استفاده بهینه. Deploy کردن اپ های iOS هم با این وضع تحریم بیشتر شبیه به جادو است تا یک کار فنی. بعضی دوستان هم استفاده از مجموعه استک های سراسر جاوا اسکریپتی که بک-اند آن با Node/Express است را هم توصیه می کنند. با این استدلال که در کل پروژه فقط یک Language استفاده می شود و این مشکل سویچ بین زبان ها را از بین می برد. خلاصه این که این قصه هم سر دراز دارد.
برای جان سالم بردن از این همه چالش، باید خیلی باهوش باشیم، خیلی از تجربه دیگران استفاده کنیم و خیلی وقت ها هم آستین بالا بزنیم و از هر کدام یک مقدار بچشیم. بعضی وقت ها تنها راه حل، Full Stack شدن و Ploygot بودن است. بعضی وقت ها هم شاید عاقلانه تر این باشد که با توجه به منابع در دسترس، اصل صورت مسئله را پاک کنیم. یعنی بگوییم اصلا Mobile App نداریم، یا این که اصلا همه چیز Server Rendered خواهد بود و حتی یک خط جاوا اسکریپت هم نمی خواهیم داشته باشیم.

پی نوشت: حین پیدا کردن عکس برای این مطلب به نوشته ای برخورد کردم که DevOps و Database را هم به عنوان Stack های جداگانه مطرح می کرد.

پی نوشت ۲: What does Full Stack mean to you?