یادگیری ماشین (ML) ، که بسیاری از صنایع را بهبود بخشیده است ، به تازگی شروع به تست نرم افزارها میکند. این صنعت دیگر هرگز مانند گذشته نخواهد بود. در حالی که یادگیری ماشین هنوز در حال رشد و تکامل است ، صنعت نرم افزار بیشتر و بیشتر از آن استفاده میکند ، و تأثیر آن شروع به تغییر قابل توجهی در روش آزمایش نرم افزار با پیشرفت فناوری میکند. ..
نصب Rust
Cargo چیست و چه کاربردی دارد؟
Cargo همراه با زبان برنامه نویسی Rust گنجانده شده، همزمان نصب میشود و برای ایجاد، ساخت و مدیریت پروژههای Rust استفاده میگردد. این یک رابط سطح بالا برای کار با کدهای Rust را ارائه میدهد که شروع به کار با Rust و مدیریت پروژههای خود را برای توسعه دهندگان آسانتر میکند.
Cargo سیستم ساخت و package manager مخصوص زبان برنامه نویسی Rust است. ابزاری است که به توسعه دهندگان Rust کمک میکند تا پروژههای خود را با خودکارسازی کارهایی مانند کامپایل کد، مدیریت وابستگیها، اجرای آزمایشها و ایجاد بستههای قابل توزیع، مدیریت کنند.
برخی از ویژگیهای Cargo
Dependency management: برنامه Cargo میتواند بهطور خودکار وابستگیهای پروژههای Rust را دانلود کرده، بسازد و مدیریت کند. این باعث میشود توسعه دهندگان به راحتی کتابخانهها و ماژولهای جدیدی را به پروژههای خود اضافه کنند.
Building and testing: برنامه Cargo میتواند پروژههای Rust را بسازد و testها را به صورت خودکار اجرا کند. همچنین گزینههایی را برای ساختن ساختهای بهینه یا اشکال زدایی فراهم میکند.
Packaging: برنامه Cargo میتواند بستههای قابل توزیعی را مانند tarballs یا بستههای باینری را برای پروژههای Rust ایجاد کند.
Customization: برنامه Cargo به توسعه دهندگان اجازه میدهد تا فرآیند ساخت برنامهی خود را با تعیین گزینههای ساخت مختلف، در فایل پیکربندی Cargo.toml سفارشی کنند. بهطور کلی Cargo توسعه و مدیریت پروژههای Rust را با ارائه یک ابزار کارآمد برای خودکارسازی بسیاری از وظایف توسعه رایج، ساده میکند.
هنگامیکه یک پروژهی جدید Rust را با استفاده از نام پروژهی مورد نظر ایجاد میکنید، یک دایرکتوری با نام داده شده، حاوی فایلها و دایرکتوریهای زیر ایجاد میگردد:
Cargo.toml : این فایل manifest پروژه است که در آن نام پروژه، نسخه، وابستگیها و سایر ابردادهها را مشخص میکنید. فایل Cargo.toml حاوی یک metadata درباره پروژه است؛ مانند نام، نسخه، نویسندگان و وابستگیهای آن. در اینجا مثالی از شکل ظاهری یک فایل Cargo.toml آورده شده است:
بخش [package] حاوی یک metadata در مورد خود پروژه، از جمله نام، نسخه، نویسندگان و جزئیات دیگر است.
بخش [dependencies] وابستگیهای پروژه را فهرست میکند. در این مثال، پروژه به پکیجهای serde و serde_json بستگی دارد که برای serialization و deserialization دادهها استفاده میشوند.
src directory: این دایرکتوری حاوی کد منبع پروژه شما است. به طور پیش فرض، شامل یک فایل main.rs است که نقطه ورود برنامه شما است.
target directory: این فهرست شامل فایلهای باینری کامپایل شده تولید شده توسط کامپایلر Rust میباشد.
هنگامی که cargo build یا cargo run را اجرا میکنید، Cargo به طور خودکار یک دایرکتوری target/debug را برای ذخیرهی فایلهای باینری کامپایل شده ایجاد میکند. اگر cargo build --release را اجرا کنید، Cargo بجای آن، یک دایرکتوری target/release را ایجاد میکند. بعلاوه، اگر هنگام ایجاد پروژهی خود از نسخهی خاصی از Rust (مانند نسخهی 2018) استفاده کنید، Cargo یک فیلد نسخه را در فایل Cargo.toml شما برای تعیین نسخه، اضافه میکند.
برای نصب rust، متناسب با سیستم عامل خود، ابتدا وارد سایت rustup شوید و فایل دانلود متناسب با سیستم عامل مورد نظرتان را دانلود و نصب کنید.
Cargo چیست و چه کاربردی دارد؟
Cargo همراه با زبان برنامه نویسی Rust گنجانده شده، همزمان نصب میشود و برای ایجاد، ساخت و مدیریت پروژههای Rust استفاده میگردد. این یک رابط سطح بالا برای کار با کدهای Rust را ارائه میدهد که شروع به کار با Rust و مدیریت پروژههای خود را برای توسعه دهندگان آسانتر میکند.
Cargo سیستم ساخت و package manager مخصوص زبان برنامه نویسی Rust است. ابزاری است که به توسعه دهندگان Rust کمک میکند تا پروژههای خود را با خودکارسازی کارهایی مانند کامپایل کد، مدیریت وابستگیها، اجرای آزمایشها و ایجاد بستههای قابل توزیع، مدیریت کنند.
Dependency management: برنامه Cargo میتواند بهطور خودکار وابستگیهای پروژههای Rust را دانلود کرده، بسازد و مدیریت کند. این باعث میشود توسعه دهندگان به راحتی کتابخانهها و ماژولهای جدیدی را به پروژههای خود اضافه کنند.
Building and testing: برنامه Cargo میتواند پروژههای Rust را بسازد و testها را به صورت خودکار اجرا کند. همچنین گزینههایی را برای ساختن ساختهای بهینه یا اشکال زدایی فراهم میکند.
Packaging: برنامه Cargo میتواند بستههای قابل توزیعی را مانند tarballs یا بستههای باینری را برای پروژههای Rust ایجاد کند.
Customization: برنامه Cargo به توسعه دهندگان اجازه میدهد تا فرآیند ساخت برنامهی خود را با تعیین گزینههای ساخت مختلف، در فایل پیکربندی Cargo.toml سفارشی کنند. بهطور کلی Cargo توسعه و مدیریت پروژههای Rust را با ارائه یک ابزار کارآمد برای خودکارسازی بسیاری از وظایف توسعه رایج، ساده میکند.
ایجاد اولین پروژهی Rust
بعد از نصب rust برای ایجاد یک پروژه جدید، terminal سیستم عامل را باز کنید و دستور زیر را در آن وارد کنید:
cargo new project_name
Cargo.toml : این فایل manifest پروژه است که در آن نام پروژه، نسخه، وابستگیها و سایر ابردادهها را مشخص میکنید. فایل Cargo.toml حاوی یک metadata درباره پروژه است؛ مانند نام، نسخه، نویسندگان و وابستگیهای آن. در اینجا مثالی از شکل ظاهری یک فایل Cargo.toml آورده شده است:
[package] name = "my-project" version = "0.1.0" authors = ["John Doe <johndoe@example.com>"] [dependencies] serde = "1.0" serde_json = "1.0"
بخش [dependencies] وابستگیهای پروژه را فهرست میکند. در این مثال، پروژه به پکیجهای serde و serde_json بستگی دارد که برای serialization و deserialization دادهها استفاده میشوند.
src directory: این دایرکتوری حاوی کد منبع پروژه شما است. به طور پیش فرض، شامل یک فایل main.rs است که نقطه ورود برنامه شما است.
target directory: این فهرست شامل فایلهای باینری کامپایل شده تولید شده توسط کامپایلر Rust میباشد.
هنگامی که cargo build یا cargo run را اجرا میکنید، Cargo به طور خودکار یک دایرکتوری target/debug را برای ذخیرهی فایلهای باینری کامپایل شده ایجاد میکند. اگر cargo build --release را اجرا کنید، Cargo بجای آن، یک دایرکتوری target/release را ایجاد میکند. بعلاوه، اگر هنگام ایجاد پروژهی خود از نسخهی خاصی از Rust (مانند نسخهی 2018) استفاده کنید، Cargo یک فیلد نسخه را در فایل Cargo.toml شما برای تعیین نسخه، اضافه میکند.
معرفی :
Svelte یک رویکرد جدید برای ایجاد رابط کاربری است که به ما کمک میکند صفحاتی پویا به صورت SPA با کارآیی و کیفیت بالا و همچنین کمترین حجم کد تولید کنیم. تفاوت اصلی svelte با رقبای سنتی خود مانند vue - React - angular این است که Svelte تنها یک فریم ورک نیست، بلکه درواقع یک کامپایلر است که همین موضوع سبب شده توجه زیادی را اخیرا به خود جلب کند. در فریم ورکهای سنتی، تمام عملیات در browser انجام میشود یا بهتر است بگوییم در run-time؛ ولی svelte تمام این عملیات را زمان build شدن برنامه شما انجام میدهد و کد جاوا اسکریپتی بدون هیچ وابستگی به هیچ پکیجی تولید میکند. نکته دیگری که باید به آن اشاره کنم این است که برخلاف سایر فریم ورکها، svelte از virtual DOM استفاده نمیکند! در بخشهای بعد در مورد virtual DOM و معایب آن بیشتر صحبت خواهیم کرد.
مقایسه مختصر فریم ورکهای معتبر :
مقایسههایی که در ادامه قصد دارم به اشتراک بگذارم، بر مبنای سه بخش Performance - size - lines of code است که به صورت مختصر با هم بررسی خواهیم کرد و کاری با جزئیات این مقایسه نداریم؛ چرا که هدف از نشان دادن این مقایسه صرفا این است که شاید برای ما سوال شود چرا باید یا بهتر است به این فریم ورک اهمیت بدهیم.
- Performance : کارآیی - که در ارتباط با مدت زمان پاسخ گویی و قابل استفاده شدن برنامه میباشد. (مقایسه به درصد - هرچه بیشتر عملکرد بهتر)
در مقایسه اول، اکثر فریم ورکها، امتیازی بالای 90 درصد دارند که در واقع نشان دهنده این است شما از هرکدام از این موارد استفاده کنید، چندان تفاوتی را احساس نخواهید کرد.
با توجه به اینکه svelte به نسبت بقیه این فریم ورکها که خیلی از آنها کاملا جا افتاده هستند، بسیار جدید است و جای بهبود دارد از نظر performance عملکرد قابل قبولی از خود نشان داده است.
- Size : اندازه - که نشان دهنده حجم نهایی فایلهای تولید شده ( Css-Html-JavaScript ) فریم ورک است. این مقایسه اندازه فریم ورک و تمام وابستگیهای آن است که به bundle نهایی برنامه اضافه شده است (هر چه اندازه فایل کمتر باشد بهتر است چراکه توسط کاربر نهایی زودتر دانلود میشود).
در مقایسه size یکی از دلایل محبوبیت این کامپایلر را مشاهده میکنید که تفاوت قابل توجهی نسبت به سایر فریم ورکها دارد.
- Lines of Code : تعداد خطوط کد - نشان دهنده این است که یک نویسنده بر اساس این فریم ورکها چند سطر کد را باید برای تهیهی یک برنامهی جدید بنویسد.
نکته دیگری که باید اینجا بهش اشاره کنم، ساده بودن svelte است. این سادگی سبب میشود میزان کدنویسی برای ساخت یک برنامه به مراتب کمتر از فریم ورکهای دیگر باشد. که در نتیجه بازدهی استفاده از آن را بالاتر خواهد برد.
برای کسب اطلاعات بیشتر و مطالعه منبع این مقایسه میتوانید به این لینک مراجعه نمایید.
نتیجه گیری : ( مزایا - معایب )
درمورد مزایای استفاده از svelte میتوان به راحتی کارکردن با آن، حجم بسیار کم کدهای نهایی برنامه و عملکرد مناسب آن و همینطور استفاده نکردن از virtualDom اشاره کرد؛ چرا که برای اولین بار کدهای تولید شده به معنای واقعی واکنش گرا خواهند بود.
هرچند معایبی هم شاید داشته باشد که قبل از هر چیز بهتر است به آنها اشاره کنم. بزرگترین و شاید تنها ایرادی که من میتوانم از این فناوری بگیرم این است که خالق این تکنولوژی یک نفر است! angular توسط شرکت google توسعه داده میشود. react توسط فیسبوک توسعه داده میشود. vue درست است که شرکت بزرگی آن را توسعه نمیدهد ولی نتیجه یک کار تیمی و چند صد نفر برنامه نویس مختلف است که به صورت open source به توسعه آن میپردازند. شاید این تنها نکته منفی باشد که اعتماد به این تکنولوژی را سخت کرده است.
دانلود و نصب :
پیش نیاز :
قبل از هرچیز برای نصب Svelte به Node.Js نیاز داریم. قبل از شروع کار، از نصب بودن آن اطمینان حاصل نمایید.
ساخت اولین برنامه :
npx degit sveltejs/template my-svelte-project cd my-svelte-project npm install npm run dev
البته با استفاده از اسکریپت dev، کدهای ما برای زمان برنامه نویسی بهینه شدهاند و چندان برای پابلیش و استفاده مناسب نیستند؛ لذا برای تولید کدهای مناسب برای محصول نهایی میتوانیم از دستور npm run build استفاده کنیم.
در بخش بعد به بررسی ساختار فایلها و کدهای ایجاد شده Svelte میپردازیم.
اشتراکها
سایت rssheap
Automated Code Test
با توجه به فاکتورهای موجود در Defensive Coding، یکی از مواردی که کیفیت کد شما را تضمین خواهد کرد، استفاده کردن از (ACT) Automated Code Test میباشد. در این قسمت قصد داریم مزایای تست اتوماتیک و Unit Test را به عنوان یکی دیگر از ابعاد Defensive Coding ذکر کنیم.
به عنوان برنامه نویسی که در حال توسعه کد هستید و قابلیتهای جدیدی را به کد خود اضافه میکنید، باید کدی را که در آن تغییر ایجاد میکنید، مرتب تست کنید، تا بررسی کنید که آیا به هدف خود رسیدهاید و توانستهاید قابلیت جدیدی را در نرم افزار اضافه کنید. روشی که توسط اکثر برنامه نویسان انجام میشود به این صورت است که بهصورت متوالی برنامه را اجرا میکنند، اجرا میکنند، اجرا میکنند و باز هم اجرا میکنند، تا اینکه مطمئن شوند همه چیز درست است. بیشتر زمانیکه در این فرآیند صرف میشود، صرف کارهای تکراری میشود. این مسئله بدون شک برای بسیار از برنامه نویسان پیش آمده است و ممکن است بعضی از این برنامه نویسان به دنبال راه چارهای بوده باشند و بعضیها هم با انجام دادن این روش تست، هیچ مشکلی نداشته باشند. اما مسئلهای که غیر قابل چشم پوشی است، این است که این روش انرژی و زمان بسیار زیادی را از برنامه نویسان میگیرد؛ راه حل چیست؟ راه حل همان ACT میباشد.
ACT به معنی نوشتن کد، جهت تست قابلیتهای نرم افزار میباشد. به این معنی که شما جهت تست کد خود، یکسری کد مینویسید که این کدها وظیفه دارند کدهای جدیدی را که به نرم افزار خود اضافه کرده اید، تست کنند و اجرای آنها توسط زیرساختهای موجود (Test Frameworks) به صورت اتوماتیک انجام میشود.
حال قصد داریم اجزای ACT را که در شکل ذیل نمایش داده شدهاند، تشریح کنیم.
· structured: برای بیان این مسئله، از مفهوم AAA استفاده میشود. A اول به معنی Arrange اطلاعاتی است که برای تست مورد نیاز است. A دوم به معنی Act یا اجرای متد در حالت تست است و A سوم بمعنی Assert یا بررسی نتایج تست میباشد. این ساختار، ساختاری است که در ادامه برای ایجاد تستها از آن استفاده میکنیم.
· Self-documented: ساختار تست به گونهای است که خود مستند میباشد و با بررسی کلی ساختار آن میتوان به هدف تست پی برد.
· Automatic: با استفاده از Test Framework ها، فرآیند تست اتوماتیک میشود.
· Repeatable: یکی از مزیتهای ACT این است که میتوان آن را برای دفعات مکرر تکرار کرد.
· TARDIS: مخفف Time And Relative Dimension In Space میباشد؛ با توجه به این مسئله ACT از کد شما در میان زمان و فضا محافظت میکند. ACT عملکرد اصلی کد شما را در حال حاضر و در زمانی در آینده تایید میکند؛ زمانیکه کد شما در حال توسعه میباشید و هر لحظه قابلیتهای جدیدی به آن اضافه میشود، ACT تضمین میکند که این تغییرات، قابلیتهای موجود در سیستم را تحت تاثیر قرار نمیدهند. بنابراین ACT از کد شما در مقابل زمان و فضا محافظت میکند.
روشهای مختلفی برای انجام دادن ACT وجود دارند که در این مقاله بر روی Unit Test تمرکز خواهیم کرد. Unit Test یکسری تستها هستند که توسط برنامه نویس نوشته و اجرا میشود. هدف این روش این است که کد به قسمتهای کوچکی تقسیم شود و بررسی شود که این قسمتها آن گونه که انتظار میرود، عمل میکنند.
برای رسیدن به این هدف باید کد را به صورت متدهای Clean و Testable نوشت. این متدها قسمتهای مستقلی از کد هستند که میتوانند تست شوند. همان طور که در شکل زیر مشاهده میکنید، برای هر متد میتوان تستهای مختلفی نوشت و حالتهای مختلف مربوط به ورودیهای معتبر، ورودیهای نامعتبر و بروز Exception را تست کرد.
بسیاری از برنامه نویسان و مدیران پروژه درمقابل مسئله استفاده از Unit Test در توسعه نرم افزار حساسیتهای خاصی نشان میدهند. بسیاری از آنها اظهار میکنند که برای این کار زمان کافی نداریم و استفاده کردن از این روش برای ما هزینه بر میباشد. اما ما در جواب این دسته از افراد باید موارد زیر را که بیشتر هم بر جنبه زمانی تاکید دارند، بیان کنیم.
· Save time:
استفاده کردن از Unit Test از هدر رفتن زمان شما جلوگیری میکند. هر برنامه نویسی میداند که حتی چند خط کد ساده هم نیاز به تست و باز بینی دارد. بنابراین برنامه نویس مجبور است آن ماژول اصلی از نرم افزار را که چند خط کد در آن نوشته است، به گونه ای اجرا کرده و فرآیند بیزینسی این ماژول را برای سناریوهای مختلف، بصورت دستی تست کند. حال فرض کنید در ادامهی این کار، شخص برنامه نویس مجبور شود کد را بطور مرتب تغییر دهد. بنابراین در این حالت مجبور است این فرآیند را چندین و چند بار تکرار کند (نرم افزار را اجرا کند، به منوی X برود، فرم Y را باز کند، حالتهای مختلف را در فرم بررسی کند).
راه حلی که Unit Test برای حل این مشکل ارئه میدهد این است که برای انجام این فرآیند میتوان کد نوشت و آن را بارها و بارها اجرا کرد. وظیفهی Unit Test ها این است که اطلاعات مورد نیاز متد یا واحدی که میخواهند آن را تست کنند، فرآهم میآورند، متد را با اطلاعات فرآهم شده زیر تست میبرند و سپس نتایج بدست آمده را بررسی خواهند کرد. شما میتوانید در صورت تغییراتی در متدها یا واحدها، Unit Test را بارها و بارها برای تست عملکرد صحیح آن متد، بعد از تغییرات اجرا کنید. همان طور که میبینید تبدیل کردن این فرآیند دستی به یک فرآیند سیستمی و اتوماتیک میتواند در جلوگیری از هدر رفت زمان بسیار تاثیر گذار باشد.
· Find Bugs Faster:
با استفاده از Unit Test شما میتوانید فرآیند پیدا کردن خطاها را بسیار سریعتر انجام دهید. برای مثال فرض کنید که شما گزارش یکسری خطاها را در نرم افزار، دریافت کردهاید. به جای اینکه سعی کنید بصورت دستی، فرآیندها را در نرم افزار مرور کنید تا دوباره شرایط بروز خطا یا شرایطی را که خطا در آن رخ داده است، جهت درک دلیل خطا یا خطاها ایجاد کنید، با استفاده از Unit Test میتوانید به راحتی و در سریعترین زمان ممکن و بصورت اتوماتیک خطاها را پیدا کنید.
· Refactor Safely:
Unit Test به شما اجازه میدهد که به راحتی کد خود را Refactor کنید. فرض کنید که میخواهید کدی را که دارای یکسری پیچیدگیها میباشد و نگهداری و توسعه آن سخت است، Refactor کنید. بدون استفاده از Unit Test، این Refactor کردن دارای ریسک بسیار زیادی است و ممکن است منجر به بروز خطاهای زیادی شود؛ در حالیکه با استفاده از Unit Test، بعد از Refactor کردن کد، میتوان Test ها را اجرا کرده و از عدم وجود خطا در کدها به راحتی مطمئن شد.
· Enhance Your Value:
با نوشتن Unit Test برای کدهای خود میتوانید یک ارزش افزوده را به کدهای خود اضافه کنید. به دلیل اینکه نوشتن Unit Test ویژگی Self-documented کد شما را افزایش میدهد و به افرادی که در تیم هستند کمک میکنند Business نرم افزار را بهتر درک کنند.
· Minimize Interruptions:
داشتن مجموعهای مناسب از Unit Test ها باعث میشود تا Interrupt های ناخواسته در Code شما بوجود نیاید. برای مثال حالتی را در نظر بگیرید که بدلیل ورود دادههای ناخواسته، نرم افزار دچار خطا میشود. دراین وضعیت در صورتیکه از Unit Test استفاده شود، هندل کردن این شرایط ناخواسته و Interrupt، بسیار راحتتر خواهد بود.
با توجه به فاکتورهای موجود در Defensive Coding، یکی از مواردی که کیفیت کد شما را تضمین خواهد کرد، استفاده کردن از (ACT) Automated Code Test میباشد. در این قسمت قصد داریم مزایای تست اتوماتیک و Unit Test را به عنوان یکی دیگر از ابعاد Defensive Coding ذکر کنیم.
به عنوان برنامه نویسی که در حال توسعه کد هستید و قابلیتهای جدیدی را به کد خود اضافه میکنید، باید کدی را که در آن تغییر ایجاد میکنید، مرتب تست کنید، تا بررسی کنید که آیا به هدف خود رسیدهاید و توانستهاید قابلیت جدیدی را در نرم افزار اضافه کنید. روشی که توسط اکثر برنامه نویسان انجام میشود به این صورت است که بهصورت متوالی برنامه را اجرا میکنند، اجرا میکنند، اجرا میکنند و باز هم اجرا میکنند، تا اینکه مطمئن شوند همه چیز درست است. بیشتر زمانیکه در این فرآیند صرف میشود، صرف کارهای تکراری میشود. این مسئله بدون شک برای بسیار از برنامه نویسان پیش آمده است و ممکن است بعضی از این برنامه نویسان به دنبال راه چارهای بوده باشند و بعضیها هم با انجام دادن این روش تست، هیچ مشکلی نداشته باشند. اما مسئلهای که غیر قابل چشم پوشی است، این است که این روش انرژی و زمان بسیار زیادی را از برنامه نویسان میگیرد؛ راه حل چیست؟ راه حل همان ACT میباشد.
ACT به معنی نوشتن کد، جهت تست قابلیتهای نرم افزار میباشد. به این معنی که شما جهت تست کد خود، یکسری کد مینویسید که این کدها وظیفه دارند کدهای جدیدی را که به نرم افزار خود اضافه کرده اید، تست کنند و اجرای آنها توسط زیرساختهای موجود (Test Frameworks) به صورت اتوماتیک انجام میشود.
حال قصد داریم اجزای ACT را که در شکل ذیل نمایش داده شدهاند، تشریح کنیم.
· structured: برای بیان این مسئله، از مفهوم AAA استفاده میشود. A اول به معنی Arrange اطلاعاتی است که برای تست مورد نیاز است. A دوم به معنی Act یا اجرای متد در حالت تست است و A سوم بمعنی Assert یا بررسی نتایج تست میباشد. این ساختار، ساختاری است که در ادامه برای ایجاد تستها از آن استفاده میکنیم.
· Self-documented: ساختار تست به گونهای است که خود مستند میباشد و با بررسی کلی ساختار آن میتوان به هدف تست پی برد.
· Automatic: با استفاده از Test Framework ها، فرآیند تست اتوماتیک میشود.
· Repeatable: یکی از مزیتهای ACT این است که میتوان آن را برای دفعات مکرر تکرار کرد.
· TARDIS: مخفف Time And Relative Dimension In Space میباشد؛ با توجه به این مسئله ACT از کد شما در میان زمان و فضا محافظت میکند. ACT عملکرد اصلی کد شما را در حال حاضر و در زمانی در آینده تایید میکند؛ زمانیکه کد شما در حال توسعه میباشید و هر لحظه قابلیتهای جدیدی به آن اضافه میشود، ACT تضمین میکند که این تغییرات، قابلیتهای موجود در سیستم را تحت تاثیر قرار نمیدهند. بنابراین ACT از کد شما در مقابل زمان و فضا محافظت میکند.
روشهای مختلفی برای انجام دادن ACT وجود دارند که در این مقاله بر روی Unit Test تمرکز خواهیم کرد. Unit Test یکسری تستها هستند که توسط برنامه نویس نوشته و اجرا میشود. هدف این روش این است که کد به قسمتهای کوچکی تقسیم شود و بررسی شود که این قسمتها آن گونه که انتظار میرود، عمل میکنند.
برای رسیدن به این هدف باید کد را به صورت متدهای Clean و Testable نوشت. این متدها قسمتهای مستقلی از کد هستند که میتوانند تست شوند. همان طور که در شکل زیر مشاهده میکنید، برای هر متد میتوان تستهای مختلفی نوشت و حالتهای مختلف مربوط به ورودیهای معتبر، ورودیهای نامعتبر و بروز Exception را تست کرد.
بسیاری از برنامه نویسان و مدیران پروژه درمقابل مسئله استفاده از Unit Test در توسعه نرم افزار حساسیتهای خاصی نشان میدهند. بسیاری از آنها اظهار میکنند که برای این کار زمان کافی نداریم و استفاده کردن از این روش برای ما هزینه بر میباشد. اما ما در جواب این دسته از افراد باید موارد زیر را که بیشتر هم بر جنبه زمانی تاکید دارند، بیان کنیم.
· Save time:
استفاده کردن از Unit Test از هدر رفتن زمان شما جلوگیری میکند. هر برنامه نویسی میداند که حتی چند خط کد ساده هم نیاز به تست و باز بینی دارد. بنابراین برنامه نویس مجبور است آن ماژول اصلی از نرم افزار را که چند خط کد در آن نوشته است، به گونه ای اجرا کرده و فرآیند بیزینسی این ماژول را برای سناریوهای مختلف، بصورت دستی تست کند. حال فرض کنید در ادامهی این کار، شخص برنامه نویس مجبور شود کد را بطور مرتب تغییر دهد. بنابراین در این حالت مجبور است این فرآیند را چندین و چند بار تکرار کند (نرم افزار را اجرا کند، به منوی X برود، فرم Y را باز کند، حالتهای مختلف را در فرم بررسی کند).
راه حلی که Unit Test برای حل این مشکل ارئه میدهد این است که برای انجام این فرآیند میتوان کد نوشت و آن را بارها و بارها اجرا کرد. وظیفهی Unit Test ها این است که اطلاعات مورد نیاز متد یا واحدی که میخواهند آن را تست کنند، فرآهم میآورند، متد را با اطلاعات فرآهم شده زیر تست میبرند و سپس نتایج بدست آمده را بررسی خواهند کرد. شما میتوانید در صورت تغییراتی در متدها یا واحدها، Unit Test را بارها و بارها برای تست عملکرد صحیح آن متد، بعد از تغییرات اجرا کنید. همان طور که میبینید تبدیل کردن این فرآیند دستی به یک فرآیند سیستمی و اتوماتیک میتواند در جلوگیری از هدر رفت زمان بسیار تاثیر گذار باشد.
· Find Bugs Faster:
با استفاده از Unit Test شما میتوانید فرآیند پیدا کردن خطاها را بسیار سریعتر انجام دهید. برای مثال فرض کنید که شما گزارش یکسری خطاها را در نرم افزار، دریافت کردهاید. به جای اینکه سعی کنید بصورت دستی، فرآیندها را در نرم افزار مرور کنید تا دوباره شرایط بروز خطا یا شرایطی را که خطا در آن رخ داده است، جهت درک دلیل خطا یا خطاها ایجاد کنید، با استفاده از Unit Test میتوانید به راحتی و در سریعترین زمان ممکن و بصورت اتوماتیک خطاها را پیدا کنید.
· Refactor Safely:
Unit Test به شما اجازه میدهد که به راحتی کد خود را Refactor کنید. فرض کنید که میخواهید کدی را که دارای یکسری پیچیدگیها میباشد و نگهداری و توسعه آن سخت است، Refactor کنید. بدون استفاده از Unit Test، این Refactor کردن دارای ریسک بسیار زیادی است و ممکن است منجر به بروز خطاهای زیادی شود؛ در حالیکه با استفاده از Unit Test، بعد از Refactor کردن کد، میتوان Test ها را اجرا کرده و از عدم وجود خطا در کدها به راحتی مطمئن شد.
· Enhance Your Value:
با نوشتن Unit Test برای کدهای خود میتوانید یک ارزش افزوده را به کدهای خود اضافه کنید. به دلیل اینکه نوشتن Unit Test ویژگی Self-documented کد شما را افزایش میدهد و به افرادی که در تیم هستند کمک میکنند Business نرم افزار را بهتر درک کنند.
· Minimize Interruptions:
داشتن مجموعهای مناسب از Unit Test ها باعث میشود تا Interrupt های ناخواسته در Code شما بوجود نیاید. برای مثال حالتی را در نظر بگیرید که بدلیل ورود دادههای ناخواسته، نرم افزار دچار خطا میشود. دراین وضعیت در صورتیکه از Unit Test استفاده شود، هندل کردن این شرایط ناخواسته و Interrupt، بسیار راحتتر خواهد بود.
من قصد دارم در قالب چند مطلب برخی از مفاهیم پایه و مهم برنامه نویسی را که پیش نیازی برای درک اکثر مطالب موجود در وب سایت است به زبان ساده بیان کنم تا دایره افرادی که میتوانند از مطالب ارزشمند این وب سایت استفاده کنند وسعت بیشتری پیدا کند. لازم به توضیح است از آنجا که علاقه ندارم اینجا تبدیل به نسخه فارسی MSDN یا کتاب آنلاین آموزش برنامه نویسی شود این سری آموزشها بیشتر شامل مفاهیم کلیدی خواهند بود.
این مطلب به عنوان اولین بخش از این سری مطالب منتشر میشود.
هدف این نوشته بررسی جزییات برنامه نویسی در رابطه با کلاس و شیء نیست. بلکه دریافتن چگونگی شکل گرفتن ایده شیء گرایی و علت مفید بودن آن است.
در سمت راست بخشی از نقشه یک ساختمان و در سمت چپ ساختمان ساخته شده بر اساس این نقشه را میبینید. ساختمان همان شیء است. و نقشه ساختمان کلاس آن است چراکه امکان ایجاد اشیائی که تحت عنوان ساختمان طبقه بندی (کلاس بندی) میشوند را فراهم میکند. به همین سادگی. کلاسها طرح اولیه، نقشه یا قالبی هستند که جزییات یک شی را توصیف میکنند.
حتماً با من موافق هستید اگر بگویم:
سوال: کلاس یا نقشه ایجاد گاو چیست؟ اگر از من بپرسید خواهم گفت طرح اولیه گاو هم ممکن است وجود داشته باشد البته در اختیار خداوند و با سطح دسترسی ملکوت!
اتومبیل، تلویزیون و ... همگی مثال هایی از اشیاء پیرامون ما در دنیای واقعی هستند که حتماً میتوانید کلاس یا نقشه ایجاد آنها را نیز بدست آورید و یا ویژگیها و کارکردهای آنها را برشمارید.
برای نوشتن برنامه جهت حل یک مسئله بزرگ باید بتوان آن مسئله را به بخشهای کوچکتری تقسیم نمود. در این رابطه مفهوم شیء و کلاس با همان کیفیتی که در محیط پیرامون ما وجود دارد به صورت مناسبی امکان تقسیم یه مسئله بزرگ به بخشهای کوچکتر را فراهم میکند. و سبب میشود هماهنگی و تقارن و تناظر خاصی بین اشیاء برنامه و دنیای واقعی بوجود آید که یکی از مزایای اصلی روش شیء گراست.
از آنجا که در یک برنامه اصولاً همه چیز و همه مفاهیم در قالب کدها و دستورات برنامه معنا دارد، کلاس و شیء نیز چیزی بیش از قطعاتی کد نیستند. قطعه کد هایی که بسته بندی شده اند تا تمام کار مربوط به هدفی که برای آنها در نظر گرفته شده است را انجام دهند.
همان طور که در هر زبان برنامه نویسی دستوراتی برای کارهای مختلف مانند تعریف یک متغیر یا ایجاد یک حلقه و ... در نظر گرفته شده است، در زبانهای برنامه نویسی شیء گرا نیز دستوراتی وجود دارد تا بتوان قطعه کدی را بر اساس مفهوم کلاس بسته بندی کرد.
به طور مثال قطعه کد زیر را در زبان برنامه نویسی سی شارپ در نظر بگیرید.
در این قطعه کد با استفاده از کلمه کلیدی class در زبان سی شارپ کلاسی ایجاد شده است که دارای دو ویژگی نام و سن و دو رفتار راه رفتن و دویدن است.
این کلاس به چه دردی میخورد؟ کجا میتوانیم از این کلاس استفاده کنیم؟
پاسخ این است که این کلاس ممکن است برای ما هیچ سودی نداشته باشد و هیچ کجا نتوانیم از آن استفاده کنیم. اما بیایید فرض کنیم برنامه نویسی هستیم که قصد داریم یک بازی فوتبال بنویسیم. به جای آنکه قطعات کد مجزایی برای هر یک از بازیکنان و کنترل رفتار و ویژگیهای آنان بنویسیم با اندکی تفکر به این نکته پی میبریم که همه بازیکنان مشترکات بسیاری دارند و به عبارتی در یک گروه یا کلاس قابل دسته بندی هستند. پس سعی میکنیم نقشه یا قالبی برای بازیکنها ایجاد کنیم که دربردارنده ویژگیها و رفتارهای آنها باشد.
همان طور که در نقشه ساختمان نمیتوانیم زندگی کنیم این کلاس هم هنوز آماده انجام کارهای واقعی نیست. چراکه برخی مقادیر هنوز برای آن تنظیم نشده است. مانند نام بازیکن و سن و ....
و همان طور که برای سکونت لازم است ابتدا یک ساختمان از روی نقشه ساختمان بسازیم برای استفاده واقعی از کلاس یاد شده نیز باید از روی آن شیء بسازیم. به این فرآیند وهله سازی یا نمونه سازی نیز میگویند. یک زبان برنامه نویسی شیء گرا دستوراتی را برای وهله سازی نیز در نظر گرفته است. در C# کلمه کلیدی new این وظیفه را به عهده دارد.
وقتی فرآیند وهله سازی صورت میگیرد یک نمونه یا شیء از آن کلاس در حافظه ساخته میشود که در حقیقت میتوانید آنرا همان کدهای کلاس تصور کنید با این تفاوت که مقداردهیهای لازم صورت گرفته است. به دلیل تعیین مقادیر لازم، حال شیء تولید شده میتواند به خوبی اعمال پیش بینی شده را انجام دهد. توجه نمایید در اینجا پیاده سازی داخلی رفتار دویدن و اینکه مثلاً در هنگام فراخوانی آن چه کدی باید اجرا شود تا تصویر یک بازیکن در حال دویدن در بازی نمایش یابد مد نظر و موضوع بحث ما نیست. بحث ما چگونگی سازماندهی کدها توسط مفهوم کلاس و شیء است. همان طور که مشاهده میکنید ما تمام جزییات بازیکنها را یکبار در کلاس پیاده سازی کرده ایم اما به تعداد دلخواه میتوانیم از روی آن بازیکنهای مختلف را ایجاد کنیم. همچنین به راحتی رفتار دویدن یک بازیکن را فراخوانی میکنیم بدون آنکه پیاده سازی کامل آن در اختیار و جلوی چشم ما باشد.
تمام آنچه که بازیکن برای انجام امور مربوط به خود نیاز دارد در کلاس بازیکن کپسوله میشود. بدیهی است در یک برنامه واقعی ویژگیها و رفتارهای بسیار بیشتری باید برای کلاس بازیکن در نظر گرفته شود. مانند پاس دادن، شوت زدن و غیره.
به این ترتیب ما برای هر برنامه میتوانیم مسئله اصلی را به تعدادی مسئله کوچکتر تقسیم کنیم و وظیفه حل هر یک از مسائل کوچک را به یک شیء واگذار کنیم. و بر اساس اشیاء تشخیص داده شده کلاسهای مربوطه را بنویسیم. برنامه نویسی شیء گرا سبب میشود تا مسئله توسط تعدادی شیء که دارای نمونههای متناظری در دنیای واقعی هستند حل شود که این امر زیبایی و خوانایی و قابلیت نگهداری و توسعه برنامه را بهبود میدهد.
احتمالاً تاکنون متوجه شده اید که برای نگهداری ویژگیهای اشیاء از متغیرها و برای پیاده سازی رفتارها یا کارکردهای اشیاء از توابع استفاده میکنیم.
با توجه به این که هدف این مطلب بررسی مفهوم شیء گرائی بود و نه جزییات برنامه نویسی، بنابراین بیان برخی مفاهیم در این رابطه را که بیشتر در مهندسی نرم افزار معنا دارند تا در دنیای واقعی در مطالب بعدی بررسی میکنیم.
این مطلب به عنوان اولین بخش از این سری مطالب منتشر میشود.
هدف این نوشته بررسی جزییات برنامه نویسی در رابطه با کلاس و شیء نیست. بلکه دریافتن چگونگی شکل گرفتن ایده شیء گرایی و علت مفید بودن آن است.
مشاهده مفاهیم شیء گرایی در پیرامون خود
حتماً در دنیای برنامه نویسی شیء گرا بارها با کلمات کلاس و شیء روبرو شده اید. درک صحیح از این مفاهیم بسیار مهم و البته بسیار ساده است. کار را با یک مثال شروع میکنیم. به تصویر زیر نگاه کنید.در سمت راست بخشی از نقشه یک ساختمان و در سمت چپ ساختمان ساخته شده بر اساس این نقشه را میبینید. ساختمان همان شیء است. و نقشه ساختمان کلاس آن است چراکه امکان ایجاد اشیائی که تحت عنوان ساختمان طبقه بندی (کلاس بندی) میشوند را فراهم میکند. به همین سادگی. کلاسها طرح اولیه، نقشه یا قالبی هستند که جزییات یک شی را توصیف میکنند.
حتماً با من موافق هستید اگر بگویم:
- در نقشه ساختمان نمیتوانید زندگی کنید اما در خود ساختمان میتوانید.
- از روی یک نقشه میتوان به تعداد دلخواه ساختمان ساخت.
- هنگامی که در یک ساختمان زندگی میکنید نیازی نیست تا دقیقاً بدانید چگونه ساخته شده و مثلاً سیم کشی یا لوله کشیهای آن چگونه است! تنها کافیست بدانید برای روشن شدن لامپ باید کلید آن را بزنید.
- ساختمان دارای ویژگی هایی مانند متراژ، ضخامت دیوار، تعداد پنجره و ابعاد هر یک و ... است که در هنگام ساخت و بر اساس اطلاعات موجود در نقشه تعیین شده اند.
- ساختمان دارای کارکرد هایی است. مانند بالا و پایین رفتن آسانسور و یا باز و بسته شدن درب پارکینگ. هر یک از این کارکردها نیز بر اساس اطلاعات موجود در نقشه پیاده سازی و ساخته شده اند.
- ساختمان تمام اجزای لازم برای اینکه از آن بتوانیم استفاده کنیم و به عبارتی در آن بتوانیم زندگی کنیم را در خود دارد.
سوال: کلاس یا نقشه ایجاد گاو چیست؟ اگر از من بپرسید خواهم گفت طرح اولیه گاو هم ممکن است وجود داشته باشد البته در اختیار خداوند و با سطح دسترسی ملکوت!
اتومبیل، تلویزیون و ... همگی مثال هایی از اشیاء پیرامون ما در دنیای واقعی هستند که حتماً میتوانید کلاس یا نقشه ایجاد آنها را نیز بدست آورید و یا ویژگیها و کارکردهای آنها را برشمارید.
مفاهیم شیء گرایی در مهندسی نرم افزار
مفاهیمی که تاکنون در مورد دنیای واقعی مرور کردیم همان چیزی است که در دنیای برنامه نویسی ـ به عقیده من دنیای واقعیتر از دنیای واقعی ـ با آن سر و کار داریم. علت این امر آن است که اصولاً ایده روش برنامه نویسی شیء گرا با مشاهده محیط پیرامون ما به وجود آمده است.برای نوشتن برنامه جهت حل یک مسئله بزرگ باید بتوان آن مسئله را به بخشهای کوچکتری تقسیم نمود. در این رابطه مفهوم شیء و کلاس با همان کیفیتی که در محیط پیرامون ما وجود دارد به صورت مناسبی امکان تقسیم یه مسئله بزرگ به بخشهای کوچکتر را فراهم میکند. و سبب میشود هماهنگی و تقارن و تناظر خاصی بین اشیاء برنامه و دنیای واقعی بوجود آید که یکی از مزایای اصلی روش شیء گراست.
از آنجا که در یک برنامه اصولاً همه چیز و همه مفاهیم در قالب کدها و دستورات برنامه معنا دارد، کلاس و شیء نیز چیزی بیش از قطعاتی کد نیستند. قطعه کد هایی که بسته بندی شده اند تا تمام کار مربوط به هدفی که برای آنها در نظر گرفته شده است را انجام دهند.
همان طور که در هر زبان برنامه نویسی دستوراتی برای کارهای مختلف مانند تعریف یک متغیر یا ایجاد یک حلقه و ... در نظر گرفته شده است، در زبانهای برنامه نویسی شیء گرا نیز دستوراتی وجود دارد تا بتوان قطعه کدی را بر اساس مفهوم کلاس بسته بندی کرد.
به طور مثال قطعه کد زیر را در زبان برنامه نویسی سی شارپ در نظر بگیرید.
class Player { public string Name; public int Age; public void Walk() { // کدهای مربوط به پیاده سازی راه رفتن } public void Run() { // کدهای مربوط به پیاده سازی دویدن } }
این کلاس به چه دردی میخورد؟ کجا میتوانیم از این کلاس استفاده کنیم؟
پاسخ این است که این کلاس ممکن است برای ما هیچ سودی نداشته باشد و هیچ کجا نتوانیم از آن استفاده کنیم. اما بیایید فرض کنیم برنامه نویسی هستیم که قصد داریم یک بازی فوتبال بنویسیم. به جای آنکه قطعات کد مجزایی برای هر یک از بازیکنان و کنترل رفتار و ویژگیهای آنان بنویسیم با اندکی تفکر به این نکته پی میبریم که همه بازیکنان مشترکات بسیاری دارند و به عبارتی در یک گروه یا کلاس قابل دسته بندی هستند. پس سعی میکنیم نقشه یا قالبی برای بازیکنها ایجاد کنیم که دربردارنده ویژگیها و رفتارهای آنها باشد.
همان طور که در نقشه ساختمان نمیتوانیم زندگی کنیم این کلاس هم هنوز آماده انجام کارهای واقعی نیست. چراکه برخی مقادیر هنوز برای آن تنظیم نشده است. مانند نام بازیکن و سن و ....
و همان طور که برای سکونت لازم است ابتدا یک ساختمان از روی نقشه ساختمان بسازیم برای استفاده واقعی از کلاس یاد شده نیز باید از روی آن شیء بسازیم. به این فرآیند وهله سازی یا نمونه سازی نیز میگویند. یک زبان برنامه نویسی شیء گرا دستوراتی را برای وهله سازی نیز در نظر گرفته است. در C# کلمه کلیدی new این وظیفه را به عهده دارد.
Player objPlayer = new Player(); objPlayer.Name = “Ali Karimi”; objPlayer.Age = 30; objPlayer.Run();
تمام آنچه که بازیکن برای انجام امور مربوط به خود نیاز دارد در کلاس بازیکن کپسوله میشود. بدیهی است در یک برنامه واقعی ویژگیها و رفتارهای بسیار بیشتری باید برای کلاس بازیکن در نظر گرفته شود. مانند پاس دادن، شوت زدن و غیره.
به این ترتیب ما برای هر برنامه میتوانیم مسئله اصلی را به تعدادی مسئله کوچکتر تقسیم کنیم و وظیفه حل هر یک از مسائل کوچک را به یک شیء واگذار کنیم. و بر اساس اشیاء تشخیص داده شده کلاسهای مربوطه را بنویسیم. برنامه نویسی شیء گرا سبب میشود تا مسئله توسط تعدادی شیء که دارای نمونههای متناظری در دنیای واقعی هستند حل شود که این امر زیبایی و خوانایی و قابلیت نگهداری و توسعه برنامه را بهبود میدهد.
احتمالاً تاکنون متوجه شده اید که برای نگهداری ویژگیهای اشیاء از متغیرها و برای پیاده سازی رفتارها یا کارکردهای اشیاء از توابع استفاده میکنیم.
با توجه به این که هدف این مطلب بررسی مفهوم شیء گرائی بود و نه جزییات برنامه نویسی، بنابراین بیان برخی مفاهیم در این رابطه را که بیشتر در مهندسی نرم افزار معنا دارند تا در دنیای واقعی در مطالب بعدی بررسی میکنیم.
نظرات مطالب
الگوی مشاهدهگر Observer Pattern
یکی از مثال هایی که خودم چند روز پیش از این الگو در جاوا برای اندروید استفاده کردم این است که در بخشی از برنامه انتقال اطلاعاتی صورت میگرفت که شاید نیاز باشد هزاران آیتم در برنامه انتقال یابند که در این صورت بهتر بود که فعالیت توسط یک نوار پیشرفت نمایش داده شود و از آنجا که این انتقال برای آیتمها در کلاسی جداگانه قرار داشت و در این حالت ممکن بود تکه کد نامربوط بین بخش رابط کاربری و منطق اضافه کند و وابستگی ایجاد کند از این الگو استفاده کردم. در این حالت هر وقت متد مورد نظر انتقالی انجام میداد کلاس پیشرفت را برای محاسبه درصد آگاه میساخت.
نظرات مطالب
Senior Developer به چه کسی گفته می شود؟
اصولا بهترین روش برای تشخیص اینکه شما در کدام سطح قرار دارید این است که خودتون به مسیری که طی کردید تا به جایگاه فعلی برسید یک نگاه دقیق داشته باشید. اصولا اکثر برنامه نویسانی که در شرکتهای نرم افزاری مشغول به کار هستند در سطح Junior یا Mid Level هستند. در این پست تمرکز اصلی برای تشریح سطح برنامه نویس ارشد بود. متاسفانه در اکثر آگهیهای استخدام شاهد این هستیم که برنامه نویس باید با انبوهی از تکنولوژیهای آشنایی داشته باشد. مثلا حتما در آگهیها دیده اید که برنامه نویس Asp.Net MVC مسلط به JQuery و HTML و CSS و JavaScript و EF و.... بعنی باید برنامه نویس هم در لایههای سطح پایین نظیر Business و سرویس برنامه نویسی کند و هم به عنوان یک Front- End کار.
به صورت معمول زمانی که برنامه نویسان خودشون را در جایگاه Senior Developer نمیبینند از واژه Software Developer استفاده میکنند.
اشتراکها
تنبل مثل یک روباه
برای مشاهده طبقه بندی Bad code smellها میتوانید به اینجا مراجعه کنید.
استفاده از کامنت، به خودی خود یک الگوی بد کد نویسی نیست. ولی ممکن است این امکان به درستی استفاده نشده و فایده مد نظر توسعه دهنده را نداشته باشد.
زمانیکه متدی پر از کامنتهای توضیحی در مورد متد و پیاده سازی آن باشد، احتمالا مشکلی به وجود خواهد آمد. معمولا کامنتهای توضیحی زمانی استفاده میشوند که کد به اندازه کافی گویای کاری که انجام میدهد نباشد. زمانیکه چنین شرایطی بوجود آمد، یکی از اولین راه حلها، اعمال تغییراتی بر روی کد، برای درک بهتر آن است.
نامگذاری مناسب و استفاده از نامهای معنی دار برای بخشهای مختلف کد مانند نام کلاسها، نام متدها، نام متغیرها و پارامترها، نقش بسیار مهمی را در زمینه کاهش کامنتهای نامناسب خواهند داشت.
اما وجود کامنتهای توضیحی در مورد کد چه اشکالی را ایجاد میکنند؟ یکی از بزرگترین اشکالاتی که چنین کامنتهایی با خود به همراه میآورند، نگهداری سخت آنها است. فرض کنید کامنتی وجود دارد که عملیات انجام شده توسط کدی را توضیح میدهد. زمانیکه آن مکانیزم تغییر کرد، نیاز خواهد بود که کامنت مربوطه نیز به دقت بررسی شود و تغییر کند. در تولید نرم افزارهای پیچیده این کار بسیار دشوار و زمینه ساز خطا خواهد بود و اگر به دلیل سختی کار یا عجله در تولید، کامنتها بروز نشوند، دیگر هیچ یک از کامنتهای نوشته شده در کد، مورد اعتماد نخواهند بود و کار به مراتب سختتر نیز خواهد شد.
چند مورد از انواع کامنتهایی که بهتر است از آنها پرهیز کنیم، در ادامه مطرح شدهاند.
کامنتهای اضافی یا توضیح واضحات
کامنتهایی که بالای متدها یا کلاسها مشاهده میشوند و توصیف کننده کاری هستند که آن کلاس یا عضو آن انجام میدهد. هنگام توصیف یک کلاس یا عضوی از آن حتما باید توجه داشت که توضیح واضحات انجام نشود. به طور مثال کد زیر را در نظر بگیرید:
// Computes the employee salary public int CalculateSalary(int emplyeeId) { return int.MaxValue; }
امضای متد به اندازه کافی نشان دهنده این است که چه کاری را انجام میدهد. پس نیازی به کامنت بالای آن وجود نخواهد داشت. در این مثال، کامنت معمولی بالای متد استفاده شده است. در مثال مذکور این امکان وجود داشت که از مدل xml documentation استفاده شود؛ ولی در اصل موضوع تفاوتی ایجاد نمیکرد.
زمانیکه میتوان از متغیر یا متد استفاده کرد
زمانیکه در بدنه متدها با محاسبه یا چکهایی روبرو هستیم که به اندازه کافی واضح نیستند، یکی از اولین راهکارهایی که به نظر میرسد، نوشتن کامنت برای آنها است. به طور مثال در متدی که مسئول پاک کردن یک حساب، در یک نرم افزار حسابداری است، چکی به صورت زیر داشته باشیم:
// checks that an account is used or not and checks that an account has childs or not if (voucherLineRepository.Any(dd => dd.PostingAccountId == accountId) || accountRepository.Any(dd => dd.ParentId == accountId])) { return; }
if (UsedInVouchers(accountId) || HasChilds(accountId)) { return; }
if (!CanDeleteAccount(accountId)) { return; } ... public bool CanDeleteAccount(int accountId) { if (UsedInVouchers(accountId) || HasChilds(accountId)) { return false; } return true; }
کدهای کامنت شده
کدهای کامنت شده حسی از ترس و عدم اطمینان را به مشاهده کننده انتقال میدهند. کسی که با کد کامنت شده مواجه شده نمیتواند اطمینان داشته باشد که کد به طور کلی حذف شده، یا موقتا حذف شده و یا باید از حالت کامنت در بیاید یا خیر؟
کسی که آن را کامنت کرده نیز از کار خود اطمینان نداشته! اگر اطمینان داشت که کامنت شدن کد مورد نظر هیچ اختلالی را ایجاد نخواهد کرد و کسی نیازی به آن نمیداشت و حتما آن را به طور کلی حذف میکرد.
کامنتهای اجباری
در بعضی پروژهها، تیم برنامه نویسی تصمیم میگیرد که به صورت اجباری بالای هر متد و عضوی از کلاسها کامنتهایی برای روشنتر شدن موضوع ایجاد کنند. نتیجهای که این کار خواهد داشت، ایجاد یک سری کامنتهای تکراری و اضافه است. کامنتهایی که در خیلی مواقع حتی کپی نام عضو مورد نظر هستند. در بعضی از پروژههایی که به صورت فریم ورک هستند، به دلیل ذات پروژه شاید نوشتن توضیحات اضافه تصمیم خوبی باشد. ولی در بیشتر موارد نوشتن کامنتهای اجباری نتیجه خوبی نخواهد داشت.
لاگ تغییرات
در سالهای پیش این عادت وجود داشت که تغییرات اعلام شده در کدهای برنامه به صورت کامنت در بالای فایلهای مورد نظر وارد میشد. با وجود اینکه با استفاده از ابزارهای سورس کنترل، این موارد خیلی مشاهده نمیشود؛ ولی ذکر آن خالی از لطف نیست. در حال حاضر عموما ابزارهای سورس کنترل میتوانند نقش نگهداری لاگ تغییرات و دلایل آنها را به خوبی بر عهده بگیرند.
کامنت در زبانهای برنامه نویسی امکان خوبی است؛ به شرطی که به خوبی مورد استفاده قرار گیرد.