loading...

برنامه نویسی ایرانی

بازدید : 107
جمعه 30 مهر 1400 زمان : 13:05

از تکثیر منطق با انتزاع جلوگیری می شود

انواع مختلفی از تکرار منطقی وجود دارد. به عنوان مثال، اگر قسمت if-then یا switch به سادگی کپی و پیست شود، پیدا کردن و حذف آن بسیار آسان خواهد بود. بسیاری از الگوهای طراحی به وضوح با هدف کاهش یا حذف موارد تکراری در برنامه هستند. اگر شرایطی که برای استفاده اصول کدنویسی از یک شی باید رعایت کنید تقریباً همیشه یکسان است، می توانید از الگوی Abstract Factory یا الگوی Factory Method استفاده کنید. اگر انواع مختلفی از رفتار شی وجود دارد، به جای نوشتن یک if-then طولانی، از الگوی Strategy استفاده کنید. در واقع می توان گفت الگوی طراحی به گونه ای ایجاد شده است که بارها و بارها در مورد راه حل مشکلات مشابه فکر نکنیم. اصل DRY همچنین برای ساختارهایی مانند طرحواره های پایگاه داده اعمال می شود. این منجر به به اصطلاح "عادی سازی" می شود.

اصول مرتبط

چندین اصل دیگر مربوط به توسعه نرم افزار وجود دارد که به اصل DRY مربوط می شود. اصل OAOO (یک بار و فقط یک بار: 1 درجه) یکی از آنهاست. این یک اصل است که فقط در مورد عملکرد و رفتار کد اعمال می شود و می توان آن را به عنوان تخصص اصل DRY در نظر گرفت. همچنین یک OCP (اصل باز / بسته) وجود دارد. این بدان معنی است که واحدهای برنامه مانند کلاس ها باید برای برنامه های افزودنی "باز" و برعکس برای تغییرات "بستن" باشند. این اصل تنها در صورتی معتبر است که اصل DRY رعایت شود. همچنین یک دین معروف به نام SRP (اصل مسئولیت واحد) وجود دارد. این بر این اصل استوار است که نباید بیش از یک دلیل برای تغییر در یک کلاس وجود داشته باشد (همیشه باید یک دلیل برای تغییر وجود داشته باشد)، و تنها در صورتی که اصل DRY همچنان به آن پایبند باشد معتبر است.

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

وظیفه اصلی پیش روی برنامه نویس ، نوشتن کد با کیفیت و اشکالات کمی در آن است. را

محدودیت اضافی نوشتن سریع کد است. نوشتن کد منبع مهارتی است که فقط می تواند باشد

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

1.اشتباهات رایج کدنویسی

خطاهای نرم افزار (ما از اصطلاحات خطاها، نقص ها و اشکالات به طور قابل تغییر در خود استفاده خواهیم کرد

بحث در اینجا؛ تعاریف دقیق در فصل بعدی ارائه شده است) واقعیتی است که همه می توانند از آن استفاده کنند

برنامه نویسان باید با تلاش زیادی در توسعه نرم افزار صرف اصول کدنویسی شناسایی می شود

و رفع اشکالات روش های مختلفی وجود دارد که می تواند بروز باگ ها را کاهش دهد، اما

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

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

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

اغلب در زبان‌هایی که جمع‌آوری خودکار زباله ندارند (مانند C، C++). آنها در برنامه های کوتاه تأثیر کمی دارند ، اما می توانند تأثیرات فاجعه باری دراصول کدنویسی طولانی مدت داشته قواعد کدنویسی باشند سیستم های.

برچسب ها اصول کدنویسی ,
بازدید : 98
جمعه 30 مهر 1400 زمان : 13:02

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

چه زمانی از TFP یا TDD استفاده می کنید؟

TFP یا TDD به ایجاد نرم افزار قوی و کاهش هزینه های نگهداری کمک می کند. این اصل یا الگوی توسعه ممکن است در شرایط خاصی قابل اجرا نباشد. به عنوان مثال ، استفاده از TFP یا TDD می تواند بسیار مشکل باشد در صورتی که تعداد زیادی مورد آزمایشی برای پشتیبان گیری از کد قدیمی ندارید. علاوه بر این، نرم افزار عملیاتی عظیم ممکن است ارزش پذیرش TFP یا TDD را نداشته باشد.

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

نمایندگان در بسیاری از شرایط بسیار مفید هستند! یکی از آنها پشتیبانی مستقیم از اصول باز-بستن (OCP) است. OCP به این معنی است که نرم افزار برای توسعه باز است اما برای تغییرات بسته است. به عنوان مثال، فرض کنید یک استاد قرار است یک نوع مقاله جدید مانند یک گزارش نمره دهد. اگر gradePaper تابعی است که در Professor پیاده سازی شده است، برای گسترش این قابلیت جدید، باید gradePaper را مستقیماً تغییر دهید. با این حال، می‌توانید از یک delegate برای ایجاد یک کلاس گزارش نمره اصول کدنویسی جدید که مطابق با TestDelegate است استفاده کنید و آن نماینده را به عنوان متغیری برای مدیریت منطق آن به کلاس استاد منتقل کنید. بنابراین نیازی به تغییر خود کلاس نیست.

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

Delegate برای فراخوانی روش انعطاف پذیر مفید است. فرض کنید کلاس شما باید یکی از 100 تابع را فراخوانی کند. این به این معنی است که کلاس باید 100 متد را پیاده سازی کند. با این حال ، اگر از نماینده استفاده می کنید ، باید نماینده مناسب کلاس را برای تماس با روش صحیح در هر زمان ارائه دهید.

نتیجه

اصول و الگوهای مختلف طراحی کمتر شناخته شده را با دقت بخوانید. انتظار داشته باشید که این اصول در نرم افزار شما اعمال شود! به سلامتی:) تکرار بی فایده است

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

به طور خودکار از تکرار کار جلوگیری کنید

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

برچسب ها اصول کدنویسی ,

تعداد صفحات : -1

درباره ما
موضوعات
آمار سایت
  • کل مطالب : 319
  • کل نظرات : 0
  • افراد آنلاین : 1
  • تعداد اعضا : 0
  • بازدید امروز : 93
  • بازدید کننده امروز : 1
  • باردید دیروز : 145
  • بازدید کننده دیروز : 0
  • گوگل امروز : 0
  • گوگل دیروز : 0
  • بازدید هفته : 1435
  • بازدید ماه : 2838
  • بازدید سال : 9933
  • بازدید کلی : 37444
  • <
    پیوندهای روزانه
    اطلاعات کاربری
    نام کاربری :
    رمز عبور :
  • فراموشی رمز عبور؟
  • خبر نامه


    معرفی وبلاگ به یک دوست


    ایمیل شما :

    ایمیل دوست شما :



    کدهای اختصاصی