نود و هفت چیزی که هر برنامه‌نویسی باید بداند: پشت هر خط از کد شما می‌بایست یک منطق وجود داشته باشد!


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

یک برنامه نویس حرفه‌ای کسی است که سورس کد پروژه ی خود را به بخش‌های کوچک تقسیم‌بندی کرده -خواه بخش‌های یک خطی مثل فراخوانی یک فانکشن، خواه بخش‌های مثلاً ده خطی- و از صحت کارکرد این بخش‌های سورس کد اطمینان حاصل کند. اگر شما بتوانید به اندازه‌ای از کارکرد سورس کد پروژه ی خود اطمینان داشته باشید که یکی از دوستان برنامه نویس شما -که نقش Devil`s Advocate را بازی می کند- نتواند به آن گیر دهد، کفایت می‌کند و شما به هدف خود دست یافته اید.

به خاطر داشته باشید
به طور کلی منظور از Devil`s Advocate یا «وکیل مدافع شیطان» کسی است که مهارت خاصی در ایراد بنی اسرائیلی گرفتن دارد و همواره نیمه ی خالی لیوان را نگاه می کند. ممکن است این تصور برای شما پیش بیاد که در شرکت های حرفه‌ای چنین افرادی اصلاً جایگاه خوبی ندارند اما این باور کاملاً اشتباه است. شرکت های تراز اول برای وکلای مدافع شیطان سر و دست می شکنند چرا که این افراد می‌توانند متضمن موفقیت یک محصول شوند.

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

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

- تا حد ممکن از متغیرهای گلوبال که امکان تغییر مقادیر آن‌ها وجود دارد استفاده نکنید چرا که این دست متغیرها منجر به ایجاد وابستگی مابین بخش‌های مختلف کد می‌شوند (منظور از متغیرهای گلوبال، متغیرهایی است که در بدنه ی کلاس‌ها تعریف شده و به نوعی public هستند؛ یعنی از هر کجای برنامه می‌توان به آن‌ها دسترسی داشت.)

- هر متغیر می بایست تا حد ممکن از Scope یا «حوزه ی» کوچکی برخوردار باشد. به عبارت دیگر، مثلاً به جای تعریف کردن متغیری تحت عنوان userAccountNumber که گلوبال است، بهتر است که این متغیر را داخل یک فانکشن تعریف کنیم و صرفاً داخل همان فانکشن به آن دسترسی داشته باشیم.

- از فضاهای خالی به منظور خوانایی بیشتر کد استفاده کنید. به عبارت دیگر، بخش‌های مختلف سورس کد را با زدن اینتر مجزا کنید و در عین حال هم از Indentation های درست استفاده کنید (منظور از Indentation، اسپیس هایی است که از سمت چپ ویرایشگر کد تا ابتدای دستورات وجود دارند.) امروزه اکثر IDE ها دارای این قابلیت هستند تا به صورت خودکار، فواصل سورس کد را منظم کنند.

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

- اگر منطق برنامه ی شما به گونه‌ای است که نیازمند بخش‌های تو در تو است، بهتر آن است که هر بخش را در قالب یک فانکشن کدنویسی کنید.

- هر فانکشن می بایست فقط و فقط یک کار را انجام دهد و از نوشتن فانکشن های «همه کاره» شدیدا خودداری کنید. گفته می‌شود که یک فانکشن خوب، فانکشنی است که در صفحه ی مانیتور، بدون نیاز به اسکرول کردن، ابتدا و انتهای آن معلوم باشد. یعنی چیزی در حدود 24 خط کد! (البته بسته به رزولوشن و اندازه ی مانتیور، این قانون برای برنامه نویسان مختلف نتایج کاملا متفاوتی دارد.)

- تعداد پارامترهای ورودی فانکشن ها می بایست محدود باشد (مثلاً 4 پارامتر ورودی به نظر محدودیت خوبی به نظر می آید) و در صورتی هم که تعداد پارامترهای ورودی مد نظر شما زیاد است -مثلا 12 پارامتر ورودی- می‌توانید پارامترهای مرتبط با یکدیگر را در قالب یک آبجکت تعریف کرده و از آن آبجکت به عنوان یکی از پارامترها استفاده نمایید.

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

لیست نظرات
کاربر میهمان
دیدگاه شما چیست؟
کاربر میهمان
محسن
محسن
درباره مفهوم Devil\s Advocate یا «وکیل مدافع شیطان» هم پیشنهاد می کنم مطلب خیلی خوب
Devil’s Advocate (وکیل مدافع شیطان) کیست و چرا حضورش در استارتاپ‌ها الزامی است!
https://sokanacademy.com/blog/5899/post
رو بخونید، چون این نقش اهمیت فوق العاده ای در پروژه ها به خصوص استارتاپ ها داره
محسن
محسن
اینکه برنامه به صورت تابع های مجزا نوشته مزایایی خیلی زیادی داره که در مطلب هم به برخی اشاره شد
مثل تمیز تر شدن و خوانا ترشدن کد و در نتیجه راحت تر میشه اشکالات رو برطرف کرد
اما به نظرم من مهمترین مزیت استفاده از فانکشن ها در برنامه اینکه اگر خوب نوشته شده باشن و یا حتی در فایل های جدا نوشته بشن و به صورت اکسترنال فراخوانی بشن این هست که میشه در پروژه های بعدی هم ازشون استفاده کرد (reusability) و یا ریفکتور بشن و اینجوری در زمان و هزینه خیلی صرفه جویی میشه،حتی اگر خیلی خوب و کاربردی باشن میشه در سایت هایی مثل گیت هاب به اشتراک گذاشت تا همه ازش استفاده کنن
و همینطور درباره اینکه هر تابع بهتر هست یک کار انجام بده، در نتیجه این کار استفاده و تعریف تابع ها کمک می کنه تا اگه نیاز بود خروجی یک تابع ورودی تابع دیگه ای باشه، اعمال تغییرات و یا اصلاحات راحت تر و سریعتر انجام بشه
Insight
Insight
اگر به قضیه اینجوری نگاه کنیم که ما به عنوان موجوداتی هوشمند قراره به کامپیوتری که فقط بلده دستورات داده شده رو اجرا کنه، پس هر کاراکتری که به عنوان کد مینویسیم وظیفه ی مشخصی داره.
برای حل یک مسئله حتما باید منطق کد ما صحیح باشه در غیراینصورت اصلا به جواب نمیرسیم. حالا اگه الگوریتم بهتری نوشته بشه، ما بهینه تر به جواب میرسیم.
یک سری Best Practice وجود داره که به ما کمک میکنه،‌ علاوه بر منطقی که برای حل مسئله وجود داره، هر دستور منطقی‌تر باشه. مثل نامگذاری شناسه‌ها در کدنویسی
vahid
vahid
منتظر ادامه دوره هستیم!
پیروز و سربلند باشید.