«یخ آب می‌شود در روح من،
در اندیشه‌هایم.
بهار،
حضور توست.
بودنِ توست.»
سال نو بر شما شاد و خوش باد.
آرزومند بهترین‌ها
سال نویی دیگر
درگذشت مهربان‌ترین
مادر دلبندم شامگاه پنجشنبه هجدهم اسفند ماه از دنیا رفت. هیچ واژه‌ای نمی‌تواند غم دوری او را بیان کند.
از همه عزیزانی که ابراز همدردی فرمودند، سپاسگزارم و برای آنها و خانواده محترمشان شادی و تندرستی آرزومندم.
فواید برنامه‌نویسی دونفره (Pair Programming)
پیش گفتار یک:
برنامه‌نویسی دو نفره تکنیکی است که در متد XP پیشنهاد و در کارایی و ضعف آن مطالب بی‌شماری نوشته شده است.
پیش گفتار دو:
در دوره‌هایی که برگزار می‌شود، از این تکنیک زیاد استفاده میکنم.
موضوع اصلی– فواید برنامه‌نویسی دو نفره:
پارسال دوره‌ای برگزار شد که بخشی از آن نیز به این تکنیک اختصاص داشت. دو همکار یکی متأهل (آقای بیگی) و یکی مجرد (آقای محمودی) و یک خانم (خانم حسنی) نیز از شرکت‌کنندگان دوره بودند. (اسامی واقعی نیست). آقای محمودی و خانم حسنی نیز اعضای یکی از تیمهای دو نفر بودند.
چند هفته پیش آقای محمودی لطف کردند و عکسهای پایان دوره را به همراه خبرهایی از عزیزان برایم ارسال کردند. خیلی شاد و خوشحال شدم(عکسها و خاطرات، رشد و پیشرفت آقای محمودی، پدر شدن آقای بیگی).
در نامه نوشته بودند که:
«مطلب آخر اینکه خانم حسنی هم خیلی خیلی سلام رسوندن»
در پاسخ ایشان نوشتم:
«سلام بنده را هم خدمت ایشان برسانید. این جمله شما خیلی مشکوک بود. نتوانستم آن را تحلیل کنم. لطفاً یوز کیس آن را برایم ارسال کنید 
»
ایشان در پاسخ نوشتند:
«اما در خصوص نکته شک برانگیز. خانم حسنی بر این عقیده‌اند که … هم چیزهایی هست، مثل عشق و زندگی.
آقای بیگی هم از سالیان پیش و بعد از اینکه متاهل شدند همیشه به دیده‌ی حسادت به دوران مجردی من مینگریستند و از اینکه روش Pair Programming شما پایانی بود بر نگاه حسرت بار ایشان به اینجانب، کمال تشکر را از جنابعالی دارند.
اما در خصوص Use Case درخواستی، شما را به دیدن لینک ذیل دعوت میکنم:
http://www.omgwiki.org/architecture-ecosystem/doku.php?id=composite_concepts
استاد پنجشنبه … من و خانم حسنی با هم سر سفره عقد نشستیم و پیمان ازدواج بستیم.»
چقدر خوشحال شدم. فکر نمی‌کنم هیچ یک از فواید برنامه‌نویسی دو نفره تا این حد مهم باشد. تکنیکی که سرآغازی بود بر یکی از مهم‌ترین اتفاقات زندگی دو جوان عزیز و با کمالات.
شاد، تندرست و خوش‌بخت باشند.
گزیده:
«امیدوارم در تمام طول زندگی آنچنان همدیگر را دوست داشته باشیم که انگار هرگز ازدواج نکرده‌ایم»
جورج گوردون بایرون
Thinking
“THINK.”
In 1914, Thomas J. Watson, Sr. joined the company that was to become
IBM, and he brought with him this simple one-word motto. It was an
exhortation to all IBM employees, no matter their role, to take care in
decision-making and do their jobs with intelligence. “THINK” soon became
an icon, appearing on publications, calendars, and plaques in the
offices of many IT and business managers within and outside IBM, and
even in The New Yorker magazine cartoons. “THINK” was a good idea in
1914, and it is a good idea now.
In 1914, Thomas J. Watson, Sr. joined the company that was to become
IBM, and he brought with him this simple one-word motto. It was an
exhortation to all IBM employees, no matter their role, to take care in
decision-making and do their jobs with intelligence. “THINK” soon became
an icon, appearing on publications, calendars, and plaques in the
offices of many IT and business managers within and outside IBM, and
even in The New Yorker magazine cartoons. “THINK” was a good idea in
1914, and it is a good idea now.
ف‌ا‌ر‌س‌ی
ای‌ا میتوانید این ع‌ب‌ارت را بخوانید. اگر این طور است، پ‌س م‌ی‌ت‌وان همواره این گونه هم ن‌وش‌ت؟
شاد باشید و تندرست.
گزیده:
چ‌ش‌م‌ه‌ا را باید ش‌س‌ت، طور دیگر باید دی‌د.
در اهمیت نرم‌افزار
دوستی دارم که زمانی به من گفت: “اگر زمانی نرم‌افزارهای ساخت ما کار نکرد و مشتریان با چوب و چماق افتادند دنبال ما، آن وقت می‌فهمم که نرم‌افزار در ایران، دیگر کالای لوکس نیست”.
خبرهای رسانه‌ها و بحثهایی که در محافل غیرنرم‌افزاری درباره سیستمهای نرم‌افزاری می‌شود، شاید معیاری باشد برای افزایش اهمیت نرم‌افزار در ایران.
خبرهای زیر و یادداشتهای خوانندگان را بخوانید. برایم جالب و آموزنده بود.
http://www.donya-e-eqtesad.com/Default_view.asp?@=282774
http://ebinews.com/news/9583
http://ebinews.ir/news/19077/
http://ebinews.com/news/19638/
http://www.donya-e-eqtesad.com/Default_view.asp?@=285510
گزیده:
اينكه امروز كه هستيم، پيامد گزينش ديروز ما است. فردا هم همان خواهيم شد كه امروز برمي گزينيم. جان ماكسول
اس.جی.
تحلیل و طراحی شیءگرا
چند وقت پیش دوستی، پرسش زیر را مطرح کرده بود:
«می‌خوام تجزیه و تحلیل شیءگرا کار کنم. به نظر شما چه کتابهایی در این زمینه مفید هستد و به چه ترتیبی اونها رو مطالعه کنم»
از خوانندگان وبلاگ خواهش کردم که لطف کنند و در صورت امکان، راهنمایی فرمایند. نتایج را در اینجا میتوانید مطالعه کنید.
فرض بر این قرار گرفت که ایشان به دنبال تحلیل و طراحی شیءگرا هستند. به خود فرصتی دادم تا راجع به این پرسش فکر کنم. چون فرصت نکردم، تصمیم گرفتم که به صورت آنی مواردی که به نظرم می‌رسد، در اینجا بنویسم. امیدوارم مفید باشد.
توصیه‌ها:
یک سال در یک تیم نصب، استقرار و پشتیبانی نرم‌افزاری کار کنید که کاربر از آن ناراضی است. این موضوع به شما کمک می‌کند که:
– ببینید کاربر چرا ناراضی است
– و چرا گاهی درخواست‌های جدید کاربر نمی‌تواند در سیستم اعمال شود
– و چرا تیم پشتیبانی قادر به اعمال درخواست‌ها در زمان مورد نظر کاربر نیست
– و نرم‌افزار چه خصوصیاتی باید داشته باشد تا انجام امور فوق ساده‌تر باشد
در این مدت بسیار کنجکاو باشید.
اگر در این مورد مسئولیت آزمون و پذیرش محصول نیز با شما بود که عالی است، وگر نه توصیه میکنم مدتی برای آزمایش یک نرم‌افزار وقت بگذارید. این کار به شما یاد می‌دهد که «یک پلیس خوب ابتدا باید دزد خوبی باشد(به نقل از یک فیلم قدیمی)» یعنی همیشه موقع طراحی و پیاده‌سازی به این بیندیشید که کجای طراحی و کد شما درز دارد.
سه سال وقت بگذارید تا برنامه‌نویس فوق‌العاده‌ای شوید. ابتدا تعریف کنید که کد دوستداشتنی شما چگونه است و برنامه‌نویس مورد علاقه شما چه کسی می‌تواند باشد، سپس با یک برنامه‌ریزی به دنبال کسب شایستگی‌ها و مهارتهای لازم باشید. یادتان باشد این موضوع را در سطح فارغ از زبان تعریف کنید. بهترین طراحانی که می‌شناسم، برنامه‌نویسان فوق‌العاده‌ای‌اند.
سعی کنید هم‌زمان در دو فضای رقیب و متفاوت حرکت کنید، یکی عمیق و دیگری کلان. مثلاً حوزه راه‌حلهای دات نت و جاوا. این کار به شما امکان می‌دهد:
– تا متعصب نشوید
– و دیگر این که یاد بگیرید که چگونه توسط یکی، دیگری را یاد بگیرید
– و مهم‌تر از همه، تفاوتها و شباهتها به شما امکان یادگیری عمیق و طراحی‌های بهتری را خواهد داد.
قلمرو مسأله (domain) – مثلاً حوزه مالی – را بیاموزید. اگر در شرکتی مشغول به کارید یا قصد خروج از شرکتی را دارید، به یاد داشته باشید که حضور مستمر در یک قلمرو مسأله بسیار مهم است. چرا؟ بهترین طراحی‌ها وقتی صورت می‌گیرد که طراح درکی عمیق از مسأله داشته باشد. به عنوان مثال مهم‌ترین دستاوردها در استفاده مجدد، در قلمرو مسأله است نه در حوزه تکنولوژی. اقلام استفاده مجدد در تیمها را که می‌نگرید شامل رخدادنگاری، امنیت، … هستند؛ یعنی همه چیز غیر از قلمرو مسأله. متأسفانه عزیزان طراح ما بر این باورند که باید در اتاق خود بنشینند تا تحلیل‌گران یا کاربران به آنها یاد دهند که قلمرو مسأله چیست:
– تحلیل‌گر یا کاربر دغدغه‌های شما را نمی‌شناسد که به شما منتقل کند
– دیگر این که این نکات با ده یا صد پرسش قابل انتقال نیست و موضوعی است تدریجی.
خود خواهید یافت که چه زمانی، شرایط تغییر قلمرو مسأله فرا رسیده است.
در کنار کسانی کار کنید که آنها را به عنوان طراح و برنامه‌نویسِ فوق‌العاده می‌شناسند و قبول دارند. نگاه، تفکر و روششان را بیاموزید. بخشی از یادگیری، یادگیری استاد-شاگردی است. این بخش را جدی بگیرید. اگر این سعادت را پیدا کردید، آموخته‌هایتان را یادداشت و برایم بفرستید تا من نیز بیاموزم.
تکنولوژی‌زده (برای شوخی آنها را تکنوکرات می‌نامم) نباشید. تکنولوژی را یاد بگیرید اما برای یادگیری آن، پروژه دیگران را که هزینه‌اش با شما نیست، خراب نکنید. هزینه، زمان، نیروی انسانی تولید و نیروی انسانی پشتیبان سیستم و چندین خصیصه غیرفنی در اتخاذ تصمیمات بسیار مؤثرند، آنها را لمس کنید. تصمیم‌گیرنده فنی لازم است که احساس وظیفه سازمانی و به دور از علایق شخصی کند. برای هر راه حلی، پیش خود مقادیر عددی خصوصیات بالا را محاسبه کنید.
در عین حال که معماری نرم‌افزار، الگوها، طراحی و تحلیل و … را یاد می‌گیرید، همواره به یاد داشته باشید که آنها ساخته ذهن یک انسان دیگر است و ممکن است لزوماً درست نباشد. تابوها را بشکنید و دیگر گونه فکر کنید. یادگیری آنها خیلی اوقات منجر به تخریب خلاقیت شما خواهد شد. اگر اصول را بدانید، راه‌حلهای طراحی شما، بی‌شک یکی از الگوهای طراحی خواهد بود. معماری، الگوها و … هدف نیستند، ابزار هستند. اما یادتان باشد که چرخ را دوباره اختراع نکنید. اشکالی که امروزه دیده می‌شود چیزی شبیه افراط و تفریط است. بعضی هیچ نمی‌دانند و نفی می‌کنند، و بعضی‌ها می‌دانند و غرق این ابزارها شده‌اند. تعادل بهترین است. شناسایی نقطه تعادل را خواهی آموخت.
اصول را به درستی بیاموزید. عزیزان بسیاری را می‌شناسم که آخرین تکنولوژی‌ها را تجربه کرده‌اند، اما مفاهیم ساده‌ای چون encapsulation برایشان غریبه است یا در حد تعاریف کتاب یا مثالهای ساده و ابتدایی می‌دانند.
جمعی از دوستان هم‌فکر را پیدا کنید. دو هفته یک بار یا ماهی یک بار با هم قرار بگذارید. تجربه و یادگیری‌هایتان را برای هم تعریف کنید. کد نوشته شده یا طراحی انجام شده را بازنگری کنید و از آن بیاموزید. از جلسه سوم به بعد، خوشحال می‌شوم اگر از بنده هم دعوت کنید که در جلسات شما حاضر شوم.
هر وقت خواستی نکته‌ای در تحلیل و طراحی یاد بگیری، ابتدا چرایی‌اش را بیاموز و بعد تاریخچه و منشأاش را. این موضوع به شما کمک می‌کند، با حفظ چرایی، چگونگی را با شرایط تطابق دهید.
نمونه خوب زیاد ببینید. طراحی‌ها و کدهای اوپن سورسهای با کیفیت را بخوانید. کد همکاران کاربلدتان را زیاد بخوانید.
هر چند وقت یک بار، طراحی‌های قدیمی یا کدهای قبلی‌تان را مرور کنید. ببینید اگر آن را دوباره انجام دهید، کجاهایش تغییر خواهد کرد. این تغییر از کجا ناشی شده است. اتفاقی بوده یا برنامه‌ریزی شده.
تصمیم‌گیری، انتخاب، ارتباط و مشارکت و به طور کلی مهارتهایی عمومی تأثیرگذار بر کارتان را بیاموزید. به استقبال نقدشدن بروید.
زبان انگلیسی‌تان را قوی کنید. اگر بتوانید همان طور که متن انگلیسی می‌نویسید، کد بنویسید. یا همان طور که موقع صحبت کردن، فکر می‌کنید، طراحی انجام دهید، کار تمام است. در آینده کافی است روش نوشتن و حرف زدنتان را عوض کنید، همه نرم‌افزارتان عوض می‌شود.
تفکر در یک نگرش مثل شیءگرایی کم کم ذهن شما تحت تأثیر قرار می‌دهد. سعی کنید پارادایمهای دیگر را نیز گاهی تجربه کنید تا ذهن شما را فریب ندهد.
هر وقت احساس کردید که از تحلیل و طراحی لذت نمی‌برید، به مرخصی بروید یا کارتان را عوض کنید.
جایی که هر چند وقت یک بار بتوانی آن را بخوانید، این جمله را قرار دهید: هدف، مؤفقیت پروژه است!
و در آخر: کتاب بخوانید.
ببخشید که طولانی شد.
گزیده:
پاداش‌هايي كه در زندگي مي‌گيريد بستگي به اين دارد كه چه كاري مي‌كنيد، چقدر خوب آن را انجام مي‌دهيد و چقدر مشكل است كه بتوان كسي را جايگزين شما كرد. برايان تريسي
مرجع: اسجی
