www.dntips.ir
مطالب
نویسندگان
گروه‌های مطالب
نقشه‌های راه
دوره‌ها
اشتراک‌ها
پرسش‌ها
عنوان:

‫آیا معیار یا چک لیستی برای میزان استاندارد بودن یک نرم‌افزار وجود دارد؟


نویسنده: هادی مزارعی
تاریخ: ۱۴۰۴/۱۰/۰۹ ۰۸:۳۷
آدرس: www.dntips.ir
آیا عبارتی تحت عنوان "این برنامه استاندارد است" در برنامه‌نویسی وجود دارد؟
  1. اگر دسترسی به منابع می‌بایست مطابق با یکسری الزامات (Authorization و Authentication) صورت پذیرد آیا صرفا بکارگیری پکیج‌های استاندارد بیانگر این معیار است؟ یا پیاده‌سازی بصورت سفارشی و بدون پکیج هم می‌تواند استاندارد باشد؟
  2. ممکن است در یک برنامه به منظور نگاشت اطلاعات از AutoMapper استفاده کنیم و در برنامه دیگر برنامه‌نویس تمام این کار را خودش پیاده کرده باشد. آیا این کار در استانداردسازی برنامه تاثیر دارد.
  3. یا مثلا فرض کنیم بجای پیاده سازی یک متد Generic برای جمع دو عدد (انواع عدد) در برنامه به تعداد نوع‌های عددی (Numeric Types) متد بنویسیم. یکی برای int، یکی برای decimal و...
  4. آیا عملکرد (Performance) و هزینه‌های سخت‌افزاری در تعیین استاندراد بودن برنامه نقش دارند؟
  5. و سایر موارد مانند الگوهای طراحی (Design Patterns)، معماری (Architecture) و...
مطالب مشابه

نظرات

  • وحید نصیری در ۱۴۰۴/۱۰/۰۹ ۱۵:۰۵
    عبارت "این برنامه استاندارد است" یک مفهوم کلی و نسبیه و مستقیماً به یک استاندارد رسمی یا پروتکل خاص اشاره نداره، بلکه بیشتر به معنای پیروی از بهترین شیوه‌ها (best practices)، اصول مهندسی نرم‌افزار، و استانداردهای پذیرفته‌شده در جامعه توسعه‌دهندگانه. استاندارد بودن یک برنامه می‌تواند بر اساس معیارهایی مانند خوانایی کد، قابلیت نگهداری، امنیت، کارایی، مقیاس‌پذیری، و رعایت الگوهای طراحی ارزیابی شود. سازمان‌هایی مانند ISO (مانند ISO/IEC 25010 برای کیفیت نرم‌افزار) یا استانداردهای زبان‌های خاص (مانند PEP 8 برای پایتون یا Java Coding Standards) وجود دارند، اما در عمل، "استاندارد" اغلب به معنای "بهینه و حرفه‌ای" است و بسته به زمینه (وب، موبایل، سیستم‌های توزیع‌شده) متفاوت است.

    دسترسی به منابع با الزامات Authorization و Authentication:
    • صرف استفاده از پکیج‌های استاندارد (مانند OAuth2، JWT در .NET یا Spring Security در جاوا) بیانگر رعایت استاندارد نیست، اما کمک‌کننده است زیرا این پکیج‌ها معمولاً بر اساس اصول امنیتی شناخته‌شده (مانند OWASP Top 10) ساخته شده‌اند و تست‌شده هستند. پیاده‌سازی سفارشی بدون پکیج هم می‌تواند کاملاً استاندارد باشد، به شرطی که اصول امنیتی را رعایت کند: مثلاً استفاده از hashing امن برای رمزها، جلوگیری از injection attacks، و مدیریت sessionها به درستی. نکته کلیدی، نتیجه نهایی است؛ نه ابزار استفاده‌شده.

    استفاده از AutoMapper در مقابل پیاده‌سازی دستی نگاشت اطلاعات:
    • این کار تأثیر مستقیمی بر استانداردسازی ندارد، اما می‌تواند بر کیفیت کلی برنامه اثر بگذارد. AutoMapper (یا ابزارهای مشابه مانند MapStruct در جاوا) یک رویکرد استاندارد و کارآمد برای mappingها است که کد را تمیزتر و کمتر تکراری (DRY principle) نگه می‌دارد. پیاده‌سازی دستی اگر خوب طراحی شده باشد (مثلاً با متدهای ژنریک و تست‌شده)، می‌تواند استاندارد باشد و حتی در مواردی که نیاز به کنترل دقیق‌تر دارید، ترجیح داده شود. اما اگر دستی باشد و منجر به کد پیچیده، تکراری یا پرخطا شود، برنامه کمتر استاندارد تلقی می‌شود. در نهایت، استاندارد بودن به خوانایی، قابلیت تست، و عدم وابستگی بیش از حد به کد سفارشی بستگی دارد؛ نه لزوماً به ابزار.

    پیاده‌سازی متدهای جداگانه برای انواع عددی به جای متد ژنریک:
    • این رویکرد معمولاً استاندارد نیست، زیرا اصل DRY (Don't Repeat Yourself) را نقض می‌کند و کد را غیربهینه و سخت‌تر برای نگهداری می‌سازد. یک متد ژنریک در زبان‌هایی مانند C# یا جاوا، استانداردتر است زیرا انعطاف‌پذیرتر و کمتر تکراری است. نوشتن متدهای جداگانه برای int، decimal، float و غیره، تنها اگر دلیل خاصی وجود داشته باشد (مثل بهینه‌سازی عملکرد در موارد خاص یا محدودیت‌های پلتفرم) قابل قبول است، اما در حالت کلی، آن را غیراستاندارد می‌کند زیرا کد را bloated (حجیم) می‌کند و احتمال خطا را افزایش می‌دهد.

    نقش عملکرد (Performance) و هزینه‌های سخت‌افزاری در استاندارد بودن:
    • بله، عملکرد و هزینه‌های سخت‌افزاری نقش مهمی دارند، اما نه به عنوان معیار اصلی. استاندارد بودن بیشتر به طراحی اولیه مربوط است (مثل انتخاب الگوریتم‌های بهینه O(n) به جای O(n²))، اما اگر برنامه‌ای عملکرد ضعیفی داشته باشد (مثل مصرف بیش از حد RAM یا CPU بدون دلیل)، حتی اگر کد تمیز باشد، استاندارد تلقی نمی‌شود. مثلاً در سیستم‌های بزرگ، رعایت اصول مانند caching، lazy loading، و بهینه‌سازی queryهای دیتابیس بخشی از استاندارد است. هزینه‌های سخت‌افزاری هم مرتبط است: یک برنامه استاندارد باید مقیاس‌پذیر باشد تا بدون نیاز به سخت‌افزار گران، کار کند. اما این معیارها نسبی هستند؛ مثلاً یک اپ ساده موبایل نیاز به عملکرد بالا ندارد، در حالی که یک سیستم توزیع‌شده باید.

    سایر موارد مانند الگوهای طراحی (Design Patterns)، معماری (Architecture) و غیره:
    • این‌ها از مهم‌ترین عوامل استانداردسازی هستند. الگوهای طراحی مانند Singleton، Factory، Observer یا MVC کمک می‌کنند کد ساختارمند و قابل گسترش باشد. معماری (مانند Microservices، Monolith، یا Clean Architecture) باید با نیاز پروژه همخوانی داشته باشد. مثلاً استفاده از Microservices برای یک اپ کوچک، غیراستاندارد است زیرا پیچیدگی غیرضروری اضافه می‌کند. موارد دیگر شامل:
    • تستینگ: استفاده از unit tests، integration tests (با ابزارهایی مثل JUnit یا xUnit) ضروری است.
    • مدیریت وابستگی‌ها: استفاده از ابزارهایی مثل NuGet، Maven یا npm برای جلوگیری از vendor lock-in.
    • امنیت و logging: رعایت استانداردهایی مثل GDPR برای داده‌ها و استفاده از loggerهای استاندارد (مانند Serilog).
    • کدینگ استایل: پیروی از کنوانسیون‌های زبان (مثل camelCase در جاوااسکریپت).
    • CI/CD: ادغام با ابزارهایی مثل GitHub Actions برای deployment خودکار.

    در کل، استاندارد بودن به تعادل بین این عوامل بستگی دارد و اغلب با ابزارهایی مثل SonarQube یا Code Reviews ارزیابی می‌شود. اگر پروژه‌ای این اصول را رعایت کند، "استاندارد" است، حتی اگر از ابزارهای سفارشی استفاده کند.