دسته: آموزش

نقد الگوهای طراحی – Design Pattern

به نظر می رسد که فقط افراد تنبل هنوز الگوهای طراحی را نقد نکرده اند. بیایید نگاهی بیندازیم به معمولی ترین استدلال ها در مورد استفاده از الگوها. کمکی  برای یک زبان برنامه نویسی ضعیف معمولاً نياز به الگوها هنگامي بوجود مي آيد كه افراد يك زبان برنامه نويسي يا فن آوري را انتخاب كنند […]

تاریخچه الگو ها (Design Patterns)

history

چه کسی الگوها را اختراع کرد؟ این سوال خوبی است ، اما خیلی دقیق نیست. الگوهای طراحی ، مفاهیم مبهم و پیچیده ای نیستند – درست برعکس الگوها راه حلهای معمولی برای مشکلات رایج در طراحی شی گرا هستند. وقتی یک راه حل در پروژه های مختلف بارها و بارها تکرار می شود ، سرانجام […]

الگوهای طراحی – Design Patterns

الگوی طراحی چیست؟ الگوهای طراحی(دیزاین پترن) راه حل های معمول برای مشکلات معمول در طراحی نرم افزار است. آنها مانند نقشه های از پیش ساخته شده ای هستند که می توانید آنها را برای حل مشکلات طراحی تکراری در کد خود سفارشی کنید. اصولا نمی شود یک الگو را پیدا کنید و آن را در […]

تکنیکهای ریفکتور

بازآرایی متد ها (Composing Methods) بخش اعظمی از refactoring شامل اصلاح و بازآرایی متد ها است. در بیشتر موارد ، متدهای بیش از حد طولانی ریشه همه مشکلات هستند. مبهم بودن کد موجود در این متد ها منطق اجرا را پنهان می کند و درک متد را بسیار دشوار کرده و تغییر آن را سخت […]

بوی بدِ کد – Bad Smells

بوی بد کد

در ادامه مباحث ریفکتورینگ به بوی کدها می پردازیم. مگر کدها بو می دهند؟ اگر سعی کنید بوی آنها را حس می کنید.نشانه های بوی بد کد ها را بشناسیم تا آنها را پیدا کنیم. بزرگها! کلاسها و متدهایی که آنقدر بزرگ می شوند که کار کردن با آنها سخت می شود. البته اوایل بوی […]

چطور ریفکتور کنیم؟

refactoring checklist

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

چه زمانی باید ریفکتور کنیم؟

refactoring

در نوشته های قبلی فهمیدیم که لازم است ریفکتور(بازسازی یا اصلاح کد) داشته باشیم. و اما یک قانون: قانون 3 وقتی کاری برای بار اول انجام می شود، فقط انجام می دهیم وقتی کار مشابهی را برای بار دوم انجام می دهیم، یواشکی! انجام می دهیم اگر برای برای سوم شد حتما باید ریفکتور کنیم […]

بدهی فنی – Technical debt

Technical Debt

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