هنوز چند بایت مونده که پیدا کنم...

ده تا قانون ساده برای اینکه برنامه نویس بهتری بشین

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

خودت رو تکرار نکن

قانون خوبیه به نظرم! من خیلی دوست دارم وقتی کد رو نوشتم و از نظر عملیاتی ازش مطمئن شدم برگردم و ببینم کدوم قسمت از کدهام تکرار شده توی روال های مختلف و منتقلشون کنم به یه بلاک دیگه واحد و قابل فراخوانی (با در نظر داشتن پارامترهای مورد نیاز و قابلیت استفاده مجدد). توی ویژوال استودیو کلید های CTRL+R+M برای شما یه قسمت از کد رو تبدیل به یک متد جداگانه میکنه. این کار به قابلیت استفاده مجدد (reusability) و آزمایش پذیری (testability) کمک میکنه.

 

اسم متغیرها رو بر اساس کاری که میکنن انتخاب کنید نه بر اساس نوعشون

تنها توقعی که اینجا هست اینکه که اگر کد کسی رو کپی زدین و بر اساس اون ادامه میدین باید روش نامگذاری رو هم ادامه بدین. و اینکه دونستن نوع یک متغیر بر اساس نامش اصلا در روند کد نویسی ما موثر نیست! یکم هم فکر برنامه نویس بعدی باشین :)

 

اسم متدها باید طوری باشه که نشون بده با فراخوانی اونها چه کاری انجام میشه

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

 

ارقام و اسامی جادویی استفاده نکنین

وقتی یکی میخواد کد شما رو بخونه نباید از خودش بپرسه این عدد و یا این رشته چیه دیگه؟! جاش بیاید از ثوابت (constant)، انواع شمارشی (enum) و متغیرهای محلی (private variable) استفاده کنید.

 

جوری متدهاتون رو بنویسین که تا حد ممکن برای تست کردن وابستگی به سایر قسمتهای اپلیکیشن نداشته باشن.

جوری بنویسین که اصلا براتون مهم نباشه کجا قراره فراخوانی بشه این متد (method). اگر از مقادیر سراسری در اپلیکیشن استفاده میکنید (مثل session یا app setting) به صورت پارامتر برای تابع تعریفشون کنید. این کمک میکنه که قابلت آزمایش کد بره بالا. البته قابلیت استفاده مجدد هم رو بالا میبره.

 

پرسیدن عیب نیست اما ندونستن هست

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

 

از قانون boy Scout پیروی کنید

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

 

دانش خودتون رو با بقیه به اشتراک بذارید

خودخوان نباشید و تصور نکنید میتونید دانش رو برای خودتون نگهش دارید فقط. تلاش کنید فرهنگ کمک به دیگران رو ایجادش کنید. اگر همکارای شما پیشرفت کنن مطمئن باشید کارتون رو از دست نمیدید! شما ارزش خودتون رو بالا میبرید چرا که هم دانش دارید و هم شخصی هستید که به اطرافیاش کمک میکنه پیشرفت کنن.

 

نکن! عزیزم، بزرگوار، محترم نکن! یهو جفت پا نپر وسط کار همکارات و تمرکز کسی رو بهم نزن

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

 

مثبت نقد کنید نه منفی! اما نقد کنید!

از نظر من انتقاد راه پیشرفته منه. اگر میشه کاری رو طوری انجام داد که بهتر باشه و درست تر خوب اگر به من بگید کمک کردید من پیشرفت کنم.

نویسنده : مدیر سیستم
پنجشنبه 15 بهمن 1394
+ 110 -

خوشحال میشیم نظرتُ بدونیم