دوره عملی طراحی و پیاده‌سازی معماری نرم‌افزار به کمک TDD

محل برگزاری مدرس تاریخ شروع اولین جلسه روز و ساعت مدت زمان کل دوره تعداد جلسات هزینه ثبت‌نام زود هنگام هزینه ثبت‌نام عادی لینک ثبت نام
آنلاین مسعود بهرامی 25 آبان 1399 1شنبه و 4 شنبه‌ها ساعت 17:30 تا 20:30 30 ساعت 10 جلسه 3 ساعته 1000000 هزار تومان 140000 هزار تومان ثبت ‌نام

این دوره مخصوص چه افرادی است؟


توسعه‌دهندگان، طراحان و معماران نرم‌افزار و همچنین CTOها و Team Leader هایی که دغدغه توسعه یک نرم‌افزار با کیفیت بالا و تست‌پذیر که در مقابل تغییرات در نیازمندیها منعطف می‌باشد را دارند.

مزایای شرکت در دوره


این دوره بصورت آنلاین برگزار می‌شود. و ویدئوها و فایل‌های تمامی جلسات در اختیار شرکت‌کنندگان قرار می‌گیرد. در نتیجه در صورتی که نتوانید در یک جلسه شرکت کنید قادر خواهید بود ویدئوی آن جلسه را پس از پایان جلسه در اختیار داشته باشید.

همچنین گروه پشتیبانی جهت پاسخ به سوالات و راهنمایی دانشجویان، در طول دوره برای تمامی شرکت کنندگان وجود دارد.

پیش‌نیازهای دوره


برای شرکت در این دوره نیاز می‌باشد که تجربه برنامه نویسی داشته باشید و با مفاهیم برنامه نویسی شی‌گرا و همچنین Clean Code آشنا باشید.

در صورتی که با برنامه شی‌گرا و مفاهیم Clean Code آشنا نیستید و تجربه کافی ندارید، پیشنهاد می‌کنیم در دوره‌ی الگوها، اصول و تکنیک‌های Clean Code مکتب‌خانه DDD شرکت کنید.

ابزارها، تکنولوژی‌های و زبان برنامه‌نویسی مورد استفاده در دوره


این دوره آموزشی به زبان برنامه‌نویسی و یا تکنولوژی خاصی وابسته نیست و محتوای آن قابل پیاده‌سازی در تمامی زبان‌های برنامه‌نویسی شی‌گرا می‌باشد.

در این دوره برای پیاده‌سازی پروژه‌ها و کد‌ها از زبان برنامه‌نویسی #C و پلت فرم dot net core استفاده می‌کنیم.

برخی از لایبرری‌های مورد استفاده در طول دوره:

  • Moq
  • FakeItEasy
  • NSubstitute
  • ‌ AutoFixture
  • NBuilder
  • FluentAssertions
  • NFluent
  • Ncrunch
  • FluentAssertions.Json

معرفی دوره


ما در این دوره که بصورت کاملا عملی و hands-on می‌باشد، به تکنیک TDD نه به عنوان روشی فقط برای نوشتن تست‌های نرم‌افزاری، که به عنوان یکی از مهمترین مکانیزم طراحی و معماری نگاه خواهیم کرد، و ضمن آشنایی با مهمترین اصول و تکنیک‌های TDD، چالش‌های مهم در هر فاز TDD را بررسی کرده و تکنیک‌های مهم و کاربردی عبور از هر فاز را بصورت عملی را فرا خواهیم گرفت، و همچنین فرا خواهیم گرفت که چگونه از TDD هنگامی که هنوز هیچ معماری یا طراحی و فریمورکی وجود ندارد، جهت تفکر، طراحی، تصمیم گیری و پیاده سازی آنها استفاده کنیم، و این موارد را به کمک تست drive کنیم، بصورتی که به پیاده‌سازی برسیم که علاوه بر اینکه کاملا تست پذیر بوده و از تغییرات در نرم‌افزار پشتیبانی می‌کند، به ما کمک می‌کند که به یک سرعت توسعه پایا دست پیدا کنیم. از طرف دیگر همچنین ما برای مهمترین بخش‌های معماری و بیزنس نرم‌افزار خود نیز تست نوشته ایم.

دانشجویان ضمن آشنایی با مهمترین اصول و پرکتیس‌های نوشتن تست نرم‌افزاری، اصول طراحی Emergent and Evolutionary Design را فرا گرفته و با یکی از متداولترین معماری‌های مدرن نرم‌افزاری به نام Ports and Adapters آشنا شده و قادر خواهند بود آن را بر اساس مکانیزم TDD پیاده سازی کنند.

در طول دوره برای یک شرکت/سازمان فرضی دامنه‌ای را مطرح کرده، و تلاش می‌کنیم تا در طول دوره آن را با پیشرانه تست‌های مختلفی که می‌نویسیم از ابتدا پیاده‌سازی کنیم.

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

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

سرفصل‌های دوره


  • چرا “نرم”‌افزارهای ما تبدیل به “سخت” افزار می‌شوند؟
  • چرا و چه موقع ما نیاز به تغییر در نرم‌افزار خواهیم داشت؟
  • مکانیزمهای متداول تغییر در نرم‌افزار
  • معرفی انواع سبک‌های معماری نرم‌افزار
    • معماری لایه‌ای
      • معماری nلایه‌
      • معماری Hexagonal
      • معماری Ports and Adapters
      • معماری Clean
    • معماری میکروکرنل
    • معماری مبتنی بر Event
    • الگوی معماری مایکروسرویس‌ها
    • معماری Space-Based
  • توسعه نرم‌افزار به عنوان یک فرآیند یادگیری
  • معرفی روش‌های کشف دانش و حقایق از دامنه مسئله
    • EventStorming
    • Example Mapping
  • بهبود چرخه‌ی بازخورد به عنوان مهمترین ابزار توسعه چابک
  • آشنایی با پرکتیسهایی که از تغییرات پشتیبانی می‌کنند
  • ایجاد دیکشنری از اصلاحات رایج
    • منظور از Test چیست؟(به عنوان اسم و به عنوان فعل)
    • Assertion
    • Expectation
    • System-Under Test (S.U.T)
    • Test Case-Test Method
    • Unit of Work
    • Test Runner
    • Test Framework
    • Fixture
    • Target Object
    • Dependent-On Component (D.O.C)
  • مزیت‌های Self-testing code
  • آناتومی Test
    • مقداردهی کردن Context
    • تعریف مکانیزم Expectation
    • Acting - تریگر کردن رفتارهای مورد نظر بر روی SUT
    • Verifying - اعمال مکانیزم‌های تائید نتیجه کار
    • ریست کردن Context(Teardown)
  • آشنایی با فلسفه Failed fast
  • تصویر بزرگ و جامع از Test-Driven Development
  • فرآیند توسعه نرم افزار به روش Test-Driven Development
  • حفظ و نگهداری چرخه‌های TDD
    • Red-Green-Refactoring
    • Failing-passing-improving-check-in
    • چرا نباید همزمان دو تا کلاه با هم و بر روی بپوشیم!(بله two-hate!)
    • چگونه در هر زمان فقط یک تصمیم بگیریم؟
  • Test به عنوان مهمترین ابزار طراحی
  • Test به عنوان Design-session
  • Test به عنوان پیشرانه تصیمات طراحی و معماری
  • توسعه و پیاده‌سازی معماری بر اساس Test
  • الگوهای توسعه نرم افزار به روش Test-Driven Development
    • شناسایی دقیق مفهوم واحد(Unit) در تست
    • تکنیک‌های ایزوله کردن تست‌ها از یکدیگر
    • لیست کردن و شناسایی سناریوهای مختلف جهت اطمینان از عملکرد واحدها
    • تکنیک‌های مختلف انتخاب یک سناریوی مناسب جهت شروع نوشتن تست
    • توسعه مبتنی بر Assertion
  • آشنایی با دو رویکرد متداول TDD
    • Chicago school (classicist)
    • London School (Outside-in)
  • توسعه به سبکOutside-in
    • فعالیت‌های Iteration صفر
    • Emerging design و architecture به کمک Testها
    • شروع با یک تست پذیرش
    • The Walking Skeleton
  • رسیدن و حفظ سرعت توسعه پایا(یکی از مهمترین اصول توسعه چابکی) به کمک TDD
  • به تعویق انداختن تصمیمات مهم طراحی و معماری به کمک Test
  • Outside-in
    • تصمیم گیری و پیاده‌سازی مهمترین جنبه‌های معماری نرم‌افزار بر اساس نیاز و با پیشرانه Test
    • آشنایی و پیاده‌سازی متریک‌های Evolutionary Architecture
  • Code Kata
    • آشنایی و پیاده‌سازی چند مثال با تکنیک Code Kata به عنوان یک تکنیک بسیار کاربردی جهت پرکتیس کردن اصول و تکنیک‌های TDD
  • انواع تست از دیدگاه طراحی و معماری
    • Unit Test
    • Integration Test
    • End-to-End Test
    • Regression Tests
    • Agile Testing Quadrants
    • The Test Pyramid
  • Ice-Cream Cone Pattern
  • طراحی و پیاده‌سازی API سرویس‌ها با هدایت و پیشرانگی Testها
    • Consumer-Driven Contract(CDC)
  • اولویت بندی و انتخاب بهترین و مناسبت‌ترین سناریو جهت نوشتن Test
    • One-step Test
    • Starter Test
    • Explanation
    • Learning Test
    • Regression Test
  • الگوها و پرکتیس‌های Testing
    • Child Test
    • Doubling
      • شناسایی و تفکیک انواع وابستگی‌های SUT
      • مشابه سازی وابستگی‌های ورودی و خروجی objectهای تحت Test
        • Stub
          • نقش Stubها در سناریوهای Happy-Path
          • نقش Stubها در سناریوهای Exceptional Path
          • نقش Stubها در Negative Testها
          • پیاده سازی Stub بصورت Hard-Codded
          • پیاده سازی Stub بصورت سفارشی بر اساس سناریو مورد Test
        • Spy
        • Mock
        • Fake
        • Dummy
      • بررسی و ارائه تکنیک‌های ساده‌ای جهت تشخیص زمان مناسب برای
      • Mock
      • کردن یا نکردن Dependencyهای مرتبط با SUT
      • Self-Shunt
      • Log String
      • Crash Test Dummy
      • Broken Test
      • Clean Check-in
      • Humble-Object
  • تکنیک‌های مهم جهت پیشرفت از فاز قرمز به سبز در چرخه توسعه TDD
    • Fake it (Till you make It)
    • Triangulate
    • External Fixture
    • Exception Test
  • الگوهای طراحی جهت رسیدن به مرحله سبز
    • Command
    • Value Object
    • Null Object
    • Template Pattern
    • Pluggable Object
    • Pluggable Selector
    • Factory Method
    • Imposter
    • Composite
    • Collecting Parameter
    • Singleton
  • گام آخر، Refactoring
    • قانون Boy-scot
    • Reconcile Differences
    • Isolate Change
    • Migrate Data
    • Extract Method
    • Inline Method
    • Extract Interface
    • Move Method
    • Method Object
    • Add Parameter
    • Method Parameter to Constructor Parameter
  • کار با انواع دیتا در تست
    • Test Data Builders
    • استفاده از Flyweight
    • Combining Builders
    • استفاده از الگوی Factory Method جهت تاکید بر زبان دامین
    • معیارهای رسیدن به Evident Data
  • طراحی Testهای مناسبی که به شما کمک می‌کنند به یک طراحی evolutionary دست پیدا کنید
  • تکیه بر لاگینگ به عنوان یک ویژگی مهم در طراحی و توسعه مبتنی بر Test
    • ValueObjectها و Mocking
    • Bloated Constructors
    • Confused Object
    • Test Names Describe Features
    • Canonical Test Structure
    • Streamline the Test Code
  • نگاهی دقیق‌تر به Assertions و Expectations
    • Just enough Dependencies
    • Just enough Many Expectations
    • Explanatory Assertion Messages
  • عیب یابی و اشکال زدایی به کمک Test
    • Highlights Detail with Matchers
    • Self-Describing Value
    • Obviously Canned Value
    • Tracer Object
    • Diagnostics are a First-Class Feature
  • Design to Fail
  • شناسایی انواع رایحه‌های بد که نوشتن تست را مشکل و غیر اقتصادی می‌کند
    • رایحه‌های بد در کد
      • Obscurer test
      • Conditional Test Logic
      • Hard-to-Test Code
      • Test Code Duplication
      • Test Logic in Production
    • رایحه‌های بد در رفتار
      • Assertion Rouletee
      • Erratic Test
      • Fragile Test
      • Frequent Debugging
      • Manual Intervention
      • Slow Tests
    • رایحه‌های بد در سطح پروژه
      • Buggy Tests
      • Developers Not Writing Tests
      • High Test Maintenance Cost
      • Production Bugs
  • طراحی بخش‌های مشکل معماری با هدایت و کمک Test
    • تکنیک‌ها و الگوهای نوشتن Test برای لایه Persistence
    • طراحی سناریوهای مبتنی بر چند نخی با پیشرانه Test
    • تست کردن سناریوهای مبتنی بر I.O
    • نوشتن Test برای سناریوهایی که نیازمند کار با File System هستند
  • طراحی سناریوهای غیرهمزمان(Asynchronous) بر اساس Test
    • Sampling on Listening
    • Two Implementations
    • Runaway Tests
    • Lost Updates
    • Testing That an Action Has No Effect
    • تکنیک‌های تمایز قائل شدن بین کانسرن‌های Synchronization و Assertion
    • Externalize Event Sources
  • جلسه رترو (بحث و پاسخ به برخی سوالات مطرح شده توسط کنت بک در مورد TDD)
    • تست‌ها و گام‌های شما در چرخه توسعه TDD تا چه اندازه می‌تواند بزرگ یا کوچک باشد؟
    • برای جه مواردی نیاز به نوشتن تست نداریم؟
    • چه معیارهای برای بررسی اینکه یک تست خوب است یا بد داریم؟
    • TDD چطور می‌تواند به توسعه فریمورک کمک کند؟
    • چه میزان بازخورد نیاز داریم؟
    • چه زمانی باید برخی تست‌ها را پاک کنید؟
    • زبانهای برنامه نویسی و محیط‌های توسعه چگونه بر فرآیند TDD تاثیر می‌گذارند؟
    • آیا می‌تواند یک سیستم بزرگ را بر اساس روش TDD توسعه دهید؟
    • آیا می‌توان توسعه محصول را بر اساس تست‌ها در سطح لایه application پیش برد؟
    • چگونه می‌توانیم به روش توسعه مبتنی بر TDD تغییر ذهنیت بدهیم؟
    • مخاطب TDD چه کسانی یا سازمان‌هایی هستند؟
    • آیا TDD به برخی شرایط اولیه و پیش‌نیازها حساس می‌باشد؟
    • آیا ارتباطی بین TDD و الگوهای طراحی می‌توان برقرار کرد؟
    • چرا TDD می‌تواند یک روش موفق و کارا برای توسعه نرم‌افزار باشد؟

در خبرنامه عضو شوید