ارائه توسط: Michael Nygard
مترجم: محمد علی بزرگ زاده 1395/11/15
در این اپیزود که در ماه مِی ۲۰۰۹ منتشر شده است درباره یک کتاب بسیار محبوب در حوزه مهندسی نرم‌افزار با عنوان Release It صحبت می‌شود. مهمان این برنامه، نویسنده این کتاب مایکل ناگارد است.
سلام مایکل.
سلام. خیلی خوشحالم که اینجا هستم.
ما خوشحالیم که توانستیم با شما جلسه داشته باشیم. خوب، اولین سئوال روشنی که وجود دارد این است که لطفاً در مورد خودتان صحبت کنید تا مخاطبان‌مان شما را بشناسند.
حتماً. من تا الان نزدیک به ۲۰ سال است که یک معمار و توسعه‌دهنده برنامه‌های نرم‌افزاری هستم. من در حوزه‌های خیلی زیادی شامل نظامی، علمی، مهندسی، صنعتی، آموزشی و مالی فعال بوده‌ام و در ۱۰ سال گذشته کارهای زیادی در حوزه خرده‌فروشی داشته‌ام. ۵ سال قبل، طی یک شرایط عجیبی که پیش آمد در نهایت به گروهی پیوستم که کار عملیات را برای نرم‌افزاری می‌کردند که ما ننوشته بودیم. بنابراین من که همیشه نرم‌‌افزار خودم را عملیاتی می‌کردم حال باید مسئولیت نرم‌افزاری که دیگر افراد توسعه داده بودند را هم می‌پذیرفتم.
بنابراین دردش را چشیدید!
دقیقاً.
:) این خودش کمی مقدمه‌ای شد که در واقع چه شد که کتاب را نوشتید. لطفاً یک نمای کلی مثلاً از ارتفاع ۳۰۰۰ کیلومتری، از کتاب به ما بدهید. خیلی‌ها احتمالاً آن را می‌شناسند. در‌واقع به طور خاص از ما درخواست شده بود که شما را دعوت کنیم، حداقل آن افراد کتاب را می‌شناسند. لطفاً از منظر خیلی کلی‌اش بگویید که کتاب شامل چه چیزهایی است و چه شد که آن را نوشتید.
آنچه که از تحویل گرفتن نرم‌افزارها تا عملیاتی کردن آن‌ها -و اینکه فردی باشم که وقتی‌که نرم‌افزارها کار نمی‌کردند ساعت ۳ صبح صدا زده می‌شدم- آموختم این است که نوع نرم‌افزار‌هایی که ما می‌سازیم برای زندگی در دنیای واقعی آنقدرها مناسب نیستند. آنچه در نهایت اهمیت دارد، دنیای واقعی عملیاتی است. و من به این نتیجه رسیدم که همه کارهایی که در زمان معماری و طراحی می‌کنیم همگی به هدف پذیرفته شدن در QA است. همگی به این هدف است که نیازمندی‌های عمل‌کردی (Functional) را برآورده کنند اما به هدف زنده ماندن در محیط عملیاتی نیستند. برای من مانند این است که دنیا آمدن بچه را هدف بگیریم اما هیچ آمادگی برای زندگی آن بچه بعد از تولدش به عنوان یک انسان، نداشته باشیم.
بله. بنابراین کتاب در این مورد است که چطور نرم‌افزار را به روشی بنویسیم که افراد عملیات از آن خوشحال شوند. این اولین فرض است که کمی بیش از حد کم‌دامنه است.
این قطعاً یک طریقه خواندن این کتاب است. اما البته تنها بحث افراد عملیات نیست. حامیان مالی و افرادی که برای نرم‌افزار ما پول می‌دهند واقعاً به این موضوع خیلی بیشتر علاقه‌مندند که نرم‌افزار در محیط عملیاتی چگونه کار می‌کند تا اینکه چطور از QA پذیرفته شده است. می‌توانید QA و اولین تست رگرسیون را قهرمانانه موفق شوید اما اگر در محیط عملیاتی اجرا نشود در نهایت، کسی اهمیت نمی‌دهد.
بسیار خوب. حال اگر بخواهیم از ارتفاع ۳۰۰۰ کیلومتری مثلاً تا ۲۰۰۰ کیلومتر پایین بیاییم، اگر ساختار کتاب و از این رو ساختار این موضوع در فضای کلی مسأله را در نظر بگیریم [چگونه بیانش می‌کنید] مثلاً در چند بخش که بخواهید در ادامه بحث توضیح‌شان دهید به آن ساختار بدهید.
من [مطالب] کتاب را بر اساس درجه اهمیت، ترتیب دادم و سعی کردم اول به بدترین مشکلات بپردازم. به همین خاطر اولین بخش کتاب در مورد پایداری (Stability) است چون اگر نرم‌افزارتان در محیط عملیاتی، پایدار نباشد اهمیتی ندارد که چه کاری می‌کند یا در آینده قرار است چه تغییری کند. بنابراین بخش اول کتاب در مورد پایداری است. و در هر بخش از کتاب، من یک مطالعه موردی را آورده‌ام. به من گفته شده که آن‌ها مانند داستان‌های کارآگاهی خوانده می‌شوند که به نوعی همان چیزی است که مدنظر من بوده است که باید یک بیان اول شخص از یک مثال دنیای واقعی ازچیزهایی باشد که در شرکت‌های واقعی رخ می‌دهد هرچند به دلایلی که واضح است همه نام‌ها، بدلی هستند.
برای اینکه نمایی از ادامه این اپیزود فراهم کنیم، بعد از پایداری چه چیزی را داریم؟
بعد از پایداری، یک فصل در مورد ظرفیت (Capacity) داریم چون بعد از آنکه سیستم‌تان را پایدار کردید، بزرگترین شکایت بعدی که دیده‌ام این بوده است که «به مقدار کافی کارا نیست چون نمی‌تواند کاربران همزمان را رسیدگی کند». اینجا هم یک مطالعه موردی آورده‌ام و تعدادی ضدالگو (Anti-Pattern) دارم. مورد متداولی که دیده‌ام افراد انجام می‌دهند این است که ظرفیت‌شان را آسیب می‌رسانند. من الگوهایی را [معرفی کرده‌ام] که می‌توانید حتی روی همان زیرساختی که به شما داده شده است، برای بهبود ظرفیت بکار ببرید. بنابراین من بطور خاص مقیاس‌پذیری (Scalability) را اشاره نمی‌کنم که به معنای قابلیت اضافه کردن منابع بیشتر است بلکه به بیشینه کردن ارزش منابعی که دارید اشاره می‌کنم.
ادامه مطلب ...

ارائه توسط: Martin Fowler and Pramod Sadalage
مترجم: محمد علی بزرگ زاده 1395/10/17
میهمانان این برنامه پرامود سدالگه و مارتین فاولر هستند. در این اپیزود، در مورد تکامل پایگاه داده (Database Evolution) و توسعه چابک پایگاه داده صحبت می‌شود. همچنین در مورد چالش‌های اصلی در کار با پایگاه‌های داده در یک فرهنگ توسعه چابک صحبت می‌شود و اینکه طراحی پایگاه داده و مهم‌تر از همه، تکامل آن را چطور می‌توان در چرخه‌های اغلب کوتاهی جای داد که در روش‌های پیشرفته توسعه نرم‌افزار وجود دارد. همینطور در مورد یکپارچه‌سازی مستمر تغییرات کد مرتبط با پایگاه داده با استفاده از اسکریپت‌های تغییر شِمای پایگاه داده، استفاده از چندین شِما برای غلبه بر استقرار متمرکز تیم‌های توسعه، چگونگی مهاجرت دادن داده‌ها در گام‌های افزایشی و ابزارهایی که می‌توانند در این محیط‌های چابک استفاده شوند صحبت می‌شود.
لطفاً خودتان را معرفی کنید.
مارتین: من مارتین فاولر هستم. یک نویسنده و سخنران پُرسر و صدا در مهندسی نرم‌افزار هستم.
پرامود: من پرامود سدالگه هستم. همانطور که مارتین گفت من خیلی به مهندسی نرم‌افزار علاقه‌مندم. من خاصه مبحث داده‌ها در هر نوع برنامه‌ای را دوست دارم و شِمای پایگاه داده (Schema) مانند NoSQL و چیزهای از این قبیل را علاقه‌مندم. فکر می‌کنم امروزه، امر داده‌ها نقش مهمی در چرخه توسعه نرم‌افزار دارد.
بسیار خوب. اجازه دهید در مورد بحث امروزمان یعنی تکامل پایگاه داده صحبت کنیم. شما از تکامل پایگاه داده دقیقاً منظورتان چیست؟
پرامود: همچنانکه نرم‌افزار تکامل می‌یابد [داده‌ها هم تکامل می‌یابند] و البته نرم‌افزار به این جهت تکامل می‌یابد که کسب و کار تکامل پیدا می‌کند. کسب و کار در‌واقع تلاش می‌کند که به اجبارهای بازار واکنش دهد یا تلاش می‌کند که راه جدیدی برای کارش بیابد. این شاید مربوط به فرآیند باشد، شاید مربوط به محصولات جدیدتر باشد و یا شاید مربوط به راه‌های جدید‌تری برای انجام کارها باشد. اما همانطور که روش‌های جدیدتری برای انجام کارها مطرح می‌شود، نرم‌افزار باید تکامل یابد. این بدان معناست که پایگاه داده‌ای که نرم‌افزار از آن استفاده می‌کند هم باید تکامل یابد. مثلاً می‌تواند مانند این باشد که قبلاً کتاب می‌فروخته‌ام و الان می‌خواهم ریش‌تراش یا چیز دیگری بفروشم. بهرحال نرم‌افزار تغییر می‌کند و وقتی نرم‌افزار تغییر می‌کند آنچه در پایگاه داده ذخیره می‌کند و آنچه از پایگاه داده بازیابی می‌کند و هرچیز دیگری که از پایگاه داده بخواهید هم تغییر می‌کند. یعنی ساختار پایگاه داده و طراحی پایگاه داده باید تغییر کند. این می‌تواند بر چند چیز دلالت داشته باشد. مثلاً قبل از این ۵۰ کاربر را پشتیبانی می‌کرده‌ام و الان نیاز دارم که ۵ میلیون کاربر را پشتیبانی کنم. این می‌تواند امور مربوط به پایگاه داده را تغییر دهد یا می‌تواند علاوه بر آن فرآیندهای کسب و کار متفاوتی را هم منجر شود. بنابراین همه این‌ها ایده تکامل پایگاه داده را در برمی‌گیرد. همانطور که گفتم از آنجاییکه نیازمندی‌ها تغییر می‌کند، بنابراین تکامل پایگاه داده هم رخ می‌دهد.
نکته خوب این است که ما در مورد تکامل خود سیستم‌های پایگاه‌های داده صحبت نمی‌کنیم مثلاً اینکه MySQL چطور در طی زمان تکامل یافته است. ما در مورد تکامل نرم‌افزاری که از یک پایگاه داده استفاده می‌کند صحبت می‌کنیم و اینکه پایگاه داده و یا شِمای (Schema) آن تغییر می‌کند. بیشتر شِمای آن و یا داده‌های آن در طی زمان تغییر می‌کند.
مارتین: بله. و من آن را خیلی مرتبط با تغییر نحوه‌ی تفکرمان به توسعه نرم‌افزار می‌بینم. از این جهت که ما این دیدگاه را داشتیم که تنها راه معقولانه ساختن نرم‌افزار این است که قبل ازکار ساختمان آن، طراحی‌اش را درآوریم و بعد، آن ساختمان را به طراحی نگاشت دهیم. اما آنچه افرادی مانند من و کلاً جنبش چابک (Agile Movement) از آن حمایت می‌کند این است که باید فرآیند مستمرتری داشته باشیم و نیاز داریم که بتوانیم تغییرات را هم رسیدگی کنیم. وقتی ما رویه چابک را در روزهای اولیه آن آغاز کردیم که به حدود سال ۲۰۰۰ برمی‌گردد یکی از مباحثه‌ها این بود که: آیا واقعاً می‌توانیم آن را بر روی یک سیستم پایگاه داده‌ی رابطه‌ای اجرا کنیم؟ در این زمینه، پرامود نقش بارزی داشته است، نه تنها از این نظر که نشان دهد که این کار را می‌شود کرد بلکه در‌واقع آن را در یک پروژه بزرگ‌مقیاس، انجام داده است. و این یک گام خیلی قابل توجهی است چون خیلی از پروژه‌ها مبتنی بر رسیدگی به حجم زیادی از داده‌های ذخیره‌شده در پایگاه‌های رابطه‌ای هستند. بنابراین مجبورید که بفهمید چطور آن پایگاه داده را تکامل دهید. و این از تکامل کد، پیچیده‌تر است چون نه تنها باید تغییرات ساختاری در پایگاه داده بدهید بلکه باید در این مورد هم تصمیم بگیرید که با داده‌ها چه کنید. چون نمی‌توانید مانند کاری که در مورد طراحی کدها می‌کنید، داده‌ها را دور بریزید و آن‌ها را دوباره بسازید. در‌واقع باید به این هم فکر کنید که چطور داده‌ها را مهاجرت دهید.
فکر می‌کنید در رسیدگی به داده‌ها به یک روش چابک و تکاملی، مهمترین مطلب چیست؟
پرامود: چیزهای زیادی هست مثلاً چیزهای کوچکی از قبیل یکپارچه‌سازی مستمر (Continuous Integration) وجود دارد که چطور جنبه پایگاه داده‌اش را فراهم می‌کنید. مورد دیگر، انشعاب دادن (Branching) است؛ اینکه در انشعاب چه رخ می‌دهد و چطور کدها را مهاجرت می‌دهید، نه فقط کدهای برنامه بلکه کدهای پایگاه داده را چطور مهاجرت می‌دهید. اینکه کدام نسخه درست است و بهرحال نسخه‌بندی یک مشکل بزرگ است. جنبه دیگر این است که آیا می‌توانید به افراد، یک Sandbox بدهید؟ آیا می‌توانید خودکارسازی کنید؟ چون در توسعه نرم‌افزار افراد نمونه‌های دیگری از برنامه را بر روی ماشین خودشان بالا می‌آورند. آیا می‌توانید این کار را با پایگاه داده بکنید؟ چطور می‌توانید این کار را خیلی ساده بکنید؟ خصوصاً برای توسعه‌دهنده‌ها، آیا می‌توانید تنظیماتی داشته باشید که افراد بتوانند نمونه‌های خود را سریع اجرا کنند. مخصوصاً در یک سناریوی تست واحد (Unit Test) آیا می‌توانید بدون هزینه خیلی زیاد، برای خودتان آغاز کنید و تست واحدتان را انجام داده و همه چیزهای [تولیدشده در جریان تست] را دور بریزید و دوباره از نو آغاز کنید؟ و چطور همه این‌ها را داخل یک چرخه یکپارچه‌سازی مستمر قرار می‌دهید؟
این‌ها اغلب مربوط به جنبه توسعه‌ آن می‌شود اما اگر در زنجیره پیش‌تر بروید [مشکلات دیگری هم مطرح می‌شود مثلاً می‌دانیم] نیازمندی‌ها و ویژگی‌های جدید به شکل مدام، مستقر می‌شود. حال چطور محیط QA را در حالت خوبی نگه داریم که تنها ویژگی‌های جدید و تغییرات جدید در پایگاه داده به آن‌ها داده شود اما با [اعمال] آن‌ها، تست‌های موجود بهم نریزد؟ بهمین ترتیب، چطور می‌خواهید آن را به محیط عملیاتی ببرید؟ وقتی رشته مدامی از تغییرات دارید، چطور بدون اینکه دسترس‌پذیری سیستم را تحت تأثیر قرار دهید، آن را مستقر می‌کنید؟ چطور این کار را می‌کنید بدون اینکه داده‌های واقعی موجود در پایگاه داده را تحت تأثیر قرار دهید از این جهت که با کارهای اشتباه آن را خراب نکنید؟ وقتی رشته مدامی از تغییرات دارید همه این چیزها مطرح می‌شود.
ادامه مطلب ...

ارائه توسط: Steve McConnel
مترجم: سید مرتضی هاشمی 1395/10/02
در این برنامه که در نوامبر ۲۰۱۶ منتشر شده است، سوِن یوهان با استیو مک‌کانل درباره‌ی برآورد نرم‌افزار (Software Estimation) صحبت می‌کند. از جمله مباحثی که مطرح می‌شود می‌توانیم به این موارد اشاره کنیم: چرا و چه وقت کسب‌وکارها به برآورد نیاز دارند یا چه وقت ندارند؟ تبدیل برآورد‌ها به طرح‌ریزی و سنجش پیشرفت بر اساس این طرح‌ریزی به چه نحوی است؟ چرا برآورد‌های نرم‌افزار همواره مملو از عدم قطعیت است؟ این عدم قطعیت‌ها چه هستند و چه‌طور با آن‌ها روبرو شویم؟
من سوِن یوهان هستم و امروز استیو مک‌کانل مهمان من است. استیو مدیر ارشد اجرایی و مهندس ارشد نرم‌افزار در شرکت نرم‌افزاری Construx است؛ او مؤلف Code Complete ، Rapid Development و بسیاری کتاب‌های دیگر است. او در سال ۲۰۰۶ کتابی در مورد برآورد نرم‌افزار منتشر کرد. همچنین به عنوان سردبیر مجله مهندسی نرم‌افزار IEEE فعالیت کرده است. من امروز با استیو درباره‌ی برآورد هزینه‌ی نرم‌افزار صحبت می‌کنم. استیو به برنامه خوش آمدی!
متشکرم که مرا دعوت کردید.
آیا چیز مهمی را در معرفی شما فراموش کردم؟
نه فکر می‌کنم، تقریباً به طور کامل توضیح دادید.
خوب. یک برآورد چیست؟
فکر می‌کنم وقتی سوال می‌کنیم که برآورد چیست، باید میان نحوه‌ی استفاده‌ی عمومی افراد -که در بسیاری از موارد ناسالم و غیرسازنده است- و آنچه‌که یک برآورد واقعاً هست، تمایز قائل شویم؛ هم از لحاظ تعریف کتابی و هم از لحاظ نحوه‌ی درست صحبت کردن در مورد برآورد. فکر کنم اگر به تعریف برآورد در واژه‌نامه نگاه کنید، برآورد یک پیش‌بینی آماری از مدت زمان انجام یک کار، یا هزینه‌ی آن، و یا این‌ که چه تعداد ویژگی را می‌توان در یک زمان مشخص تحویل داد است. بنابراین مفهوم مورد نظر در اینجا پیش‌بینی است. تعریف واژه‌نامه‌ای معمولاً مفهومی از تقریبی، تجربی و مقدماتی بودن یا چیزی شبیه به آن را نیز مطرح می‌کند. بنابراین در واقع ما درباره‌ی یک تصویر مقدماتی یا پیش‌گویی تجربی یا همچنین چیزی صحبت می‌کنیم. فکر می‌کنم این درست باشد. این بهترین و سازنده‌ترین روش فکر کردن به آن در نرم‌افزار است.
در عمل آن‌چه فهمیدیم این است که افراد در هر دو سوی تصمیمات فنی و کسب‌وکار، قطعاً گرایش دارند که از کلمه‌ی برآورد به معنی پیش‌گویی آماری استفاده کنند؛ اما از آن به معنی تعهد هم استفاده می‌کنند. یعنی افراد کسب‌وکار می‌پرسند به برآورد شما این کار چقدر طول می‌کشد؟ افراد فنی هم می‌گویند فکر می‌کنیم تا فلان تاریخ طول بکشد. در این لحظه تاریخ مورد نظر تبدیل به تعهدی به کسب‌وکار می‌شود؛ این کمی فراتر از برآورد می‌رود. فکر می‌کنم استفاده از این کلمه علاوه بر اشاره برآورد و تعهد، برای اشاره به اهداف هم استفاده می‌شود. مثلاً طرف کسب‌وکار ممکن است بگوید ما واقعاً دوست داریم که این کار تا فلان تاریخ تمام شود و در حین گفتگو ما به نحوی کلمات برآورد و تعهد را تلفیق می‌کنیم. این منجر به انواع مشکلات می‌شود که می‌توانیم در صورت نیاز در مورد آن‌ها صحبت کنیم؛ اما فکر می‌کنم برای کوتاه کردن سخن اگر بتوانیم در گفتگوهایمان و یا حداقل در ذهن‌مان میان برآورد‌ها، تعهدات و اهداف تمایز قائل شویم -حداقل در جنبه‌ی فنی معادله- خودمان را برای داشتن گفتگوهای بسیار سازنده‌تری درباره‌ی برآورد آماده کرده‌ایم. ما ارزش بسیاری در صِرفِ روشن کردن این مفهوم دیده‌ایم. چون روشن کردن مفهوم، منجر به روشن شدن فعالیت هم می‌شود. بنابراین می‌دانیم کِی برآورد می‌کنیم، کِی درباره‌ی یک هدف صحبت می‌کنیم، و کِی تعهد می‌دهیم. روشن کردن این کلمات در حقیقت به ما کمک می‌کند تا از دادن تعهد درحالی که فکر می‌کنیم صرفاً برآورد می‌کنیم، دوری کنیم.
تعهد، هدف و برآورد. رئیس من از من یک برآورد خواست اما در واقع می‌خواست به هدفی برسد و از ما تعهدی برای رسیدن به هدف بگیرد. آیا این بازگویی از زبان من درست است؟ :-)
فکر می‌کنم درست باشد. فکر می‌کنم روش سازنده‌ای برای فکر کردن به آن است. یعنی [تشریح] کامل آن این است که کسب‌وکار چیزی در ذهن دارد که فکر می‌کند به درد کسب‌وکار می‌خورد. این هدف است. معمولاً کسب‌وکار می‌پرسد چه برآوردی از این کار دارید؟ فکر می‌کنید چه تعداد ویژگی می‌توانید تا فلان تاریخ تحویل دهید؟ بنابراین آن‌چه که کسب‌وکار طبیعتاً فکر می‌کند این است که آن‌چه که امیدوار بودیم به آن دست پیدا کنیم، صد درصدِ آن‌چیزی است که در ذهنمان بود. عموماً این‌طور است که افراد خوش‌بین هستند. افراد فنی می‌روند و کار واقعیِ برآورد کردن را انجام می‌دهند که من در واقع به آن برآورد می‌گویم. و عموماً برمی‌گردند و همان‌طور که از نام خوش‌بینی پیداست متوجه می‌شوند در واقع هدف کسب‌وکار [در زمان] مورد نظر قابل دست‌یابی نیست؛ [هدف] خیلی خوش‌بینانه بود. توانایی حقیقی سازمان برای تحویل آن کافی نیست. اتفاقی که در اینجا رخ می‌دهد این است که ما از برآورد استفاده می‌کنیم تا بفهمیم توانایی ما در رسیدن به یک هدف و این‌که به آن متعهد شویم مقعول است یا خیر. برآورد در واقع به ما کمک می‌کند تعیین کنیم که این تعهدی است که «احتمالاً» به آن دست می‌یابیم یا این تعهدی است که «احتمالاً» نمی‌توانیم زیر بار آن برویم. اما مفهومی از بی‌ثباتی و احتمال در هر برآورد واقع‌بینانه وجود دارد. بنابراین در هر برآورد واقع‌بینانه درجه‌ای از انعطاف‌پذیری وجود دارد. وقتی می‌گوییم برآورد، حاکی از احتمال برآورده شدن تعهد است، برآورد آن را تضمین نمی‌کند. در عوض می‌گوید که فرصت خیلی خوبی برای برآوردن تعهد داریم یا این‌که امکان تلاش کردن برای آن را داریم یا این‌که هیچ شانسی برای عمل به تعهد نداریم و در نتیجه احتمالاً از همان ابتدا نباید زیر بار آن برویم.
ادامه مطلب ...