Table of Contents
مهندسان اصلی، عناصر فنی سازمان های نرم افزار مدرن هستند، با استفاده از نفوذ که به مراتب فراتر از مشارکت های کد فردی گسترش می یابد، تصمیمات آنها معماری و طراحی سیستم های بنیادی را شکل می دهند، به طور مستقیم بر مقیاس پذیری، حفظ قابلیت و دوام کسب و کار طولانی مدت تاثیر می گذارد. درک اینکه چگونه این رهبران فنی ارشد کار می کنند و انتخاب های خاص خود را انجام می دهند - برای هر سازمان مهندسی تلاش برای نوآوری و نوآوری عملیاتی ضروری است.
نقش غیر واقعی یک مهندس ارشد
یک مهندس ارشد در تقاطع تخصص فنی عمیق و تفکر استراتژیک کسب و کار نشسته است، بر خلاف مهندسان کارکنان که ممکن است بر مشکلات پیچیده خاص تمرکز کنند، مهندسان ارشد یک دیدگاه سیستم در سراسر جهان، اغلب در تیم ها و پروژه های متعدد کار می کنند، آنها به سادگی ارشد ترین مشارکت کنندگان فردی نیستند؛ آنها به عنوان چند برابر نیروی عمل می کنند که جهت فنی، مهندسین مربی دیگر، و انسجام معماری را در کل سازمان مهندسی تنظیم می کنند.
این نقش با معمار نرم افزار اختصاصی یا یک مدیر فنی متفاوت است. معماران به طور معمول طرح های سطح بالا را تعریف می کنند، اما ممکن است با اجرای مدیران در اولویت قرار دادن افراد و فرآیند، مهندسان اصلی هر دو ترکیب شوند: آنها عمیقا در کد، بررسی ها و بحث های طراحی مشغول هستند، در حالی که همچنین از تصمیمات فنی که با اهداف کسب و کار هماهنگ می شوند، قدرت آنها از تخصص ثابت شده، نه سلسله مراتب رسمی، به آنها اجازه می دهد تا از تصمیم گیری های خط لوله نفوذ داده ها را به آنها.
در عمل، یک مهندس ارشد ممکن است یک روز را صرف ارزیابی یک فناوری پایگاه داده جدید کند، منجر به بررسی معماری برای یک سرویس جدید، عیب یابی یک حادثه تولید، و مشاوره یک تیم در الگوهای طراحی API احساس می شود که تاثیر آنها در سلامت بلند مدت از پایه کد و سرعت که تیم ها می توانند بدون دریافت بدهی فنی، ویژگی های ارائه دهند.
Shaping Software Architecture
معماری نرم افزار در مورد ساختارهای بنیادی است که یک سیستم را تعریف می کند: اجزای آن، روابط آنها و اصول حاکم بر طراحی و تکامل آنها، مهندسان اصلی، پیش بینی های اولیه این ساختارها هستند.
انتخاب الگو معماری
یکی از تصمیم های مهم ترین یک مهندس ارشد انتخاب سبک معماری برای یک سیستم است – یا هدایت تکامل یک مدل موجود، الگوهای مشترک شامل میکروسرویس ها، معماری های تکلی، سیستم های مبتنی بر رویداد و معماری های سیستم عامل، و ساختار سازمانی، هر یک از تجارت عمیق دارند.
یک مهندس ارشد با تجربه می داند که بهترین معماری، همان معماری است که متناسب با متن فعلی است.[۱] آنها همچنین ممکن است از یک مونوlith به خوبی ساختار یافته در زندگی یک استارت آپ حمایت کنند و بعدا انتقال به میکروسرویس ها را به عنوان نیازهای مقیاسی هدایت کنند؛ آنها همچنین اصول معماری اصلی را اجرا می کنند: جداسازی نگرانی ها، شل، انسجام بالا و وابستگی در منابع خارجی مانند [FLT] مفاهیم اساسی برای استفاده از این مقاله های کاربردی مهندسی فنی، اما خرد در مورد بحث های کاربردی در مورد بحث های کاربردی مهندسی مکانیک فنی و کارآمد است.
تصمیمات تکنولوژی Stack
انتخاب فن آوری ها - برنامه نویسی زبان ها، پایگاه های داده، سیستم های پیام رسانی، خدمات ابر - منطقه دیگری است که مهندسان اصلی نفوذ اندازه ای دارند.این انتخاب ها به ندرت در مورد آن ابزار به طور عینی "بهترین" است؛ در عوض، آنها شامل ارزیابی عوامل مانند آشنایی تیمی، بلوغ، حمایت جامعه، مجوز، هزینه و حفظ طولانی مدت است. - یک مهندس ارشد باید تمام شیوه های استخدام جدید را در برابر محدودیت های ناشناخته یا محدودیت های ناشناخته ایجاد کند.
به عنوان مثال، انتخاب یک فروشگاه سند NoSQL بر روی یک پایگاه داده ارتباطی ممکن است سرعت توسعه دهندگان را برای طرح های انعطاف پذیر بهبود بخشد، اما یکپارچگی و گزارش پیچیده، یک مهندس ارشد معماران و تیم ها را از طریق فرآیندهای تصمیم گیری ساختار یافته هدایت می کند، اغلب با استفاده از سوابق تصمیم گیری معماری (ADRs) برای مستندسازی منطق، آنها همچنین محافظان را ایجاد می کنند - مانند لیست های فن آوری تایید شده یا بررسی های طراحی اجباری - جلوگیری از بارگیری مجدد سیستم عامل و تسریع در برابر چند زبانه های مکانیکی که باعث افزایش اصطکاک های فنی و تخریب می شود.
نگرانی های ناشی از صلیب
معماری فقط در مورد تجزیه و تحلیل عملکردی نیست؛ باید الزامات غیر عملکردی (NFRs) را که در کل سیستم قطع می شود، امنیت، عملکرد، دسترسی و بهره وری هزینه نگرانی های اولیه است، مهندسان اصلی اطمینان حاصل کنند که این ها پس از هرج و مرج نیستند، آنها شیوه هایی مانند دفاع در عمق، سرعت، شکستن مدارها و تخریب ظریف را پشتیبانی می کنند، زمانی که برای الگوهای مناسب و ظرفیت بارگذاری، مقاومت می کنند، زمانی که آنها می توانند شیوه های مهندسی را تأیید کنند و سیستم های بارگذاری کنند.
رهبری در این فضا اغلب شامل نوشتن استانداردها، بررسی طرح ها برای انطباق و اجرای حوادث گذشته است که به بهبود معماری واکنش می دهد. کتاب Google SRE بسیاری از این اصول را بیان می کند و مهندسان اصلی کسانی هستند که آنها را با زمینه های سازمانی خود سازگار می کنند.
تصمیم گیری های طراحی در هر سطح
فراتر از معماری سطح بالا، مهندسان اصلی بر تصمیمات طراحی دقیق تأثیر می گذارند که تعیین می کنند که معماری در کد چقدر خوب است.این شامل قراردادها، مدل های داده، استراتژی های مدیریت خطا، روش های تست و الگوهای استقرار است.در حالی که تیم های فردی تصمیم های طراحی روزانه را می گیرند، مهندس اصلی چارچوب را فراهم می کند و اغلب اسناد طراحی انتقادی را بررسی می کند یا در بررسی کد برای اجزای اصلی شرکت می کند.
طراحی API و Interface
بد طراحی شده API باعث مشکلات کاتتر بندی: اتصال سخت، بازنویسی گران قیمت و ادغام های دشوار. مهندسین اصلی تعریف قراردادها برای رابط های RESTful یا gRPC، استراتژی های نسخه برداری و فرمت های پاسخ خطا که آنها برای الگوهای سازگار فشار می آورند تا مصرف کنندگان بتوانند رفتار را پیش بینی کنند.به عنوان مثال، آنها ممکن است دستور دهند که همه API ها به اشتباهات ساختاری با کدهای ماشین آلات و کدهای قابل خواندن بازگردند که همه جهش های احتمالی در آن سیستم های نظم و انضباط را به سرعت تقسیم می کنند.
مدل سازی داده ها و ذخیره سازی
داده ها خون حیاتی اکثر سیستم ها هستند و مهندسان اصلی تصمیم می گیرند که تصمیمات مدل داده های کلیدی را تصویب یا تایید کنند، آنها در مورد عادی سازی در مقابل غیر عادی سازی، استراتژی های کلیدی اولیه، برنامه های فهرست بندی و مدیریت چرخه عمر داده ها، همچنین توصیه می کنند که معاملات و یا دسترسی به طور معمول، اغلب به موضوع CAP یا مدل PACELC اشاره می کنند.
قابلیت اطمینان و تحمل خطا
طراحی برای شکست یک ویژگی مهندسی بالغ است. مهندسین اصلی از الگوهایی مانند retries با backoff نمایی، timeouts، فله ها و جبران معاملات حمایت می کنند.آنها پذیرش چک های بهداشتی، شکستن مدار و خاموش کردن های ظریف را در اطراف استراتژی های استقرار - استقرار سبز آبی، می توانند آزاد، پرچم های ویژگی - به طور مستقیم توانایی سیستم انعطاف پذیری و بازیابی سریع تیم از خطاهای بازیابی.
تعادل نوآوری و بدهی فنی
یک چالش اولیه برای مهندسان اصلی مدیریت بدهی فنی در حالی که نوآوری را قادر می سازد، آنها باید تصمیم بگیرند که چه زمانی برای پذیرش ناکارآمدی های کوتاه مدت برای سرعت و زمانی که برای سرمایه گذاری در بازسازی مجدد برای جلوگیری از رکود طولانی مدت نیاز به درک عمیق از نقشه راه های محصول، ظرفیت تیم و هزینه واقعی از پیچیدگی.
مهندسان اصلی اغلب ابتکارات را برای پرداخت بدهی هدایت می کنند: مهاجرت از چارچوب های میراث، تقسیم یکنواختات، بهبود پوشش آزمون، یا خودکارسازی خط لوله استقرار، آنها همچنین اضافه های جدید را به سیستم نگه می دارند، اطمینان حاصل می کنند که هر ویژگی یا خدمات جدید توسط ارزش کسب و کار توجیه شده است و پیچیدگی های غیر ضروری را اضافه نمی کند.
مهم تر از آن، آنها همچنین یک فرهنگ مهندسی را پرورش می دهند که نوآوری در آن ایمن است.با سرمایه گذاری در شیوه های تست خوب، ادغام مداوم و بی ثباتی، آنها تیم ها را قادر می سازد تا بدون شکستن تولید، آزمایش کنند و پروژه های اثبات مفهوم برای فن آوری های جدید را پشتیبانی کنند و فضا را برای هکت ها یا اسپرینت ها ایجاد کنند.این رویکرد متعادل مانع از رکود و هرج و آشوب می شود، ایجاد سازمان انعطاف پذیر و سازگار کردن.
نتیجه گیری
تاثیر مهندسان اصلی بر معماری نرم افزار و تصمیم گیری های طراحی نمی تواند بیش از حد مشخص شود.آنها مباشر از دید فنی هستند، اطمینان حاصل می کنند که سیستم ها بر پایه های جامد ساخته شده اند در حالی که سازگار با الزامات در حال تغییر هستند، نفوذ آنها در هر انتخاب معماری نفوذ می کند - از الگوی بیش از حد به قرارداد API ریز- و هدایت آنها در نگرانی های متقابل مانند اطمینان، امنیت و جلوگیری از قطع هزینه و جلوگیری از جبران هزینه های اضافی.
سازمان هایی که در پرورش مهندسان قوی و توانمند سازی آنها با قدرت تصمیم گیری واقعی سرمایه گذاری می کنند، سرعت مهندسی بالاتر، نرخ حوادث پایین تر و تحویل قابل پیش بینی تر را می بینند؛ این افراد اختیاری نیستند؛ آنها یک عامل موفقیت حیاتی برای هر شرکت مبتنی بر تکنولوژی هستند که مایل به ساخت سیستم های نرم افزاری قوی، مقیاس پذیر و طولانی مدت با درک و استفاده از نقش منحصر به فرد خود هستند، تیم های نمودار مشترک می توانند از یک دوره عالی فنی پایدار جلوگیری کنند.
برای مطالعه بیشتر در مورد معماری و طراحی بهترین شیوه هایی که مهندسان اصلی اغلب از آن ها دفاع می کنند، به نوشته های معماری تمیز توسط رابرت C. Martin و چارچوب معماری ابر گوگل اشاره کنید که الگوهای عملی برای سیستم های مقیاس سازمانی ارائه می دهد.