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

ارائه توسط: Martin Thompson
مترجم: مرتضی هاشمی 1393/05/28
در این اپیزود، Robert Ford با Martin Thompson یکی از متخصصان پیشرو در تنظیم و بهبود کارایی سیستم‌های کامپیوتری است مصاحبه می‌کند. در این اپیزود، بحث می‌شود که چطور داشتن پیش‌زمینه و درک از عملکرد سخت‌افزاری و مکانیک کامپیوتر می‌تواند شما را در طراحی و توسعه مؤثرتر سیستم‌های نرم‌افزاری یاری دهد. مارتین، یک سخنران در کنفرانس‌های فناوری، بنیانگذار شرکت LMAX، یکی از بنیانگذاران پروژه متن بازِ Disruptor و صاحب بلاگی به نام درک مکانیکی (Mechanical Sympathy) است. او در حال حاضر صاحب Real Logic Ltd. است که یک شرکت مشاوره در زمینه‌ی سیستم‌های کامپیوتری در لندن است.
مارتین لطفاً کمی در مورد سوابق خود به شنوندگان ما بگویید. چطور به مبحث کارایی علاقه‌مند شدید؟
(این موضوع) خیلی حالبه، من کارهای زیادی در طول دهه‌های اخیر انجام دادم. اما همیشه به سمتی کشیده می‌شدم که کارایی کامپیوتر افزایش پیدا می‌کرد. در آنجا فرصت‌هایی ایجاد می‌شد که قبلاً وجود نداشت. فکر می‌کنم اولین کاری که در این زمینه انجام دادم به سال 92 بر می‌گردد که اطلاعات فرابورس را می‌گرفتم. در آن زمان مجبور بودیم همه چیز را روی Main Frame های IBM پردازش کنیم. این اطلاعات روی دو هارد دیسک که روی یک کامپیوتر نصب شده بودند، جا می‌شد. آن موقع اندازه‌ی هارد دیسک‌ها حدود 250 مگابایت بود. اما امروز ما نهان‌گاه‌ها (Cache) را برای نگه‌داری این اطلاعات داریم و این فرصت‌هایی را در کسب و کار ایجاد می‌کند که قبلاً امکان‌پذیر نبود.
فعالیت‌های حرفه‌ای من شامل چیزهای متفاوتی بوده است: مدل‌سازی وسایل نقلیه، کار با فهرست‌های بزرگ، کار با سیستم‌های تجاری. سیستم‌هایی که واقعاً با هم متفاوتند، اما تنظیم کارایی و دستیابی به توان عملیاتی (Throughput) بالا بخشی از اکثر این کارها بوده است.
اسم بلاگ شما درک مکانیکی است، منظورتان از آن چیست؟
درک مکانیکی اصلاح جالبی است. من از طرفداران مسابقات موتورسواری هستم؛ این اصطلاح از آن‌جا نشئت گرفت. Jackie Stewart نام موتورسواری در دهه‌های 60 و 70 است که موتورسوار فوق‌العاده موفقی بود و در زمین‌های مرطوب خیلی خوب عمل می کرد. او در مورد داشتن حس درک مکانیکی با موتوری که سوارش بود صحبت می‌کرد. زمانی که آن وسیله را درک می‌کرد، نسبت به بقیه‌ی موتور سوارها بهتر عمل می‌کرد و این در زمین‌های مرطوب به خوبی نشان داده می‌شد. در یک جمله درک مکانیکی یعنی به کارگیری قابلیت‌ها تا مرز توانایی آن و نه فراتر از آن، تا بهترین نتیجه حاصل شود. برای او درک مکانیکی به معنی هماهنگی در کار کردن با موتورش بود و برای من هم چیزی شبیه به این در سخت‌افزار و نرم‌افزار است. هر زمان که نرم‌افزار نحوه‌ی کارکرد سخت‌افزار و بستر سخت‌افزاری را درک کند، با آن هماهنگ می‌شود و بهترین نتیجه حاصل می‌شود.
امروزه تعداد زیادی از نرم‌افزارها را می‌بینیم که بر خلاف سخت‌افزار عمل می‌کنند و درک خیلی محدودی از آن دارند. در نتیجه نه تنها کارایی پایینی دارند، بلکه ممکن است دچار مشکلات دیگری هم بشوند: چون ابزارها به درستی استفاده نشده‌اند، هنگام رخ دادن شرایط مرزی مشکلات بروز می‌کنند. این به این معنی نیست که شما باید تمام جزئیات را مانند یک فرد خبره بفهمید، تنها دانستن موارد مهم کافی است. مثلاً در مسابقات موتورسواری، لازم نیست بدانم که موتور چطور ساخته شده است، فقط لازم است بدانم چطور کار می‌کند. بنابراین لازم است مفاهیم اساسی نحوه‌ی کارکرد جعبه دنده و سیستم تعلیق را بفهمم. با دانستن این موارد در سطح پایه‌ای می‌توان بهترین نتیجه را گرفت. در نرم‌افزار هم همینطور است.
ادامه مطلب ...

ارائه توسط: Michael Plöd
مترجم: محمد علی بزرگ زاده 1393/04/20
در این اپیزود، Arno با Michael Plöd در ارتباط با Object Relational Mappers یا OR Mappers مصاحبه می‌‌کند.
Michael لطفاً خود را معرفی کنید.
سلام، از اینکه به این مصاحبه SE Radio گوش می‌دهید ممنونم. نام من Michael Plöd است. من برای شرکت Senacor Technologies در نورمبرگ آلمان کار می‌کنم. نقش من توسعه‌دهنده ارشد یا معمار (هر چه اسمش را بگذارید) است. معمولاً بر روی پروژه‌های طولانی‌مدت تر کار می‌کنم. چند سال پیش کار با نگاشت‌گرهای OR را آغار کردم. بیشتر با نگاشت‌گرهای مبتنی بر جاوا از قبیل Hibernate و JDO و امروزه JPA کار کرده‌ام. خوشحال می‌شوم که سئوالات شما را بشنوم و امیدوارم بتوانم به آنها جواب دهم.
بیایید با این سئوال شروع کنیم که نگاشت‌گر OR چیست؟ درباره چیست؟
اساساً نگاشت‌گر OR چیزی است که به مسأله عدم تطابق بین اشیاء با روابط می‌پردازد. بین یک نرم‌افزار شیء‌گرا و پایگاه‌های داده یک عدم تطابق طبیعی وجود دارد. بعنوان مثال اگر به نحوه گروه کردن اشیاء یک حوزه (Domain) در مقابل نحوه تعریف کردن شِمای رابطه‌ای (Schema) نگاه کنید، بوضوح می‌بینید که از یک طرف با کلاس‌ها و خواص (Attribute) کار می‌کنید و نوع‌های داده‌ای دارید که یا مربوط به زبان برنامه‌نویسی است یا انواع داده‌ای است که خودتان داخل زبانی که با آن کار می‌کنید، تعریف می‌کنید. اما در طرف دیگر با جداول و ستون‌ها کار می‌کنید و این چیزها را داخل شِماها، گروه می‌کنید. در یک پایگاه داده رابطه‌ای نیز یک سیستم انواع داده دارید. اما در غالب پایگاه‌های داده این سیستم انواع داده خیلی استاتیک است. البته برخی از پایگاه‌های داده، گونه‌هایی از پشتیبانی انواع‌های داده تعریف شده توسط کاربر را دارند. اما اغلب این پشتیبانی خیلی پیشرفته نیست.
مطلب دیگر، جابجا شدن (Navigation) است. وقتی در گرافی از اشیاء جابجا می‌شوید، در یک نرم‌افزار شیء گرا یا کلاً در نرم‌افزار می‌دانید که چطور از یک موجودیت (Entity) مثلاً موجودیت A به سمت موجودیت B جابجا شوید. اما در طرف دیگر (در پایگاه‌های رابطه‌ای)، جابجایی، جهت ندارد. می‌توانید از جدول مشتریان به جدول صورتحساب‌ها جابجا شوید اما در همان حال می‌توانید از طریق کلید خارجی (Foreign Key) از جدول صوتحساب‌ها به جدول مشتریان هم جابجا شوید. بنابراین می‌بینید که یک مسیر جابجایی وجود ندارد.
بسیار خوب، اما برای دسترسی به داده‌ها، زبان برنامه‌نویسی SQL را دارید. چرا به نگاشت‌گر OR نیاز دارید؟ مزیت استفاده از یک نگاشت‌گر OR بر روی SQL نسبت به استفاده از تکنولوژی‌هایی که برای دسترسی مستقیم به پایگاه داده در زبان‌های برنامه‌نویسی وجود دارد، چیست؟
اساساً از یک نگاشت‌گر OR برای کپسوله کردن پایگاه داده استفاده می‌کنید. خیلی از شرکت‌ها می‌گویند که با استفاده از نگاشت‌گر OR می‌توانید بسادگی بین پایگاه‌های داده مختلف سوییچ کنید. بله، این درست است. اما من می‌گویم که در اکثر پروژه‌های شرکت‌های بزرگ، سوییچ کردن به یک پایگاه داده دیگر، چیز خیلی نادری است. فکر می‌کنم مورد کاربرد و مزیت اصلی استفاده از یک نگاشت‌گر OR این است که توسعه‌دهندگان با اشیاء کار کنند و مقدار زیادی کدهای منطق کسب و کار (Business Logic) ننویسند که اغلب مربوط به پردازش دستورات SQL باشد.
بعلاوه، کتابخانه‌هایی که تعامل با SQL را پیاده‌سازی می‌کنند، خیلی سطح پایین هستند. بعنوان مثال اگر به JDBC، دقت کنید، یک کتابخانه سطح پایین است که در آن با دستورات و ResultSet ها کار می‌کنید و می‌بایست بر روی نتایج حرکت کنید و خیلی از امور مربوط به مدیریت منابع (Resource Management) را انجام دهید. از این منظر، نگاشت‌گر OR کاملاً این چیزها را کپسوله می‌کند. (در آنجا) با فایل‌های XML، یا Annotation ها یا حتی از طریق قراردادهای نامگذاری (Code Convention)، گونه‌هایی از متادیتا را دارید که بوسیله آنها، توضیح می‌دهید که چطور کلاس‌هایتان را به جداول‌ نگاشت می‌کنید و توضیح می‌دهید که چطور ارث‌بری و روابط یا چیزهای دیگر را نگاشت می‌کنید.
ادامه مطلب ...