محلی برای یادگیری جاوا

۲ مطلب در دی ۱۳۹۴ ثبت شده است

نکاتی برای نوشتن کد تمیز-نام های معنادار

در مورد ضرورت نوشتن کدهای تمیز به اختصار توضیح دادم. اما در این پست و پست های بعد نحوه انجام اینکار را توضیح می دهم:

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

  • از نام هایی که هدفشان معلوم است استفاده کنید.
  • از نام هایی که اطلاعات درست نمی دهند (disinformation) بپرهیزید. بعضی لغات معنای تثبیت شده ای در ذهن دارند. از این لغات برای معانی دیگر استفاده نکنید. برای مثال hp مربوط به پلتفرم unix است. اگر در کد خود وتر (hypotenues) دارید شاید ظاهرا hp نام خوبی برای آن به نظر برسد. اما گمراه کننده است و نباید از آن استفاده کرد.
  • از کلماتی مانند list تنها در کاربرد خودشان استفاده کنید. مثلا اگر گروهی از دانش آموزان دارید که در سیستم بصورت list نیستند متغییرشان را studentList نام گذاری نکنید. studentGroup نام بهتری ست.
  • از کلمات خیلی مشابه برای متغییر های مختلف استفاده نکنید. چون اشتباها به جای یکدیگر در نظر گرفته می شوند:

xyzControllerForEfficientHandelingOfSetting

xyzControllerForEfficientStorageOfSetting

  • از O و L تک استفاده نکنید چون با 0 و 1 اشتباه گرفته می شوند.
  • تفاوت های معنادار ایجاد کنید. مثلا a1 و a2 هیچ اطلاعاتی به ما نمی دهد (noninformative). تنها می توان فهمید که یک سری هستند.
  • تفاوت بی معنی ایجاد نکنید. در واقع از noise word استفاده نکنید. مثلا ProductData و ProductInfo هیچ تفاوتی ندارند. یا نام گذاری کلاس مشتری به CustomerObject درست نیست. چون Customer به تنهایی اطلاعات را می رساند و Object در ادامه ی آن اضافه است.
  • از نام های قابل تلفظ استفاده کنید. مثلا مخفف genymdhms، که مربوط به تاریخ و سال و ماه و... است، نام خوبی نیست. 
  • از نام های قابل جستجو استفاده کنید. مثلا اگر نام متغیر تک حرف باشد، سرچ آن هزار نتیجه دارد و پیدا کردن جواب سخت است. اما MAX_STUDENT به راحتی قابل پیدا کردن است.
  • تک حرف ها بهتر است تنها برای نام متغیرهای local استفاده شوند.
  • از کد کردن بپرهیزید. مثل استفاده از I در ابتدای نام interface ها و یا انتهای Imp در انتهای نام کلاس های پیاده ساز.
  • نام کلاس ها باید یک اسم یا یک عبارت اسمیه باشد.
  • نام متدها باید یک فعل یا یک عبارت فعلیه باشد.
  • بامزگی نکنید. چون نام های بامزه تنها در ذهن افراد درگیر شوخی می مانند.
  • برای هر مفهوم فقط از یک اسم استفاده کنید. مثلا برای گرفتن اطلاعات از get و fetch و retrieve و ... در کلاس های مختلف استفاده نکنید. بعدا از کجا باید بفهمید که کدام متعلق به کدام است و تفاوتشان چیست؟
  • برای مفاهیم متفاوت از یک اسم استفاده نکنید.
  • از نام های موجود در solution domain استفاده کنید. خوانندگان کد، برنامه نویس هستند و از لغات موجود در علم کامپیوتر مطلعند پس نام هایی مثل jobQueue یا accountVisitor مفهوم را می رساند.
  • کلمات با معنا در نام ها اضافه کنید. فرض کنید متغیر های firstname, lastname, country, state و ... را میبینید. با دیدن این متغیرها می فهمیم که مربوط به آدرس هستند. اما اگر فقط متغیر state را ببینیم چطور؟ آیا متوجه می شویم مربوط به آدرس است؟ می توانیم یک context با معنا به آنها اضافه کنیم که مشخص شود مربوط به آدرس اند. به این شکل: addrFirstname, addrLastname, addrCountry, addrState و ... با این نام گذاری خواننده می فهمد که این متغیرها مربوط به یک مفهوم بزرگترند. اما راه بهتر تعریف کلاس Address است که در این صورت علاوه بر خواننده، کامپایلر هم می فهمد که این متغییر ها به مفهوم بزرگتری وابسته اند.
  • کلمات بی معنا در نام ها اضافه نکنید. مثلا اگر نام پروژه Gas Station Delux است، منطقی نیست قبل از نام همه ی متغیر های برنامه GSD اضافه کنیم چون اطلاعاتی نمی دهد و نام ها را بدون هیچ مزیتی طولانی می کند.

در پست بعد در مورد توابع تمیز توضیح خواهم داد.

۲۱ دی ۹۴ ، ۰۹:۵۸ ۱ نظر موافقین ۱ مخالفین ۰
پریسا

Clean Code کد تمیز

حتما تا به حال در مباحث پیشرفته ی برنامه نویسی با عبارت کد تمیز یا Clean code مواجه شده اید.

اما سوال این است که چرا و چگونه کد تمیز بنویسیم؟ در این پست به چرایی و در پست های بعد به چگونگی نوشتن کد تمیز می پردازم.

بیشتر مطالب اصلی که در این زمینه در این وبلاگ گفته خواهد شد ترجمه یا برداشت از کتاب زیر است:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

چرا کد تمیز؟

به طور کلی می توان فواید زیر را برای کد تمیز بر شمرد:

-maintain یا نگهداشت آن ساده تر است 

-یافتن bug ها ساده تر است

-bug ها کمتر هستند

-فهم آن ساده تر است

-...

یک سناریوی آشنا!

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

در چنین پروژه های با افزایش feature های پروژه این در هم ریختگی ها بیشتر می شود تا جایی که کد غیر قابل مدیریت می شود. اینجاست که گفته می شود bad code شرکت را به مرور ورشکست می کند!!

با بهم ریختگی کد با گذر زمان بهره وری یا productivity تیم رو به کاهش می رود تا جایی که به 0 میل می کند. مدیران در چنین مراحلی سعی می کنند با افزایش feature ها بهره وری تیم را بالا ببرند اما اینکار به نتیجه نمی رسد. چون با این کار درهم ریختگی کدها بیشتر و بیشتر می شود. تیم به هم می ریزد و develop روی کدهای موجود امکان ادامه ندارد در نتیجه درخواست طراحی یک سیستم جدید داده می شود.

مدیران نمی توانند تمام منابع را به طراحی سیستم جدید اختصاص دهند و همچنین نمی توانند انکار کنند که سیستم موجود قابل ادامه نیست پس یک تیم جدید انتخاب می شود (TIGER team). همه افراد دوست دارند در این تیم باشند چون پروژه ی آن green field است.

tiger team پروژه ی خوبی تولید می کند اما فقط برای خودش، و بقیه مجبور به کار با سیستم قبلی اند. سیستم جدید باید تمام ویژگی های سیستم قبلی را داشته باشد و علاوه بر آن باید تمام تغییرات ممتد سیستم قدیمی را نیز پوشش دهد.

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

پس طبق آنچه گفته شد clean code یک موضوع cost effective نیست، بلکه مسیله ایست برای بقای حرفه ای پروژه.

پی نوشت:

TIGER team: سر آمد  Totally Integrated Group of Expert Resources است. در واقع جمعی از خبرگان برای تحقیق و حل یک مشکل فنی.

green field project: پروژه ای که محدود و مقید به پروژه های قبلی نیست.

۰۹ دی ۹۴ ، ۱۰:۵۵ ۳ نظر موافقین ۱ مخالفین ۰
پریسا