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

برمی گردم، سالها به عقب در یک روز زمستانی ...

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

آری، من می دانم که نمی دانم، شاید زیباتر باشد که ندانم.

پس بازمی گردم، می روم، قدم به قدم، پله ها، پله ها را هم پایین می روم، فقط چند قدم دیگر، ولی دیگر کسی نیست، چرا کسی هست، کسی که نمی دانم کیست!

در پاییز سال 1997، برین و پیج به این نتیجه رسیدند که موتور جستجوی بک راب به یک نام جدید نیاز دارد. پیج در یافتن یک نام چشمگیر که قبلا مورد استفاده قرار نگرفته باشد، دچار دردسر شده بود و لذا از شون اندرسون، هم اتاقی اش در خواست کمک کرد. آندرسون به یاد می آورد: «من به سمت تخته سیاه رفتم و با روش طوفان مغزی شروع به نوشتن اسامی روی آن کردم و او دائما می گفت نه، نه، نه. این کار چندین روز ادامه داشت. او رفته رفته مایوس می شد و ما یک جلسه دیگر طوفان مغزی تشکیل دادیم. من نزدیگ تخته سفید نشسته بودم و یکی از آخرین چیزهایی که به آن رسیدم این بود که "نظرت راجع به گوگل پلکس چیست؟" او شکل کوتاهتر این اسم را دوست داشت. من کلمه G-o-o-g-l-e را با املای غلط روی تخته سفید نوشتم  و حالا به چشم می آمد. لاری با آن موافقت کرد و بعدا در همان شب آن را ثبت کرد و  روی تخته سفید نوشت: google.com. شبیه یاهو یا آمازون، یک حلقه نه چندان دقیق اینترنتی به آن اضافه کرد و  روز بعد که به دفترم آمدم دیدم تامارا یاداشتی برایم گذاشته و نوشته است است ‘تو املای آن را غلط نوشته ای. درست آن باید این باشد: G-o-o-g-o-l’»

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

سرگئی برین و لاری پیج: موسسین شرکت گوگل

کتاب the google story، کتاب بسیار خواندنی در مورد تاریخچه و سیر تکامل شرکت گوگل است، واقعا این شرکت سرنوشت جالبی دارد، که می تواند خیلی آموزنده باشد.خواندن این کتاب را به دوستان توصیه می کنم البته ترجمه فارسی کتاب نیز موجود می باشد با عنوان «سرگدشت شگفت انگیز گوگل» برای افراد مثل خودم که زبانشان زیاد خوب نیست.

ظرفیت هارد دیسک با سرعت بسیار خوبی هر روز افزایش پیدا می کند، رم ها نیز این روزها از لحاظ افزایش سایز دارند هر روز بیشتر و بیشتر می شوند و به حد قابل قبولی می رسند و CPU ها نیز همینطور.

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

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

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

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

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

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

میندیش که دیگران ، تو را به آرمانت خواهند رساند .

رهبران فرزانه ی پیشین،

دلیل موفقیت خود را در مردم می دیدند

و دلیل شکست خود را در خود.

راستی را در مردم می دیدند و کژی را در خود.

از این رو، حتا با رنج یک تن،

گناه از خویش می دیدند و خود را در کنار می نهادند.

ولی امروز به یقین این گونه نیست.

امروز، رهبران کارشان را در نهان می کنند،

و گناه بر مردم بی خبر می نهند.

مشکلات را فزونی می دهند،

و مردمان که توان رویارویی با این دشواری را ندارند،

مجازات می کنند.

آنان را به بالاترین مرتبه زیر فشار می گذارند،

و آنان که تابش را ندارند، هلاک می شوند.

وقتی مردم دریابند که توان کافی ندارند، ظاهر سازی کنند.

و دم که گاه چنین دو رویی و تظاهر است،

چه گونه رهبران و مردم با هم بسازند؟

توان که نباشد، نیرنگ به کار رود.

آگاهی که نباشد، فریب به کار رود.

مواد اولیه زندگانی نباشد، دزدی به کار رود.

ولی عامل اصلی در این دزدی و دروغ گویی کیست؟ (لطفاً جواب دهید)

منبع: این کتاب بی فایده است (آموزه های جوانگ زه)

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

دوستان که می خواهند بحث Unit Testing را دنبال کنند، می توانند به وبلاگ آقای وحید نصیری با عنوان تازه های برنامه نویسی مراجعه کنند. مطالعه این منبع را برای آشنایی با موضوعات روز برنامه نویسی به همه دوستان توصیه می کنم.

... شب عاشورا بود شهر یکپارچه روضه بود وخانه یکپارچه سکوت و درد...

گفتم در این تنهایی درد و این شب سوگ، بنشینم و با خود سوگواری کنم، مگر نمی شود تنها عزاداری کرد؟ نشستم و روضه ای برای دل خویش نوشتم:

... پیش چشمم را پرده ای از اشک پوشیده است.

در میان هیاهوی مکرر و خاطره انگیز دجله و فرات، این دو خصم خویشاوندی که هفت هزار سال، گام به گام با تاریخ همسفرند، غریو و غوغای تازه ای برپا است:

صحرای سوزانی را می نگرم، با آسمانی به رنگ شرم، و خورشیدی کبود و گدازان، و هوایی آتش ریز، و دریای رملی که افق در افق گسترده است، و جویباری کف آلود از خون تازه ای که می جوشد و گام به گام، همسفر فرات زلال است.

می ترسم در سیمای بزرگ و نیرومند او بنگرم، او که قربانی این همه زشتی و جهلاست.به پاهایش می نگرم که همچنان استوار و صبور ایستاده و این تن صدها ضربه را بپاداشته است

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

می ترسم در سیمای بزرگ و نیرومند او بنگرم، او که قربانی این همه زشتی و جهل است.

به پاهایش می نگرم که همچنان استوار و صبور ایستاده و این تن صدها ضربه را بپاداشته است.

ترسان و مرتعش از هیجان، نگاهم را بر روی چکمه ها و دامن ردایش بالا می برم:

اینک دو دست فرو افتاده اش،

دستی بر شمشیری که به نشانه شکست انسان، فرو می افتد، اما پنجه های خشمگینش، با تعصبی بی حاصل می کوشد،تا هنوز هم نگاهش دارد

جای انگشتان خونین بر قبضه شمشیری که دیگر ...

... افتاد!

و دست دیگرش، همچنان بلاتکلیف.

نگاهم را بالاتر میکشانم:

از روزنه های زره خون بیرون می زند و بخار غلیظی که خورشید صحرا میمکد تا هر روز، صبح و شام، به انسان نشان دهد و جهان را خبر کند.

نگاهم را بالاتر میکشانم:

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

نگاهم را از رشته های خونی که بر آن جاری است باز هم بالاتر می کشانم:

ناگهان چتری از دود و بخار! همچون توده انبوه خاکستری که از یک انفجار در فضا میماند و ...

دیگر هیچ !

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

«هستم»، که «زندگی می کنم».

این همه «بیچاره بودن» و بار «بودن» این همه سنگین!

اشک امانم نمی دهد؛ نمی توانم ببینم.

پیش چشمم را پرده ای از اشک پوشیده است.

در برابرم، همه چیز در ابهامی از خون و خاکستر می لرزد، اما همچنان با انتظاری از عشق و شرم، خیره می نگرم؛

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

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

هم اکنون سیمای خدایی او را خواهم دید؟

چقدر تحمل ناپذیز است دیدن این همه درد، این همه فاجعه، در یک سیما، سیمایی که تمامی رنج انسان را در سرگذشت زندگی مظلومش حکایت می کند. سیمایی که ...

چه بگویم؟

مفتی اعظم اسلام او را به نام یک «خارجی عاصی بر دین الله و رافض سنت محمد» محکوم کرده و به مرگش فتوی داده است.

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

در پیرامونش، جز اجساد گرمی که در خون خویش خفته اند، کسی از او دفاع نمی کند.

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

نه باز می گردد،

که : به کجا؟

نه پیش می رود،

که : چگونه؟

نه می جنگد،

که : با چه؟

نه سخن می گوید،

که : با که؟

و نه می نشیند، که :

هرگز !

ایستاده است و تمامی جهادش اینکه ... نیفتد

همچون سندانی در زیر ضربه های دشمن و دوست، در زیر چکش تمامی خداوندان سه گانه زمین(خسرو و دهگان و موبد – زور و زر و تزویر – سیاست و اقتصاد و مذهب)، در طول تاریخ، از آدم تا ... خودش!

به سیمای شگفتش دوباره چشم می دوزم، در نگاه این بنده خویش مینگرد، خاموش و آشنا؛ با نگاهی که جز غم نیست. همچنان ساکت میماند.

نمی توانم تحمل کنم؛سنگین است؛

تمامی «بودن»م را در خود می شکند و خرد می کند.

می گریزم.

اما می ترسم تنها بمانم، تنها با خودم، تحمل خویش نیز سخت شرم آور و شکنجه آمیز است.

به کوچه می گریزم، تا در سیاهی جمعیت گم شوم.

در هیاهوی شهر، صدای سرزنش خویش را نشنوم.

خلق بسیاری انبوه شده اند و شهر، آشفته و پرخروش می گرید، عربده ها و ضجه ها و عَلم و عَماری و «صلیب جریده» و تیغ و زنجیری که دیوانه وار بر سر و روی و پشت و پهلوی خود می زنند، و مردانی با رداهای بلند و....... د

عمامه پیغمبر بر سر و....... د

آه ! ... باز همان چهره های تکراری تاریخ! غمگین و سیاه پوش، همه جا پیشاپیش خلایق!

تنها و آواره به هر سو می دوم، گوشه آستین این را می گیرم، دامن ردای او را می چسبم، می پرسم، با تمام نیاز می پرسم؛ غرقه در اشک و درد:

«این مرد کیست»؟

«دردش چیست»؟

این تنها وارث تاریخ انسان، وارث پرچم سرخ زمان، تنها چرا؟

چه کرده است؟

چه کشیده است؟

به من بگویید:

نامش چیست؟

هیچ کس پاسخم را نمی گوید!

پیش چشمم را پرده ای از اشک پوشیده است.

دکتر شریعتی

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

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

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

فقط سئوال این مدلی نباشه که سیستم حسابداری را چگونه طراحی می کنید!!!

و به پیشنهاد مدیر محترم بخش هم , اولین پست به فهرست بندی سوال اختصاص داده می شود.

سئوال اول رو خودم مطرح می کنم. تا دوستان دیگر هم ادامه دهند.

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

هر کسی توتمی دارد ،

و توتم من " قلم " است.

و قلم توتم قبیله من است .

خدای همه قبایل ،

خدای همه عالمیان بدان سوگند می خورد .

به هر چه از آن می تراود سوگند می خورد .

به خون سیاهی که از حلقومش می چکد ، سوگند می خورد .

و من ؟

قلم خویشاوند آن من راستین من است .

عطیه روح القدس من است.

زبان دفترهای خاکستری و سبز من است .

همزاد آفرینش من ،

زاد هجرت من ،

همراه هبوط من

و انیس غربت من

و رفیق تبعید من

و مخاطب نوع چهارم من

و همدم خلوت تنهایی و عزلت من

و یادآور سرگذشت و یادآور سرشت و بازگوی سرنوشت من است .

روح من است که جسم یافته است .

" آدم بودن من " است که شیء شده است .

آن " امانت " است که به من عرضه شده است .

آه که چه سخت و سنگین است !

زمین در کشیدن بار سنگینی اش می شکند .

کوه ها به زانو می آیند و آسمان می شکافد و فرو می ریزد .

قلم ، توتم قبیله من است .

قلم ، توتم من است .

او نمی گذارد که فراموش کنم ، که فراموش شوم ،

که با شب خو کنم ، که از آفتاب نگویم ،

که دیروزم را از یاد ببرم ، که فردا را بیاد نیارم ،

که از " انتظار " چشم پوشم ،

که تسلیم شوم ،

نومید شوم ،

به خوشبختی رو کنم ،

به تسلیم خو کنم ،

که ... !

قلم ، توتم من است ، توتم ما است .

به قلمم سوگند !

به خون سیاهی که از حلقومش می چکد سوگند !

 به رشحه ی خونی که از زبانش می تراود سوگند !

به ضجه های دردی که از سینه اش برمی آید سوگند ... !

که توتم مقدسم را نمی فروشم ، نمی کشم .

گوشت و خونش را نمی خورم .

به دست زورش تسلیم نمی کنم .

به کیسه زرش نمی بخشم .

به سرانگشت تزویرش نمی سپارم .

دستم را قلم می کنم و قلمم را از دست نمی گذارم .

چشمهایم را کور می کنم ،

گوشهایم را کر می کنم ،

پاهایم را می شکنم ، انگشتانم را بند بند می برم ،

سینه ام را می شکافم ،

قلبم را می کشم ، حتی زبانم را می برم و لبم را می دوزم ...

اما قلمم را به بیگانه نمی دهم ...

قلم ، توتم من است .

بگذار بر قامت بلند و راستین و استوار قلمم به صلیبم کشند ،

به چهار میخم کوبند ،

تا او که استوانه حیاتم بوده است ، صلیبب مرگم شود .

شاهد رسالتم گردد ، گواه شهادتم باشد .

تا خدا ببیند که به نامجوئی ، بر قلمم بالا نرفته ام ،

تا خلق بداند که به کامجوئی

بر سفره ی گوشت حرام توتمم ننشسته ام ،

تا زور بداند ، زر بداند و تزویر بداند

که امانت خدا را ، فرعونیان نمی توانند از من گرفت .

ودیعه عشق را قارونیان نمی توانند از من خرید .

و یادگار رسالت را بلعمیان نمی توانند از من ربود ...

هر کسی را ، هر قبیله ای را توتمی است .

توتم من ، توتم قبیله ی من قلم است .

قلم زبان خدا است .

قلم امانت آدم است .

قلم ودیعه عشق است .

هر کسی را توتمی است .

و قلم ، توتم من است .

و قلم ، توتم ما است.

به تصویر بالا نگاه کنید فکر می کنید کلاس دیاگرام بالا متلعق به کدام قسمت از یک نرم افزار است. شاید حدس زدن آن در اولین مرحله برای خیلی ها مشکل باشد پس لطفا بر روی تصویر کلیک کنید تا تصویر را با اندازه واقعی مشاهده کنید و از نام متدها قضیه را حدس بزنید. تمام کلاس های بالا برای تست متدهای کلاس های نرم افزار یا همان تست واحد (Unit Test)  طراحی و پیاده سازی شده است. شاید اگر به سورس بسیاری از نرم افزارهای مشهور دسترسی داشته باشید، حتما مشابه این کلاس ها را در یک پکیچ جداگانه در سورس خواهید یافت (تصویر بالا مربوط به مولفه منوی  RadControls از شرکت Telerik است که حنما اکثر توسعه دهندگان وب با محصولات این شرکت آشنا هستند). پس اجازه بدهید در پایین به بررسی اصول و نحوه پیاده سازی تست های واحد بپردازیم.

تست واحد (Unit Testing):

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

 چرا باید تست واحد را انجام بدهیم؟

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

مزایا و منافع

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

1-      تست های واحد همانند یک سند اجرایی هستند که نشان می دهند شما انتظار دارید که کد نوشته شده در شرایط مختلف چگونه عمل کند. اعضای تیم می توانند برای درک عملکرد کد و اینکه چگونه آن را بکار ببرند به تست های واحد مراجعه کنند.

تست های واحد مستنداتی هستند که با تغییر و اصلاح کد بروز رسانی می شوند.

علاوه بر اینها نظرات و حدس های برنامه نویس را در تست ها می توانیم مستند سازی کنیم.

2-      به اشتراک گذاری کد با دیگران راحتتر است، چون اگر عضوی از تیم کد را طوری دستکاری کنید که درست کار نکند، اجرای تست ها با شکست روبرو می شود.

3-        با انجام تست های واحد، زمان انجام تست ها در سایر فازها کاهش می یابد.

4-      تست ها، انتظارات برنامه نویس را در مورد چگونگی عمل کردن یک قطعه کد، ارزیابی می کنند.

بهانه و مقاومت

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

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

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

3-      تست کردن شغل من نیست: خوب این کار شما نیست. پس تصور کنید که دو توسعه دهنده داریم نفر اول تست ها واحد را انجام می دهد و دیگری نه. بعد از اتمام کار، کدهای نوشته شده به تیم تست و کنترل کیفیت ارجاع داده می شوند. نتیجه تقریبا روشن است  کدهای نفر اول با حداقل خطا برای رفع اشکال ارجاع داده می شود ولی نفر دوم باید لیست درازی از خطاها را اصلاح کند. کدام یک از   اینها مسیر ترقی را سریع طی خواهد کرد و از امنیت شغلی برخودار خواهد بود حتما نفر اول.

4-      اگر من تست ها را انجام دهم احتمالا افراد دیگری که مسئول تست هستند احتمالا کارشان را از دست بدهند: شما اصلا نگران این موضوع نباشید شما فقط مسئول تست واحدها هستید، و این فقط مرحله بسیار کوچک از فرآیند کلی تست می باشد.

5-      چرا از تست کردن به صورت دستی، استفاده نکنیم؟ تست دستی امکان نفوذ خطاهای انسانی به سیستم را افزایش می دهد و همچنین تکرار کردن تست های دستی، بسیار مشکل تر است. برای اینکه تست های دستی را دوباره انجام بدهیم، به مستنداتی نیاز داریم که مراحل انجام تست ها را شرح بدهند. با تغییر کد، این مستندات به سرعت کهنه می شوند و این یعنی اینکه برای به روزنگهداشتن مستندات، باید کار اضافی انجام دهیم. 

(در قسمت بعدی به نحوه پیاده سازی تست های واحد و معرفی Nunit خواهیم پرداخت.)

اخیراً در فرودگاه گفتگوی لحظات آخر بین مادر و دختری را شنیدم

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

آنها همدیگر را بوسیدند و دختر رفت. مادر بطرف  پنجره ای که من در کنارش نشسته بودم آمد. آنجا ایستاد و می توانستم  ببینم که می خواست و احتیاج داشت که گریه کند. من نمی خواستم که خلوت او را بهم بزنم ولی خودش با این سؤال اینکار را کرد: " تا حالا با کسی خداحافظی کردید که می دانید برای آخرین بار است که او را می بینید؟ " جواب دادم: " بله کردم. منو ببخشید که فضولی می کنم چرا آخرین خداحافظی؟ "

او جواب داد: " من پیر و سالخورده هستم او در جای خیلی دور زندگی می کنه. من چالشهای زیادی را پیش رو دارم و حقیقت اینست که سفر بعدی او برای مراسم دفن من خواهد بود. "

" وقتی داشتید خداحافظی می کردید شنیدم که گفتید " آرزوی کافی را برای تو میکنم. " میتوانم بپرسم یعنی چه؟ "
او شروع به لبخند زدن کرد و گفت: " این آرزویست که نسل بعد از نسل به ما رسیده. پدر و مادرم عادت داشتند که اینرا به همه بگن."  او مکسی کرد و درحالیکه سعی می کرد جزئیات آنرا بخاطر بیاورد لبخند بیشتری زد و گفت: "

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

آرزوی باران کافی برای تو میکنم که زیبایی بیشتری به روز آفتابیت بدهد.

آرزوی شادی کافی برای تو میکنم که روحت را زنده و ابدی نگاه دارد.

آرزوی رنج کافی برای تو میکنم که کوچکترین خوشی ها به بزرگترینها تبدیل شوند.

آرزوی بدست آوردن کافی برای تو میکنم که با هرچه می خواهی راضی باشی.

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

آرزوی سلامهای کافی برای تو میکنم که بتوانی خداحافظی آخرین راحتری داشته باشی."

بعد شروع به گریه کرد و از آنجا رفت.

(تقدیم به یک مادر)

دوست خوبمان آقای نوبر لطف کردند و نواقصی را که در قسمت اول تست نرم افزار بود کاملتر کردند که عبارتند از :

1.       در کتاب هنر تست نرم افزار - the art of software testing خواندم (و به نظرم کاملا منطقی می آید) که هدف نهایی از تست نرم افزار یافتن باگهای بیشتر است و نه چیز دیگر! البته ادله محکم و قابل قبولی نیز برای این تعریف ارایه میکند.

2.       در متن اشاره کرده ای که "یک مجموعه از ورودهای صحیح با خروج های مربوط به آن را تهیه می کنیم ...". در حوزه تست نرم افزار سناریوی ذکر شده در متن (سناریوی آفتابی-sunny scenario) کاملا لازم است اما سناریوی دیگر (سناریوی بارانی-rainy scenario) که هدف آن کشف اشکالات نرم افزار در مواجهه با مقادیر نادرست (مثلا عدم نمایش پیغام خطای مناسب) است نیز از اهمیت بالایی برخوردار است.

3.       . در تجربیاتی که داشتم Equivalence Partitioning و Boundary Value Analysis را در تستهای جعبه سیاه نیز به کار بردم که منجر به صرفه جویی در زمان و احتمال کشف خطاهای بیشتری شد.
و البته بعضی از موارد دیگر را می توانید تحت عنوان اصول اساسی تست نرم افزار از وبلاگ ایشان دنبال کنید و البته به همه دوستان توصیه می کنم حتما پست های اول وبلاگ ایشان را که بیانگر اهمیت تست نرم افزار می باشید را حتما مطالعه کنند. و البته از همه دوستان می خواهم که نواقص و اشکالات را بیان کنند تا به مطالبی با کیفیت خوب برسیم.

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

1. تست واحد (Unit testing)
2. تست مجتمع سازی  (Integration Testing)
3. تست سیستم (System Testing)
4. تست پذیرش (Acceptance Testing)

تست واحد (Unit testing) :

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

تست مجتمع سازی  (Integration Testing) :

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

تست سیستم (System Testing) :

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

تست امنیت (Security Testing) : فرضی کنید سیستم باید اطلاعات حساس و حیاتی را پردازش و مدیریت کند و افرادی هستند که بدنبال دسترسی غیر مجاز به این اطلاعات و سوء استفاده از آن هستند. برای اطمینان از عملکرد سیستم در برابر نفوذگران ما باید مکانیزم امنیتی ایجاد شده در سیستم را بررسی کنیم تا مطمئن شویم که سیستم می تواند نفوذهای غیر قانونی  را تشخیص دهد و در برابر آنها عکس العمل نشان دهد.

تست بازیابی (Recovery Testing) : در این نوع آزمایش باعث ایجاد مشکل و از کار افتادن سیستم به روش های مختلف می شویم و بررسی می کنیم که آیا سیستم می تواند خود را به طور خودکار بازیابی کند و به فعالیت خود ادامه دهد.

و ...

 تست پذیرش (Acceptance Testing) :

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

تست آلفا : تست آلفا در سایت توسعه دهنده نرم افزار و در اغلب موارد توسط کارمندان داخلی و در بعضی از موارد توسط مشتری انجام می گیرد.

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

و ...

دکترها به من گفتند که هیچ گاه راه نمی روم، اما مادرم گفت که من راه می روم و من حرف مادرم را باور کردم.
بگذارید داستان دختر کوچکی را برایتان بگویم که در یک کلبه محقر دور از شهر در یک خانواده فقیر به دنیا آمده بود.

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

بدین ترتیب در 9 سالگی دختر کوچولو بست های آهنی پایش را کنار گذاشت و بر خلاف آنچه دکترها می گفتند که هیچ گاه به طور طبیعی راه نمی رود، راه رفت و 4 سال طول کشید تا قدم های منظم و بلندی را برداشت و این یک معجزه بود. او یک آرزوی باور نکردنی داشت، آرزو داشت بزرگ ترین دونده زن جهان شود اما با پاهایی مثل پاهای او این آرزو به چه معنایی می توانست باشد؟

در 13 سالگی در یک مسابقه دو شرکت کرد و در تمام مسابقات، آخرین نفر بود. همه به اصرار به او می گفتند که این کار را کنار بگذارد، اما روزی فرا رسید که او قهرمان مسابقه شد.

از آن زمان به بعد ویلما در هر مسابقه ای شرکت کرد و برنده شد.

در سال 1960 او به بازی های المپیک راه یافت، و آنجا در برابر اولین دونده زن دنیا یک دختر آلمانی قرار گرفت که تا بحال کسی نتوانسته بود او را شکست دهد. اما ویلما پیروز شد و در دو 100 متر، 200 متر، و دو امدادی 400 متر، 3 مدال المپیک گرفت.

آن روز او اولین زنی بود که توانست در یک دوره المپیک 3 مدال طلا کسب کند، در حالی که گفته بودند او هیچ وقت نمی تواند دوباره راه برود.

منبع : farsicrc.com

فرمانده گروهان: بزرگترین عاملی که یک سازمان یا شرکت را از سازمانهای و شرکت های دیگر متمایر می کند چیست؟

...

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

...

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

من عاشق یک پارگراف از یک کتاب طراحی نرم افزار هستم که به طور خلاصه اینرا می گفت: "نرم افزار خوب نرم افزاری است که مشتری را خوشحال کند و زمانی مشتری خوشحال خواهد شد که تمام نیازمندیهای که در نظر دارد برآورده شود". پس ما به عنوان توسعه دهنده نرم افزار باید مطمئن شویم که مشتری خود را خوشحال خواهیم کرد، فرآیند و شیوه رسیدن به این اطمینان خاطر یعنی هدف تست نرم افزار. تست نرم افزار به طور رسمی جزی از بازبینی و اعتبارسنجی نرم افزار می باشد، که این دو واژه به صورت زیر تعریف و  با هم مقایسه می شوند.

وارسی:  "آیا محصول درستی را می سازیم؟"

اعتبارسنجی: "آیا محصول را به درستی می سازیم؟"

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

استراتژی تست

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

استراتژی جعبه سیاه:

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

در یک استراتژی آزمایش جعبه سیاه ما عموما موارد زیر را مورد بررسی و آزمایش قرار می دهیم:

1.       بررسی اینکه سیستم نیازمندهای عملیاتی و غیر عملیاتی را تامین می کند یا نه.

2.       اعتبارسنجی ورودیها

3.       بررسی مقادیر مرزی برای متغییرها: به یک متغییر مقداری کمتر از حداقل مقداری که می تواند قبول کند یا بیشتر از حداکثر مقداری که می تواند قبول کند می دهیم و سیستم را در این شرایط تست می کنیم.

4.       بررسی خروج های سیستم: یک مجموعه از ورودهای صحیح با خروج های مربوط به آن را تهیه می کنیم و سپس ورودها را به سیستم وارد می کنیم و خروج های که توسط سیستم داده می شود را با خروجی های واقعی مقایسه می کنیم.

5.       بررسی رفتار سیستم در برابر پردازش ورودها و پرس و جوهای بزرگ و سنگین

6.       ...

برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سیاه وجود دارد که عبارتند از:

functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing, system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing , ….

if (name=="Lee" && employeeNumber=="1234" &&

    employmentStatus=="RecentlyTerminatedForCause") {

    send Lee a check for $1,000,000;

استراتژی جعبه سفید

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

در یک استراتژی آزمایش جعبه سفید ما عموما موارد زیر را مورد توجه و بررسی قرار می دهیم:

1.       بررسی سطر به سطر کد (Code coverage): در این حالت باید سیستم را به گونه ای اجراء و بررسی کنیم که مطمئن شویم سطر به سطر کد برنامه حداقل یکبار اجراء شده است.

2.       بررسی همه انشعاب ها در کد برنامه (branch) : در کد برنامه باید تمام عبارت های شرطی ( if elseها و Switch case ها)   را تک به تک مورد بررسی قرار داد. به این صورت که در یک عبارت if else هم فسمت if و هم قسمت else هر کدام بصورت مجزا یکبار اجراء شوند. 

3.       بررسی همه حلقه ها در برنامه : حلقه ها در نرم افزار نقش اساسی دارند، چون می تونند با اشتباه جزئی مقدار زیادی از منابع را مصرف کرد برای مثال شرط خروج از حلقه به اشتباه هیچ وقت True نشود. برای نمونه حلقه ها را با ورودی بزرگتر از شرط خروج حلقه چک کنید یعنی حلقه اصلا اجر نشود. تستی طراحی کنید که حلقه دقیقا یکبار اجراء شود، تستی طراحی کنید که حلقه در یک بازه خاص اجراء شود و ....

4.       مدیریت خطای مطلوب : برسی اینکه اگر به یک متد یک ورودی نامعتبر وارد شود، نحوه آگاه سازی و نمایش مطلوب خطا برای کاربر چگونه باشد؟

5.       بررسی امنیت : سیستم را از این جهت که چگونه در برابر دسترسی های غیرمجاز، هک، کرک و هر چیز دیگر که می تواند به آن آسیب برساند مورد بررسی قرار می دهد. در اینجا  ما باید مکانهای از کد را که داده ها را اعتبارسنجی و مدیریت می کنند، دسترسی به منابع یا عملیات مهم و حیاتی را انجام می دهند را بررسی کنیم.

6.       ...

7.       برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سفید وجود دارد که عبارتند از:

Basis Path Testing, Equivalence Partitioning/Boundary Value Analysis, Method Coverage, Statement Coverage, Branch Coverage, Condition Coverage, Data Flow Testing, Flow Graphs Revisited, ….

ادامه دارد.

لوئیز زنی بود با لباسهای کهنه و مندرس، و نگاهی مغموم وارد خواروبار فروشی محله شد و با فروتنی از صاحب مغازه خواست کمی خواروبار به او بدهد. به نرمی گفت شوهرش بیمار است و نمیتواند کار کند و شش بچه شان بی غذا مانده اند.

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

مشتری دیگری که کنار پیشخوان ایستاده بود و گفت و گوی آن دو را میشنید به مغازه دار گفت :
ببین خانم چه می خواهد، خرید این خانم با من .
خواربار فروش با اکراه گفت: لازم نیست، خودم میدهم. لیست خریدت کو؟
لوئیز گفت: اینجاست.
" لیست را بگذار روی ترازو. به اندازه وزنش، هر چه خواستی ببر."

لوئیز با خجالت یک لحظه مکث کرد، از کیفش تکه کاغذی در ‏آورد، و چیزی رویش نوشت و ‏‏آن را روی کفه ترازو گذاشت. همه با تعجب دیدند کفه ی ترازو پایین رفت.
خواروبار فروش باورش نشد. مشتری از سر رضایت خندید.
مغازه دار با ناباوری شروع به گذاشتن جنس در کفه ی ترازو کرد. کفه ی ترازو برابر نشد، آن قدر چیز گذاشت تا کفه ها برابر شدند.
در این وقت خواروبار فروش با تعجب و دل خوری تکه کاغذ را برداشت ببیند روی آن چه نوشته شده است.
کاغذ، لیست خرید نبود، دعای زن بود که نوشته بود:" ای خدای عزیزم، تو از نیاز من با خبری، خودت آن را بر آورده کن "
مغازه دار با بهت جنس ها را به لوئیز داد و همان جا ساکت و متحیر خشکش زد.
لوئیز خداحافظی کرد و رفت.

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

"من می خام پولیس بشم" این جمله را پسر دایی کوچکم هر وقت من می بینه به من می گه. اما من حتی زمانی که یک بچه بودم نیز این جمله را نگفتم. 2 ماه گذشت، آموزش هم تمام شد. در تمام مدت این 2 ماه، محیط نظامی، قوانین و مقررات خشک و بی روحش را با تمام نفرت که از همه آنها داشتم تحمل کردم. اما اعتراف می کنم که شانس با من همراه بود چون مرکز آموزش در شهر خودمان بود (شاید یکی از بزرگترین نقص های بیشمار این وبلاگ این باشه که هیچ اطلاعاتی خاصی از نویسنده آن در خود وبلاگ نیست، پس می گویم که من اهل تبریز هستم و آموزش را در مرکز آموزش ولیعصر(عج) تبریز بودم)، و واقعا فرماندهان خوبی داشتیم هم فرمانده گروهان، هم فرمانده گردان و تقریبا بسیار خوب با من راه آمدند. با منی که  یک سرباز بی استعداد بودم یا یک سربازی که  نمی خواست خودش را با محیط وفق دهد و همه پیامدهای آن را قبول می کرد پس بی استعداد بنظر می آمد البته گزینه دوم، گزینه نزدیگ به واقعیت است. من در این 2 ماه خودم را با محیط نظامی و قوانین آن وفق ندادم اما 18 ماه هنوز در بیش است، 18 ماهی که دیگر در شهر خودم نیستم، 18 ماهی که شاید در تهران باشم . 24 ساعت زمانی کافی است، برای روزی بزرگ داشتن فکر کنم جمله ای مشابه این در یکی از شعرهای احمد شاملو بود پس 18 ماه زمانی بسیار کافی است که من یک نظامی خوب بشوم و شاید زمانی کافی باشد که نظام را با خودم وفق دهم پس باید منتطر باشم و نتیجه را نگاه کنم. البته جا دارد از اینجا از فرماندهان خودم واقعا تشکر و قدردانی کنم و برای آنها آرزوی موفقیت یعنی ستارهای بیشتر و بزرگتر در نظامی گری و سلامتی و بهروزی در کل زندگی کنم. 

سلام به همه دوستان، شارپدیا عزیز من جمله این نیز بگذرد را واقعا قبول دارم ولی دعا کنید زود بگذرد.

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

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

(اینم برای یک دوست با اینکه می دانم هیچ وقت به اینجا سر نمی زند، می خاستم توی پست هجرت و حافظه قرار بدهم که نشد: دوست داشتن دلیل نمی خواهد بلکه دل می خواهد.)

1)      نظریه X  و Y مک گریگور

افرادیکه تحت رهبری شما قرار دارند دارای چه ویژگیهای هستند؟ آیا آنها افراد مسولئیت پذیر هستند یا نه؟ قدرت خلاقیت آنها در چه حد است؟ با چه عواملی میزان انگیزه آنها بالا می رود؟ شما می توانید به این سوالاتی نسبت به دید خودتان پاسخ دهید، اما فردی به نام مک گریگور نگرش مدیران را در مورد افرادی که تحت رهبریشان قرار دارند را اینگونه بیان می کند: در هر گروه و تیمی، دو دسته از افراد وجود دارند، گروه X و گروه Y اما ویژگیهای این افراد:

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

2)      نیازهای مک کللند

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

سه عاملی که در بالا بدانها اشاره شد از دید مک کللند، نیازهای اساسی انسان هستند یعنی:

1-       نیاز به کسب قدرت 2- نیاز به برقراری ارتباط با دیگران 3- نیاز به موفقیت و پیشرفت

مک کللند نشان داد وجود انگیزه در انسان یا همان میل به موفقیت و پیشرفت در افراد شرط اساسی برای پیشرفت و توسعه کشورهای در حال رشد است و برای رشد و توسعه، تا حد ممکن باید این نیاز را در آنها تقویت نمود. مک کللند معتقد بود فقط 10% افراد هر جامعه دارای نیاز به کسب موفقیت هستند. و چنانچه نیاز به کسب موفقیت در یک جامعه یا کشور قوی نباشد فرآیند توسعه در آن جامعه یا کشور عملی نمی شود.

3)      نظریه انتظار

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

مانند مثال بالا نظریه انتظار، انگیزه هر عمل، و علت بروز هر رفتار خاص را مورد بررسی قرار می دهد، و بیان می کند که انگیزش هر فرد تابعی است از «جذابیت نتایج» و «اعتقاد به اینکه کوشش فرد به انجام کار منجر می شود» و «انجام کار به نتیجه مطلوب ختم می شود». «جذابیت نتایج» بر شدت نیازی که به وسیله این نتایج برآورده می گردد، دلالت دارد.

همیشه به دنبال دلیلی هستیم تا کسی را دوست بداریم، به یادش بیافتیم و.... و دوباره من دلیلی دارم تا به یاد کسی بیافتم  که کسی بود، نه بخاطر اینکه اسمش دکتر علی شریعتی بود بلکه بخاطر اینکه در کلامش و تفکرش می توان زیبایی را دید و حس کرد.

می خواستم زندگی کنم ، راهم را بستند
ستایش کردم ، گفتند خرافات است
عاشق شدم ، گفتند دروغ است
گریستم ، گفتند بهانه است
خندیدم ، گفتند دیوانه است
دنیا را نگه دارید ، می خواهم پیاده شوم !

When the Declaration of Independence was still a draft, Benjamin Franklin, sitting beside Thomas Jefferson, revised Jefferson's wording of "We hold these truths to be sacred and undeniable" to the now-famous phrase, "We hold these truths to be self-evident." According to biographer Walter Isaacson, Jefferson was distraught by Franklin's edits. So Franklin, aware of his friend's state, sought to console Jefferson by telling him the tale of his friend John Thompson.

John had just started out in the hat-making business and wanted a sign for his shop. He composed his sign like so:

Before using the new sign, John decided to show it to some friends to seek their feedback. The first friend thought that the word "hatter" was repetitive and unnecessary because it was followed by the words "makes . . . hats," which showed that John was a hatter. The word "hatter" was struck out. The next friend observed that the word "makes" could be removed because his customers would not care who made the hats. So "makes" was struck out. A third friend said he thought the words "for ready money" were useless, as it was not the custom to sell hats on credit. People were expected to purchase hats with money. So those words were omitted.

The sign now read, "John Thompson sells hats."

"Sells hats!" said his next friend. "Why, nobody will expect you to give them away. What then is the use of that word?" "Sells" was stricken. At this point there was no use for the word "hats" since a picture of one was painted on the sign. So the sign was ultimately reduced to:

In his book Simple and Direct, Jacques Barzun explains that all good writing is based upon revision [Barzun]. Revision, he points out, means to re-see. John Thompson's sign was gradually revised by his friends, who helped him remove duplicate words, simplify his language, and clarify his intent. Jefferson's words were revised by Franklin, who saw a simpler, better way to express Jefferson's intent. In both cases, having many eyes revise one individual's work helped produce dramatic improvements.

The same is true of code. To get the best refactoring results, you'll want the help of many eyes. This is one reason why extreme programming suggests the practices of pair-programming and collective code ownership [Beck, XP].

Refactoring to Patternsمنبع :

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

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

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

- " کوه اورست، بار اول بر من پیروز شدی! اما سال دیگر تو را شکست می دهم، و دلیلش ساده است: تو دیگر به اوج ارتفاعت رسیده ای، اما من تازه دارم رشد می کنم!"

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

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

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

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

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

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

ملا صدرا میگوید:

خداوند بی نهایت است و لامکان و بی زمان

اما به قدر فهم تو کوچک می شود

و به قدر نیاز تو فرود می آید

و به قدر آرزوی تو گسترده می شود

و به قدر ایمان تو کارگشا می شود

یتیمان را پدر می شود و مادر

محتاجان برادری را برادر می شود

عقیمان را طفل می شود

ناامیدان را امید می شود

گمگشتگان را راه می شود

در تاریکی ماندگان را نور می شود

رزمندگان را شمشیر می شود

پیران را عصا می شود

محتاجان به عشق را عشق می شود

خداوند همه چیز می شود همه کس را...

به شرط اعتقاد،

                                                      به شرط پاکی دل،

                  به شرط طهارت روح،

                          به شرط پرهیز از معامله با ابلیس

بشویید قلب هایتان را از هر احساس ناروا

و مغزهایتان را از هر اندیشه خلاف

و زبان هایتان را از هر گفتار ناپاک

و بپرهیزید از ناجوانمردی ها ،ناراستی ها،نامردمی ها...

چنین کنید تا ببینید خداوند چگونه

بر سر سفره شما با کاسه ای خوراک و تکه ای نان می نشیند

در دکان شما کفه های ترازویتان را میزان می کند

و در کوچه های خلوت شب با شما آواز می خواند....

 مگر از زندگی چه می خواهید که در خدایی خدا یافت نمی شود؟؟؟؟؟

منبع: آسمونی

داستان از این قراره که روزی یک نفر از دهی به شهر میاد و از قضای روزگار به یک کنسرت موسیقی میره. در بازگشت از شهر در راه به مطرب ده میرسه که داشته با پسرش ساز و دهل میزده. همین که مطرب رو می بینه بهش میگه که من توی شهر رفتم یک جایی به اسم کنسرت و کلی از همکارات رو یک جا دیدم. مطرب هم که تا به اون روز کنسرت ندیده و نشنیده بوده، با بهت می پرسه که کنسرت چیه؟

مرد دهاتی میگه که کنسرت یه جایی که اولش که رفتیم تو یه عده روی یه بلندی با سازهاشون نشسته بودند و هر کی برای خودش هی ساز میزد (حواستون که هست داشتند سازهاشون رو کوک می کردند). بعد یکی که اصلا ساز نداشت از در اومد تو و همه براش دست زدند. بعد هم روشو کرد به مطربهای روی بلندی و شروع کرد به دستور دادن که تو بزن و تو نزن، تو بزن، تو نزن و الی آخر. آخرشم به همشون گفت دیگه نزنید. بعد هم مردم براش دوباره دست زدند و اون هی دولا و راست میشد می گفت من نبودم اینا بودن من نبودم اینا بودن.»

این دقیقا تعریف یک سیستم شی‌گراست. دقیقا هدف یک سیستم شی گرا ایجاد هارمونی معنادار (collaboration) میان اجزاء مستقل سیستم برای دست یابی به یک کارکرد مشخص است. در صورتی که در سیستمهای ساخت یافته رویکرد ما دقیقا رویکرد حل مساله بود. مساله تعریف می شد و برنامه نویس مساله را هدف گرفته و برای حل آن با استفاده از یک سری دستورات خطی شروع به حل مساله می‌کرد. در منطق شی گرا اجزا یک سیستم الزاما تعلقی به سیستم ندارند و می توانند به همان صورت که به سایر سیستم ها سرویس می دهند به سیستم مورد نظر ما نیز سرویسی را ارایه کنند. تنها مساله توان طراح سیستم در ایجاد تشریک مساعی و یا به تعبیری همکاری مناسب میان اجزاء مختلف سیستم است.

پس اینها همه اسمش زندگی است:

دلتنگی ها، دل خوشی ها، ثانیه ها، دقیقه ها

حتی اگر تعداد شان به دو برابر آن رقمی که برایت نوشتم برسد

ما زنده ایم جون بیداریم

ما زنده ایم چون می خوابیم

و رستگار و سعادتمندیم،

زیرا هنوز بر گستره ویرانه های وجودمان پانشینی

برای گنجشک عشق باقی گذاشته ایم.

 حسین پناهی

Your team has developers with different capabilities, experience, and skills. Each person has different strengths and expertise. That mix of diverse talents and backgrounds makes it an ideal environment for learning.

On a team, it’s not enough if you personally know a lot. If other members of your team are not as knowledgeable, the team isn’t as effective as it could be: a well-educated team is a better team.

While working on projects, you need to use terms and metaphors to clearly communicate your design concepts and intent. If most members of your team are not familiar with these ideas, it will be hard for you to be effective. Also, suppose you’ve taken a course or gone to a symposium. You generally lose what you don’t use. You need to bring what you have learned into your team. Share it with the rest of the team when you get back.

Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).

A “brown-bag session” is a great way to share knowledge in a team. Pick a day of the week, for instance Wednesday (generally any day other than Monday and Friday works well). Plan to get together over lunch so you don’t have to worry about running into other meetings or getting special permission. Keep the cost low by having folks bring their own lunch (in a brown bag, of course).

Each week, ask one member of your team to lead the discussion. He or she will present some concepts, demo a tool, or do just about anything that’s of interest to the team. You can pick a book and go through some specific sections, items, or practices from it.2 Do whatever works.

 Plan to start with the person leading the session that week speaking for fifteen minutes or so. Then you can open the topic for discussion so everyone can present their ideas and discuss how the topic might be relevant to your projects. Discuss benefits, provide examples from your own applications, and plan to get follow-up information.

These brown-bag sessions can be very valuable. It raises the industry awareness of the whole team, and you can personally learn a lot from them as well. Wise managers tend to value team members who raise the value of other members, so presenting can directly help your career, as well.

 What It Feels Like

It feels like everyone is getting smarter. The whole team is aware of new technology and starts pointing out how to apply it or points out pitfalls to watch for.

Keeping Your Balance

• Reading groups that go through a book chapter by chapter are very helpful, but pick good books. Learning XYZ in 7 Days with Patterns and UML is probably not a good book.

• Not all the topics will be winners or even seem appropriate at the moment. Pay attention anyway; it wasn’t raining when Noah built the ark.

• Try to keep it in the team. A catered lunch in the auditorium with PowerPoint slides loses some of the intimacy and discussion opportunities.

• Stick to a regular schedule. Constant, small exposure is agile. Infrequent, long, and drawn-out sessions are not.

• If some team members balk at coming to the lunch, bribe them with pizza.

• Stretch beyond purely technical books and topics; pertinent nontechnical topics (project estimation, communication skills, etc.) will help the team as well.

• Brown-bag sessions aren’t design meetings. Overall, you want to focus on discussing general topics that are relevant to your application. Solving specific issues is usually better left to a design meeting.

" brown-bag session" با نام های مختلف در منابع مختلف آورد شده است، اما نامی که من خودم آنرا دوست دارم و در بعضی ار منابع نیز ذکر شده است، "روز آزاد " می باشد. البته می توان روز آزاد را به دو قسمت تقسیم کرد، نیمه اول روز را برای مباحث علمی و جدید اختصاص داد، که هدفش بالا بردن سطح دانش تیمی و به اشتراک گذاشتن دانش بین اعضاء تیم می باشد. و نیمه دوم روز را برای تفریح و سرگرمی، که می تواند هدفش بالا بردن سطح روحیه و نشاط افراد تیم باشد. نظر شما درباره روز آزاد چیست؟ آیا یک چنین روزی می تواند در فرهنگ ما جا باز کند یا نه؟ 

(رنگ قرمز در متن شخصیت منفی، رنگ سبز در متن شخصیت مثبت)

هفت جا ، نفس خويش را حقير ديدم :

نخست ، وقتي ديدمش که به پستي تن مي داد تا بلندي يابد.

دوم ، آن گاه که در برابر از پا افتادگان ، مي پريد. 

سوم ، آن گاه که ميان آساني و دشوار مختار شد و آسان را برگزيد. 

چهارم ، آن گاه که گناهي مرتکب شد و با بادآوري اين که ديگران نيز همچون او دست به گناه مي زنند ، خود را دلداري داد. 

پنجم ، آن گاه که از ناچاري ، تحميل شده اي را پذيرفت و شکيبايي اش را ناشي از توانايي دانست. 

ششم ، آن گاه که زشتي چهره اي را نکوهش کرد ، حال آن که يکي از نقاب هاي خودش بود. 

هفتم ، آن گاه که آواي ثنا سرداد و آن را فضيلت پنداشت.

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

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

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

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

تمام تاکید من نه بر اسم ها که بر افعال است.

تا می توانی از اسم ها حذر کن،

اینکار در زبان امکان پذیر نیست، ولی در عرصه زندگی می توانی،

چون زندگی خود یک فعل است.

زندگی یک اسم نیست، واقعا "زندگی کردن" است و نه "زندگی".

عشق نیست، عشق ورزیدن است.

پیوند نیست، پیوند یافتن است.

ترانه نیست، ترانه خواندن است.

رقص نیست، رقصیدن است.

شاید شما هم یک یا چند دوست صمیمی داشتید یا دارید که با هم پشت یک کامپیوتر نشستید و برنامه های متنوعی را نوشتید، و از این کار لذت برده اید، اما شاید در آن لحظات متوجه نشده اید که شما در حال یکی از تکنیک های XP به نام برنامه نویسی دو نفره هستید.

برنامه نویسی دونفره، نوعی از برنامه نویسی است که دو برنامه نویس باهم و در کنار هم پشت یک کامپیوتر می نشینند و بر روی یک قسمت از کد برنامه، طراحی و یا تست نرم افزار کار می کنند. یکی از جفت ها که کد برنامه را تایپ می کند یا مستندات مربوط به طراحی را می نویسد را راننده (driver) می نامند. فرد دیگر را هدایت کننده (navigator) می نامند که کارهای راننده را نظارت می کند و سعی می کند اشکلات او را کشف کند. خطاهای مانند syntax errors، فراخوانی یک تابع به صورت اشتباه، پیاده سازی یک الگوریتم به شیوه ناکارا و ....  در واقع از بعد دیگر می توان گفت  در برنامه نویسی دو نفره، افراد مختلف با دانش ها و مهارت ها مختلف می توانند مهارتشان را ترکیب کنند تا یک مسئله مشکل را حل کنند. فرض کنید شما کسی هستید که مهارتتان در پایگاه داده در سطح عالی هست و دوست شما کسی که در برنامه نویسی شی گرا مهارت خیلی زیادی دارد در اینصورت شما می توانید کدی را بنویسید که به صورت بهینه و کارا به پایگاه داده دسترسی پیدا کند.

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

1.       کیفیت: در این شیوه ما کدی با کیفیت بالا خواهیم داشت چون اکثر خطاها و اشتباهات در همان مرحله اول تشحیص داده می شود.

2.       صرفه جویی در زمان: چون ما کدی با کیفیت بالا خواهیم داشت، زمان تست و تغییرات در سیستم کاهش خواهد یافت.

3.       افراد شاد: برنامه نویس های که با این تکنیک کار می کنند، اکثرا خوشحالتر و شادتر از زمانی هستند که به تنهایی کار می کنند. برای نمونه شما فشار کمتر را تحمل می کند چون همیشه کسی را در کنار خود دارید که به شما کمک کند و این باعث می شود که شما خیلی خوشحالتر باشید.

4.       اعتماد و روحیه همکاری بالا: در این شیوه شما تک و تک افراد تیم خود را به خوبی خواهید شناخت و باعث می شود که شما به آنها اعتماد کند و روح همکاری بخاطر شناخت عمق افراد بالا برود.

5.       دو نفر همیشه بهتر از یک نفر است.

6.       یادگیری و انتقال دانش : فرضی کنید شما دیروز در مورد یک موضوع جدید چیزهای را یاد گرفته اید، امروز صبح به زوجتان آن مورد را توضیخ می دهید و او را نیز با موضوع آشنا می کنید، سپس زمانیکه زوج ها بعد از مدتی عوض می شوند، شما به آن فرد جدید، و زوج قبلی شما به زوج جدیدش آنرا توضیح می دهد و شما هنگام ناهار خواهید دید که کل تیم شما با موضوع جدید آشنا شده است. واقعاً جالب نیست.

7.       مالکیت جمعی (این گزینه یکی از نقاط مورد علاقه من است و بعداً در یک پست مجزا آنرا بررسی خواهیم کرد.)

(بقیه برای قسمت دوم، انگیزه من برای نوشتن این مطلب حضور یکی از دوست های خوبم در شرکت بود که مرا به یاد ترم های اول دانشگاه و برنامه های که با هم پشت یک کامپیوتر نوشتیم انداخت  ولی من هنوزم آرزو کار مشترک با ایشان را دارم. ولی فکر کنم باید این مطلب را یک ویرایش اساسی کنم و دوباره پست کنم. موفق باشید.)

فکر کنم چند ماه قبل یک ایمیل برایم رسیده بود که محتوایش برایم جالب بود. احتمالا اکثر دوستان نیر ایمیل های مشابه را دریافت کردند یا از متن آن که در پایین می خواهیم به آن اشاره کنم از طریق سایت های دیگر باخبر شده اند. ایمیل مربوط بود به یک مسابقه که توسط شرکت مایکروسافت پشتبانی و حمایت می شد و مربوط بود به ارائه یک مقاله در مورد ویژوال استودیو 2008 یا پیاده سازی یک برنامه در این محیط و تاکید مسابقه نیز بر روی ویژگیهای جدید این محیط مانند Linq و ... بود. و جایزه مسابقه از نظر مالی فکر کنم مبلغ جالبی بود ولی دقیقا یادم رفته است که مبلغ جایزه نفر اول چقدر بود. فکر کنم آنزمان هنوز نسخه اصلی برنامه نیز ارائه نشده بود. همانروز ایمیل را به چند تا از دوستانم نشانم داد و گفتم که فکر می کنید هدف شرکت مایکروسافت از انجام این مسابقه چه می تواند باشد؟ (این سوال را حالا از تک تک شما دوستان نیز دارم) حتی یکی از دوستانی که کمی روی این سوال بحث کردیم یکی از طرفداران دوآتشه شرکت بورلند و محصولاتش بودند و می گفتند که حتی توی یک مسابقه مشابه که شرکت بورلند چند سال قبل روی محیط دلفی برگزار کرده بود جز منتخبان مسابقه بودند. ولی اکثر پاسخ دوستان، پاسخ های بود که به نظر من زیاد جالب نبودند چون خود شرکت مایکروسافت خودش می توانست بدون هیچ زحمتی خودش اینکارها را انجام دهد. یا بعضی از پاسخ ریشه ها در محیط و فرهنگی بود که ما در داخل کشور با آن روبرو هستیم. ولی یکی از دلایل عمده که به نظر من می تواند وجود داشته باشد موضوعی است که به عینا در کتاب کسب و کار به شیوه بیل گیتز (Business the bill gates way) به آن اشاره شده است (قسمت پایین از کتاب اشاره شده است ولی نوشته های با رنگ آبی نظرات شخصی من هستند):

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

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

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

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

البته دریافت بازخورد از مشتری در محصولات مایکروسافت دیگر فقط به نرم افزار بتا محدود نمی شود، اگر کمی به پیام های که در محصولات این شرکت نرم افزاری ظلاهر می شوند دقت کنیم نحوه دریافت بازخورد را خواهیم یافت مثلاً ....

منتظر نظرات شما هستم.

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

"تو همزمان نمی توانی جوانی و شناخت جوانی را در یک آن در اختیار داشته باشی، زیرا که زندگی، جوان را از شناخت باز می دارد و جستجو درباره ذات معرفت او را از زندگی باز می دارد."

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

"همه اندوه هایم را در پاییر جمع کردم و در باغ خویش دفن نمودم.

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

سپس همسایگانم آمدند تا گل های باغچه ام را تماشا کنند. همه آنها به من گفتند: اگر پاییز فرا رسید و زمان بذر افشانی شد، آیا از بذرهای این گلها به ما می دهی تا در باغهایمان بکاریم؟

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

چند روز قبل برای رفع مشکل در سیستم نرم افزاری یکی از مشتریان به شرکت آنها رفته بودم، تقریبا اولین باری بود که بخاطر اینکار به یک شرکت مراجعه می کردم، و همین کار دلیلی برای نوشتن این مطلب شد. شرکت مورد نظر فکر کنم تقریبا همزمان با ورود من به رشته نرم افزار، از نرم افزار مورد نظر استفاده می کند یعنی چیزی نزدیگ به 5 سال. ولی چیزی که برای من جالب بود، سوالات بسیار ساده و پیش پا افتاده آنها در مورد نرم افزار بود که از من می پرسیدند. سوالاتی که فکر می کردم هر کسی بعد از چند ماه استفاده از نرم افزار باید خودش در جواب دادن به آنها استاد باشد (کاربران نرم افزار مورد نظر در طول این چند سال تغییر نکرده اند.!). گفتم حق با نرم افزاریها است که اغلب اعتراضات کاربران را نادیده می گیرند(حداقل در گروههای که من از نزدیگ آنها رادیده ام). ولی یک چیز باعث شد که فورا تغییر عقیده بدهم. یک متن که تازه توی یک EBook خوانده بودم، سعی می کنم بعد از این  همیشه با این موضوع به این صورت برخورد کنم. متنی را که گفتم در کتاب Practices of an Agile Developer خوانده بودم که در پایین عین متن را آوردم. فقط چند قسمت از این کتاب را مطالعه کردم کتاب بسیار جالبی بود، و از همه زیباتر شیوه نگارش کتاب بود، در کل کتاب از دو شخصیت استفاده شده است چیزی شبیه سوژه های کارتونی یک شخصیت مثبت (یک فرشته که شیوه صحیح را نشان می دهد) و یک شخصیت منفی که شیوه اشتباه برخورد با مسئله را نشان می دهد.(جملات قرمز توصیه شخصیت منفی است و جملات سبز توصیه شخصیت مثبت است).

Listen to Users

Andy once worked for a large company that developed products for high-end Unix workstations. This wasn’t the sort of environment where you could just run setup.exe or pkgadd to install the software. You had to copy files and tune various settings on your workstation.

Andy and his team thought everything was going well, until one day Andy was walking past the tech support area and overheard a support engineer laughing loudly into the phone: “Oh, it’s not a bug; you made the same mistake everyone does.” And it wasn’t just this one engineer.

The whole department was chuckling at the poor, naïve, stupid customers.

Apparently there was a situation where you, the hapless customer, had to go tweak some obscure system file to contain a magic value, or otherwise the application would not run at all. No error message, no crash, just a big black screen followed by an abrupt exit. Granted, a line in the installation instructions mentioned this fact, but apparently some 80% of the customers missed that fact and had to instead submit to abuse via the company’s tech support line.

Whether it’s a bug in the product, a bug in the documentation, or a bug in our understanding of the user community, it’s still the team’s problem, not the user’s.

Then there was the case of the expensive manufacturing shop-floor control system that none of the users would use. It seems the first step to using the system was to log on with their name and password, and the majority of the workers in this plant were illiterate. No one have ever bothered to ask them or get their feedback, so a completely useless system was installed. (The developers in question had to retool the entire GUI to be picture-based at huge expense.)

We go to great lengths to get feedback from code using unit tests and such, but it’s all too easy to ignore the feedback from users. So not only do you need to talk to real users (not their managers or a surrogate

such as a business analyst), you need to listen to them.

Even if they sound stupid.

What It Feels Like

You don’t get irate or dismissive of stupid complaints; you can look past that and see the real, underlying problem.

Keeping Your Balance

• There is no such thing as a stupid user.

• There is such a thing as a stupid, arrogant developer.

• “That’s just the way it is” is not an answer.

• If the code can’t be fixed, perhaps the documentation and training

can be.

• Your users may have read all the documentation and will remember everything about your application all the time.

But probably not.

در پایان از همه دوستان بخاطر دیر به دیر آپ دیت شدن معذرت می خام، واقعا باور کنید فشار کار خیلی زیاد است و دلیلش هم خیلی ساده است: عدم رعایت زمانبندی، مدیریت اشتباه و .... از طرف دیگر فقط 2 ماه به کنکور مانده و من تازه می خام شروع به خواندن کنم و از همه اینها بدتر فقط یک ماه از فرجه 6 ماه مانده و احتمالا تا چند ماه بعد باید برم خدمت مثلا مقدس سربازی. از همه بدتر قضیه دنبال دار پروژه ... می باشد، که واقعا نمی دانم دیگر باهاش چیکار کنم و تقریبا وقتی یادم می افته یا از طرف آنها تماس می گیرند کلاً انرژیم تخلیه می شه (نمی دانم یک پروژه مگه می تونه چقدر از زمانبندی عقب بیفته  چند هفنه، چند ماه، یک سال و چند ماه !!!!). دعا کنید ....

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

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

 اما یک دلیل که فکر کنم ریشه روانشناسی هم داشته باشد در سالهای اول دانشگاه بوجود می آید و بعدها بعضی ها نمی توانند ترک کنند. شاید جملاتی مانند این که پروژه من چند هزار سطر شد و یا شبیه آن برای خیلی از دوستان آشنا باشد. جملاتی که در ترمهای اول دانشگاه تکرار می شود و تعداد سطرها بدون توجه به هر اصل دیگر، عامل اصلی برتری یک پروژه در بین گروه خاص از دانشجویان می شود. و سپس بعضی از دوستان نمی توانند از دام این عامل برتری خلاص شوند. و اغلب مشکلاتی که بخاطر این مسئله در برنامه هایشان بوجود می آید را با جملاتی مانند اینکه پروژه در این حجم (از لحاظ تعداد سطرها) نگهداریش واقعا مشکل و کار هر کسی نیست و ... را تکرار می کنند. و صدها دلیل کوچک و بزرگ می توان پیدا کرد که می تواند عامل مشکل بالا باشد. اما برای رفع این مشکل بد نیست که یک اصل را به نام DRY (Don't Repeat Yourself ) را مرور کنیم.

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

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

تکه کد بالا را در نظر بگیرید، فکر می کنید مشکلی روی این کد وجود دارد یا نه. شاید در نگاه اول این کد مشکل نداشته باشد اما در این تکه کد اصل DRY رعایت نشده است. صفت length را در نظر بگیرید، مقدار این صفت با توجه به مقادیر start و end محاسبه می شود و با تغییر هر کدام از این صفات، آن نیز تغییر می کند (همیشه این نوع تکرار کد را با افزونگی در پایگاه داده مقایسه می کنم و می کویم صفتی که  قابل محاسبه از روی صفات دیگر باشد، نیازی به ذخیره سازی ندارد. می شود نرمالسازی در پایگاه داده را مفهومی مشابه این اصل دانست). پس بهتر است این تکه کد به صورت زیر تغییر کند.

می توانیم به سادگی راه حل های زیادی برای رهایی از این دام پیدا کنیم و فکر می کنم نیاز زیادی به بحث روی این موضوع نیست، البته پیشگیری مثل همیشه بهترین شیوه درمان است. اما دوست دارم ادعای جالبی که آقایان  Andy Hunt و  Dave Thomas(اصل DRY، برای اولین با توسط این دو نفر ارائه شده است.) رابیان کنم و دوست دارم نظر شما را در مورد این ادعا بدانم. به نظر شما مرحله نگهداری یک برنامه  از چه زمانی شروع می شود؟ نمی دانم دقیقا پاسخ شما چیست، اما پاسخ دو نفر بالا به این صورت است که برنامه نویسان همیشه در مرحله نگهداری هستند.  و تنها در 10 دقیقه اول یعنی زمانیکه شما برای اولین با یک تکه کد را تایپ می کنید در مرحله نگهداری قرار ندارید و سپس شما بارها و بارها یک تکه کد را تغییر می دهید تا به هدف خود برسد و اینها جزء مرحله نگهداری هستند. حال نظر شما چیست؟

 آن که دیگران را می شناسد، خردمند است.

آن که خود را می شناسد، روشنیده است.

آن که بر دیگران پیروز می شود، نیرومند است.

آن که بر خود پیروز می شود، نیرومند است.

آن که شادی را می شناسد، ثروتمند است.

آن که بر راه خویش پا بر جا می ماند، با اراده است.

فروتن باش، و اما غرور خویش را حفظ کن.

خم شو، اما سرافراز بمان.

خود را خالی کن، و اما سرشار بمان.

خود را بفرسای، اما تازه بمان.

خردمند خود را به نمایش نمی گذارد، و از این راه می درخشد.

خود نمایی نمی کند، و بنابراین او را می بینند.

خود را ستایش نمی کند، و بنابراین سزاوار است.

و از آن جا که رقابت نمی کند، هیچ کس را در جهان یارای رقابت با او نیست.

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

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

تنها یک چیز تغییر نمی کند. تغییر.

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

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

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

یک طراحی می تواند به این صورت باشد که شما یک کلاس Shape تعریف می کنید، که اشکال دیگر از آن کلاس به ارث می برند، و یک کلاس دیگر مثلا با نام DrawManager تعریف می کنید که لیست اشیاء را نگهداری می کنید و مسئول رسم اشکال مختلف بر روی صفحه نمایش است. مثلا متدی یا نام DrawAllShape داریم که با توجه به هر نوع هر شکل تابع مخصوص رسم ان شکل را فراخوانی می کند. در این متد ما کدی شبیه کد پایین خواهیم داشت.

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

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

در بسیاری از الگوهای طراحی یکی از مهمترین ویژگیهای که در نظر گرفته شده است، اصل open-closed می باشد. برای نمونه می توانید الگوی TEMPLATE را بررسی کنید. ما باید بعضی از تغییراتی که می تواند در سیستم رخ دهد را، پیش بینی کنیم و با استفاده از مفهوم abstractions از سیستم خود در مقابل این تغییرات حفاظت کنیم. در واقع می توان گفت که کلید اصل open-closed دو مفهوم abstractions و encapsulation می باشد.                                                                                                          

و به آنان گفتم:

هر که در حافظه چوب ببیند باغی

صورتش در وزش بیشه شوری ابدی خواهد ماند.

هر که با مرغ هوا دوست شود

خوابش آرام ترین خواب جهان خواهد بود.

آنکه نور از سرانگشت زمان برچیند

می گشاید گره پنجره ها با آه.

زیر بیدی بودیم.

برگی از شاخه بالای سرم چیدم، گفتم:

چشم را باز کنید، آیتی بهتر از این می خواهید؟

می شنیدم که بهم می گفتند:

 سحر میداند، سحر!

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

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

الگوی که می توانیم برای حل این مسئله بکار ببریم، الگوی Iterator نام دارد. این الگو یک اینترفیس تعریف می کند که امکان دسترسی نرتیبی به عناصر یک مجموعه را می دهد. هر کلاس که بخواهد به عناصر یک مجموعه دسترسی پیدا کند از طریق این اینترفیس عمل خواهد کرد که مستقل از پیاده سازی شی مرکب و کلاسی که این اینترفیس را پیاده سازی کرده است خواهد بود.

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

دیاگرام الگوی Iterator

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

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

همانطوریکه روی صندلی نشسته اید به بدن خود تان توجه کنید و آنرا مورد بررسی قرار بدهید، شاید بدن خود را به صورت ترکیبی از چندین شی مانند دست، پا، چشم و ...  ببینید. سپس با دست خود یک کتاب را بردارید و شروع به ورق زدن آن بکنید، مشاهده می کنید که یک کتاب از ده ها صفحه تشکیل شده است و هر صفحه از چندین پارگراف و هر پار گراف از چندین سطر تشکیل شده است.  روی آیکون My Computer کلیک می کنید، دریواهای که کامپیوترتان دارید نشان داده می شود، روی یکی از دریواها کلیک می کنید، لیست فایل ها و folder های آن دریوا نشان داده می شود، سپس روی یکی از folder ها کلیلک می کند، مشاهده می کند که خود آن folder، از چندین folder و یا فایل تشکیل شده است. در هر کدام از نمونه های بالا، همانطوریکه دیدید یک شی ممکن شامل چندین شی ساده یا مرکب دیگر نیز باشد، آن شی باید بداند که چگونه این اشیاء را نگهداری و مدیریت کند و هر چه تعداد اینگونه اشیاء مرکب در سیستم افزایش یابد، سیستم پیچیده تر خواهد شد. شما برای حل این مشکل چه پیشنهادی دارید و چه راه حلی ارائه می کنید؟

اجازه بدهید کار را با یک مثال ادامه دهیم. برای مثال فرض کنید که می خواهیم یک برنامه ایجاد کنیم که فایل سیستم ویندوز را شبیه سازی کند. در فایل سیستم ویندوز ما دو شی اصلی به نامه های Folder و فایل داریم. Folder ها می توانند از فایل ها یا Folder ها دیگر تشکیل شوند، در حالیکه فایل ها نمی توانند شامل مولفه ای دیگری از فایل سیستم باشند. برای این مثال می توان طراحی های گوناگونی را ارائه کرد. یک طراحی می تواند بدین صورت باشد که، یک اینترفیس مشترک برای هر دو شی موجود در مسئله تعریف کنیم، که شامل متدهای باشد که در هر دو شی وجود دارند. شکل زیر طراحی حاصل را نشان می دهد.

با این طراحی  Clinet می تواند یک مجموعه از اشیاء FileSystemComponent را ایجاد کند. و با استفاده از متد addComponent، شی  DirComponent، نمونه های مختلفی از FileSystemComponents را به DirComponent اضافه کند.

هنگامیکه Clinet بخواهد سایز هر کدام از این اشیاء را استخراج کند، به سادگی متد getComponentSize را فراخوانی کند، Client نباید از نحوه محاسبه و عملیاتی که برای اندازه گیری سایز یک مولفه صورت می گیرد آگاه باشد. در این مورد، client با هر دو شی FileComponent و DirComponent به یک صورت رفتار می کند.

Clinet  در مورد متد مشترک getComponentSize، با هر دو شی  FileComponent و DirComponent رفتار یکسانی را دارد. اما Clinet   برای فراخوانی متدهای مانند addComponent و getComponent نیاز دارد که دو شی را از همدیگر تشخیص دهد، چونکه این متدها فقط برای DirComponent تعریف شده است. به همین دلیل client نیاز دارد تا نوع شی مورد نظر را برای فراخوانی این متدها چک کند تا مطمئن شود که با یک نمونه از DirComponent سر و کار دارد.  برای بهبود این طراحی بگونه ای که نیازی به تشخیص تفاوت بین دو شی وجود نداشته باشد، طراحی را به چه صورت تغییر می دهد.

ما می خواهیم طراحی را بگونه ای تغییر دهیم که clinet  نیازی به تشخیص شی مرکب DirComponent از FileComponent نداشته باشد، و با هر دو شی به یک صورت رفتار کند.

طراحی را می توانیم به این صورت تغییر دهیم که، متدهای addComponent و getComponent را به اینترفیس مشترک FileSystemComponent  انتقال دهیم، و یک پیاده سازی پیش فرض برای این متدها انجام دهیم و اینترفیس مشترک FileSystemComponent   را به یک کلاس abstract تغییر دهیم. پیاده سازی پیش فرض برای این متدها بخاطر FileComponent  هست و کار خاصی را انجام نمی دهد. اما کلاس DirComponent این متدها را بازنویسی مجدد می کند تا پیاده سازی خاص خود را انجام دهد.

با این کار مشکل قبلی ما حل می شود، چون کلاس پدر FileSystemComponent، دارای یک پیاده سازی پیش فرض برای متدهای addComponent و getComponent هست، و دیگر clinet   نیاز به کنترل نوع شی برای فراخوانی این دو متد ندارد.

تصور کنید که می خواهیم یک متد جدید با نام  removeComponent را به کلاس DirComponent اضافه کنیم، در اینصورت این متد را به پدر FileComponent نیز اضافه می کنیم و یک پیاده سازی پیش فرض برای این متد در نظر می گیریم.

با طراحی بالا ما توانستیم مشکل خود را حل کنیم، اما روشی که برای غلبه بر مسئله استفاده کردیم، الگوی Composite نام دارد. ما در مواقعی از این الگو استفاده می کتیم که یک شی پیچیده داریم و می خواهیم آنرا به یک سلسله مراتب از اشیاء کل و جز (part-whole hierarchy) تجزیه کنیم. یا همانند مثال بالا،  client قادر باشد تفاوت بین اشیاء مرکب (DirComponent) و اشیاء منفرد را نادیده بگیرید. و client با همه اشیاء موجود در ساختار مرکب بصورت یکسان رفتار کند.

کلاس دیاگرام این الگو به صورت زیر است:

در دیاگرام بالا کلاس Leaf، کلاس های هستند که دارای فرزند نیستند مانند کلاس FileComponent در مثال.

کلاس Composite، کلاسی مانند DirComponent در مثال می باشد. در این کلاس رفتارهای مربوط به مولفه های که دارای فرزند هستند تعریف می گردد.

کلاس FileSystemComponent همان کلاسFileSystemComponent با ویژگیهای که در بالا اشاره شد هست.

پرودگارا

به من آرامش ده

تا بپذیرم آنچه را که نمی توانم تغییر دهم

دلیری ده

تا تغییر دهم آنچه را که می توانم تغییر دهم

بینش ده

تا تفاوت این دو را بدانم

مرا فهم ده

تا متوقع نباشم دنیا و مردم آن

مطابق میل من رفتار کنند.

متن بالا را جبران خلیل خلق کرده است، اما نمی دانم آنرا در کدام کتاب برای ما به یادگار گذاشته است، اما می دانم آنرا از تابلوی که روی میزم هست برای شما می نویسم، تابلوی که یک دوست برایم به یادگار گذاشته است، دوستی که شاید گفته هایش و خاطراتش را زود فراموش می کند. اما یک دوست هر کجا باشد و هر گونه که باشد، برای من تا آخر یک دوست است (حتی دوست مشترکمان).  دوستانم هر کجا که هستید، هر کجا باشید،  زندگی توام  با رضایت و موفقیت برای شما آرزومندم.

چند قطعه دیگر از جبران خلیل، که آنها را در کتاب ماسه و کف به یادگار گذاشته است:

به من می گویند یک گنجشک در دست بهتر از ده گنجشک روی درخت است.

اما من به آنها می گویم: « یک گنجشک روی درخت بهتر از ده تا در دست است.»

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

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

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

او بود که به من آموخت که:

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

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

عشق در هر رنگی و سطحی با زیبایی محسوس، در نهان یا آشکار، رابطه دارد. چنانچه شوپنهاور می گوید: "شما بیست سال بر سن معشوقتان بیافزید، آنگاه تاثیر مستقیم آن را بر احساستان مطالعه کنید."!

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

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

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

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

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

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

عشق در دریا غرق شدن است و دوست داشتن در دریا شنا کردن. عشق بینایی را می گیرد و دوست داشتن هدیه می دهد.