این کتاب ۴۸۰ صفحه ای برای تمامی کاربران و توسعه دهندگان Microsoft CRM مفید است و دید نسبتاً جامعی از این سیستم در زمان کوتاهی بدست داده، با انتقال مناسب مفاهیم، کمک زیادی به استفاده صحیح و توسعه مناسب این سیستم می کند.

و همچنان خونه دلخواهمان را پیدا نکرده ام.

پیکنیک بدون نمک یک فاجعه خواهد بود، و همه آنها با این مورد موافق بودند.
بعد از یک بحث طولانی، جوانترین لاک پشت برای آوردن نمک از خانه انتخاب شد.

لاک پشت کوچولو ناله کرد، جیغ کشید و توی لاکش کلی بالا و پایین پرید، گر چه او سریعترین لاک پشت بین لاک پشت های کند بود!

او قبول کرد که به یک شرط بره؛ اینکه هیچ کس تا وقتی اون برنگشته چیزی نخوره.
خانواده قبول کردن و لاک پشت کوچولو به راه افتاد.

سه سال گذشت … و لاک پشت کوچولو برنگشت. پنج سال … شش سال … سپس در سال هفتم غیبت او، پیرترین لاک پشت دیگه نمی تونست به گرسنگی ادامه بده.
او اعلام کرد که قصد داره غذا بخوره و شروع به باز کردن یک ساندویچ کرد.

در این هنگام لاک پشت کوچولو ناگهان فریاد کنان از پشت یک درخت بیرون پرید،« دیدید می دونستم که منتظر نمی مونید. منم حالا نمی رم نمک بیارم»!

نتیجه اخلاقی:
بعضی از ماها زندگیمون صرف انتظار کشیدن برای این می شه که دیگران به تعهداتی که ازشون انتظار داریم عمل کنن. آنقدر نگران کارهایی که دیگران انجام میدن هستیم که خودمون (عملا) هیچ کاری انجام نمی دیم.

منبع: نامه ای از دوست عزیزم آقای جاودانی

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

در این پست، منظور از طراحی، طراحی نرم افزار است که دارای جنبه های مختلفی است. برخی از آن عبارتند از:

• طراحی معماری
• طراحی کلاس ها
• طراحی واسط کاربری
• طراحی بانک اطلاعاتی
• طراحی الگوریتم
• طراحی پروتکل

مهمترین مسأله ای که باید در یک طراحی خوب در نظر گرفت، اهداف طراحی است. طراحی خوب، طراحی است که به اهداف ما از طراحی نرم افزار منجر شود. البته این اهداف، اهداف ذینفعان است که بانیان اصلی تولید نرم افزار هستند.

در زیر به برخی از این اهداف اشاره می کنیم:

• افزایش سود خالص با کاهش هزینه های تولید و افزایش درآمد که برای بیشتر سازمانها این مهمترین هدف است.
• حصول اطمینان از پوشش دادن نیازمندی های مشتری و حل مسائل وی
• شتاب دادن به توسعه. که این هدف باعث کوتاه مدت شدن هزینه ها می شود و اطمینان می دهد که نرم افزار برای یک رقابت موثر و به موقع(در زمان تعیین شده توسط مشتری) به بازار ارائه می گردد.
• افزایش شاخص های کیفیت مانند usability، efficiency، reliability، maintainability و reusability که خود به نحوی باعث پایین آمدن هزینه ها و افزایش درآمد می شود.

طراحی نرم افزار، اتخاذ تصمیمات طراحی برای حل مسائل است. پرواضح است که در هر انتخاب، برای اینکه چیزی را بدست آوریم ناگزیریم چیزهایی را از دست بدهیم(قانون بقای طراحی!!). بنابراین سبک و سنگین کردن در طول طراحی پروژه و برقراری توازن بین اهداف(افزایش کیفیت، پایین آمدن هزینه تولید) شرط اصلی داشتن یک طراحی خوب است. البته این نکته را در نظر داشته باشیم که بالا بودن کیفیت نرم افزار ممکن است در بالا رفتن مقطعی هزینه ها، نقش مستقیم داشته باشد، اما در بیشتر موارد، در طول زمان، این هزینه ها به پروژه باز می گردد(با پایین آمدن هزینه توسعه و نگهداری).

James Shore در مقاله خود(Quality With a Name) اینطور می گوید:

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

در این مقاله کیفیت طراحی اینگونه تعریف می شود:

Design quality = change / developer time

 

برای گرفتن کامل این مطلب توصیه می کنم این مقاله ارزشمند را به طور کامل مطالعه کنید.

برای کامل تر شدن بحث از مقاله آقای Fowler کمک می گیریم. در این نمودار محور cumulative functionality همان قابلیت تجمعی(نه قابلیت مقطعی) است.

این نمودار نشان می دهد که نداشتن طراحی(عدم تلاش برای یک طراحی خوب) باعث پیشرفت سریع پروژه در ابتدای مسیر می شود اما به مرور زمان Productivity و کیفیت نرم افزار رو به افول می گذارد. نداشتن طراحی خوب باعث می شود تا به مرور زمان اعمال تغییرات در نرم افزار با سختی بیشتری انجام شود. در صورتی که با داشتن طراحی خوب، Productivity پایدارتر خواهد بود. نکته اینکه این دوخط(good design و no design) در نقطه ای از زمان یکدیگر را قطع می کنند. خط فرضی که از این تقاطع عبور می کند(design payoff line)، نقطه تصمیم گیری است. یعنی اگر میزان قابلیت های تجمعی نرم افزار شما در طول زمان زیر این خط فرضی باشد، عدم تلاش برای یک طراحی خوب تصمیم بهتری است و بالعکس٫ در واقع تصمیم گیری بر اساس این انجام می شود که قابلیت های این نرم افزار در آینده قرار است تا چه اندازه توسعه داده شود.

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

از نظرات دوستان در تکمیل این مطلب استقبال می کنم.

خوش به حال روزگار!

ای دریغ از تو اگر چون گل نرقصی با نسیم،

ای دریغ از من اگر مستم نسازد آفتاب!

ای دریغ از ما اگر کامی نگیریم از بهار.

بهاران خجسته باد!

Make interfaces easy to use correctly and hard to use incorrectly.

طراحی باید طوری باشد که استفاده کننده(Client) را به اشتباه نیندازد و او را به سمت استفاده صحیح از اینترفیس هدایت کند. به قول خودمان طراحی نباید دارای پتانسیل خطای زیادی باشد. اگر کلاینت در استفاده از Interface دچار اشتباه شود به این علت است که شما(طراح اینترفیس) اجازه این اشتباه را به وی داده اید.

Meyers می گوید:

responsibility for interface usage errors belongs to the interface designer, not the interface user.

دوست عزیزی(آقای صفری) در بخش نظرات نوشته بودند:

به قول Steve Jobs طراحی باید به گونه ای باشد که محصول ما انگار روح دارد . ایشون طراحی را یک لایه برروی هسته نمی داند همانطور که خودش اذعان دارد iPod روح دارد یعنی این روح با کاربر ارتباط برقرار می کند .

الحق به خاطر همین روحیه است که Apple اینقدر موفق است .

مقاله ایشان در باب طراحی قابل توجه است.

انگیزه اصلی نوشتنم شروع کلاس پربار Design Pattern توسط استاد عزیزم مهندس مهرداد در موسسه فراتر از دانش و پیگیری ایشان بود.

این بود که به مجتبای عزیزم زحمت راه اندازی دوباره هاست رو دادم و با WordPress 2.9.2 وبلاگ نویسی رو شروع کردم. سعی می کنم حداقل بخشی از مطالبی رو که یاد می گیرم در این وبگاه با دوستان عزیز به اشتراک بگذارم.