۱۵ توصیه من به برنامه نویسان

پس از قریب به ۲۰ سال شبانه‌روز کدنویسی کردن و مو سفید کردن در این وادی، ۱۵ تجربه مهم کسب کرده‌ام که گاهی با خودم می‌گویم اگر یک نفر بود این‌ها را با تأکید فراوان در همان ابتدا به من بگوید، الان به جای زجر کشیدن از ویرایش پروژه‌های قدیمی، از آن‌ها لذت می‌بردم.

این نکات را در حین تدریس دوره‌های برنامه‌نویسی یک به یک به یاد آورده‌ام و یادداشت کرده‌ام و البته دانش‌جویان می‌دانند که چقدر در کلاس‌ها روی آن‌ها تأکید می‌کنم؛ هدیه به شما:

۱- از تکرار بپرهیزید؛ حتی یک خط کد

این مهم‌ترین توصیه هر برنامه‌نویسی در طول تاریخ برنامه‌نویسی است. اصلاً نسل‌های مختلف برنامه‌نویسی و هر چقدر برنامه‌نویسی پیشرفت می‌کند فقط دارد «تکرار» کمتر می‌شود.

این جمله را دانش‌جویان بارها از من می‌شنوند:

اگر یک قطعه کد را دو بار تکرار کردید، حتماً یک راه برای جلوگیری از این تکرار وجود داشته که باید آن راه را یاد بگیرید.

معمولاً وقتی برنامه‌نویس مشغول کدنویسی است، وقتی راه حل یک مسأله را می‌یابد، ذوق می‌کند و دوست دارد سریعاً کد را بنویسد و پروژه را منتشر کند یا کد را تحویل دهد اما اگر کمی صبر کند و بیشتر روی کد متمرکز شود می‌بیند که تکرارهای زیادی داشته که این تکرارها بعدها استخوان در گلو می‌شود! باور کنید انسان را پیر می‌کند! من وقتی الان به کدهایی که مثلاً در پروژه تستا ۳ نوشته‌ام نگاه می‌کنم اصلاً تعجب می‌کنم که چرا این همه تکرار داشته‌ام؟ مثلاً برای محاسبه نمره یک داوطلب، چندین بار محاسبات سنگین نمره در بخش کاربری، در بخش مدیریت، در آمار کل داوطلبان و و و ... تکرار شده است! این‌ها اکنون که مثلاً می‌خواهم یک تغییر کوچک در کارنامه یا در نحوه محاسبه نمره بدهم بیچاره‌ام می‌کند. و یا اگر یک مشتری سفارشی‌سازی داشته باشد، شما مجبورید با یک هزینه کم، ساعت‌ها درگیر تغییر کدهای تکراری خود باشید!

۲- تابعی عمل کنید؛ حتی ساده‌ترین کارها را

هر کاری که می‌خواهید روی یک سری داده انجام دهید، سعی کنید آن کار را در قالب یک تابع تعریف کنید. حتی ساده‌ترین کارها. مثلاً اگر قرار است یک عنصر در صفحه را ltr کنید، یک تابع برای این کار تعریف کنید.

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

۳- نام‌ها مهم هستند؛ در انتخاب نام‌ها بسیار دقت کنید

یکی از بدترین عادات یک برنامه‌نویس انتخاب سرسری نام متغیرها و تابع‌ها و کلاس‌ها و... است. من خودم واقعاً از کدهای قدیمی‌ام خجالت می‌کشم! در هر بخشی یک نوع نام‌گذاری متفاوت داشته‌ام!

از بین سه قاعده مشهور نام‌گذاری متغیرها (یعنی کوهان‌شتری: myVariable و پاسکال: MyVariable و آندرلاین: my_variable) یکی را انتخاب کنید و تا انتها به آن پایبند باشید.

من بعد از این همه پروژه و... به این نتیجه رسیده‌ام که روش کوهان‌شتری مزایای بیشتری دارد.

نام‌ها را حتماً مرتبط با محتوای مخزن انتخاب کنید. مثلاً اگر قرار است یک متغیر حاوی شمارشگر دانشجویان باشد به جای i از stCounter یا studentCounter استفاده کنید.

۴- یا زنگی زنگ؛ یا رومی روم: فواصل را در همه جا به یک صورت در نظر بگیرید.

فواصل بین نام متغیر و = و مقدار و این نوع فواصل را به یک صورت در کل پروژه پیش ببرید؛ به یکی از این دو صورت:

var x = 5;

var x=5;

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

مهم این است که در همه جا به یک صورت عمل کنید. اگر کدها را کثیف نوشته‌اید، می‌توانید از Code Beautifierها استفاده کنید تا آن‌ها کدهایتان را مرتب کنند.

۵- کامنت، کامنت، کامنت!

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

بدون کامنت مناسب (نه کم و نه زیاد) کدنویسی فرسایشی می‌شود.

۶- از ثوابت استفاده نکنید!

هر چند ممکن است توصیه به عدم استفاده از ثوابت، از نظر علمی درست به نظر نرسد اما از نظر عملی من به شما می‌گویم که بخشی از موهای سفیدم(!) به خاطر استفاده از constantها یا ثوابت است.

شما به احتمال ۹۹ درصد در آینده نظرتان عوض می‌شود و می‌خواهید محتوای یک مخزن را در طول برنامه تغییر دهید. اگر از ثوابت استفاده کرده باشید، طبیعتاً ممکن نیست و تغییر آن هم به متغیر، به این راحتی ممکن نیست. مثلاً در پروژه‌های تستا و نمرا، ما جملات فارسی سیستم را به صورت ثوابت تعریف کرده‌ایم:

چه می‌دانستیم یک روز مشتری می‌خواهد به جای «نام کاربری» کلمه «کد ملی» درج شود! حالا اگر مشتری بخواهد این را تغییر دهد در هر آپدیت دوباره به حالت اول برمی‌گردد. اما اگر به صورت متغیر تعریف می‌کردیم خیلی راحت یک کپی از این می‌گرفت به فایل farsi.custom می‌برد و در آنجا به عبارت دلخواهش تغییر می‌داد و ما آن را در نظر می‌گرفتید و در آپدیت‌ها هم که آن فایل را به‌روز نمی‌کنیم.

۷- داده‌ها را یک‌باره به خروجی بفرستید

وای! این باید در صدر همه نکات قرار می‌گرفت! نمی‌دانید این موضوع چقدر مهم است! عزیزانم، هرگز خروجی را خط به خط تولید نکنید؛ بلکه هر چیزی که قرار است به خروجی برود را در یک متغیر بریزید و در انتها آن متغیر را به خروجی بفرستید.

مثلاً به جای اینکه بنویسید:

بنویسید:

یعنی شما باید عادت کنید که در کل پروژه‌تان فقط یک echo به خروجی داشته باشید! همین و بس!

هر کدام از این نکات را که می‌نویسم یک عمر زجر و تلاش اضافه از مغزم عبور می‌کند و افسوس می‌خورم که ای کاش این‌ها را در ابتدای کدنویسی می‌دانستم :( همین مورد من را بیچاره کرده!

۸- بیشتر از ۸۰ کاراکتر در هر خط، کد ننویسید

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

اکثر IDEها یک Ruler دارند که در ستون ۸۰ یک خط نشان می‌دهد که برنامه‌نویس از آن خط تجاوز نکند. آن را فعال کنید و هرگز کد را بیشتر از ۸۰ کاراکتر در هر خط کِش ندهید. مثلاً این کد مسخره‌ای که من ده سال پیش نوشته‌ام:

باید اینطور می‌بود (تصور کنید چقدر از کد در سمت راست بوده!):

۹- قبل از انجام تغییرات اساسی در کدها یا دیتابیس، یک بک‌آپ بگیرید

بارها شده که مثلاً با اطمینان و خیال راحت آمده‌ام یک دستور UPDATE در دیتابیس را اجرا کرده‌ام و مثلاً متوجه شده‌ام که یادم رفته در این دستور WHERE بزنم یا WHERE صحیح نبوده و زده تمام رکوردهای دیتابیس را داغون کرده! همینطور در کدهای برنامه‌نویسی. دیگر هر وقت می‌خواهم هر کاری روی دیتابیس خودم یا مشتری انجام دهم، یک بک‌آپ می‌گیرم.

۱۰- چند فیلد اضافه برای روز مبادا در دیتابیس در نظر بگیرید

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

۱۱- عادت کنید که از try ... catch استفاده کنید

این یکی از عادت‌های خوب است که در جاهایی که احتمال خطا می‌رود، از try ... catch استفاده کنید. درباره مدیریت استثناءها با try ... catch بیشتر مطالعه کنید... درباره عادت‌های خوب در برنامه‌نویسی بیشتر جستجو و مطالعه کنید. عادت کنید که «خوب» کد بنویسید.

۱۲- پیچیدگی‌ها را از دید کاربر مخفی کنید

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

و خلاصه این جمله در ذهن شما باید تکرار شود: Hide system complexity from the End-user

۱۳- کاربر را اذیت نکنید!

باور کنید برخی برنامه‌نویس‌ها بلانسبت سادیسم دارند و انگار از آزار و اذیت مردم لذت می‌برند. یک نمونه که نوبر بود را در درگاه پرداخت قسط بانک مسکن دیدم! دقت کنید:

اولاً که باید از این برنامه‌نویس پرسید فلسفه کپچا چیست؟ پاسخ: در این فرم، جلوگیری از حمله Brute force  (در فرم‌های ثبت‌نام جلوگیری از حمله DOS) خوب، حالا چرا یک هکر حمله Brute Force انجام می‌دهد؟ برای اینکه نام کاربری و رمز یک نفر را کشف کند و مثلاً به اکانت او نفوذ کند. حالا در صفحه‌ای که یک شماره اقساط پرسیده می‌شود به نظر شما کپچا لازم است؟ کدام هکر احمقی می‌آید حمله Brute Force کند که شماره کارت اقساط مردم را هک کند!! (مثل آن دزدی که کیف مردم را زده بود، دید داخلش قبض برق هست و دارد تاریخش می‌گذرد رفت پرداخت کرد!!) حالا برفرض یک هکر احمق این کار را کند، خوب، آیا باید همان اول کپچا را نشان داد؟ قطعاً می‌دانید که وقتی حمله بروت فورس رخ می‌دهد که مثلاً پنج بار بیشتر یک چیزی تست شود. پس نمایش کپچا در هیچ فرمی در بار اول و دوم و سوم و چه بسا تا پنجم لازم نیست (همانطور که ما در سیستم‌هایمان تا ۵ بار اگر کاربر نام و رمز را غلط بزند کپچا نشان نمی‌دهیم)، بله اگر بیش از ۵ بار این فرم اشتباه پر شد، شک می‌کنیم که حمله بروت‌فورس است و حالا کپچا را نشان می‌دهیم. حالا در این سایت، اصلاً کپچا که لازم نبوده، برفرض اگر لازم بوده، تا ۵ بار اشتباه هم نباید نشان داده می‌شد، حالا مهم نیست، کپچا را همان بار اول نمایش داده، اما اینکه کپچا را وارد کنی و بعد دوباره یک کادر باز شود و بنویسد جمع دو عدد را بنویس، این دیگر نوبر است!!!!!!! حالا از این نوبرتر اینکه باز از این همه خان عبور می‌کنی و می‌روی صفحه بعد، آنجا هم یک کپچای دیگر قبل از ورود به درگاه وجود دارد!!!!!!!!!!!!!!!!!!!!!!!!!!!! به خدا دلم می‌خواهد گریه کنم!

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

(در مورد این موضوعات در مطلب «اهمیت طراحی با کاربری آسان در جذب مشتری (Usability) (مطلب شماره ۱)» قبلاً توضیح داده‌ام)

۱۴- کدها را سریع حذف نکنید؛ کامنت کنید

اگر به این نتیجه رسیدید که این پیاده‌سازی از الگوریتم را نمی‌پسندید و یک پیاده‌سازی دیگر را می‌پسندید، کدهای قبلی را فعلاً سریع پاک نکنید؛ آن‌ها را کامنت کنید؛ شاید نظرتان عوض شد.

اصولاً در حذف کامل هیچ چیزی عجله نکنید...

۱۵- در جاهایی که مغزتان به جایی راه نمی‌دهد، از خدا کمک بخواهید

برنامه‌نویسی یعنی قدرت حل مسأله... اما گاهی یک مسأله پیش می‌آید که واقعاً عقل انسان به جایی راه نمی‌دهد! من روزانه با این مسائل مواجه می‌شوم. در این مواقع به روش ابن سینا عمل کنید که نقل می‌کنند که هر گاه به یک مسأله پیچیده برمی‌خورد، دو رکعت نماز می‌خواند و جواب را در نماز یا بعد از آن می‌یافت. در یک نگاه فیزیولوژیکی باید بگوییم که کمی به خودتان استراحت بدهید و مغزتان را راحت کنید؛ اما چه آرامش‌بخشی بهتر از نماز؟ و اینکه در مسائل پیچیده یواشکی دست‌هایتان را به سمت آسمان بالا ببرید و از خدا بخواهید که مسأله را آسان کند. من همیشه این کار را کرده‌ام و باور کنید گاهی موضوعی که فکر می‌کردم چند روز من را درگیر می‌کند ناگهان یک الگوریتم بسیار آسان‌تر به ذهنم رسیده که با چند خط کد آن نیاز مشتری و خودم تأمین شده!

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

موفق باشید؛
حمید رضا نیرومند