# Use Pattern Matching to Avoid ‘As’ Followed by A ‘Null’ Check dotnet_diagnostic.IDE0019.severity = warning
{
"outputFileName": "out.js",
"inputFiles": [ "in.js" ],
"minify": {
"enabled": true,
"preserveImportantComments": true
}
} {
"outputFileName": "output/bundle.css",
"inputFiles": [
"css/lib/**/*.css", // globbing patterns are supported
"css/input/site.css"
],
"minify": {
"enabled": true,
"commentMode": "all"
}
}, The Intersection of Microservices, Domain-Driven Design and Entity Framework Core
Domain-Driven Design (DDD) provides much of the strategic design guidance that we can use to determine the boundaries around and interactions between Microservices in our solutions. DDD also follows up with tactical design patterns for your business logic. In this session we'll take a look at some of these patterns and how EF Core naturally, or with some additional configuration, persists the data that your microservices depend on.
public enum Rainbow
{
Red,
Orange,
Yellow,
Green,
Blue,
Indigo,
Violet
} class RGBColor
{
internal byte Red { get; }
internal byte Green { get; }
internal byte Blue { get; }
internal RGBColor(byte red, byte green, byte blue)
{
Red = red;
Green = green;
Blue = blue;
}
public override string ToString() => $"rgb({Red}, {Green}, {Blue})";
} internal static RGBColor FromRainbow(Rainbow rainbowBolor)
{
switch (rainbowBolor)
{
case Rainbow.Red:
return new RGBColor(0xFF, 0x00, 0x00);
case Rainbow.Orange:
return new RGBColor(0xFF, 0x7F, 0x00);
case Rainbow.Yellow:
return new RGBColor(0xFF, 0xFF, 0x00);
case Rainbow.Green:
return new RGBColor(0x00, 0xFF, 0x00);
case Rainbow.Blue:
return new RGBColor(0x00, 0x00, 0xFF);
case Rainbow.Indigo:
return new RGBColor(0x4B, 0x00, 0x82);
case Rainbow.Violet:
return new RGBColor(0x94, 0x00, 0xD3);
default:
throw new ArgumentException(message: "invalid enum value", paramName: nameof(rainbowBolor));
};
} internal static RGBColor TasteTheRainbow(Rainbow rainbowColor) =>
rainbowColor switch
{
Rainbow.Red => new RGBColor(0xFF, 0x00, 0x00),
Rainbow.Orange => new RGBColor(0xFF, 0x7F, 0x00),
Rainbow.Yellow => new RGBColor(0xFF, 0xFF, 0x00),
Rainbow.Green => new RGBColor(0x00, 0xFF, 0x00),
Rainbow.Blue => new RGBColor(0x00, 0x00, 0xFF),
Rainbow.Indigo => new RGBColor(0x4B, 0x00, 0x82),
Rainbow.Violet => new RGBColor(0x94, 0x00, 0xD3),
_ => throw new ArgumentException(message: "invalid enum value", paramName: nameof(rainbowColor)),
}; var operation = "+";
int a = 1, b = 2;
var result = operation switch
{
"+" => a + b,
"-" => a - b,
"/" => a / b,
_ => throw new NotSupportedException()
}; class Address
{
public string AddressLine1 { get; set; }
public string AddressLine2 { get; set; }
public string City { get; set; }
public string State { get; set; }
public string PostalCode { get; set; }
public string CountryRegion { get; set; }
} static class PropertyPatterns
{
internal static decimal ComputeSalesTax(
Address location,
decimal salePrice) =>
location switch
{
{ State: "Fars" } => salePrice * 0.06m,
{ State: "Tehran", City: "Tehran" } => salePrice * 0.056m,
// Other cases removed for brevity...
_ => 0M
};
} static class TuplePatterns
{
internal static string RockPaperScissors(
string first,
string second)
=> (first, second) switch
{
("rock", "paper") => "Rock is covered by Paper. Paper wins!",
("rock", "scissors") => "Rock breaks Scissors. Rock wins!",
("paper", "rock") => "Paper covers Rock. Paper wins!",
("paper", "scissors") => "Paper is cut by Scissors. Scissors wins!",
("scissors", "rock") => "Scissors is broken by Rock. Rock wins!",
("scissors", "paper") => "Scissors cuts Paper. Scissors wins!",
(_, _) => "tie"
};
} class Shape
{
protected internal double Height { get; }
protected internal double Length { get; }
protected Shape(double height = 0, double length = 0)
{
Height = height;
Length = length;
}
}
class Circle : Shape
{
internal double Radius => Height / 2;
internal double Diameter => Radius * 2;
internal double Circumference => 2 * Math.PI * Radius;
internal Circle(double height = 10, double length = 10)
: base(height, length) { }
}
class Rectangle : Shape
{
internal bool IsSquare => Height == Length;
internal Rectangle(double height = 10, double length = 10)
: base(height, length) { }
} static class ObjectPatterns
{
internal static string ShapeDetails(this Shape shape)
=> shape switch
{
Circle c => $"circle with (C): {c.Circumference}",
Rectangle s when s.IsSquare => $"L:{s.Length} H:{s.Height}, square",
Rectangle r => $"L:{r.Length} H:{r.Height}, rectangle",
_ => "Unknown shape!" // Discard
};
} class Point
{
public int X { get; }
public int Y { get; }
public Point(int x, int y) => (X, Y) = (x, y);
public void Deconstruct(out int x, out int y) => (x, y) = (X, Y);
}
enum Quadrant
{
Unknown,
Origin,
One,
Two,
Three,
Four,
OnBorder
} static class PositionalPatterns
{
internal static Quadrant AsQuadrant(Point point) => point switch
{
(0, 0) => Quadrant.Origin,
var (x, y) when x > 0 && y > 0 => Quadrant.One,
var (x, y) when x < 0 && y > 0 => Quadrant.Two,
var (x, y) when x < 0 && y < 0 => Quadrant.Three,
var (x, y) when x > 0 && y < 0 => Quadrant.Four,
(_, _) => Quadrant.OnBorder, // Either are 0, but not both
_ => Quadrant.Unknown
};
} خیلی از ما با کابوس پروژه ای که هیچ تجربه ای در انجام آن نداریم روبرو شده ایم. نبودن تجربه موثر منجر به خطاهای تکراری و غیر قابل پیش بینی شده و تلاش و وقت ما را به هدر میدهد. مشتریان از کیفیت پایین، هزینه بالا و تحویل دیر هنگام محصول ناراضی هستند و توسعه دهندگان از اضافه کارهای بیشتر که منجر به نرم افزار ضعیتتر میگردد، ناخشنود.
همین که با شکستی مواجه میشویم از تکرار چنین پروژه هایی اجتناب میکنیم. ترس ما باعث میشود تا فرآیندی بسازیم که فعالیتهای ما را محدود نموده و ایجاد آرتیفکتها[۱] را الزامی کند. در پروژه جدید از چیزهایی که در پروژه‌های قبلی به خوبی کار کردهاند، استفاده میکنیم. انتظار ما این است که آنها برای پروژه جدید نیز به همان خوبی کار کند.
اما پروژه‌ها آنقدر ساده نیستند که تعدادی محدودیت و آرتیفکت ما را از خطاها ایمن سازند. با بروز خطاهای جدید ما آنها را شناسایی و رفع میکنیم. برای اینکه در آینده با این خطاها روبرو نشویم آنها را در محدودیتها و آرتیفکتهای جدیدی قرار میدهیم. بعد از انجام پروژه‌های زیاد با فرآیندهای حجیم و پر زحمتی روبرو هستیم که توانایی تیم را کم کرده و باعث کاهش کیفیت تولید میشوند.
فرآیندهای بزرگ و حجیم میتواند مشکلات زیادی را ایجاد کند. متاسفانه این مشکلات باعث میشود که خیلی از افراد فکر کنند که علت مشکلات، نبود فرآیندهای کافی است. بنابراین فرآیندها را حجیمتر و پیچیدهتر میکنند. این مسئله منجر به تورم فرآیندها میگردد که در محدوده سال ۲۰۰۰ گریبان بسیاری از شرکتهای نرم افزاری را گرفت.
اتحاد چابک
در وضعیتی که تیمهای نرم افزاری در بسیاری از شرکتها خود را در مردابی از فرآیندهای زیاد شونده میدیدند، تعدادی از خبره‌های این صنعت که خود را اتحاد چابک[۲] نامیدند در اویل سال ۲۰۰۱ یکدیگر را ملاقات کرده و ارزش هایی را معرفی کردند تا تیمهای نرم افزاری سریعتر نرم افزار را توسعه داده و زودتر به تغییرات پاسخ دهند. چند ماه بعد، این گروه ارزشهایی تعریف شده را تحت مانیفست اتحاد چابک در سایت http://agilemanifesto.org منتشر کردند.
ما با توسعه نرم افزار و کمک به دیگران در انجام آن، در حال کشف راه‌های بهتری برای توسعه نرم افزار هستیم. از این کار به ارزشهای زیر میرسیم :
۱- افراد و تعاملات بالاتر از فرآیندها و ابزارها
۲- نرم افزار کار کننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.
افراد مهمترین نقش را در پیروزی یک پروژه دارند. یک فرآیند عالی بدون نیروی مناسب منجر به شکست میگردد و بر عکس افراد قوی تحت فرآیند ضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفقتر هستند از تعداد برنامه نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال میتوانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گرانقیمت از برنامه رایگان کد باز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفا به آنها به عنوان امکانی جهت تسهیل فرآیندها نگاه کنید.
نرم افزار بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را میگیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم میشوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می‌توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال میدهیم. ما آنها را بخشی از تیم میکنیم و با تعامل نزدیک و رو در رو به آنها آموزش میدهیم.
نرم افزار نمیتواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم افزاری که می‌خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده میکند، بسازند. اما این تعامل به کیفیت پایین نرم افزار و در نهایت شکست آن می‌انجامد. پروژه‌های موفق بر اساس دریافت بازخورد مشتری در بازه‌های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتبا اعمال نظر میکند.
قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساسا نقص دارد. بهترین قرارداد این است که تیم توسعه و مشتری با یکدیگر کار کنند.
توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم افزاری است. وقتی که طرحی را میریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.
مسیر یک پروژه نرم افزاری نمیتواند برای بازه زمانی طولانی برنامه ریزی شود. اولا احتمالا محیط تغییر میکند و باعث تغییر در نیازمندیها میشود. ثانیا همین که سیستم شروع به کار کند مشتریان نیازمندیهای خود را تغییر میدهند. بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمیکنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد.
۱- بالاترین اولویت ما عبارت است از راضی کردن مشتری با تحویل سریع و مداوم نرم افزار با ارزش. تحویل نرم افزار با کارکردهای کم در زود هنگام بسیار مهم است چون هم مشتری چشم اندازی از محصول نهایی خواهد داشت و هم مسیر کمتر به بیراهه می‌رود.
۲- خوش آمدگویی به تغییرات حتی در انتهای توسعه. اعضای تیم چابک، تغییرات را چیز خوبی می‌بینند زیرا تغییرات به این معنی است که تیم بیشتر یاد گرفته است که چه چیزی مشتری را راضی میکند.
۳- تحویل نرم افزار قابل استفاده از چند هفته تا چند ماه با تقدم بر تحویل در دوره زمانی کوتاهتر. ما مجموعه از مستندات و طرحها را به مشتری نمی‌دهیم.
۴- افراد مسلط به بیزنس و توسعه دهندگان باید روزانه با یکدیگر روی پروژه کار کنند. یک پروژه نرم افزاری نیاز به هدایت مداوم دارد.
۵- ساخت پروژه را بر توان افراد با انگیزه بگذارید و به آنها محیط و ابزار را داده و اعتماد کنید. مهمترین فاکتور موفقیت افراد هستند، هر چیز دیگر مانند فرآیند، محیط و مدیریت فاکتورهای بعدی محسوب میشوند که اگر تاثیر بدی روی افراد میگذارند، باید تغییر کنند.
۶- بهترین و موثرترین روش کسب اطلاعات در تیم توسعه، ارتباط چهره به چهره است. در تیم چابک افراد با یکدیگر صحبت میکنند. نامه نگاری و مستند سازی فقط زمانی که نیاز است باید صورت گیرد.
۷- نرم افزار کار کننده معیار اصلی پیشرفت است. پروژه‌های چابک با نرم افزاری که در حال حاضر نیازهای مشتری را پاسخ میدهد، سنجیده میشوند. میزان مستندات، حجم کدهای زیر ساخت و هر چیز دیگری غیره از نرم افزار کار کننده معیار پیشرفت نرم افزار نیستند.
۸- فرآیندهای چابک توسعه با آهنگ ثابت را ترویج میدهد. حامیان، توسعه دهندگان و کاربران باید یک آهنگ توسعه ثابت را حفظ کنند که بیشتر شبیه به دو ماراتون است یا دوی ۱۰۰ متر. آنها با سرعتی کار میکنند که بالاترین کیفیت را ارائه دهند.
۹- توجه مداوم به برتری تکنیکی و طراحی خوب منجر به چابکی میگردد. کیفیت بالاتر کلیدی برای سرعت بالا است. راه سریعتر رفتن این است که نرم افزار تا جایی که ممکن است پاک و قوی نگهداریم. بنابراین همه اعضای تیم چابک تلاش میکنند که با کیفیتترین کار ممکن را انجام دهند. آنها هر آشفتگی را به محض ایجاد برطرف میکنند.
۱۰- سادگی هنر بیشینه کردن مقدار کاری که لازم نیست انجام شود، است. تیم چابک همیشه ساده‌ترین مسیر که با هدف آنها سازگار است را در پیش میگیرند. آنها وقت زیادی روی مشکلاتی که ممکن است فردا رخ دهد، نمیگذارند. آنها کار امروز را با کیفیت انجام داده و مطمئن میشوند که تغییر آن در صورت بروز مشکلات در فردا، آسان خواهد بود.
۱۱- بهترین معماری و طراحی از تیمهای خود سازمان ده بیرون می‌آید. مدیران، مسئولیتها را به یک فردی خاصی در تیم نمی‌دهند بلکه بر عکس با تیم به صورت یک نیروی واحد برخورد میکنند. خود تیم تصمیم میگیرد که هر مسئولیت را چه کسی انجام دهد. تیم چابک با هم روی کل جنبه‌های پروژه کار میکنند. یعنی یک فرد خاص مسئول معماری، برنامه نویسی، تست و غیره نیستند. تیم، مسئولیتها را به اشتراک گذاشته و هر فرد بر کل کار تاثیر دارد.
۱۲- در بازهای زمانی مناسب تیم در مییابد که چگونه میتواند کاراتر باشد و رفتار خود را متناسب با آن تغییر دهد. تیم میداند که محیط دائما در حال تغییر است، بنابراین خود را با محیط تغییر میدهد تا چابک بماند.
امروزه صنعت نرم افزار دارای سابقه بدی در تحویل به موقع و با کیفیت نرم افزار است. گزارشات بسیاری تایید میکنند که بیش از ۸۰ درصد از پروژه‌های نرم افزاری با شکست مواجه میشوند؛ در سال ۲۰۰۵ موسسه IEEE برآورد زده است که بیش از ۶۰ بیلیون دلار صرف پروژه‌های نرم افزاری شکست خورده شده است. عجب فاجعهای؟
وقتی که از مدیران و کارکنان سوال میشود که چرا پروژه‌های نرم افزاری با شکست مواجه میشوند، آنها به موضوعات گسترده ای اشاره میکنند. اما شش دلیل زیر بارها و بارها تکرار شده است که به عنوان دلایل اصلی شکست نرم افزار معرفی میشوند:
۱- درگیر نشدن مشتری
۲- عدم درک درست نیازمندها
۳- زمان بندی غیر واقعی
۴- عدم پذیریش و مدیریت تغییرات
۵- کمبود تست نرم افزار
۶- فرآیندهای غیر منعطف و باد دار
با آنکه Agile برای هر مشکلی راه حل ندارد ولی برای مسائل فوق بدین صورت کمک میکند:
برای رفع مشکل عدم همکاری کاربر نهایی یا مشتری، Agile مشتری را عضوی از تیم توسعه میکند. به عنوان عضوی از تیم، مشتری با تیم توسعه کار میکند تا مطمئن شود که نیازمندها به درستی برآورده میشوند. مشتری همکاری میکند در شناسایی نیازمندیها، تایید میکند نتیجه نهایی را و حرف آخر را در اینکه کدام ویژگی به نرم افزار اضافه شود، حذف شود و یا تغییر کند، را میزند.
برای مقابله با مشکل عدم درک درست نیازمندیها، Agile تاکید دارد که نیازمندیهای کسب شده باید به صورت ویژگیهایی تعریف شوند که بر اساس معیارهای مشخصی قابل پذیرش باشند. این معیارهای پذیرش برای نوشتن تستهای پذیرش به کار میروند. به این ترتیب قبل از اینکه کدی نوشته شود، ابتدا تست پذیرش نوشته میشود. این بدین معنی است که هر کسی باید اول فکر کند که چه میخواهد، قبل از اینکه از کسی بخواهد آن را انجام دهد. این راهکار فرایند کسب نیازمندیها را از بنیاد تغییر میدهد و به صورت چشم گیری کیفیت برآورد و زمان بندی را بهبود میدهد.
برای حل مشکل زمان بندی غیر واقعی، Agile زمان بندی را به صورت یک فرآیند مشترک بین تیم توسعه و سفارش دهنده تعریف میکند. در شروع هر نسخه از نرم افزار، سفارش دهنده ویژگیهای مورد انتظار را به تیم توسعه میگوید. تیم توسعه تاریخ تحویل را بر اساس ویژگیها برآورد میزد و در اختیار سفارش دهنده قرار میدهد. این تعامل تا رسیدن به یک دیدگاه مشترک ادامه مییابد.
برای رفع مشکل ضعف در مدیریت تغییرات، Agile اصرار دارد که هر کسی باید تغییرات را بپذیرد و نسبت به آنها واقع بین باشد. یک اصل مهم Agile میگوید که هر چیزی میتواند تغییر کند مگر تاریخ تحویل! به عبارت دیگر همین که محصول به سمت تولید شدن حرکت میکند، مشتری (در تیم محصول) میتواند بر اساس اولویتها و ارزشهای خود ویژگیهای محصول را کم یا زیاد کرده و یا تغییر دهد. به هر حال او باید واقع بین باشد. اگر او یک ویژگی جدید اضافه کنید، باید تاریخ تحویل را تغییر دهد. به این ترتیب همیشه تاریخ تحویل رعایت میگردد.
برای رفع مشکل کمبود تست، Agile تاکید میکند که ابتدا باید تستها نوشته شوند و همواره ارزیابی گردند. هر برنامه نویس باید اول تست را بنویسد، سپس کد لازم برای پاس شدن آن را. همین که کد تغییر میکند باید تستها دوباره اجرا شوند. در این راهکار، هر برنامه نویس مسئول تستهای خود است تا درستی برنامه از ابتدا تضمین گردد.
برای رفع مشکل فرآیندهای غیر منعطف و باددار، Agile مدیریت پروژه را درون فرآیند توسعه میگنجاند. وظایف مدیریت پروژه بین اعضای تیم توسعه تقسیم میشود. برای مثال هر ۷ نفر در تیم توسعه نرم افزار (متدلوژی اسکرام) زمان تحویل را با مذاکره تعیین میکنند. همچنین کد برنامه به صورت خودکار اطلاعات وضعیت پروژه را تولید میکند. به عنوان مثال نمودار burndown ، تستهای انجام نشده، پاس شده و رد شده به صورت خودکار تولید میشوند.
یکی از مشکلات توسعه چابک این است که شما اول باید به خوبی آن را درک کنید تا قادر به پیاده سازی درست آن باشید. این درک هم باید کلی باشد (مانند Scrum و XP) و هم جزئی (مانند TDD و جلسات روازنه). اما چگونه باید به این درک برسیم؟ کتابها و مقالات انگلیسی زیادی برای یادگیری توسعه چابک و پیاده سازی آن در سازمان وجود دارند، ولی متاسفانه منابع فارسی کمی در این زمینه است. هدف این کتاب رفع این کمبود و آموزش عملی توسعه چابک و ابزارهای پیاده سازی آن است.
برای این یک توسعه دهنده چابک شوید، باید به مهارتهای فردی و تیمی چابک برسید. در ادامه این مهارتها معرفی میشوند.
قبل از هر چیز شما باید یک برنامه نویس باشید و مقدمات برنامه نویسی مانند الگوریتم و فلوچارت، دستورات برنامه نویسی، کار با متغیرها، توابع و آرایه‌ها را بلد باشید. پس از تسلط به مقدمات برنامه نویسی میتوانید مهارتهای برنامه نویسی چابک را فرا بگیرید که عبارتند از:
- برنامه نویسی شیءگرا
- توسعه تست محور
- الگوهای طراحی
در ادامه نحوه کسب این مهارتها بیان میشوند.
اساس طراحی چابک بر تفکر شیءگرا استوار است. بنابراین تسلط به مفاهیم و طراحی شیءگرا ضروری است.
مهمترین و انقلابی‌ترین سبک برنامه نویسی از دهه گذشته تا به امروز، توسعه یا برنامه نویسی تست محور است. این سبک بسیاری از ارزشهای توسعه چابک را فراهم میکند و یادگیری آن برای هر توسعه دهنده چابک ضروری است.
الگوهای طراحی راه حلهای انتزاعی سطح بالا هستند. این الگوها بهترین تکنیکهای[۴] طراحی نرم افزار هستند و بسیاری از مشکلاتی که در طراحی نرم افزار رخ میدهند با استفاده از این الگوها قابل حل هستند.
انجام پروژه نرم افزاری یک کار تیمی است. شما پس از یادگیری مهارتهای فردی باید خود را آماده حضور در تیم توسعه چابک کنید. برای این منظور باید با مهارت تیمی مانند آشنایی با گردشکار تولید نرم افزار، حضور موثر در جلسات، قبول مسئولیتها و غیره آشنا شوید.
تمامی مهارتهای تیمی توسعه چابک توسط اسکرام آموزش داده میشوند. اسکرام فریم ورکی برای توسعه چابک است که با تعریف فرآیندها، نقشها و آرتیفکتهای مشخص به تیمهای نرم افزاری کمک میکند تا چابک شوند.
[۱] Artifact : خروجی یک فرآیند است. مثلا خروجی طراحی شیءگرا، نمودارهای UML است.
[۲] Agile Alliance
[3] Acceptance Tests
