ارائه توسط: Michael Kircher, Markus Voelter
مترجم: محمد علی بزرگ زاده 1393/08/23
این اپیزود اولین اپیزود از سری مصاحبه‌های SE Radio است که در سال 2006 ضبط شده است. در این اپیزود مارکوس ولتر و مایکل کریکر در مورد الگوها (Pattern) صحبت می‌کنند. الگوها مبحث بسیار مهم و پرکاربردی در مهندسی نرم‌افزار به حساب می‌آید. این مبحث با کتاب الگوهای طراحی موسوم به GOF خیلی شناخته شد. GOF مخفف Gang of Four اشاره به 4 نویسنده کتاب مذکور است. در این اپیزود همچنین در مورد الگوهایی که فراتر از بحث این کتاب قرار می‌گیرند نیز صحبت می‌شود.
3 مثال خیلی مطرح از الگوها که می‌توانید عنوان کنید، کدامند؟
فکر می‌کنم الگویی که بیشترین استفاده را داشته و احتمالاً بیش از همه شناخته شده است، الگوی ناظر (Observer) است که در آن یک شیء، مجموعه‌ای از اشیاء دیگر را از وقوع تغییرات باخبر می‌کند. مثلاً اگر یک برنامه گرافیکی داشته باشید که در آنجا چند View داشته باشید که تغییراتی در نوعی ساختارهای داده را انعکاس می‌دهند، وقتی ساختار داده تغییر می‌کند، اشیاء مختلف View را از تغییرات باخبر می‌کند و View ها در مورد داده‌های تغییریافته پرس‌وجو می‌کنند و خود را متناظر با آن تغییر می‌دهند.
الگوی معروف دیگر، احتمالاً الگوی نماینده (Proxy) است. این الگو، همه جا در سیستم‌های از راه دور (Remoting Systems) استفاده می‌شود. بجای اینکه با یک شیء مستقیم صحبت کنید -که در مورد شیء‌های دور (Remote Objects) امکانپذیر نیست- با یک شیء محلی صحبت می‌کنید که مانند شیء دور به نظر می‌رسد و شیء محلی یا همان نماینده، همه فراخوانی‌ها را از طریق شبکه یا روش‌های دیگر، به شیء دور، ارسال می‌کند.
الگوی دیگر، الگوی رآکتور (Reactor) است. فکر کنم بهتر باشد که شما توضیحش دهید.
رآکتور، اساساً کارهای ناهمبسته‌سازی (Decouple)، مقسم‌سازی (Demultiplexing) و توزیع (Dispatching) رخدادها را انجام می‌دهد. بعنوان مثال، در مورد رخدادهای شبکه این کار را انجام می‌دهد و این امور را از منطقی که برنامه برای رسیدگی به رخدادها دارد مجزا می‌سازد. در یک طرف رآکتور را دارید و در طرف دیگر هندلرهایی دارید که برای رخدادهای مختلف در رآکتور ثبت‌نام (Register) می‌شوند. هرگاه یک رخداد ثبت‌نام شده رخ دهد، هندلر موردنظر درگیر شده و به آن عکس‌العمل نشان می‌دهد.
آیا این الگو، غالباً در سیستم‌های مقیاس‌پذیرِ چندنخی (Multithread) استفاده می‌‌شود؟
در واقع در سیستم‌های چندنخی خیر. رآکتور می‌تواند به خوبی برای طراحی برنامه‌های تک‌نخی مقیاس‌پذیر استفاده شود. البته می‌توانید در محیط‌های چندنخی نیز با آن کار کنید. در آنصورت به الگوهای دیگر مثلاً الگوی پیشوا-پیروان (Leader/Followers) نیاز دارید تا به همروندی، بپردازید.
بسیار خوب. قبل از اینکه بخواهیم به جزییات زیاد بپردازیم بهتر است که کمی در مورد تاریخچه الگوها صحبت کنیم. فکر کنم کانینگهم اولین کسی باشد که بخواهیم در موردش صحبت کنیم. درسته؟
کانینگهم و کنت بک در سال 1987 کار بر روی مستندسازی حداقل 5 الگوی واسط کاربری (User Interface) را آغاز کردند و آن را در c2.com مستند کردند. از آنجا بود که همه چیزها شروع شد. در دهه 90 اریک گاما ، این سبک نگارش الگو را آغاز کرد که بعداً در سال 1995 به کتاب معروف الگوهای طراحی انجامید که توسط اریک گاما ، ریچارد هلم ، راف جانسون و جان وسیدس معروف به دسته 4 تایی‌ها، نوشته شد.
جالب است زیرا فکر می‌کنم غالب افراد فکر می‌کنند که کتاب GOF، اولین نوشته در مورد الگوها در دنیای IT بوده است اما اینطور نیست.
بله، کمی بعد از GOF، کار کتاب معماری نرم‌افزار الگو‌گرا (Pattern Oriented Software Architecture) آغاز شد که بوشمن ، منییِر ، رونرت ، سامرلد و استال نویسندگان جلد اول کتاب بودند. بیشتر آن را با عنوان POSA1 می‌شناسند.
تفاوت‌هایی بین الگوهای کتاب GOF و کتاب POSA هست. الگوهای کتاب GOF، الگوهای طراحی کلاسیک هستند. محتوای کتاب POSA1 چیست؟
POSA1 در ارتباط با الگوهای معماری است. گاهی با عنوان سبک‌های معماری (Architectural Styles) نیز نامیده می‌شود.
بسیار خوب. قبل از آنکه بخواهیم در مورد محتوای برخی الگوهای خاص صحبت کنیم، فکر می‌کنم بهتر باشد یک نگاهی به شکل الگوها بیاندازیم. الگوها با یک روش کاملاً مشخص، مستند می‌شوند. در واقع، چندین روش وجود دارد. فکر می‌کنم در کتاب GOF برای هر الگویی 11 بخش داریم. درسته؟
بله، فکر می‌کنم.
مهمترین آنها، پیش‌زمینه (Context)، مسأله (Problem) و راه حل (Solution) است. اگر بخواهیم الگو را تعریف کنیم گفته می‌شود الگو، مسأله‌ای معروف در یک پیش‌زمینه خاص است که راه حل مشخصی دارد. مستندسازی یک الگو تنها در صورتی معنی می‌دهد که افراد زیادی با مسأله‌اش احتمالاً در زمینه‌های تکنیکی مختلف مواجه شده باشند و راه‌حل‌های مختلفی داشته باشد. بخش پیش‌زمینه یک الگو هر محیط یا شرایطی که در ارتباط با نرم‌افزار دارید را توضیح می‌دهد. بعد از آن بخش مسأله مطرح می‌شود و بعد از آن راه حل را نشان می‌دهید که کمک می‌کند در آن پیش‌زمینه خاص مسأله را حل کنید. بخش مهم دیگر الزامات (Forces) است. شما تنها در صورتی می‌توانید یک مسأله را به یک روش خاص حل کنید که بدانید هنگام حل آن، چه مواردی را باید در نظر داشته باشید؛ مواردی از قبیل اینکه سیستم باید سریع اجرا شود یا اینکه کمترین مقدار ممکن از حافظه را مصرف کند. وقتی دارید در یک الگو مسأله را توضیح می‌دهید همواره باید الزاماتی که شما را در جهت یافتن راه حل کمک می‌کند را توضیح دهید. به این شکل یک تکه دانش قابل استفاده مجدد تهیه می‌شود که دیگران می‌توانند آن را بخوانند و در محیط یا نرم‌افزار خودشان بکار گیرند.
ادامه مطلب ...

ارائه توسط: Kent Beck
مترجم: محمد علی بزرگ زاده 1393/08/10
اینبار می‌خواهیم با کِنت ‌بِک در مورد تاریخچه JUnit و آینده تست Unit، مصاحبه کنیم.
خوش آمدی کِنت!
خیلی ممنونم. خوش‌وقتم که اینجا هستم.
خیلی خرسندیم که با شما مصاحبه می‌کنیم. لطفاً خود را برای شنوندگان معرفی کنید و کمی در مورد گذشته و پیش‌زمینه خود برایمان بگویید.
من یک خوره نسل سومی هستم. پدربزرگم یک خوره رادیو بود. پدرم یک خوره الکترونیک بود که خوره برنامه‌نویسی شد. حالا من پیشه خانوادگی‌مان را در پیش گرفته‌ام. من در محیطی آکنده از تکنولوژی بزرگ شدم. وقتی 12-13 ساله یا شاید 11 ساله بودم، برنامه‌نویسی را آغاز کردم؛ روی ماشین حسابی که پدرم به خانه آورده بود برنامه‌نویسی می‌کردم.
نمی‌دانم چه چیزهایی را برجسته کنم که برای شنوندگان جذاب باشد! خیلی کارها کرده‌ام. الگوهای نرم‌افزاری مبحثی بود که در ابتدا بر روی آن کار کردم. (بر روی چیزهای دیگری هم کار کرده‌ام مثلاً) متدولوژی eXtreme Programming و توسعه برآمده از تست (Test Driven Development)، معماری xUnit که اولین بار برای زبان SmallTalk پیاده‌سازی شد و بعداً بوسیله اریک ‌گاما و من به زبان جاوا ترجمه شد. غیر از آن مثلاً بر روی Responsive Design هم کار کرده‌ام. به چه چیز دیگری علاقه‌مندید؟!
شما کتاب‌های زیادی نوشته‌اید. این خیلی خوب است.
بله، فکر می‌کنم تا الان 8 کتاب نوشته باشم.
فکر می‌کنم به مقیاس جامعه ما زیاد باشد.
بله، با استاندارد خوره‌ها، زیاد است.
فکر می‌کنم در Twitter خواندم که از هواداران اپیزودهای SE Radio هستید. درسته؟
بله، من در 8 هکتار از زمین‌های چمنزار و جنگلی زندگی می‌کنم که در خارج از یک دهکده کوچک قرار دارد که آن هم خارج از یک شهر کمی‌ بزرگتر است؛ در وسط ناکجا آباد! به همین خاطر، تفریحات زیادی دارم. من به پادکست‌های زیادی گوش می‌دهم از جمله فکر می‌کنم به همه اپیزودهای SE Radio گوش داده‌ام. خیلی خوب است که موقعی که در حال بیل زدن، کودپاشی و غذا دادن به حیوانات هستید، به چیزی گوش دهید که غذای ذهنتان باشد.
جالب است. خیلی باعث افتخار است که شنونده همه اپیزودها بوده‌اید. لطفاً کمی در مورد تاریخچه JUnit برایمان بگویید. کار چطور آغاز شد؟
بله، اولین کار تجاری من در زبان Small Talk بود. Small Talk یک تاریخچه‌ای از تست داشت اما تست خودکار نبود. تغییرات کمی در برنامه‌تان می‌دادید و مدتی می‌گذشت و تغییرات بیشتری می‌دادید. بنابراین، این چرخه‌های افزایشی (Incremental) شکل گرفته بود اما تست خودکار نبود. من زنجیره‌ای از کارها را تجربه کردم و 4-5 تکنیک مختلف برای نوشتن تست‌های خودکار را آزمودم. بعد، یک روز از من خواسته شد که به یک تیم توسعه، مشاوره بدهم.
اوایلِ کار مشاوره‌ام بود. من می‌دانستم که می‌خواهم به آنها بگویم که تست خودکار بنویسند اما روشی برایشان نداشتم که چطور این کار را بکنند. در همان حالی که نوعی اضطراب و هراس داشتم گفتم به من اجازه بدهید که از همان ساختاری که برای تست در محیط Small Talk داریم استفاده کنم. ما متغیرهایی داریم که مقداردهی اولیه می‌شوند و بعد هم عبارات را داریم. گفتم که چطور است که آن‌ها را بی‌هیچ تکلفی، به مدل اشیاء برگردانیم. محیط کاری شما معادل می‌شود با یک کلاس. متغیرهایی که استفاده می‌کنید تبدیل می‌شود به نمونه‌های متغیر (Instance Variable) و تکه کدی که برای تست می‌نویسید، متدهای کلاس می‌شوند. این، نوعی نگاشت بی‌تکلف بود. من گفتم بجای اینکه تست را دستی انجام دهیم و ببینیم که چه چیزی در خروجی چاپ می‌شود و آن وقت مطمئن شویم که تست موفق بوده، بگذاریم کامپیوتر این کار را بکند. از همین جا بود که اعلان‌ها (Assertion) آمدند (اشاره به معنای خاص Assertion در تست Unit است که برای چک کردن نتایج تست از آن‌ها استفاده می‌شود - مترجم). منشأ معماری از اینجا بود و این مربوط به سال 1992 می‌شود. این اولین فریم‌ورک تست یونیت بود که همه این موفقیت‌ها از آنجا ناشی شد.
ادامه مطلب ...

ارائه توسط: Andreas Rueping, Markus Voelter
مترجم: محمد علی بزرگ زاده 1393/06/13
در این اپیزود می‌خواهیم در مورد مستندسازی و به طور خاص در مورد مستند‌سازی چابک (Agile Documentation) صحبت کنیم. ممکن است فکر کنید که علاقه‌ای به مستندسازی ندارید زیرا خود کد را ترجیح می‌دهید. احتمالاً این یکی از مشکلات اصلی پروژه‌های نرم‌افزاری است زیرا مستندسازی -اگر در نظر گرفته شود- بعد از همه کارهای دیگر، درنظر گرفته می‌شود. به همین علت مستندات بد هستند و زشت به نظر می‌رسند. افراد نمی‌دانند چه چیزی را، چگونه و چه زمانی مستند کنند. در این اپیزود قصد داریم برخی از این موارد را روشن کنیم. برای این منظور Andreas Rueping مهمان ماست. او نویسنده کتاب مستند‌سازی چابک است که انتشارات Wiley آن را منتشر کرده است.
Andreas لطفاً کمی در مورد خودتان و موضوع مستند‌سازی چابک صحبت کنید.
سلام Markus، برای دعوتتان متشکرم. همینطور به شنوندگان سلام می‌کنم. من یک معمار و مهندس نرم‌افزار مستقل در هامبورگ هستم که بر روی پروژه‌های IT مختلفی کار کرده‌ام. خیلی وقت است که در این حوزه مشغولم. امروزه بیشتر تمرکزم بر روی معماری‌های مبتنی بر اینترنت و نرم‌افزارهای مدیریت محتوای تحت‌وب است. موضوع مستندسازی، موضوعی است که چند سالی است بر روی آن کار می‌کنم زیرا در هر پروژه‌ای، مستقل از نوع تکنولوژی‌‌اش، می‌توانیم رویه‌های برتری (Best Practice) را در ارتباط با مستندسازی مشاهده کنیم که خوب عمل می‌کنند و چیزهایی را هم ببینیم که خوب عمل نمی‌کنند.
سرانجام، شروع کردم که به این تجربه‌های مربوط به رویه‌های برتر، در قالب تعدادی الگو (Pattern) شکل بدهم و به این ترتیب بود که کتاب مستندسازی چابک نمو یافت. عنوان چابک از این موضوع ناشی می‌شود که می‌خواسته‌ام بر روی چیزهایی که متدهای چابک‌ (Agile Method) در مورد مستندسازی می‌گویند، تأکید کنم. اینکه مستندسازی بیش از حد، بیش از آنکه خوب باشد، زیانبار است. و اینکه می‌توانیم از متدهای چابک‌، اطلاعات زیادی در ارتباط با اینکه مستندسازی خوب چیست و چه چیز نیست، بدست بیاوریم. فکر می‌کنم یکی از نکات مهمی که می‌توانیم از متدهای چابک‌ بیاموزیم این است که «مستندسازی» و «فراگیری»، یکسان نیستند. شما می‌توانید خیلی چیزها را مستند کرده باشید اما این به این معنی نیست که همه چیزهایی که تیم فراگرفته است را مستند کرده‌اید. به همین ترتیب می‌توانید مستندات را بخوانید اما ممکن است همه دانشی که نویسندگان در ابتدای کار، در مستندات قرار داده‌اند را بدست نیاورید.
دانش عظیمی در یک پروژه وجود دارد. چطور می‌‌توان اینکار (انتقال آن به مستندات) را انجام داد؟! برخی متدهای چابک‌ به این سمت گرایش می‌یابند که «بیایید اصلاً هیچ چیزی را مستند نکنیم» که در واقع درست نیست. اما اغلب متدهای چابک‌، توصیه می‌کنند که مستندسازی خود را محدود به چیزهایی بکنید که واقعاً ضرورت دارند و مستند کردن آنها سودمند است. آنچه من انجام دادم این بود که برخی رویه‌های برتر و الگوها را جمع‌آوری کردم که در این مورد هستند که چه مستنداتی سودمند هستند و همچنین اینکه چطور مستنداتی که فکر می‌کنید در پروژه‌تان ضروری است را شکل دهید. بنابراین کتابی که به آن اشاره کردید، در واقع از دو ایده مجزا تشکیل یافته است. یکی اینکه مستنداتتان را به یک اندازه منطقی کاهش دهید و دیگر اینکه مستندسازی‌هایی که تصمیم می‌گیرید ضرورت دارند را به روشی انجام دهید که سودمند، خوانا و قابل درک باشد و بطور کلی ارزش مستندسازی و ارزش خواندنش را داشته باشد.
ادامه مطلب ...