اصولی که یک برنامه نویس خوب باید بدونه

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

نمیتونیم این تغییر رو بدیم چون کد مون باگی میشه.

تقصیر برنامه نویس قبلیه، به ما ربطی نداره.

باید خیلی زمان/انرژی بذاریم که این تغییر کوچیک رو ایجاد کنیم.

کد ها خیلی قدیمی اند و کسی ازشون سر در نمیاره.

برای کد ها دایکیومنت نداریم.

این جملات آشنا اند؟

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

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

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

در اینجا چند مورد کلیدی که هر برنامه نویسی باید رعایت کنه رو عنوان میکنم:

۱٫ درک کردن هدف برنامه ای که مینویسید

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

یادتون باشه: هدف نوشتن یک برنامه این نیست که نشون بده چقدر شما باهوشید.

برنامه نویسی که رویکردش رسیدن به اون هدف برنامه نباشه نهایتا یه برنامه بد تولید میکنه.

و برنامه بد چیه؟

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

۲٫ ساده سازی

سادگی، بالاترین پیچیدگی است. —لئوناردو داوینچی

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

یک برنامه نویس خوب برنامه ای میسازه که با نگاه کردن به کد میشه راحت فهمیدش و اگر احتیاج به تغییر داشته باشه، یه برنامه نویس دیگه به راحتی بتونه کدش رو (در صورت نیاز) تغییر بده و دیباگ کنه.

تقریبا میشه گفت همه برنامه نویس ها آدم های باهوشی اند و آدم های باهوش دوست ندارن که احمق فرض بشن. همین مسئله باعث میشه که تمایل داشته باشن که پیچیده تر کد بزنن. یا مثلا چنین تصوراتی ممکنه داشته باشن:

این طوری بقیه دولوپر ها کد هامو میفهمن، باید یه طوری کد بزنم که وقتی یه نفر میبینه بگه وای چقد باهوشه!!

این اشتباهات به خاطر ذهنیت و پیشفرض های ذهنی اشتباهه، نه به خاطر کمبود دانش اون فرد.

همواره اینو مد نظر داشته باشید که: برنامه نویس جدیدی که به پروژه شما اضافه میشه هیچی از پروژه نمیدونه و باید همه چیز رو با نگاه کردن به کد متوجه بشه.

حقیقت اینه که اگر این اتفاق بیوفته و برنامه نویس جدید به راحتی کد شما رو بفهمه، یعنی شما بردید و کارتون رو به درستی انجام دادید ?.

پیچیدگی باهوش بودن شما رو نشون نمیده، ولی سادگی این کارو میکنه.  — Larry Bossidy

حالا سوالی که پیش میاد اینه که چقدر ساده کد بزنیم؟ جواب: در حدی که یه احمق هم کد تون رو بفهمه!

۳٫ پیچیدگی

مدیریت پیچیدگی اساس برنامه نویسی کامپیوتری است. — Brian Kernighan

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

ولی این پایان ماجرا نیست.

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

چطور قربانی این پایان تلخ نباشیم؟

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

این ها دلایلی بود که به نظر من باعث ایجاد پیچیدگی در نرم افزار میشن. ممکنه دلایل دیگه ای هم وجود داشته باشه ولی به صورت کلی یک قانون جامع وجود داره:

هدف اصلی مدیریت و کاهش پیچیدگیه، نه اضافه کردن اون.

۴٫ نگهداری

نگهداری یک بخش بسیار مهم در نرم افزاره که متاسفانه اغلب اهمیتش فراموش میشه.

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

همه تغییرات و توسعه ها نیازمند نگهداری هست.

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

یه قانون مهم برای نگهداری پروژه:

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

۵٫ ثبات قدم

ثبات در پروژه هم یه بخش مهمی از سادگیه. منظور از ثبات اینه که اگر کاری رو در پروژه به یه شکل خاصی انجام میدید، همه جای پروژه به همون شکل انجام بدید. به عنوان مثال، اگر متغیر ها رو به صورت camelCase نام گذاری می کنید، در کل پروژه متغیر ها رو به صورت camelCase نام گذاری کنید.

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

۶٫ اولویت بندی

چطوری در مورد این که چه زمانی چه تسکی رو انجام بدید تصمیم میگیرید؟

شما میتونید با مد نظر گرفتن این سه فاکتور خیلی بهتر تسک ها و فیچر های درخواستی رو اولویت بندی کنید:

• میزان مطلوبیت این تغییر (D): چقدر به این تغییر احتیاج دارید و این تغییر چه اولویتی داره؟
• میزان ارزشی که این تغییر برای شما ایجاد میکنه (V): چقدر این تغییر ارزش داره چقدر میتونه به بیزینس شما نفع برسونه؟
• میزان زمان و انرژی لازم برای پیاده سازی این تغییر (E): چند واحد زمانی و چند نفر باید برای پیاده سازی این تغییر کار کنن؟

فرمول محاسبه اولیت: D=V/E

میزان مطلوبیت برای تغییر برابر با میزان ارزشی که برای بیزینس ایجاد میکنه رابطه مستقیم و با زمان و انرژی لازم برای ایجاد اون تغییر رابطه عکس داره.

وقتی که تسک ها رو اولویت بندی میکنید باید این قانون رو مد نظر بگیرید:

تغییرات و تسک هایی که ارزش بیشتر و زمان/انرژی کمتری دارن اولیت بیشتری نسبت به تغییرات و تسک هایی که ارزش کمتر و زمان/انرژی بیشتری دارن، دارن.

۷٫ توانایی حل مسئله

مهم ترین توانایی که یک برنامه نویس میتونه داشته باشه توانایی حل مسئله ست. برای حل مسئله اول باید مسئله رو کامل درک کنید. درباره چیزی که از شما خواسته شده کاملا توجیه باشید و هیچ ابهامی براتون نداشته باشه. اون مسئله رو یه کاغذ بنویسید و سعی کنید برای یه نفر توضیح بدید:

اگر نمیتونید یک مسئله رو خیلی ساده برای کسی توضیح بدید به این معنیه که شما اون مسئله رو نفهمیدید. — Richard Feynman

قدم دوم برنامه ریزیه، هیچ کاری نکنید و فقط به مسئله و راه حل هاش فکر کنید (به قول خارجی ها sleep on it) ، سعی کنید که مسئله رو تحلیل کنید و اطلاعات مربوط به اون مسئله رو تجزیه تحلیل کنید. سعی کنید که این قدم زمان زیادی از شما نگیره.

قبل از دست به کار شدن فکر کنید!

قدم سوم تکه تکه کردنه. سعی کنید که یه مسئله بزرگ رو یک باره حل نکنید. وقتی که به یه مسئله بزرگ برخورد میکنید ممکنه از بزرگ بودنش بترسید. بخاطر همین بهتره که یک مسئله بزرگ رو اول به زیر مسئله های کوچیک تر تقسیم کنید و اون زیر مسئله ها رو یک به یک پشت سر هم حل کنید و بعد در نهایت مسئله بزرگ حل میشه.

۸٫ اگر خوبه پس کافیه

عالی، دشمن خوبه. — Voltaire

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

میدونید نتیجه ش چی میشه:

• نوشتن یه عالمه کد که به اون هیچ احتیاجی نیست
• اضافه شدن یه عالمه پیچیدگی به پروژه
• اضافه شدن کد های به درد نخور به پروژه
• انعطاف بیش از حد پروژه
• رد شدن ددلاین های پروژه
• سروکله زدن با باگ هایی که به واسطه پیچیدگی تولید شده

در عوض باید چیکار کرد؟

اول کوچیک شروع کنید، بعد بهبود ببخشید، بعد گسترش بدید.

۹٫ فرضیه های اشتباه

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

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

برای جلوگیری از این قضیه باید این قانون رو مد نظر داشته باشید:

برنامه باید متناسب با نیازی که همین الان دارید نوشته بشه، نه نیازی که فکر میکنید در آینده ممکنه داشته باشید.— Max Kanat-Alexander

۱۰٫ چرخ رو دوباره اختراع نکنید!

به لطف کامیونیتی های نرم افزاری خیلی از کتابخونه ها و کد های آماده میتونن خیلی از بخش های پروژه تون رو هندل کنن و نیازی نیست که مجدد اون ها رو برنامه نویسی کنید.

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

• چیزی لازم دارید که وجود نداره
• چیزی که وجود داره با تکنولوژی بدی ایجاد شده یا نمیتونه نیاز شما رو برطرف کنه
• چیزی که الان وجود داره دیگه توسعه و نگهداری نمیشه

قانون:

چرخ رو دوباره اختراع نکنید!

۱۱٫ اتوماسیون یا خودکار سازی

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

اگر میشه اتوماتیکش کرد، اتوماتیکش بکن.

۱۲٫ اندازه گیری کد

اندازه گیری فرایند توسعه برنامه بر اساس تعداد خط کد مثل اندازه گیری فرایند ساخت هواپیما بر اساس وزنه. — بیل گیتس

بعضا دیده شده که برنامه نویس ها برنامه نوشته شده رو بر اساس تعداد خط کد اندازه گیری میکنند. اونها فکر میکنند که تعداد خط کد بیشتر یعنی انجام دادن کار بیشتر. یا مثلا فکر میکنن برنامه ای که تعداد خط کد بیشتری رو داشته باشه برنامه مهم تر و بزرگ تریه.

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

من نمیگم تعداد کمتر خط کد همیشه به معنی بهتر بودن اون برنامه ست ولی اگر فرض کنیم یک درصدی از خط کدی که نوشته میشه باگ داره (مثلا ۰٫۰۲ درصد) پس هرچقدر کد بیشتری نوشته بشه، باگ بیشتری ساخته میشه، همچنین پیچیدگی بیشتر به پروژه اضافه میشه و این باعث میشه که بقیه برنامه نویس ها سخت تر بتونن کد رو بفهمن و این یعنی نگهداری سخت تر میشه.

حالت بهینه اینه که کد کمتری زده بشه تا خوندن و فهمیدنش ساده تر باشه و البته تمام استاندارد ها رو هم رعایت کنه.

۱۳٫ میزان مفید بودن

میزان مفید بودن چطوری ارزیابی میشه؟ با نوشتن کد بیشتر یا با حذف کد یا چی؟

هدف اصلی برنامه نویس باید این باشه که پروژه رو کوچیک و تمیز نگه داره. پس “چطور کد بیشتری تولید کنم؟” و “چطور کد های قبلی رو کمتر کنم؟” به یک اندازه مهم اند.

یکی از روزهایی که بیشترین بهره وری رو داشتم روزی بود که ۱۰۰۰ خط کد رو حذف کردم.— Ken Thompson

۱۴٫ مستندات و کامنت گذاری

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

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

هدف اصلی کامنت گذاری اینه که “چرایی” اون قطعه از کد رو نشون بده نه “چگونگی” ش رو.

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

ما در بامیلو یک فرایند ۱۳ مرحله ای برای آشنایی با کل سیستم ها و تیم ها داشتیم که در قالب گیمیفیکیشن کل معماری بامیلو رو بهمون منتقل کرد. به نظرم همچین کاری خیلی مفیده.

۱۵٫ انتخاب تکنولوژی

برای انتخاب تکنولوژی این چند مورد رو بررسی کنید:

• آیا اون تکنولوژی هنوز در حال توسعه ست؟
• آیا نگهداری اون ادامه خواهد داشت؟
• آیا امکان عوض کردن اون تکنولوژی در آینده وجود داره؟
• آیا اون تکنولوژی کامیونیتی و جامعه ای داره که ازش پشتیبانی کنند؟

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

۱۶٫ رشد فردی

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

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

بدانید و آگاه باشید که همه تکنولوژی ها خوبن، فقط کافیه ۱) در جای درستی ازشون استفاده کنید ۲) به درستی ازشون استفاده کنید.

۱۷٫ سوال نپرسید

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

همیشه گوش شنوا داشته باشید و به توانایی هاتون مغرور نباشید. من این اطمینان رو بهتون میدم که حجم چیز هایی که نمیدونید بسیار بسیار بیشتر از چیز هاییه که میدونید.

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

حرف آخر:

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

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

د