ویرگول
ورودثبت نام
Mohsen Rajabi
Mohsen Rajabi
خواندن ۷ دقیقه·۱ سال پیش

چگونه پروژه Net. را در سال 2023 شروع کنیم

در این مقاله در مورد معماری پروژه صحبت نمی کنیم. این مقاله بدون توجه به معماری پروژه شما است. (معماری تمیز، برش عمودی، Nlayer، معماری شش ضلعی و…).

در این مقاله، بهترین روش ها و ابزارها برای شروع یک پروژه net. در سال 2023 را مورد بحث قرار می دهیم. همچنین یاد می گیریم که چگونه از ابزارها و تحلیلگرها برای بهبود کد استفاده کنیم.

  • استفاده از best practice ها
  • استفاده از آخرین ویژگی ها زبان و ابزار ها
  • رعایت اصول Clean Code
  • یکسان سازی دست خط برنامه نویس ها
  • بهبود کد
  • چک کردن کیفیت کد و پیدا کردن باگ
  • چک کردن مشکلات امنیتی کد

آیا تا به حال فکر کرده اید که پروژه ای مانند AspCore در GitHub بیش از 1100 توسعه دهنده دارد، چگونه مدیریت می شود؟ چگونه دست خط یکسان است؟ بررسی کد چگونه انجام می شود؟ best practice ها یا موارد بهینه سازی چگونه مشاهده می شود؟

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

این مقاله تجربه شخصی من در تیم های بزرگ نرم افزاری و مقالات متعدد است.

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

تجربه من نشان داده است که وقتی از این ابزارها استفاده می کنید.

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

به مثال های زیر توجه کنید:

  • چگونه می توانیم بررسی کنیم که کدی که نوشته ایم پیچیدگی دارد؟
  • چگونه می توانیم Smell Code را در داخل کد پیدا کنیم؟
  • چگونه متوجه می شویم که شرایط بسیار متفاوتی در داخل متد وجود دارد (به دلیل وجود سوئیچ های if و مختلف)؟

همه موارد فوق را با چشم و خطای انسانی می توانیم درک کنیم. اگر به طور خودکار همه موارد بالا را بفهمیم و حتی به کد اجازه ندهیم چه می شود?

خب بریم سر کار

ابتدا ساختار فایل های ما باید اینگونه باشد

فایل Directory.Build.props

ابتدا در مورد Directory.Build.props صحبت خواهیم کرد.

در این فایل تنظیمات کل پروژه را مشخص می کنیم.

  • از چه نسخه ای از آنالایزر استفاده می کنیم؟
  • در این تنظیمات مشخص می کنیم که برنامه روی کدام نسخه از SDK تنظیم شود
  • تنظیمات آنالایزر
  • تنظیمات آنالایزرهای شخص ثالث

فایل زیر بر اساس تجربه من در تیم ها و پروژه های بزرگ است. در دنیای تحلیلگرها، اینها بهترین هستند.

https://gist.github.com/EngRajabi/c33855cfa41e555ec0303458a8c62fe5

انجام تمام تنظیمات در این مقاله یک کار طولانی و دشوار است. در اینجا در مورد برخی تنظیمات صحبت خواهیم کرد.

  • LangVersion: این ویژگی نسخه زبان سی شارپ را که روی آخرین نسخه تنظیم شده است را مشخص می کند
  • AnalysisLevel: این ویژگی نسخه تحلیلگر را مشخص می کند. که روی آخرین نسخه تنظیم شده است. جزئیات بیشتر
  • TreatWarningsAsErrors و CodeAnalysisTreatWarningsAsErrors: فعال کردن این 2 ویژگی باعث می شود که Warnings در حالت Error نمایش داده شود بنابراین باید آنها را برطرف کنیم.
  • RunAnalyzerDuringBuild: این ویژگی باعث می شود که آنالیز در حین build اجرا شود
  • RunAnalyzersDuringLiveAnalysis: این ویژگی باعث می شود که آنالیز در حین کدنویسی اجرا شود.
  • EnforceCodeStyleInBuild: این ویژگی باعث می شود که خطاهای Code Style به عنوان Error اضافه شوند.
  • ManagePackageVersionsCentrally: این ویژگی برای مدیریت بسته ها در سطح جهانی استفاده می شود. جزئیات بیشتر
  • Nullable: این ویژگی قابلیت Nullable را فعال می کند. جزئیات بیشتر
  • NoWarn و NoError: برای تنظیم خطاهایی که می خواهیم نادیده بگیریم.
  • ReportAnalyzer: این ویژگی گزارش تحلیلگر را فعال می کند
  • AnalysisMode: این ویژگی تنظیمات تحلیلگر .net را مشخص می کند که همه در اینجا فعال هستند. جزئیات بیشتر
  • Features: این ویژگی به کامپایلر می گوید که دقیق تر عمل کند. جزئیات بیشتر
  • EnableNETAnalyzers: این ویژگی آنالایزرهای .net را فعال می کند.

در <!-- third-party analyzers --> ما شروع به اضافه کردن تحلیلگرهای شخص ثالث کردیم. این آنالایزرها به همراه net. به ما کمک می کنند تا کد بهتری داشته باشیم. در مورد معرفی آنالایزرها می توانید لینک nuget آنها را بررسی کنید.

  • Microsoft.CodeAnalysis.NetAnalyzers: این تحلیلگر به صورت پیش فرض در SDK موجود است. اما اگر نیاز به استفاده از آخرین نسخه آن دارید، این بسته را نصب کنید. به همین دلیل است که ما این بسته را نصب می کنیم.
  • Microsoft.VisualStudio.Threading.Analyzers: این تحلیلگر مایکروسافت است که با خطاها و مشکلات Threading سروکار دارد.
  • Microsoft.CodeAnalysis.BannedApiAnalyzers: این تحلیلگر به ما کمک می کند تا استفاده از یک سری کدها را منسوخ اعلام کنیم. مانند استفاده از DateTimeOffset.UtcDateTime به جای DateTimeOffset.DateTime. این تنظیمات را در فایل BannedSymbols.txt قرار می دهیم
  • سری تحلیلگرهای Roslynator: این آنالایزرها یک سری نقش های مفید را به پروژه اضافه می کنند.
  • SonarAnalyzer.CSharp: این آنالایزر بسیار محبوب SonarQube است که بسیار مفید است.
  • Meziantou.Analyzer: این تحلیلگر توسط Meziantou که یکی از توسعه دهندگان مایکروسافت است نوشته شده است.
  • SecurityCodeScan.VS2019: این تحلیلگر برای بررسی های امنیتی است

فایل .editorconfig

می توانید تنظیماتی را در این فایل قرار دهید که در IDE بررسی می شود.

ما یک سری تحلیلگر را در بالا تعریف کردیم. ما می توانیم برخی از تنظیمات آنها را با این فایل تغییر دهیم.

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

فایل زیر بر اساس تجربه من و تقلید از پروژه های بزرگ مانند AspCore است. همچنین CodeMetrice به آن اضافه شده است که پیچیدگی کد را محاسبه می کند و در صورت بالا بودن پیچیدگی خطا ایجاد می کند.

پیشنهاد میکنم از این فایل استفاده کنید

https://gist.github.com/EngRajabi/63779b0d02eea78ce220ff7a49e5a068

فایل Directory.Packages.props

در این فایل ما بسته های nuget را مدیریت می کنیم.

https://gist.github.com/EngRajabi/f1a44483dd54915e1544e16afa9de15d

فایل BannedSymbols.txt

در این فایل می توانیم یک سری ویژگی های net. را به صورت غیرمجاز تعریف کنیم. این مانع از استفاده برنامه نویسان می شود.

https://gist.github.com/EngRajabi/e66e1d16042e434d122dfe14c0bdae01

فایل .gitignore

در این فایل مواردی را که نیازی به اضافه شدن به source controle ندارند را مشخص می کنیم. این فایل حاوی best practice ها است.

https://gist.github.com/EngRajabi/9ce5f603c2c0f72da60a5251785346d8

فایل global.json

در این فایل ما SDK پروژه را پیکربندی می کنیم. با این تنظیمات، ما مشخص می کنیم که پروژه ما از کدام نسخه SDK استفاده می کند و شما مجاز به ساخت با کدام نسخه هستید.

https://gist.github.com/EngRajabi/966e06b758be47f75af93c2371df387e

فایل nuget.config

در این فایل مشخص می کنیم که از کدام repo برای بسته ها استفاده کنیم. در سازمان های بزرگ آدرس repo شرکت در اینجا مشخص می شود. اگر مخزن خاصی ندارید، به این فایل نیازی نیست.

https://gist.github.com/EngRajabi/5183e95fc65e04272cd8e9f9e3845041

فایل AssemblyInfo.cs

در این فایل تنظیمات CLS را مشخص می کنیم.

https://gist.github.com/EngRajabi/a314fb17ca48e3855c3a4f84ffa7381e




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

تجربه به من ثابت کرده است. اکثر آنالیزهایی که به برنامه نویسان اعلام می شد جدید بود و آنها از آن اطلاعی نداشتند و این تحلیل ها باعث یادگیری آنها شد.

با رشد تیم و افزایش تعداد افراد، این تنظیمات بهره وری کار را تا حد زیادی افزایش می دهد و کیفیت کار را بهبود می بخشد.

این تحلیل ها در سیستم هر برنامه نویس شروع به کار می کنند. اگر برنامه نویسی موارد خطا را مدیریت نکند، پروژه Build نخواهد شد. اگر کد خود را commit کند، در فرآیند CICD هنگام Build پروژه، تمام آنالیزها انجام می شود و باعث می شود CICD با خطا مواجه شود. و نیاز به اصلاح دارد.

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

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

زمانی که من سرپرست Backend شرکت SadadPSP بودم، تعداد برنامه نویسان دات نت 15 نفر بیشتر بود. من همیشه نگران نگهداری کد بوده ام.

من همیشه مسئول بالا بردن کیفیت کد، حفظ دستخط کد پروژه و استفاده از ابزارهایی برای بهبود کار بودم.

این مقاله حاصل تجربیات من در ابتدا در شرکت SadadPsp و اکنون در کارگذاری مفید است. امیدوارم استفاده کرده باشید.

لطفا با دوستان خود به اشتراک بگذارید

best practiceپروژهclean codeبررسی کدبرنامه نویس
Web Developer
شاید از این پست‌ها خوشتان بیاید