۱۰ اصل برنامه‌نویسی ساده که همه برنامه‌نویس‌ها باید رعایت کنند!
1398/01/17 16:23 , میلاد صاحب نظر

۱۰ اصل برنامه‌نویسی ساده که همه برنامه‌نویس‌ها باید رعایت کنند!

هر کسی می‌تواند کد بزند. اما کد خوب چطور؟ اینجا است که کار مشکل می‌شود.

همه ما داستان‌های وحشتناکی در مورد کدهای اسپاگتی، زنجیرهای if-else تو در تو و گسترده، برنامه‌هایی که با تغییر دادن تنها یک متغیر کلا به هم می‌ریزند، توابعی که به نظر مبهم می‌رسند و از این قبیل موارد شنیده‌ایم. وقتی فقط با گذراندن یک ترم دانشگاه سعی می‌کنید یک برنامه سر همی بنویسید این اتفاقی است که می‌افتد.

نباید هدفتان فقط نوشتن کدی باشد که اجرا شود. بلکه هدف شما باید نوشتن کدی باشد که قابل بررسی و نگهداری باشد – بررسی و نگهداری نه تنها به وسیله خودتان، بلکه توسط هر شخص دیگری که ممکن است لازم باشد در آینده با نرم‌افزار شما کار کند. به همین دلیل، ما چند اصل معرفی می‌کنیم که به شما در نوشتن کدهای تمیز و منظم کمک می‌کنند.

  1. ساده و راحت بودن

اصل "ساده و راحت بودن" در تمام زندگی به درد می‌خورد، اما این اصل به خصوص برای پروژه‌های برنامه‌نویسی متوسط تا بزرگ نیز صدق می‌کند.

این اصل از ابتدای کار، یعنی در زمانی که قصد دارید دامنه و وسعت برنامه‌ای که می‌خواهید بنویسید را مشخص کنید آغاز می‌شود. فقط چون علاقه شدیدی به توسعه بازی دارید، به این معنا نیست که حتما می‌توانید دنیای بعدی Warcraft یا call of duty را به وجود آورید.

هر وقتی چیزی به نظرتان ساده آمد، آن را یک مرحله ساده‌تر کنید – به هر حال بدون شک در آینده به خطاها و اشکالات عجیب و غریب بر خواهید خورد، پس کار را ساده انجام دهید.

ساده و راحت بودن کد

ساده و راحت بودن کد

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

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

  1. کار تکراری نکنید

اصل "انجام ندادن کار تکراری" برای نوشتن کد مرتب و ساده یک امر حیاتی است. وقتی کد می‌نویسید، مسلما دوست ندارید داده‌ها و منطق‌های مختلف را بارها تکرار کنید. اگر در کدتان یک قطعه کد را بارها و بارها تکرار کرده‌اید، پس این اصل را رعایت نکرده‌اید.

اصل مقابل و مخالف اصل "انجام ندادن کار تکراری"، اصل "دو بار نوشتن هر چیزی" است(یا به قول معروف اصل "وقت همه را تلف کردن"). یکی از بهترین روش‌ها برای تشخیص کدهای نوشته شده با اصل"دو بار نوشتن هر چیزی"، این است که از خودتان بپرسید: برای اینکه بخواهید رفتار برنامه را به نوعی تغییر دهید، چند قسمت از کد خود را باید اصلاح کنید؟

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

در صفحه علاقه‌مندی‌ها نیز باز همان کد را دارید. بهترین کار این است که همه آن‌ها را درون یک تابع به صورت چکیده قرار دهید تا اگر بعدا لازم شد آن قطعه کد را تغییر دهید، فقط لازم باشد همین یک تابع را فقط در یک قسمت از کد تغییر دهید.

  1. باز / بسته

چه در حال نوشتن اشیاء در جاوا باشید چه در حال نوشتن ماژول‌ها در پایتون، به هر حال باید کد خود را به روی افزونه‌ها باز  به روی اصلاح کلی برنامه بسته نگه دارید. این اصل برای همه انواع پروژه‌ها کاربرد دارد، اما زمانی خیلی اهمیت دارد که یک کتابخانه یا فریمورک (که برای استفاده دیگران طراحی شده است) منتشر می‌کنید.

برای مثال، فرض کنید می‌خواهید یک فریمورک GUI منتشر کنید. می‌توانید آن را همین‌طور که هست منتشر کنید و انتظار داشته باشید که کاربران نهایی مستقیما کد شما را اصلاح کرده و تغییر دهند.

اما وقتی ۴ ماه بعد یک آپدیت کامل برای آن عرضه کردید، آن موقع چه اتفاقی می‌افتد؟ کاربران چگونه می‌توانند همه آن اضافات را بدون نابود کردن کل کاری که شما انجام داده‌اید به برنامه اضافه کنند؟

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

ثبات بیشتر برنامه (کاربر نمی‌تواند تصادفا رفتار اصلی برنامه را نقض کند) و قابلیت رسیدگی و نگهداری بهتر (کاربران فقط باید نگران کدهای اضافی باشند). اصل باز / بسته برای ایجاد یک API خوب، مهم و کلیدی است.

  1. ترکیب بندی مهم‌تر از ارث‌بری

اصل "ترکیب‌بندی مهم‌تر از ارث‌بری" بیان می‌کند که اشیاء دارای رفتارهای پیچیده باید کار خود را با استفاده از نمونه‌های(instanceها)اشیاء که دارای رفتار مخصوص به خود هستند انجام دهند، نه با ارث‌بری از یک کلاس و افزودن رفتارهای جدید.

اعتماد بیش از حد به ارث‌بری می‌تواند باعث بروز دو مشکل اصلی و اساسی شود. اول، سلسله مراتب ارث‌بری ممکن است در یک چشم به هم زدن شلوغ و بی‌نظم شود. دوم، شما انعطاف‌پذیری کمتری برای تعریف رفتارهای خاص دارید، به خصوص وقتی می‌خواهید رفتار را از یک شعبه ارث‌بری در یک شعبه دیگر پیاده‌سازی کنید:

ترکیب بندی مهم‌تر از ارث‌بری

ترکیب بندی مهم‌تر از ارث‌بری

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

  1. تک مسئولیتی

اصل تک مسئولیتی بیان می‌کند که هر کلاس یا ماژول در یک برنامه فقط باید یک کارایی داشته باشد. یعنی هر کلاس فقط باید یک دلیل برای تغییر یافتن داشته باشد.

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

  1. مجزا سازی نگرانی‌ها

اصل مجزا سازی نگرانی‌ها همانند اصل تک مسئولیتی است، اما خیلی چکیده و محدود تر. در اصل، یک برنامه باید به گونه‌ای طراحی شده باشد که دارای کپسوله‌سازی‌های غیر همپوشانی مختلف و زیادی باشند و این کپسوله‌سازی‌ها نباید از وجود همدیگر آگاه باشند.

یک مثال معروف از این اصل، مدل پارادایم (model – view – controller(MVC است،که یک برنامه را به سه قسمت مجزا تقسیم می‌کند: داده (model)، منطق (controller) و چیزی که کاربر نهایی می‌بیند (view). تفاوت‌های MVC در فریمورک‌های وب مرسوم امروزی عادی هستند.

مجزاسازی مشکلات

مجزاسازی مشکلات

برای مثال، کدی که بارگذاری و ذخیره داده‌ها درون یک پایگاه داده را کنترل می‌کند، لازم نیست بداند که چگونه آن داده روی وب رندر می‌شود. کد رندرینگ ممکن است کاربر نهایی یک ورودی بگیرد، اما بعد آن ورودی را به یک کد منطقی برای پردازش انتقال می‌دهد. هر بخش خودش را کنترل می‌کند.

این امر منجر به کد ماژولار می‌شود، که باعث می‌شود نگهداری و اصلاح کد ساده‌تر شود. و در آینده، اگر زمانی لازم شد همه کد رندرینگ را بازنویسی کنید، می‌توانید این کار را بدون نگرانی در مورد چگونگی ذخیره شدن داده‌ها یا پردازش منطق انجام دهید.

  1. شاید هیچ‌وقت نیاز پیدا نکنید

اصل "شاید هیچ‌وقت نیاز پیدا نکنید" بیان می‌کند که شما هیچ‌گاه نباید برای کارایی که ممکن است در آینده نیاز داشته باشید، کدی را جلو جلو بنویسید. احتمال دارد که اصلا به آن کد نیاز پیدا نکنید و نوشتن آن فقط وقت شما را هدر دهد – و فقط این نیست، بلکه همچنین می‌تواند پیچیدگی کد شما را افزایش دهد.

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

گاهی برنامه‌نویسان بی‌تجربه سعی می‌کنند کوتاه‌ترین و کلی‌ترین کد ممکن را بنویسند تا از کدهای "همه چیز را دو بار بنویس" پرهیز کنند، اما اگر کد بیش از حد چکیده و کوتاه باشد، در نهایت به یک کد خیلی نامفهوم و غیر ممکن برای تغییر تبدیل می‌شود.

نکته این جا است که اصل "کار تکراری نکنید" را فقط در صورت نیاز به کار ببرید. اگر متوجه شدید چند قطعه کد بارها و بارها نوشته شده‌اند، پس آن‌ها را چکیده کنید – اما اگر فقط حدس می‌زنید یا فکر می‌کنید که یک قطعه کد ممکن است بارها تکرار شود، هیچ‌وقت از این اصل استفاده نکنید. اکثر مواقع کد تکرار نمی‌شود.

  1. از بهینه‌سازی زودرس و نابهنگام خودداری کنید

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

در حالی گه، این اصل به این امر اشاره می‌کند که قبل از به وجود آمدن ضرورت، به الگوریتم‌ها سرعت دهید.

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

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

ابتدا به سادگی هر چه تمام‌تر به حد نصاب‌های خود برسید، سپس کد خود را بررسی کنید تا بتوانید تنگنا‌های حقیقی آن را بیابید.

  1. اصلاح، اصلاح، اصلاح

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

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

بررسی و اصلاح کد

بررسی و اصلاح کد

مجموعه کدهای برنامه دائم در حال تغییر و تحول هستند. اینکه بارها کد را مرور کنید، بازنویسی کنید یا حتی کل کد را از اول طراحی مجدد کنید یک امر کاملا طبیعی است.

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

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

  1. کد منظم مهم‌تر از کد هوشمندانه است

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

حقیقت این است، هوش شما برای هیچ‌کس اهمیتی ندارد.

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

برنامه‌نویسان خوب و کد خوانا و مرتب رابطه مستقیم با یکدیگر دارند. هر جا لازم بود کامنت بگذارید. به راهنماها و سبک کد نویسی مشخص شده پایبند باشید، خواه این راهنماها و سبک‌ها توسط یک زبان مانند پایتون مشخص شده باشند، خواه توسط یک شرکت مانند گوگل.

از عبارات خاص هر زبان برای همان زبان استفاده کنید و هیچ‌وقت سعی نکنید در محیط پایتون با جاوا یا برعکس کد بنویسید.

چه چیزی از شما یک برنامه‌نویس خوب می‌سازد؟

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

منبع: makeuseof

 مطالب مرتبط

 ۴ برنامه‌نویس معروف که کدهای موفقیت زندگیشان را نوشتند
7 دلیل منطقی برای آموختن #C
 طبقه بندی زبان های برنامه نویسی
با یادگیری چگونگی تمرکز بر کارها، می‌توانید بهتر کد بنویسید
 LINQ(زبان جستجوی یکپارچه)
برنامه نویسی شیءگرا چیست؟

از آخرین دوره های آموزشی و تخفیف ها مطلع شوید

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

آخرین مطالب

آموزش جامع SQL Server (جلسه ۱۲)
آموزش جامع SQL Server (جلسه ۱۲)

دستور UPDATE در SQL Server برای تغییر داده‌های موجود در یک جدول، از دستور UPDATE به شکل زیر استفاده ...

آموزش جامع SQL Server (جلسه ۱۵)
آموزش جامع SQL Server (جلسه ۱۵)

دستور DROP TABLE در SQL Server گاهی، لازم است یک جدول که دیگر استفاده‌ای ندارد را حذف کنید. برای ...

آموزش جامع SQL Server (جلسه ۳۵: Window Functionها – بخش ۲)
آموزش جامع SQL Server (جلسه ۳۵: Window Functionها – بخش ۲)

بخش اول از آخرین مبحث دوره جامع آموزش SQL Server در جلسه قبلی بررسی شد. این مبحث که ...

آخرین دیدگاه ها

دیدگاه خود را درباره این پست بنویسید

فرم ارسال نظرات