فراتر از Microsoft .Net Framework

یه راست برم سر اصل مطلب ! من علاقه‌ی بسیار زیادی به #C دارم و Syntax اش به نظرم بی عیب و نقصه . همچنین به نظرم بهترین IDE برای توسعه محصولات نرم افزاری Visual Studio است.  به قول یکی از دوستانم آرش “این از این!”

اما …

بهتره گه گاه به بیرون از چهارچوبی که داریم باهاش کار می‌کنیم نگاه کنیم و ببینیم تو بقیه پلتفرم ها چه خبره. اینکه مثلا Database Migration در Ruby On Rails یا همون RoR چقدرتر و تمیز پیاده شده است واقعا آموزندس. وقتی می‌ببینم Scaffoling در RoR چجوری باعث سرعت در توسعه یک وب اپلیکیشن میشه میتونه خیلی به درک چهارچوبی که خودمون درش کار می‌کنیم کمک می‌کنه. وقتی می‌بینیم بقیه با چه IDEای هایی کار می‌کنند یکم تو دلمون میخندیم که ای بابا Visual Studio کجا و این کجا ! :)

اینکه بفهمیم ساختار یه برنامه Android چه جوربه. Activity ها با View ها چجوری ارتباط برقرار می‌کنند. یا مثلا بفهمیم مفهموم Intent تو Android چیه. وقتی یکم در مورد Google App Engine  بخونیم. یا ببینم Heroku چیه و چجوری کار میکنه. در مورد Django یکم تحقیق کنیم و بفهمیم چرا سرعت توسعه باهاش انقدر زیاده. روش کار کردن با ‌Git از طریق Command  و ترمینال چیه. اصن چندجور Source Control دیگه غیر از اونی که بلدیم وجود داره. بقیه تو زبان های برنامه نویسی دیگه چجوری Unit Test می نویسند. تو چه سیستم هایی از NoSQL ها استفاده میشه؟ یا اصلا Naming Convention ها یا اصول و قواعد نامگذاری تو بقیه زبان های برنامه نویسی چجوری هستند. وقتی می‌بینیم که تو بقیه اکو سیستم ها چقدر خوب و راحت از Package Manager هایی مثل Homebrew یا gem استفاده میشه، تشابهاتش با Nuget واضح تر میشه  و باعث میشه از ابزارمون بهتر و مفید تر استفاده کنیم. گاهی حتی لازمه Syntax یه زبانی مثل Objective-C رو ببنیم و زور بزنیم تا بفهمیم، تو این چند سطر کد چی نوشتن و بعدش خدا رو شکر کنیم که Andres Hejlsberg و همکاراش چقدر خوش سلیقه بودند!‌:)

ممکنه شما بیشتر Backend Developer باشید وعشق نوشتن سرویس ها، ساختارهای برنامه، کار با دیتابیس و Socket Programming. ولی خب بدی نیست بعضی وقتا حتی یکم در مورد CSS Framework  ها مطالعه کنیم. اینکه چند تا معروف هاش کدومان؟ اینکه بفهمیم اصولا میخواهند چه مشکلی رو حل کنند خیلی به نظرم مفیده. یا مثلا این Node چیه که انقدر همه جا ازش صحبت میشه. واقعا ذاتش Javascript هست یا زبان تعامل باهاش Javascript. یا مثلا چی شده که انقدر Client Side Scripting باب شده و اینهمه Framework براش تولید شده.

خلاصه همه و همه این ها باعث میشه یک دید کلی‌تر و عمیق تری از ماجرا دستمون بیاد. به قول خارجی ها یک Big Picture برامون شکل میگیره. ازقدیم گفتم توسعه یک محصول فقط کد نویسی نیست! ولی کد نویسی هم فقط به #C و Visual Studio و SQL Server خلاصه نمیشه. کمی که به بیرون نگاه کنیم و ببینم تو بقیه سیستم ها و پلتفرم ها چه خبره، قطعا با دید بازتری از ابزارها، سرویس ها و زبان برنامه نویسی مورد علاقمون استفاده خواهیم کرد. وقتی بتونیم دید بازتر وعمیق تری داشته باشیم، هنگام طراحی هامون بهتر و راحتتر میتونیم قطعات پازلمون رو کنار هم قرار بدیم.

۱۰-مهر-۱۳۹۳
دسته بندی شده در: عمومی, کدنویسی

همان کاری که با RUP کردیم را با اسکرام نکنیم.

چندی وقتی بود این موضوع در ذهنم بود، اما خواندن مطلب معرفی استودیو اسکرام مستر دوستان در روباکو ترغیبم کرد چند خطی دراین باره بنویسم.

چطور اسکرام مستر شویم؟ آمادگی برای مدرک بین‌المللی PSM.

هدفم از این نوشته انتقاد از کلاس ها و استدیو روباکو نیست. من با تیم روباکو تا به حال ملاقاتی نداشتم اما با توجه به کارهاشون حتی چند نفر مشتری هم براشون فرستادم.

بیشتر میخواهم در مورد معرفی اسکرام و به صورت کلی متد های Agile صحبت کنم. این مورد در سایت ها و بلاگ های ایرانی و هم خارجی دیده میشد.  یکی از معروفترین  زیر مجموعه های متدهای چابک SCRUM هست. مشکل اصلی که در معرفی  اسکرام  وجود داره اینه که همه با خودشون مگن ! ” ایول میریم یه دوره ۲ روزه و یک جزوه ۱۶ صفحه ای رو میخونیم و کارهاشو انجام میدیم و همه مشکلاتمون حل میشه.”

یه جور ساده انگاری در این قضیه نهفته است. فراموش می کنیم در همان صفحه ۳ راهنمای اسکرام نوشته شده است.

Scrum is Simple to undrestand and difficult to Master

تمام مشکلات قبلی را می اندازیم گردن، RUP , UML , Water Fall و …. یادمان میرود خودمان به قوانین همان متدلوژی های قدیمی هم خوب عمل نکردیم.

RUP

خب به نظرم همه مشکلات قدیمی مربوط به RUP  نبود. الان هم تمام مشکلاتمان با SCRUM حل نخواهد شد. و باید بدونیم تازه این اول راه است و مشکلات زیادی به استقبال شما خواهند آمد. همیشه  وقتی اینجور معرفی ها در مورد اسکرام و اجایل رو میخونم فکر میکنم مکنم ممکنه چند سال دیگه همین حرفایی که الان در مورد RUP میزنیم را در مورد روش های اجایل بزنیم. همونطور که RUP هم آنقدرها بد نبود و بسیاری از مشکلاتش ( مخصوصا در شرکت های ایرانی ) به دلیل عدم آگاهی و شناخت  از آن بود، اسکرام هم نسخه ای معجزه آسا و درمانی سهل و آسان برای تمام درد ها نیست. پیاده سازی اسکرام آنقدرها هم آسان نیست. حدود ۴-۵ سال است در مورد چابک، اجایل و روش های توسعه مدرن نرم افزار بر حسب علاقه ام مطالعه میکنم. ۲ سال هست مدرک PSM را گرفته ام و به عنوان Scrum Master کار میکنم. در ادامه بخشی از واقعیتهای پنهان اسکرام، روش های چابک و تجربیات شخصی ام را مینویسم.

اینکه فکر کنیم با درست کردن یک لیست از نیازمندی های محصول ، درست کردن یک Task Board خوشگل ، معرفی یک نفر به عنوان Product Owner یا مالک محصول ، یک نفر به عنوان Scrum Master و برگزاری یکسری جلسه مثلا ۲ هفته یکبار، همه چی حل خواهد شد بسیار ساده انگارانه است.اصولا این روش مواجهه با اسکرام، کارها رو خرابتر هم میکنه. همان نظم و دیسیپلین نصفه نیمه ای که قبلا وجود داشت هم فراموش میشه و آغاز یک شلخته گی و بی نظمی، کل تیم و پروژه را  تهدید خواهد کرد.
کارهای سختی را باید به عنوان مدیر اسکرام انجام دهیم:

  • فرآیند ساخت یک تیم اسکرام، خیلی خیلی مشکل هست.
  • پیدا کردن و یا آموزش برنامه نویسان خوبی که روح چابکی و اسکرام را بدانند و بپذیریند کار بسیار سختی است.
  • اینکه بتوانید قوانین و چهار چوب اسکرام را در سازمانی که در آن کار میکنید پیاده کنید کار زمان بری است.
  • اینکه بتوانید فرهنگ کاری تیم و سازمانتان را  تغییر دهید کار مشکل و زمان بری است.
  • کم کم به این بینش میرسید که دیگر نمیتوان با استفاده از روش های قدیمی کد نویسی و یا  ابزارهای قدیمی، خیلی چابک باشید پس نیاز خواهید داشت در خلال تغییر فرهنگ سازمانی آموزش هایی را برای تیم فنی ترتیب دهید که هم زمانبر است و هم هزینه زیادی خواهد داشت. (استفاده از روش هایی مثل Continues Integration و Continues Deployment و یا جدی گرفتن تست اتوماتیک و … که همه و همه در تحویل سریع تر نرم افزاری کارا در بازه های زمانی کوتاه تر یک نیاز جدی خواهند بود)
  • روش مواجهه با برنامه نویسان قدیمی سازمان که با تیم همکاری نمکنند، تکروی میکنند ، کار تیمی را نمی پسندند و علاقه ای به Inspect and Adapt ندارند شما را مجبور میکند تصمیمات سختی در مورد نیروی انسانی و تیم توسعه تان بگیرید.
  • تشویق و ترغیب برنامه نویسان و آموزش آنها به پیروی از روش های  برنامه نویسی بهینه (Clean Code) در نبود Document ها کار نسبتا سختی است. (مخصوصا برنامه نویسان خفن ! )
  • کمک به مالک محصول در تعریف PBI ها و واضح کردن User Story ها
  • برگزاری جلسات منظم و هدفمند Grooming و تحلیل و بررسی کارهای آینده همراه با تیم اسکرام
  • حفاظت از تیم توسعه اسکرام و دور کردن آنها از هر نوع Impediment محیطی و سازمانی
  • پیوسته نگه داشتن نظم حرکتی اسپرینت ها، جلسات و … در آغاز کمی مشکل است تا همه  به آن عادت کنند
  • و به قول فیصل محمود باید بدانید بیشتر از ۷۰ درصد مشکلات شما در پیاده سازی اسکرام، روابط انسانی و مشکلات مربوط به تعامل بین افراد تیم است.

در پایان باید تاکید کنم که من مطالعه و استفاده از روش های چابک مانند اسکرام را توصیه مکنم و ولی فقط میخواستم بدانید اسکرام آن تعاریف ساده و مدینه فاضله ای که عموما در وب سایت ها و وبلاگ ها میخوانیم نیست.

۵-مرداد-۱۳۹۲
دسته بندی شده در: Agile, عمومی Tags: , , , |

Single Responsibility Principle به زبان ساده.

در پست ۵ اصل پایه ای طراحی شی گرا – SOLID به زبان ساده در مورد ۵ اصل مهم در طراحی شی گرا صبحت کردم. در این پست اولین این اصول یا همان SRP را با یک مثال کوچک توضیح میدهم.

اصل SRP بیان میکند که هر کلاس باید فقط یک وظیفه یا مسئولیت داشته باشند ، Uncle Bob وظیفه یا مسئولیت را خیلی سرراست تعبیر میکند.

 وظیفه یا مسئولیت دلیلی برای تغییر یک کلاس  است.

public class OrderProcessor
{

public void Process(Order order)
{
ProcessOrder();

if (order.Customer.NotifiyMe)
NotifyCustomer(order.Customer, order.Id.ToString());
}

private void ProcessOrder()
{
// Process Order Logic
}

private void NotifyCustomer(ContactDetails contact, string message)
{
//Send Notification To User

}
}

خب، همانطور که میبینید این یک نمونه بسیار ساده  است که وظیفه اش پردازش سفارش است. حتی در جمله قبلی ای که نوشته ام وظیفه این کلاس به وضوح بیان شده است. وظیفه این کلاس “پردازش سفارش” است. اگر من بخواهم نحوه فرستادن Notification خود را تغییر دهیم باید کلاس OrderProcessor را دستکاری کنیم. در حالی که وظیفه اصلی این کلاس “پردازش سفارش” است و اصلا نیازی نیست از چگونگی ارسال ایمیل یا اس ام اس آگاه باشد. همچنین هرنوع دستکاری در منطق ارسال پیام باعث تغییر در کلاس OrderProcessor نیز میشود. در اینجا به وضوح دیده میشود که دو وظیفه یا دو کار در یک کلاس پیاده سازی شده است که نقض کننده اصل SRP است.
ساده ترین کار بیرون کشیدن یک کلاس جدید است که کل منطق ارسال پیام در آن Encapsulate میشود. من آنرا Notification Service می نامم.

public class OrderProcessor
{
private readonly NotificationService _notificationService
= new NotificationService();

public void Process(Order order)
{
ProcessOrder();

if (order.Customer.NotifiyMe)
_notificationService.Send(order.Customer.ContactDetails,order.Id.ToString());
}

private void ProcessOrder()
{
// Process Order Logic
}
}

public class NotificationService
{
public void Send(ContactDetails contact, string message)
{
    //Send Notication Logic
}
}

به صورت کلی، کلاس های متعدد با وظایف واضح و متمایز ، منجر به طراحی قابل انعطافی میشود. هر چه وظایف یک کلاس بیشتر باشد دلایل برای تغییر آنهم بیشتر خواهد شد که این اصلا خوب نیست.

خب نمونه کد اخیر یک مرحله بهینه شد (Refactor) اما هنوز هم مشکلاتی دارد!

  1. کلاس OrderProcessor جدید وابسته به کلاس NotificationService است.
  2. کد اخیر Testable نیست.
  3. هنوز نمونه کد اخیر تمام اصول Solid را رعایت نکرده است.

چند گام برای بهتر شدن کد قبلی را یکجا برمیداریم :)

public class OrderProcessor
{
private readonly INotificationService _notificationService;

public OrderProcessor(INotificationService notificationService)
{
_notificationService = notificationService;
}

public void Process(Order order)
{
ProccessOrder();

if (order.Customer.NotifiyMe)
_notificationService.Send(order.Customer.ContactDetails,order.Id.ToString());
}

private void ProcessOrder()
{
// Process Order Logic
}
}

public interface INotificationService
{
void Send(ContactDetails contact, string message);
}

public class EmailNotificationService : INotificationService
{
public void Send(ContactDetails contact, string message)
{
// Sending Email Logic
}
}

با اینکه این نوشته قرار بود فقط در مورد SRP باشد ، اما اصول و قواعد کد نویسی خوب و بهینه به هم پیوسته است. در نمونه کد بالا با استفاده از یک Interface کلاس ProcessOrder دیگر به Concrete Implementation مربوط به NotificationService وابسته نیست. همچنین با استفاده از Constructor Injection میتوانیم نوع خاصی از INotificationService را به کلاس ProcessOrder ارسال  (تزریق) کنیم. کد اخیر Coupling کمتری دارد همچنین قابلیت Test بهتری دارد.
در زبان C# دوراه برای استفاده از Abstraction یا انتراع وجود دارد . Interface و Abstract Class ها. من در کد اخیر از Interface استفاده کرده ام. در نمونه کد آخر ردپایی از اصول ISP و OCP نیز به چشم میخورد که در آینده بیشتر در مورد آنها صحبت خواهم کرد.

۱۴-اردیبهشت-۱۳۹۲
دسته بندی شده در: Clean Code, SOLID, کدنویسی

مرتب سازی و مرور ساده تر بکلاگ محصول در TFS 2012.2

حدود ۲۰ روز پیش تیم توسعه TFS یا همان Team Foundation Server مایکروسافت آپدیت شماره ۲ این محصول را به صورت رسمی عرضه کردند. این آپدیت همزمان با آپدیت شماره ۲ محصول Visual Studio 2012 مایکروسافت عرضه شده است و ویژگی های خوبی به Visual Studio و TFS اضافه شده است.

واسط کاربری TFS تغییرات خوبی کرده و بسیار شبیه به TFS Service شده است. در مورد ویژگی های جدید به صورت خلاصه میتوان به موارد زیر اشاره کرد.

  • Work Item Tagging – تگ زدن کارها
  • Kanban Board – اضافه شدن تخته یا برد کانبان برای بکلاگ محصول
  • ارسال کارها و Task به وسیله ایمیل در بکلاگ محصول
  • دسترسی راحت تر به Version Control از طریق دشبورد وب
  • امکان مقایسه Source Code ها و تغییرات انجام شده در واسط کاربری وب
  • Code Coloring و Syntax Highlighting در واسط کاربری وب
  • و….

برای مشاهده لیست کامل تغییرات ایجاد شده و ویژگیهای جدید میتوانید ازین لینک استفاده کنید.

اما دو ویژگی جدید در قسمت Agile Planning یا همان مدیریتِ چابک اضافه شده است که به نظرم بسیار مفید کاراست. اولی همان اضافه شدن Kanban Board است که یک نمای خوب است از Product Backlog شما و نحوه پیشرفت کلی کارها. این نوع برد قبلا به TFS Service اضافه شده بود که در حال حاضر به در TFS 2012 هم قابل  استفاده است. همچنین ستون های این برد امکان تغییرات دارد و همچنین میتوانید مراحل جدیدی متناسب با فرآیند کاری خود به سیستم اضافه کنید.

اما ویژگی دوم بسیار کوچک ولی بسیار کاراست.این ویژگی چیزی نیست جز همان Work Item Tagging یا تگ زدن (نشانه زدن) کارها. اگر Product Back Log محصول شما شلوغ است و یا مدیر محصول شما از ترس شلوغ شدن بیش از حد Product Back log از اضافه کردن Item های جدید هراس دارد ( به سبب عدم کنترل مناسب رو لیست بزرگی از کارها) میتوانید به سادگی از تگ کردن کارها استفاده کنید.

Workitem Tagging In TFS 2012

خیلی ساده میتوانید PBI ها را تگ کنید، بر اساس تگ ها فیلتر کنید و به راحتی کارها دسته بندی کنید. هر چند قبلا هم می شد براساس Area دسته بندی هایی ایجاد کرد اما امکان Tagging بسیار راحتتر و کاربردی تر است. به نظرم ازین به بعد پیدا کردن آیتمها در جلساتی مثل Grooming و Planning بسیار ساده تر خواهد بود.

۷-اردیبهشت-۱۳۹۲
دسته بندی شده در: Agile, TFS

۵ اصل پایه ای طراحی شی گرا – SOLID به زبان ساده

SOLID به زبان ساده

SOLID مخفف پنج اصل زیر بنایی طراحی شی گرا (Object-Oriented Design) است که اوایل سال ۲۰۰۰ میلادی توسط Robert C. Martin یا همان Uncle Bob معرفی شد.
اگر هنگام طراحی و برنامه نویسی از این اصول پیروی کنیم و رعایت این اصول و قوانین را مد نظر داشته باشیم، نرم افزار توسعه یافته شده را میتوان راحتتر در طول زمان توسعه (Extensibility) داد و نگهداری (Maintainable) کرد.

اصولا برنامه نویسان از این روشها و اصول هنگام برنامه نویسی و یا بهینه سازی کد های موجود (Refactoring) استفاده میکنند.
اگر با Unit Testing یا همان تست واحد! آشنا باشید و در یک پروژه نسبتا قدیمی کار کنید و بخواهید برای این سیستم Unit Test بنویسید به زودی متوجه میشود که به راحتی نمیتوان برای آن تست درست حسابی نوشت. امکان دست زدن به کلاسها، جدا کردن کلاسها، جایگزین کردن آنها توسط Mock ها و Stub ها وجود نداره و عملا امکان نوشتن Unit Test استاندارد و مفید وجود ندارد.
دلیل این مشکل این است که هنگام توسعه اولیه نرم افزار، نوشتن کدی که قابل تست باشد مد نظر نبوده است (یا اولویت نداشته) و یا اصول و قوانین پایه ای طراحی شی گرا رعایت نشده است. خب در این مرحله اکثر برنامه نویسان و توسعه دهندگان شروع به Refactoring یا بهینه سازی کدها میکنند. ولی باید از کجا شروع کرد؟
دقیقا در این نقطه این ۵ اصل به کمک ما می آیند و با استفاده از آنها میتوانیم کدهای فعلی را تا حد زیادی بهبود داده و مرحله به مرحله قابلیت تست را به آنها اضافه کنیم.

اگر هم از متدهای جدید برنامه نویسی مانند توسعه آزمایش محور (Test Driven Development) استفاده کنیم و واقعا TDD کار کنیم! ناخودآگاه بسیاری از این اصول در کدهای و کلاس های نوشته شده وجود دارند.

اما این اصول چه چیزهایی هستند که اینقدر میتوانند مفید و کارا باشند؟!
این ۵ اصل که اصول اولیه و پایه طراحی کلاس ها و اشیا هستند به ترتیت عبارتند از:

۱٫Single Responsibility Principle
یک کلاس باید فقط یک دلیل برای تغییر داشته باشد، یا یک کلاس باید فقط یک مسئولیت داشته باشد.

۲٫Open Closed Principle
شما باید بتوانید رفتار یک کلاس را توسعه دهید بدون اینکه آنرا تغییر دهید. (کد آنرا دستکاری کنید)

۳٫Liskov Substitution Principle
کلاسهای به ارث رفته (مشتق شده) باید بتوانند جایگزین کلاسهای اصلی شوند.

۴٫Interface Segregation Principle
تعداد بیشتری اینترفیس کوچک و خاص، بهتر از یک اینترفیس بزرگ (چاق) با متدهای بیشتر است.

۵٫Dependency Inversion Principle
وابستگی به Abstraction و نه Concrete Implementation.

سعی میکنم در ۵ پست جدا گانه هر یک از ۵ اصل رو یک توضیح مختصری بدم. نکته مهمی که باید به خاطر داشته باشیم این است که این اصول یک راهنما هستند و نه یک هدف ! همیشه باید سعی کنیم یک تناسب و تعادل را رعایت کنیم.

۲۹-فروردین-۱۳۹۲
دسته بندی شده در: Agile, SOLID, کدنویسی Tags: |

← نوشته های قدیمی تر