begin
تجربه ی جناب مهندس Giles Colborne !
گاهی اوقات برنامه نویسان گمان می‌کنند که کاربران برنامه یا اپلیکیشنی که توسعه می دهند مثل حودشان فکر می‌کنند و همان ارتباطی که خود با برنامه شان دارند را کاربران دیگر هم خواهند داشت که این ایده معمولا اشتباه است. چنین باوری از دید روانشناسی اصطلاحاً False Consensus Bias نامیده می شود. این Bias توضیح میدهد که چرا برخی برنامه نویسان بعضاً اوقات سختی را در محل مشتری میگذرانند!
Apply Functional Programming Principles
begin
استفاده ی اصولی از قواعد برنامه نویسی تابعی
تجربه ی جناب مهندس Edward Garson !
Functional Programming این اواخر طرفداران بسیاری پیدا کرده است. این مدل عبارت است از روشی که در آن منطق به کار گرفته شده در برنامه مشابه مبحث منطق در توابع ریاضی در نظر گرفته می شوند. اگر شما درک عمیقی از این مدل داشته باشید و آن را به کار ببرید طراحی های شما دارای یک شفافیت ازجاعی (Referential transparency) خواهد بود و به عبارتی در سطح بالاتری از کیفیت قرار میگیرند.
Referential transparency یک ویژگی بسیار مطلوب است و دلالت بر این دارد که توابع ، به شکل با ثباتی میتوانند در شرایط یکسان (ورودی های یکسان) همیشه به یک شکل کار کنند و خروجی مورد نظر را فراهم نمایند صرفنظر از اینکه از کجا و در چه زمانی Call شوند.استفاده از توابع اجازه میدهد وظایف بزرگ به وظایف کوچک تر تبدیل شوند و Debug کردن به شکل فزاینده ای آسان شود.
از معایب این روش نیز استفاده ی بی رویه از پارامترها در تابع میباشد به شکلی که یک ابَر تابع میسازید که ده ها وظیفه ی مختلف را انجام میدهد و تعداد زیادی پارامتر دارد که با تغییر یکی رفتار برنامه زیر و رو میشود! (ابن مورد یک بدهی فنی محسوب و اصلا توصیه نمیشود!)
end.
begin
چیز یک : تجربه ی جناب Seb Rose
بدهی فنی ...
پیش می‌آید که باید بین «انجام اصولی یک پروژه» و «انجام سریع یک پروژه» یکی را انتخاب کنیم و در ابتدای کار سرعت بخشیدن به فرایند طراحی جذاب‌تر به نظر می‌رسد با این استدلال که بعداً هم میشود مجدد به کدها سر زد و اگر مشکلی داشت آن ها را از بین برد! اما تجربه نشان داده است زمانی که در بر گیرنده واژه ی بعداً است، خود حاوی بسیاری باگ ها و مشکلات خواهد بود که برنامه نویس مجبور است بیشتر تمرکز خود را روی آن‌ها بگذارد و از توجه به مشکلات -هرچند جزئی- گذشته باز می ماند.
چنین سیاستی در برنامه نویسی اصطلاحاً Technical Debt گفته میشود که به صورت تحت الفظی می‌توان آن را به «بدهی فنی» ترجمه کرد . این بدهی فنی اصلاً چیز خوبی نیست و گاهی اوقات منجر به بوجود آمدن فجایعی در تولید نرم افزار می شود. برای روشن شدن این مسأله مثالی می زنیم. بدهی فنی همچون وام گرفتن است که در کوتاه مدت کار ما را راه می‌اندازد اما غافل از این که در آینده می بایست با بهره ای که روی آن می‌آید -n درصد بیشتر- قرض خود را پرداخت کنیم.
در برنامه نویسی هم قضیه دقیقاً به همین صورت است. اگرچه گاهی اوقات می‌توان از راه کارهایی استفاده کرد که به کدنویسی ما سرعت بخشند اما این در حالی است که در آینده اضافه کردن ویژگی‌های جدیدی به پروژه را دشوار می‌سازد و به اصطلاح نمی‌توان به سادگی کدهای خود را Refactor کرد. جالب اینجا است که هرچه از زمان ایجاد این دست مشکلات بیشتر می گذرد، یافتن راه‌کار هم برای آن‌ها دشوارتر خواهد شد. اما اگر ما از زمان بندی پروژه عقب باشیم و مجبور باشیم سرعت عمل را بر کیفیت ترجیح دهیم چطور؟ توصیه ما این است که هرگز سیاست فدا کردن کیفیت کار به خاطر سرعت بخشیدن به آن را دنبال نکنید اما اگر واقعاً مجبور هستید، پس این کار را انجام دهید و حتماً به خاطر داشته باشید که شما با این کار یک بدهی فنی برای خود ایجاد کرده‌اید که می بایست در اولین فرصت این بدهی خود را صاف کنید. برای این منظور هم، حتماً در مستندات پروژه این قضیه را ذکر کنید تا فراموش نشود که در غیر این صورت ممکن است مجبور شوید بهای گزافی بابت آن بپردازید. (مطلب بعدی: چیز 2!)
end.
begin
مقدمه)
در سال 2010 انتشارات Oreilly کتابی با عنوان
Ninety Seven Things Every Programmer Should Know عرضه نمود.
در کتاب فوق 97 نکته ی کاربردی با توجه به تجربیات برنامه نویسان برتر دنیا (تا آن روز!) ارائه شد.در ادامه و در آینده طی 97 مطلب جداگانه ، تک تک این Best Practice ها را بررسی خواهم نمود. (دانلود کتاب اصلی) برو به مطلب بعدی : چیز1 !
end.
