در ابتدا درک یک پروژه بزرگ و قدیمی همیشه دشوار است. معماری یکی از فعالیت های ارزیابی معمار است. معمولاً باید با پروژه های بزرگ و قدیمی کار کنید و نتایج باید در عرض یک هفته تحویل داده شود.
چگونه می توان پروژه ای با 100 هزار خط کد یا بیشتر را در یک هفته ارزیابی کرد و در عین حال نتایجی را ارائه داد که واقعاً برای مشتری مفید است.
اکثر معماران و رهبران فنی با ارزیابی های پروژه مشابهی مواجه شده اند. این ممکن است مانند یک فرآیند نیمه رسمی یا به عنوان یک سرویس جداگانه به نظر برسد همانطور که در شرکت ما انجام می شود، به هر نحوی که اکثر شما با این کار برخورد کرده اید.
نسخه اصلی به زبان انگلیسی برای دوستان غیر روسی شما اینجا است: .
رویکرد شرکت ما
من به شما خواهم گفت که در شرکت ما چگونه کار می کند و در شرایط مشابه چگونه عمل می کنم، اما شما به راحتی می توانید این رویکرد را با توجه به نیاز پروژه و شرکت خود تغییر دهید.
دو نوع ارزیابی معماری وجود دارد.
داخلی - ما معمولاً این کار را برای پروژه های درون شرکت انجام می دهیم. هر پروژه ممکن است به چند دلیل درخواست ارزیابی معماری کند:
- تیم فکر می کند پروژه آنها کامل است و این مشکوک است. ما چنین مواردی داشته ایم و اغلب در چنین پروژه هایی همه چیز با ایده آل فاصله دارد.
- تیم می خواهد پروژه و راه حل های خود را آزمایش کند.
- تیم می داند که اوضاع بد است. آنها حتی ممکن است مشکلات و علل اصلی را لیست کنند، اما لیست کاملی از مشکلات و توصیه هایی برای بهبود پروژه می خواهند.
خارجی فرآیندی رسمی تر از ارزیابی داخلی است. مشتری همیشه فقط در یک مورد می آید، زمانی که همه چیز بد است - بسیار بد. معمولا مشتری متوجه می شود که مشکلات جهانی وجود دارد، اما نمی تواند به درستی علل را شناسایی کند و آنها را به اجزاء تقسیم کند.
ارزیابی یک معماری برای یک مشتری خارجی مورد پیچیده تری است. روند باید رسمی تر باشد. پروژه ها همیشه بزرگ و قدیمی هستند. آنها مشکلات، باگ ها و کدهای اشتباه زیادی دارند. گزارشی از کار انجام شده حداکثر ظرف چند هفته باید آماده شود که شامل مشکلات اصلی و توصیه هایی برای بهبود باشد. بنابراین، اگر به ارزیابی خارجی پروژه بپردازیم، ارزیابی داخلی یک تکه خواهد بود. بیایید سخت ترین مورد را در نظر بگیریم.
ارزیابی معماری پروژه سازمانی
یک پروژه معمولی برای ارزیابی یک پروژه بزرگ، قدیمی و سازمانی با مشکلات زیادی است. مشتری نزد ما می آید و از ما می خواهد که پروژه اش را تعمیر کنیم. مانند یک کوه یخ است، مشتری فقط نوک مشکلات خود را می بیند و هیچ ایده ای در زیر آب (در اعماق کد) ندارد.
مشکلاتی که مشتری ممکن است از آنها شکایت کند و ممکن است از آنها آگاه باشد:
- مسائل مربوط به عملکرد
- مشکلات قابلیت استفاده
- استقرار طولانی مدت
- نبود واحد و سایر آزمایشات
مشکلاتی که مشتری به احتمال زیاد از آنها آگاه نیست، اما ممکن است در پروژه وجود داشته باشد:
- مشکلات ایمنی
- مشکلات طراحی
- معماری اشتباه
- خطاهای الگوریتمی
- فناوری های نامناسب
- بدهی فنی
- روند توسعه اشتباه
فرآیند بررسی معماری رسمی
این یک فرآیند رسمی است که ما به عنوان یک شرکت دنبال می کنیم، اما شما می توانید بسته به شرکت و پروژه خود آن را سفارشی کنید.
درخواست از مشتری
مشتری می خواهد معماری پروژه فعلی را ارزیابی کند. مسئول طرف ما اطلاعات اولیه پروژه را جمع آوری کرده و کارشناسان لازم را انتخاب می کند. بسته به پروژه، اینها ممکن است متخصصان مختلفی باشند.
راه حل معمار - مسئول اصلی ارزیابی و هماهنگی (و اغلب تنها).
کارشناسان خاص را جمع کنید – دات نت، جاوا، پایتون و سایر متخصصان فنی بسته به پروژه و فناوری
کارشناسان ابر - اینها می توانند معماران ابری Azure، GCP یا AWS باشند.
شالوده – DevOps، مدیر سیستم و غیره
سایر کارشناسان – مانند کلان داده، یادگیری ماشین، مهندس عملکرد، کارشناس امنیت، سرب QA.
جمع آوری اطلاعات در مورد پروژه
شما باید تا حد امکان اطلاعات پروژه را جمع آوری کنید. بسته به شرایط می توانید از تکنیک های مختلفی استفاده کنید:
- پرسشنامه و روش های دیگر ارتباط از طریق پست. بی اثرترین راه.
- جلسات آنلاین
- ابزارهای ویژه برای تبادل اطلاعات مانند: Google doc، Confluence، مخازن و غیره.
- جلسات "زنده" در سایت. موثرترین و پرهزینه ترین راه.
چه چیزی باید از مشتری دریافت کنید؟
اطلاعات اولیه. پروژه در مورد چیست؟ هدف و ارزش آن. اهداف و برنامه های اصلی برای آینده. اهداف و استراتژی های کسب و کار. مشکلات اصلی و نتایج مطلوب.
اطلاعات پروژه. پشته فناوری، چارچوب ها، زبان های برنامه نویسی. استقرار در محل یا ابر. اگر پروژه در فضای ابری است، از چه خدماتی استفاده می شود. از چه الگوهای معماری و طراحی استفاده شده است.
الزامات غیر کاربردی. کلیه الزامات مربوط به عملکرد، در دسترس بودن و سهولت استفاده از سیستم. الزامات ایمنی و غیره
موارد استفاده اساسی و جریان داده ها.
دسترسی به کد منبع. مهمترین قسمت! شما قطعا باید به مخازن و اسناد نحوه ساخت پروژه دسترسی داشته باشید.
دسترسی به زیرساخت. خوب است که برای کار با سیستم زنده به صحنه یا زیرساخت تولید دسترسی داشته باشید. اگر مشتری ابزارهایی برای نظارت بر زیرساخت و عملکرد داشته باشد، موفقیت بزرگی است. در قسمت بعدی در مورد این ابزار صحبت خواهیم کرد.
اسناد. اگر مشتری مدارک داشته باشد، این شروع خوبی است. ممکن است قدیمی باشد، اما هنوز شروع خوبی است. هرگز به اسناد اعتماد نکنید - آن را با مشتری، در زیرساخت واقعی و در کد منبع آزمایش کنید.
فرآیند ارزیابی معماری
چگونه می توان چنین حجم وسیعی از اطلاعات را در مدت زمان کوتاهی پردازش کرد؟ اول از همه کار را موازی کنید.
DevOps باید به زیرساخت نگاه کند. منجر فنی به کد. مهندس عملکرد برای مشاهده معیارهای عملکرد. یک متخصص پایگاه داده باید در ساختارهای داده عمیق تر کند.
اما این یک مورد ایده آل است زمانی که شما منابع زیادی دارید. به طور معمول، یک تا سه نفر یک پروژه را ارزیابی می کنند. شما حتی می توانید تخمین را خودتان انجام دهید، که اغلب در صورت داشتن دانش و تجربه مناسب در تمام زمینه های پروژه، چنین است. در این مورد، شما باید تمام فرآیندها را تا حد امکان خودکار کنید.
متأسفانه، شما باید اسناد را به صورت دستی بخوانید. با تجربه مناسب، می توانید به سرعت کیفیت اسناد را درک کنید. چه چیزی درست است و چه چیزی به وضوح با واقعیت منطبق نیست. گاهی اوقات ممکن است معماری را در اسناد مشاهده کنید که هرگز در زندگی واقعی کارساز نخواهد بود. این یک محرک برای شما است که در مورد چگونگی انجام آن در پروژه در واقعیت فکر کنید.
ابزارهای مفید برای ارزیابی خودکار پروژه
ارزیابی کد یک تمرین ساده است. می توانید از تحلیلگرهای کد استاتیک استفاده کنید که مسائل مربوط به طراحی، عملکرد و امنیت را به شما نشان می دهد. در اینجا تعداد کمی از آنها هستند:
یک ابزار عالی برای یک معمار است. این تصویر بزرگ، وابستگی‌های بین ماژول‌ها و مناطق بالقوه برای بازسازی را به شما نشان می‌دهد. مانند همه ابزارهای خوب، هزینه خوبی دارد، اما می توانید از نسخه آزمایشی 30 روزه استفاده کنید.
- یک ابزار خوب قدیمی ابزاری برای تحلیل کدهای استاتیک به شما امکان می دهد کدهای بد، اشکالات و مشکلات امنیتی را برای بیش از 20 زبان برنامه نویسی شناسایی کنید.
همه ارائه دهندگان ابر دارای ابزارهای نظارت بر زیرساخت هستند. این به شما این امکان را می دهد که اثربخشی زیرساخت خود را از نظر هزینه و عملکرد به درستی ارزیابی کنید. برای AWS این است . برای Azure آسان است .
نظارت و ثبت عملکرد اضافی به یافتن مشکلات عملکرد در همه سطوح کمک می کند. شروع از پایگاه داده با پرس و جوهای بی اثر، backend و پایان دادن به frontend. حتی اگر مشتری قبلاً این ابزارها را نصب نکرده باشد، می توانید آنها را به سرعت در سیستم موجود ادغام کنید تا مشکلات عملکرد را شناسایی کنید.
مثل همیشه، ابزارهای خوب ارزشش را دارند. من می توانم چند ابزار پولی را توصیه کنم. البته می توانید از منبع باز استفاده کنید اما زمان بیشتری از شما می گیرد. و این باید از قبل انجام شود، نه در طول فرآیند ارزیابی معماری.
- ابزاری برای ارزیابی عملکرد برنامه
– سرویس نظارت بر سیستم ابری
ابزارهای زیادی برای تست امنیت وجود دارد. این بار یک ابزار رایگان اسکن سیستم را به شما توصیه می کنم.
– ابزاری برای اسکن برنامه های کاربردی وب برای انطباق با استانداردهای امنیتی.
بیایید همه چیز را در یک کل جمع کنیم.
تهیه گزارش
گزارش خود را با داده هایی که از مشتری جمع آوری کرده اید شروع کنید. اهداف پروژه، محدودیت ها، الزامات غیرعملکردی را شرح دهید. پس از این، تمام داده های ورودی باید ذکر شود: کد منبع، اسناد، زیرساخت.
گام بعدی. هر مشکلی را که به صورت دستی یا با استفاده از ابزارهای خودکار پیدا کردید فهرست کنید. گزارش های بزرگ تولید شده به صورت خودکار را در انتها در بخش برنامه ها قرار دهید. باید شواهد کوتاه و مختصری از مشکلات یافت شده وجود داشته باشد.
مشکلات موجود در مقیاس خطا، هشدار، اطلاعات را اولویت بندی کنید. شما می توانید مقیاس خود را انتخاب کنید، اما این مقیاس پذیرفته شده است.
به عنوان یک معمار واقعی، وظیفه شما ارائه توصیه هایی برای اصلاح مشکلات یافت شده است. بهبودها و ارزش تجاری که مشتری دریافت خواهد کرد را شرح دهید. چگونه ارزش کسب و کار را از قبلا بحث کردیم
یک نقشه راه با تکرارهای کوچک تهیه کنید. هر تکرار باید شامل زمان تکمیل، توضیحات، مقدار منابع مورد نیاز برای بهبود، ارزش فنی و ارزش تجاری باشد.
ما ارزیابی معماری را تکمیل می کنیم و گزارشی را به کارفرما ارائه می دهیم
هرگز فقط یک گزارش پست نکنید. ممکن است اصلا خوانده نشود یا بدون توضیح مناسب خوانده و درک نشود. به طور خلاصه، ارتباط زنده به رفع سوء تفاهم بین افراد کمک می کند. شما باید یک جلسه با مشتری برنامه ریزی کنید و در مورد مشکلات پیدا شده صحبت کنید و روی مهم ترین آنها تمرکز کنید. توجه مشتری به مشکلاتی که ممکن است حتی از آنها بی اطلاع باشد، ارزش دارد. مانند مسائل امنیتی و توضیح اینکه چگونه می توانند بر تجارت تأثیر بگذارند. نقشه راه خود را با بهبودها نشان دهید و در مورد گزینه های مختلفی که برای مشتری مناسب تر است صحبت کنید. این می تواند زمان، منابع، مقدار کار باشد.
به عنوان خلاصه ای از جلسه خود، گزارش خود را برای مشتری ارسال کنید.
در نتیجه
ارزیابی معماری یک فرآیند پیچیده است. برای انجام صحیح ارزیابی باید تجربه و دانش کافی داشته باشید.
می توان تنها در یک هفته نتایج مفیدی برای مشتری و کسب و کارش ارائه کرد. حتی اگر به تنهایی این کار را انجام دهید.
بر اساس تجربه من، بسیاری از بهبودها در وسط دانلود شدند و گاهی اوقات هرگز شروع نشدند. کسانی که میانگین طلایی را برای خود انتخاب کردند و تنها بخشی از بهبودهایی را که برای کسب و کار مفید بود با حداقل هزینه کار انجام دادند، به طور قابل توجهی کیفیت محصول خود را بهبود دادند. کسانی که هیچ کاری انجام ندادند می توانستند بعد از چند سال پروژه را به طور کامل ببندند.
هدف شما این است که حداکثر پیشرفت ها را با حداقل قیمت به مشتری نشان دهید.
مقالات دیگر از بخش می توانید در اوقات فراغت خود بخوانید
برای شما کد تمیز و تصمیمات معماری خوب آرزو می کنم.
گروه فیسبوک ما - .
منبع: www.habr.com