سه:
اغلب دانشجویان آن چه را که آموخته‌اند به شیوه‌ی «یادگرفتن از روی دست کسی» است. یعنی در تیمی که بوده‌اند یا جایی که درس خوانده‌اند، شخصی الگویی را برای طراحی استفاده کرده است و آنها نیز آن را یاد گرفته‌اند و استفاده می‌کنند. مثال پررنگ این شیوه، مبحث لایه‌بندی در معماری است یا استفاده از ترکیبی از interface و class که البته در این مثال (مسأله اشکال هندسی) زیاد از آن استفاده می‌شود. برای این کار، رابط interfaceای به نام IShape و بعد کلاسی به نام Circle و … که آن را پیاده‌سازی می‌کند، ایجاد می‌کنند.

این روش که شاید بتوان آن را «یادگیری با مثال» نیز نامید، در عین حال که یکی از روشهای بسیار مؤثر یادگیری است اما خطر بزرگی را نیز به همراه دارد. چنین روشی اگر فقط در سطح «مثال» باقی بماند و به «چرایی» یا به اصطلاح خودمانی «فلسفه‌ی کار» نینجامد بسیار خطرناک است.
مثال بامزه‌ی این الگوی رفتاری، داستان زیر است:
«زوج جوانی در تعطیلات پیش خانواده عروس می‌روند. عروس از یخچال گوشت را درمی‌آورد. قسمتی از آن را می‌برد و روی قطعه بزرگتر می‌گذارد و آن را در فر می‌گذارد. همسرش از این رفتار غیرمعمول تعجب می‌کند و می‌پرسد چرا این کار را کرده است.
عروس لحظه‌ای فکر می‌کند و می‌گوید:خب، این راهی است که که باید گوشت را پخت. مادر، مگر این طورنیست؟
مادرش می‌گوید:بله، من یاد گرفته‌ام که این طوری انجام بدهم.
بعد مادربزرگ صحبت می‌کند: بله. من خودم این روش را به شما یاد داده‌ام. اما ما آن روزها جوان بودیم و پول زیادی نداشتیم که ماهی‌تابه‌ای بزرگ بخریم. من بیشتر از چهل سال است که دیگر این کار را نمی‌کنم.»

در اینجا وقتی که از دانشجو می‌پرسید که «چرا از ترکیب interface و class استفاده کرده‌اید؟» و بعد بحث را به این سمت می‌برید که «چرا از interface استفاده کرده‌اید؟»، پاسخ‌هایی که دریافت می‌کنید نشان می‌دهد که یادگیری آنان به «چرایی» ختم نگردیده است. آخر گفت‌وگو به اینجا ختم می‌شود که «روزی شخصی (همکاری یا استادی) این گونه انجام داده است و من یادگرفتم». یکی از بامزه‌ترین آنها پاسخی بود که یکی از عزیزان داد: «استادی داشتیم که می‌گفت ما همیشه از ترکیب interface و class استفاده کرده‌ایم و جواب گرفته‌ایم!».
ندانستن «چرایی» خطرات زیادی به همراه دارد. شاگردی که چرایی را نداند، احتمالاً از استاد پیشی نخواهد گرفت. وقتی «چرایی» را می‌دانیم، با حفظ آن، «چگونگی‌»های متنوع و متفاوتی را ابداع می‌کنیم. چرایی‌ها معمولاً ثابت هستند و این چگونگی‌ها هستند که در طول زمان و با تجربه تغیییر می‌کنند.
یکی از گروه‌هایی که به دنبال «یادگیری با مثال» هستند، کسانی‌اند که علجه دارند، وقت کافی برای یادگیری دقیق و عمیق ندارند یا کلاً عجول هستند. این روش هر چند برای شروع و «راه افتادن کار» خوب است، اما اگر در همین سطح باقی بماند، اثرات عمیقی نخواهد داشت.

پرسشهایی که در مسأله‌ی اشکال هندسی می‌توان طرح کرد عبارتند از:
1- تفاوت بین interface و abstract class چیست؟ (لطفاً دقت فرمایید که پاسخ این پرسش فقط دو کلمه است و نه یک لیست بلند و بالا که در اینترنت پیدا خواهید کرد)

2- از interface برای shape استفاده کنیم یا abstract class؟ یا فرقی نمی‌کند کدام یک را انتخاب کنیم؟ (امیدوارم پاسخ شما از این جنس نباشد: «تجربه‌ی من می‌گوید….»؛ «فلانی در کتاب فلان گفته است ….»؛ «چه فرقی نمی‌کند؟!»؛ «مهم آن است که مشتری راضی باشد!»)

3- اصلاً چرا باید برای Shape عنصر و المانی در طراحی در نظر بگیریم؟ (توجه داشته باشید که وجود عامل سومی باعث توجیه وجود Shape می‌گردد و نه دایره و مستطیل. اگر عامل سوم وجود ندارد، وجود Shape در طراحی بی‌استفاده است و فقط از روزی عادت ایجاد شده است)

پرسش از چرایی، حتی در آموزه‌های مدیریتی نیز وجود دارد:
«چرا؟
سیمون سینک، نویسنده کتاب «قدرت چرایی» می‌گوید: همه سازمان‌های بزرگ دنیا، با این سوال روبه‌رو هستند که چرا ما این کار را انجام می‌دهیم؟» این سوال، باید برحسب سیاستی در سطح شرکت باشد. به کارمندانی که مودبانه در مورد چرایی عملکرد سازمان سوال می‌پرسند، توجه کنید. این نشان می‌دهد آنها به شغلشان علاقه دارند و کنجکاوی آنها می‌تواند در نهایت به یک قابلیت مدیریتی تبدیل شود.» دنیای اقتصاد

توصیه: علاوه بر «چگونگی»، به دنبال «چرایی»‌ باشید.
توصیه: فلسفه‌ی مکانیزم‌ها و امکاناتی را که در طراحی دارید، به درستی یاد بگیرید. چرا Interface؟ چرا …

گزیده:
متفاوت بودن آسان، ولی بهتر بودن بسیار دشوار است.
جاناتان ایو

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

گفتار:
آموزش طراحی را معمولاً با یک مثال شروع می‌کنم: دو شکل داریم، مستطیل و دایره. می‌خواهیم آنها را رسم کنیم و مساحت‌شان را کنارشان بنویسیم. طرحی برای مسأله و مبتنی بر پارادایم شیءگرایی ارائه کنید.
چون دوره‌ی آموزشی است، بین دانشجویان نوعی «مسابقه‌ی دانایی» راه می‌افتد. هر کسی تلاش دارد همه‌ی دانش و تجربه‌اش را روی میز بریزد و طرحش اشاره‌ای به آنها داشته باشد. این موضوع طبیعی است، هر انسانی دوست دارد که بگوید «باسواد و باتجربه‌ام»

دانشجویان با انبوهی از تکنیک‌ها و مفاهیم به مسأله حمله می‌کنند: از Interface, abstract class بگیرید تا مباحثی مانند Layering و DI و گاه AOP!

یک:
اولین نکته‌ای که در این شرایط آموخته‌ام این است که «گاهی ندانستن بهتر از دانستن است» و «گاهی بی‌تجربگی به تجربه می‌چربد»!
دانش و تجربه‌ی دانشجویان به خصوص بهترین‌هایشان منجر به بحرانی می‌شود که آن را «انفجار پیچیدگی بی‌مورد» می‌نامم. به زبان ساده‌تر، برای جابه‌جایی یخچال به خانه‌ی جدید، نیازی به اجاره‌ی تریلی هجده چرخ نیست! بدیهی است که تریلی به مراتب قوی‌تر از پیکان‌ وانت است.
انتخاب تکنیک‌ها از یک سیستم اقتصادی تبعیت می‌کند. چقدر هزینه کنیم و چه به دست آوریم. مدیر مؤفقی روزی به من آموخت که «حواست باشد گاهی ده واحد هزینه می‌‌کنی و فقط دو واحد به دست می‌آوری!».
توصیه: همواره در مورد مسائل طراحی، در چارچوب یک سیستم اقتصادی تصمیم‌گیری کنید.

دو:
معلمان زحمت‌کش ریاضی، فیزیک و شیمی سعی می‌کردند که بیاموزند که فهم و درک مسأله، پنجاه درصد حل مسأله است. یادم می‌آید که معلمانم برای یاددان این موضوع، ورودی را یک طرف می‌نوشتند و خروجی‌های مورد انتظار را طرف دیگر. سپس می‌گفتند دنبال مطلب یا راه حلی باشید که بتواند شما را از طرف اول به طرف دوم برساند.
در این بین برای این که معنی قید (Constraint) را بیاموزانند، محدودیت‌هایی بر راه حل حاکم می‌کردند. مثلاً حد زیر را بدون استفاده از روش هوپیتال به دست آورید. جوابهای معادله‌ی درجه دوم زیر را بدون استفاده از روش دلتا محاسبه کنید. پاسخ پرسش زیر را در کم‌تر از نصف صفحه بنویسید.
جورج پوليا جایی گفته است: «پاسخ به پرسشی كه فهميده نشده باشد، كاري ابلهانه است. كار كردن براي رسيدن به هدفي كه مورد پسند نيست، غم‌انگيز است.»
دانشجویان قبل از آن که مسأله را خوب بفهمند، حول و حوش آن «بچرخند» و ابعاد آن را خوب ببینند، علاقه دارند زود به راه حل فکر کنند و به راه حل برسند. چون هدف نهایی، «راه حل» است. البته وقت کمی که به آنها داده می‌شود نیز این عارضه را تشدید می‌کند.
توصیه: هرچند دست‌یابی به راه حل، موضوعی است تدریجی، اما تا قبل از فهم درست و کامل مسأله و تحلیل آن، به راه حل فکر نکیند.

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

گزیده:
صبح، باران، بی‌بالان!

واژه‌های جدیدی به واژه‌نامه اضافه شده است. لطفاْ آنها را در اینجا مشاهده فرمایید.
خوشحال خواهم شد که نظرات شما را دریافت کنم.

گزیده:
شب، سکوت، کویر

برچسب‌ها: واژه‌نامه, Agile چابک

گفتار:

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

پرسشی که هنوز برایم بی‌جواب مانده این است که: چرا شخصی بعد از نزدیک به دو دهه همکاری با یک شرکت از آن جدا می‌شود؟

بی‌شک چنین شخصی یکی از سرمایه‌های بسیار نایاب آن شرکت است. شرکت‌ها چه طرحی برای نگهداری سرمایه‌های انسانی خود دارند؟ آیا شرکت‌های نرم‌افزاری برای چنین روزهایی آماده‌اند؟

گزیده:
نامه‌های بابا لنگ دراز به جودی:
جودی! کاملا با تو موافق هستم که عده‌ای از مردم هرگز زندگی نمی‌کنند و زندگی را یک مسابقه دو می‌دانند و می‌خواهند هرچه زودتر به هدفی که در افق دوردست است دست یابند و متوجه نمی‌شوند که آن قدر خسته شده‌اند که شاید نتوانند به مقصد برسند و اگر هم برسند ناگهان خود را در پایان خط می‌بینند. درحالی که نه به مسیر توجه داشته‌اند و نه لذتی از آن برده‌اند.

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

مرجع: از میان نامه‌ها

پیش گفتار:
حاج قربان سلیمانی (۱۲۹۹ – ۳۰ دی ۱۳۸۶)، بخشی و نوازنده دوتار و خواننده موسیقی محلی شمال خراسان بود.

از جمله افتخارات وی می‌توان به کسب مقام اول جشنوارهٔ موسیقی لیون فرانسه و همچنین احراز مقام ستارهٔ جشنواره اوینیون فرانسه اشاره کرد. وی ده‌ها اجرای دوتارنوازی در کنسرت‌های موسیقی کشورهای اروپایی، آسیایی و امریکا داشت. به نقل از اینجا

می گفت: «وقتی ساز می زنم همه چیز را از یاد می برم. در وضعیت معمولی نشستن برایم سخت است؛ نیم ساعتی که می نشینم، خسته می شوم. اما ساز که می زنم؛ تو بگو دوساعت؛ سه ساعت می زنم. دیگر حواسم به چیز دیگری نیست. من با سازم حرف می زنم. سازبه من می‌گوید؛ حالا بزن یا نزن. نمی دانم او ساز من است یا من ساز او… وقتی که ساز و نوایش آدم را گیر بیندازد دیگر نمی‌توانی از چنگش آزاد شوی. در این حال است که از خود بی خود می‌شوم، حساب زمان از دستم در می‌رود و تمام بدنم خیس عرق می‌شود. سیم‌های ساز جان می‏گیرند و با هر پنجه من به فریاد و لرزه در می‌آیند.»

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

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

گفتار:
خدا رحمت کند حاج قربان را. چه عاشقانه درباره‌ی سازش سخن گفته است.
هر چند من و سماموس، هیچ شباهتی به استاد بزرگ، حاج قربان و سازش نداریم، اما اتفاقات چند وقت اخیر مرا یاد حاج قربان انداخت و حرفهایش، سه ماهی است که اینجا چیزی ننوشته‌ام و ماجرا از آن جا شروع شد که «یه روز ساز با من قهر کرد و هر چه خواستم بنوازنم نشد که نشد». خیلی فکر کردم و مانده‌ بودم که «او ساز من است یا من ساز او».
اما هر چه باشد حقیقت این است که «وقتی ساز می‌زنم همه چیز را از یاد می‌برم. … اما ساز که می‌زنم؛ تو بگو دوساعت؛ سه ساعت می‌زنم. دیگر حواسم به چیز دیگری نیست. من با سازم حرف می‌زنم. ساز به من می‌گوید؛ حالا بزن یا نزن. نمی‌دانم او ساز من است یا من ساز او… وقتی که ساز و نوایش آدم را گیر بیندازد دیگر نمی‌توانی از چنگش آزاد شوی.»

گزیده:
ندارد

مترجم: خانم مهندس فاطمه اردستانی

بخش اول

۱-۲- داستان کاربر به کاهش فاصله مشتری-توسعه‌دهنده کمک می‌کند
در توسعه‌ی چابک‏‏، توسعه‌دهنده موظف است به زبان کاربر صحبت کند، اما کاربر موظف به صحبت به زبان توسعه‌دهنده نیست. نکته اصلی، ارتباط مؤثر است که برای تحقق آن، نیاز به زبان مشترکی است. داستان کاربر این نقش ‏‏را بازی می‌کند چرا‏‏که کاربر و تیم فنی برداشت یکسانی از آن دارند.

بیل وِیک یکی از ابداع‌کنندگان XP، این موضوع را بدین شکل توصیف می‌کند:
زبان دست‌وپا شکسته، زبان ساده‌ای است که معمولاً برای تجارت‏‏ و توسط افرادی به‌کار می‌رود که علی‌رغم تمایل به همکاری، نمی‌توانند به زبان مادری‏‏ یکی از دو طرف با هم صحبت کنند. داستان‏‏ کاربر شبیه این زبان است. انتظار نداریم که مشتریان یا کاربران، سیستم را مانند برنامه‌نویسان بفهمند. لذا داستان کاربر، کارِ زبان دست‌وپا شکسته را می‌کند تا دو طرف تا اندازه‌ای که برای همکاری موثر لازم است، گفت‌وگو کنند و به توافق برسند.

به کمک داستان کاربر مجبور نیستیم زبان یکدیگر را با مهارتی که برای سرودن شعر و غزل لازم است، یاد بگیریم. بلکه نیازمان این است وقتی‌که درباره‌ی معامله‌ای برد-برد مذاکره می‌کنیم، همدیگر را به‌اندازه کافی درک کنیم!

۱-۳-داستان‌کاربر نیازمندی نیست
اگرچه با داستان کاربر اکثر کارهایی که قبلاً توسط مشخصات نیازمندی نرم‌افزار، مورد کاربرد و غیره انجام می‌شد امکان‌پذیر است؛ اما اساساً در پاره‌ای موارد ظریف ولی بسیار مهم متفاوتند:
– آنها مشخصات تفصیلی نیازمندی‌ها نیستند(کاری که سیستم باید انجام دهد) بلکه عبارات قابل مذاکره درباره‌ی انگیزه‌ی کاربرند (نیاز است کاری در این‌باره انجام شود).

– آنها کوتاه، روان و قابل فهم برای توسعه‌دهندگان، ذینفعان و کاربران هستند.

– آنها بخش‌های کوچکی از کارکردهای باارزش سیستم‏‏ را نشان می‌دهند که برنامه‌نویس می‌تواند در بازه‌ی چند روز تا چند هفته پیاده‌سازی کند.

– برآورد آنها نسبتاً آسان است، در نتیجه حجم کار لازم برای پیاده‌سازی کارکردهای سیستم می‌تواند به‌سرعت تعیین گردد.

– آنها در قالب مستندات حجیم و سنگین منتقل نمی‌شوند، بلکه در لیست‌هایی قرار‏‏ می‌گیرند که مرتب‏‏ و بازمرتب‌سازی آنها با یافتن اطلاعات جدید راحت‌تر است.

– آنها در ابتدای پروژه دارای جزئیات نیستند بلکه جزییات آنها در وقت مناسب(به‌موقع ) بیان می‌شود و به همین دلیل است که از تفصیل زودهنگام، تأخیر در توسعه‏‏، افزایش موجودی نیازمندی‏‏ها و اعلام قیدهای بیش‏ ‏‏‏‏‏از حد برای راه‌حل اجتناب می‌کنند.

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

– داستان کاربر و کدی که به‌سرعت برای آن نوشته می‌شود، ورودیِ تدوین مستنداتی است که به تدریج و همزمان با کد کامل می‌شوند.

گزیده:
مراقب باش كه نيروهايت را بر سر مسايل پراكنده از دست ندهي. هميشه تلاش كن كه آنها را متمركز كني. گوته
مرجع: اس.جی.

برچسب‌ها: چابک Agile, نیازمندی‌ها Requirements

Mostly, when you see programmers, they aren’t doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they’re sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head.
Charles M. Strauss

گزیده:
ندارد