فعال در حوزه های هوش مصنوعی .علوم داده . رایانش امن و ابری . دانش آموخته دانشگاه صنعتی امیرکبیر . مدیر تست نفوذ و امنیت شبکه .کارشناس امنیت شرکت فناوری اطلاعات نوین ،
درس هایی راجب برنامه نویسی از زبان Matt Butcher
درس هایی راجب برنامه نویسی از زبان Matt Butcher
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این حرف خیلی معنی داره که تو ادامه میگم:
- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن
برنامه نویسی به عنوان صنعتگری
«صنعتگری» به معنی تعهد به یه حرفه است، جایی که مهارت با گذشت زمان و از طریق تلاش سخت و تمرین مداوم به وجود میاد. نوشتن کد، با تمام دیباگ و تست کردن و بازنویسیهاش، یه کار کاملاً عملیه. ساختن نرمافزار خوب به مهارت، دانش و تمایل مداوم برای پیشرفت نیاز داره. وقتی کد مینویسین، وقت بذارین که کارتون رو خوب انجام بدین. درسته که «کمالگرایی دشمنه» و باید کد بزنین که کارتون راه بیفته. اما رعایت اصول درست کد نویسی، اسمگذاری درست متغیرها و فکر کردن به مشکلی که دارین حل میکنین، همه اینا باعث میشه که نگهداری از کدتون تو دراز مدت راحتتر بشه.
پشتیبانی از کد ضعیف یه درده. اما نگهداری از کد خوب، از لحاظ فکری خیلی راضیکنندهست.
چرخ رو از اول اختراع نکن
یه کتابخونه یا ابزاری هست که کار رو راه میندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر میکنم هر مهندس نرمافزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:
کتابخونههای دیگهای هم بودن، اما سنگین/پر از باگ/پیچیده/و …
یه راه جدید دارم که بقیه بهش فکر نکرده بودن.
انجام دادنش خودم بیشتر یاد می گیرم تا اینکه از کد بقیه استفاده کنم (حرفت درسته، اما با هزینهای خیلی بیشتر از اون چیزی که فکرشو میکردی).
تو همه این موارد، دو تا چیز نادیده گرفته میشن:
چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.
پس وقتی که ابزار آماده هست، اما فکر میکنین شاید خودتون بهتر انجامش بدین، از خودتون بپرسین چقدر برای نگهداری از اون کد تو چند سال آینده اشتیاق دارین؟ آیا استثناهایی برای این قضیه وجود داره؟ بله! اما اونم بعد از اینکه واقعاً بررسی کردین که آیا راهحلهای موجود به اندازه کافی برای انجام کار خوب هستن یا نه.
هر چی کدت پیچیدهتر، دیباگش سختتره
فرض کنید یه تابع می نویسید که یه عملیاتی رو انجام میده ولی کدش پیچیدس و حالا برای دفاع از خودتون میگید تست نوشتید. و کدتون ار نظر فرمت بینقص و خیلی خوب کار میکنه. بعد یه روز یه آسیبپذیری پیدا میشه. یه هکر بتونه تابعی که نوشید رو مجبور کنه که بیشتر از حافظهی سیستم، حافظه اختصاص بده. بعد از چند سال که اصلاً به این کد دست نزدید، باید درستش کنید. وقتی کد رو میخونید، انگار یه چیز کاملاً غریبس , باید بفهمید چطور میتونید اون باگ رو درست کنید.
شاید مجبور بشین خطهای بیشتری کد بنویسین (چون کارهای پیچیده رو به تابعهای کوچیکتر تقسیم میکنین)، اما اگه نتیجهش بشه کدی که دیباگ و نگهداریش راحتتره، ارزشش رو داره.
کاهش نیازهای آینده برای پشتیبانی
هر سیستم خوبی یه سری کنترل کیفیت داره. کد هم باید همینطور باشه. باید یه استراتژی برای تست نوشتن پیدا کنید،به هر حال، مهم نیست استراتژی شما چیه، اگه الان تست نکنین، بعداً باید دیباگ کنین.
خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همهچی رو مستند کن! آدما یه جور پیشفرض عجیب دارن. فکر میکنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون میمونه. خود آیندهت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.
بهترین راهی که میتونی با محدودیتهای حافظهت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:
کامنت بذار.
اسمها رو خوب انتخاب کن.
مستندات خوب بنویس.
کامیتمسیجهای مفید بنویس.
خود آیندهت ازت ممنون میشه. یا حداقل از دستت عصبانی نمیشه.
نتیجه گیری: اگه بقیه نتونن اونو بفهمند، همیشه مشکل شما باقی میمونه
پس طوری مستندش کن که بقیه بتونن اونو بفهمند.
اگه کدتون راحتفهم نباشه، مثل یه کابوس برمیگرده سراغتون. چون بقیه نمیتونن اونو بفهمند. کدتون رو انقدر راحتفهم کنین که یه نفر دیگه بتونه اونو درست کنه بدون اینکه حتی نیاز باشه شما بفهمین!
نتیجه گیری
این قانون رو به عنوان یه راه برای ترغیب کردن خودتون به بهبود کدتون پیشنهاد میدم:
یادتون باشه هر خط کدی که مینویسین باید بعدا ازش پشتیبانی کنین!
این کار باعث صرفهجویی در زمان و انرژی شما در آینده میشه. باعث میشه همکاراتون عصبانی نشن. تغییر دادن کد امروز به کد فردا رو راحتتر میکنه. و به احتمال زیاد باعث میشه همه فکر کنن شما هم یکی از اون برنامهنویسهای فوق حرفهای هستین.
مطلبی دیگر از این انتشارات
زبان های برنامه نویسی
مطلبی دیگر از این انتشارات
فرمتینگ مناسب در پایتون
مطلبی دیگر در همین موضوع
جای ادوارد هاپر خالی