مهندسی تمام پشته یک سوم خوب است

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

این یک فانتزی دوست داشتنی است. یک توسعه دهنده که همه این کارها را انجام می دهد – fullstackicorn جادویی.

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

کار خود را به عنوان یک مهندس نرم افزار شروع کرده یا پیشرفت می کنید؟ مهندسی تمام پشته شما را دو برابر سریعتر در مسیر سریع برای رسیدن به موقعیت های ارشد قرار می دهد.

مهندسی تمام پشته افسانه ای جذاب است، اما در بسیاری از موارد این یک سازش نادرست است که می تواند در ازای ایجاد استرس بیشتر در یک فرد، محصولی با کیفیت پایین تر تولید کند.

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

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

چند استثنا وجود دارد: ابزارهای خاص در موارد استفاده خاص که مهندسان تمام پشته می توانند کد کاملاً کاربردی را ارائه دهند. (در زیر در مورد این موارد بیشتر خواهم گفت.) و تخصص تمام پشته می تواند یک بازی نهایی برای مهندسان بسیار ارشد با سال ها تجربه باشد. اما در بیشتر موارد، تمام پشته می‌تواند انتخابی برای رضایت دادن به راه‌حل‌های کمتر بهینه باشد و در عین حال مهندسین را برای شکست تنظیم کنید.

آیا مهندسی تمام پشته یک سوم ارزش را ارائه می دهد؟ یک چهارم؟ ریاضی هرچه که باشد، نتیجه واضح است: شما از یک تیم مهندسین متخصص با کارایی بالا و با تجربه، ارزش بسیار بیشتری دریافت خواهید کرد.

ذهن ما چند رشته ای نیست

با همه استعدادهای ما، مغز انسان به صورت تصاعدی مقیاس نمی‌شود و ما در پردازش موازی تحت بارهای شناختی سنگین وحشتناک هستیم.

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

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

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

تصور کنید سعی کنید همزمان یک زبان جدید (انسانی) را از یک گروه زبانی نامرتبط و یک هندسه جدید غیر اقلیدسی یاد بگیرید، در حالی که هر دو را برای حل یک مشکل مهندسی جالب استفاده کنید… همه اینها در حالی که قوانین دستور زبان و بدیهیات اساسی همچنان در حال تغییر هستند. برو.

ممکن است به نظر قهرمانانه برسد که به چنین چالشی برسیم، اما سازمان‌های مهندسی در واقع توسط تیمی که می‌تواند چالش‌ها را تقسیم کرده و غلبه کند و در عین حال بر روی بهترین راه‌حل کار می‌کند، بهتر به آنها خدمت می‌کند. اذعان به محدودیت های ما منجر به نتیجه بهتری می شود.

سرزمین fullstackicorn

زمین محدودی وجود دارد که fullstackicorn می تواند آزادانه در آن پرسه بزند.

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

برای تکه‌ای از مشکلات مهندسی نرم‌افزار، هر مهندس فول استک که به تنهایی کار می‌کند، می‌تواند راه‌حلی مناسب ایجاد کند. دو مورد استفاده برای این وجود دارد:

1. یکپارچه های ارائه شده در سمت سرور.
2. MVPهای هک شده (حداقل محصولات قابل دوام) یا نمونه های اولیه (گاهی اوقات یک مورد خاص از شماره ۱).

برخی از مشکلات به اندازه کافی آشنا و ساده هستند که بتوان آن ها را با یکپارچه های ارائه شده در سمت سرور حل کرد. Ruby on Rails، Django، Laravel… اگر راه حل مورد نیاز به راحتی با الگوهای عقیده ای که این فریم ورک ها ارائه می دهند مطابقت داشته باشد، یک تیم باتجربه از توسعه دهندگان فول استک که در آن چارچوب ها مهارت دارند، قادر خواهند بود آن را به طور کارآمد بسازند.

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

به‌طور مشابه، استارت‌آپ‌های در مراحل اولیه گاهی اوقات به ساختن یک MVP «سست» راضی می‌شوند، زیرا به دنبال تأمین مالی هستند. (این ممکن است به خوبی بر روی یکی از فریم ورک های رندر شده سمت سرور ساخته شده باشد.) مهندسان فول استک می توانند این کار را انجام دهند، اما نباید مورد سوء استفاده قرار گیرند یا تحت فشار ناعادلانه قرار گیرند فقط به این دلیل که استارت آپ توانایی استخدام یک تیم عمیق تر را ندارد. .

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

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

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

تیم های مهندسی فول ون

برای بسیاری از مشکلات و فرصت‌ها در مهندسی نرم‌افزار، تیم‌های مشترک مهندسین فرانت‌اند و بک‌اند می‌توانند بسیار مؤثرتر از تک‌نوازان فول استک باشند.

توسعه‌دهنده Back-end می‌تواند روی لایه داده، نقاط پایانی RESTful خوب طراحی شده، مشکلات مقیاس‌پذیری، اجتناب از مشکل n+1 برای جستجوها و غیره تمرکز کند.

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

بسیاری از کارهای آنها، هرکدام به تنهایی می توانند انجام دهند، کاملاً بر تخصص خود متمرکز شده اند و به طرز خیرخواهانه ای نسبت به نگرانی های دیگری ناآگاه هستند. اما در جایی که حوزه‌های مسئولیت آن‌ها با هم جمع می‌شوند – جایی که دایره‌های موجود در نمودار ون همپوشانی دارند – اعضای تیم برای تصمیم‌گیری در مورد بهترین راه‌حل با یکدیگر همکاری می‌کنند.

کاربران برای دسترسی یا ویرایش به چه داده هایی نیاز دارند؟ UI چگونه API را فراخوانی می کند؟ قرارداد داده چگونه به نظر می رسد؟ تیم در مورد این سؤالات با هم هماهنگ می کند، سپس هر کدام به سراغ بخش خود از راه حل می روند.

با گرد هم آوردن تیم برای انجام این مکالمات، روند را برای مدت کوتاهی به نصف کاهش می‌دهید، اما پس از جدا شدن دوباره به سرعت کامل برمی‌گردید، با شرایط لازم برای سریع‌تر رفتن و پیاده‌سازی ویژگی‌ها به درستی در سیلوهای خودشان. (در همین حال، مهندس فول استک کل پروژه را در بهترین حالت، با چندوظیفگی و تغییر زمینه که همه چیز را به یک خزیدن می رساند، با نیم سرعت صرف می کند.)

همانطور که ممکن است انتظار داشته باشید، با توجه به این تداخل‌های مسئولیت‌ها، برای هر یک از اعضای تیم مهم است که درک درستی از حوزه تخصص دیگری داشته باشد. اما اگر این تخصص خیلی عمیق نباشد، اشکالی ندارد، به ویژه برای مهندسانی که هنوز در مراحل اولیه کار خود هستند.

مشاغل با همکاری ایجاد می شوند

در اوایل کار یک مهندس نرم افزار – احتمالاً در مشاغل دیگر نیز – تمایلی وجود دارد که سعی کند همه چیز را به یکباره یاد بگیرد. اما این بی حوصلگی در واقع پیشرفت شما را کند می کند.

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

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

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

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

بله، شما بهتر از بسیاری از ریاضیدانان، بیولوژی مولکولی و سلولی را درک می کنید، هرچند کمتر از بسیاری از زیست شناسان. این به شما در حرفه و توانایی شما برای ایجاد تأثیر معنادار در زمینه کاری خود برتری می دهد.

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

کامل تر از فول استک

وضعیت پایانی این مسیر شغلی می‌تواند یک مهندس تمام عیار باشد، اگرچه در آن مرحله شما برای خیلی بیشتر موقعیت دارید. شما یک معمار نرم افزار هستید، شاید یک مدیر مهندسی. شما فردی هستید که درک قوی از اصول، دانش تخصصی در یک زمینه از زمینه، آشنایی با حوزه‌های خارج از تخصص شما، و درک کاملی از نحوه جمع آوری همه اینها برای حل جالب‌ترین مشکلات دارید.< /p>

این وعده واقعی دو به یک است، گاهی اوقات پنج در برابر یک یا ۱۰ برای یک. نه یک مهندس تمام عیار که بتواند کار دو نفره را در دو برابر زمان و با نصف کیفیت انجام دهد. در عوض، شخصی که مسیر یک متخصص را طی کرده و از طریق همکاری بین رشته‌ای، درک پیچیده‌ای از نحوه طراحی نرم‌افزار خوب ایجاد کرده است.

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