چگونه کدبهتر و خوانا تر بنویسیم ؟

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

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

فرقی نمی کند که مبتدی باشید یا یک برنامه نویس باتجربه، همیشه باید سعی کنید یک برنامه نویس خوب شوید (نه فقط یک برنامه نویس…). به یاد داشته باشید که شما مسئول کیفیت کد خود هستید، بنابراین برنامه خود را به اندازه کافی خوب کنید تا سایر توسعه دهندگان بتوانند درک کنند و هر بار برای درک کدهای نامرتب که در پروژه خود نوشته اید، شما را مسخره نکنند.

چه چیزی یک کد تمیز را ایجاد می کند؟ قبل از اینکه در مورد هنر نوشتن کد تمیز و بهتر صحبت کنیم، اجازه دهید برخی از ویژگی های آن را ببینیم…

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

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

-Grady Booch (نویسنده تحلیل و طراحی شی گرا با کاربردها)

چگونه کدی تمیز بنویسیم ؟

• از نام های معنی دار استفاده کنید

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

$a = 10; //number of users

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

• اصل مسئولیت واحد (SRP)

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

• آنها باید کوچک باشند.
• آنها باید فقط یک کار را انجام دهند و آن را به خوبی انجام دهند.

دو نکته بالا به وضوح اشاره می کند که عملکرد شما باید از اصل مسئولیت واحد پیروی کند. یعنی نباید ساختار تودرتو داشته باشد یا نباید بیش از دو سطح تورفتگی داشته باشد. پیروی از این تکنیک کد شما را بسیار خواناتر می کند و اگر عملکرد شما وظیفه خاصی را انجام دهد، سایر توسعه دهندگان به راحتی می توانند ویژگی دیگری را درک یا پیاده سازی کنند. همچنین مطمئن شوید که تابع شما نباید بیش از سه آرگومان داشته باشد. آرگومان های بیشتر وظایف بیشتری را انجام می دهند، بنابراین سعی کنید آرگومان ها را تا حد امکان کمتر نگه دارید. ارسال بیش از سه آرگومان کد شما را گیج‌کننده می‌کند و در صورت وجود مشکل، اشکال‌زدایی آن بسیار بزرگ و سخت است. اگر تابع شما دستور try/catch/finally دارد، یک تابع مجزا ایجاد کنید که فقط شامل دستورات try-catch-finally باشد. مراقب نام تابع خود نیز باشید. از یک نام توصیفی برای تابع خود استفاده کنید که باید به وضوح مشخص کند که چه کاری انجام می دهد. مانند:

function subtract($x, $y) {
    return$ x - $y;
}

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

• از نوشتن نظرات غیر ضروری خودداری کنید

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

Good code is its own best documentation. As you’re about to add a comment, ask yourself, “How can I improve the code so that this comment isn’t needed?” Improve the code and then document it to make it even clearer.

• کد خواندنی برای مردم بنویسید

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

// Bad Code
class CarouselRightArrow extends Component{render(){return ( <a href="#" className="carousel__arrow carousel__arrow--left" onClick={this.props.onClick}> <span className="fa fa-2x fa-angle-left"/> </a> );}};
  
// Good Code
class CarouselRightArrow extends Component {
  render() {
    return (
      <a
        href="#"
        className="carousel__arrow carousel__arrow--left"
        onClick={this.props.onClick}
      >
        <span className="fa fa-2x fa-angle-left" />
      </a>
    );
  }
};

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

• تست های واحد را بنویسید

آزمون واحد نوشتن در توسعه بسیار مهم است. کد شما را تمیز، انعطاف پذیر و قابل نگهداری می کند. ایجاد تغییرات در کد و کاهش باگ ها آسان تر می شود. فرآیندی در توسعه نرم‌افزار وجود دارد که به نام Test Driven Development (TDD) نامیده می‌شود که در آن نیازمندی‌ها به چند مورد آزمایشی خاص تبدیل می‌شوند و سپس نرم‌افزار برای گذراندن تست‌های جدید بهبود می‌یابد. به گفته رابرت سی مارتین (عمو باب)، سه قانون TDD نشان می دهد…

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

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

• مراقب وابستگی ها باشید

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

• پروژه خود را به خوبی سازماندهی کنید

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

نظر شما چیست ؟ با ما در نظرات در میان بگذارید.