ارائه توسط: Jonathan Aldrich
مترجم: محمد علی بزرگ زاده 1395/06/12
در این اپیزود، مارکوس ولتر با جاناتان آلدریچ در ارتباط با تکنیک‌ها، مفاهیم و ابزارهای تحلیل ایستای کد صحبت می‌کند. این مصاحبه در حاشیه کنفرانس OOPSLA سال ۲۰۰۶ ضبط شده و در ژوئن ۲۰۰۷ منتشر شده است.
پیش از آنکه در مورد موضوع صحبت کنیم فکر می‌کنم خوب است که خودتان را معرفی کنید و کمی در مورد پیش‌زمینه کاری خود و آنچه در زندگی واقعی‌تان انجام می‌دهید صحبت کنید.
ممنونم. من استادیار دانشگاه کارنگی ملن (CMU) هستم. در آنجا در زمینه تحلیل ایستای زبان‌های برنامه‌نویسی تحقیق می‌کنم و همینطور در این زمینه تدریس دارم. این مباحث [که می‌خواهم در موردش صحبت کنم] هم از خودآموزی است که اینجا در OOPSLA ارائه کردم و هم از برخی کلاس‌هایی که آنجا تدریس داشته‌ام.
بسیار خوب. برای اینکه آغاز کنیم می‌توانیم بخواهیم که توضیح دهید چرا می‌خواهید تحلیل ایستا بکنید و در‌واقع تحلیل ایستا چیست؟ ما را با موضوع آشنا کنید.
من دوست دارم به این شکل به آن بنگرم که تحلیل ایستا روشی برای کاوش کردن روش‌های مختلفی است که برنامه ممکن است اجرا شود که عموماً به یک طریق انتزاعی است. اگر آن را با تست مقایسه کنیم، در تست، برنامه را با تعدادی ورودی‌های معین اجرا می‌کنیم و هدف شما به عنوان تستر‌ این است که برنامه را به روش‌های مختلف زیادی اجرا کنید تا ببینید که چطور کار می‌کند و آیا مطابق با آنچه انتظار دارید عمل می‌کند یا خیر. در این زمینه، تحلیل ایستا دیدگاه دیگری دارد و بجای یک اجرای خاص معین، برنامه را به روش انتزاعی‌تری می‌آزماید و آن را برای شکل‌های عمومی نقیصه‌ها بررسی می‌کند. مزیت کاوش انتزاعی برنامه این است که می‌توانید مشکلات زیادی را بیابید که لزوماً با یک اجرای معین نمی‌توانستید زیرا می‌بایست آن [اجرای معین] را بیابید.
شما باید به این فکر کنید که ورودی‌های درستی را بکار بگیرید تا آن نوع از مشکلات را پوشش دهید.
دقیقاً. درسته.
با تحلیل ایستا چه نوع خطاهایی را می‌توانید بیابید؟ آیا نوع‌های خاصی از خطاها هستند که می‌توانند به سادگی یافت شوند و بقیه اینطور نیستند؟
بازه کاملاً وسیعی از خطاها هست که تحلیل ایستا می‌تواند بیابد. در حال حاضر، آسیب‌پذیری‌های امنیتی (Security Vulnerability) یک مسأله حیاتی برای بسیاری از شرکت‌ها است و مسائلی از قبیل لبریز شدن بافر، ورودی‌های غیرمعتبر و یا فرضاً داده‌های آلوده‌شده (Tainted Data) می‌تواند باشد و یا حمله‌هایی از قبیل SQL Injection و Command Injection و Cross Site Scripting می‌تواند باشد. خطاهای حافظه، یک مشکل رایج دیگر برنامه‌نویسی است که بر روی آسیب‌پذیری تأثیر دارد. چیزهایی از قبیل Null Derefrence یعنی دسترسی به داده‌هایی که مقداردهی اولیه نشده‌اند، همینطور موارد نشتی حافظه (Memory Leak) است که بسیاری از توسعه‌دهنده‌ها با آن دست به گریبانند. اغلب سخت است با استفاده از تست و بازرسی و اینجور چیزها این‌ها را یافت. این‌ها موارد رایج آن است و موارد ممکن زیاد دیگری هم هست که افراد از منظر تحقیقاتی به آن نگاه می‌کنند. چیزهایی از این قبیل که چطور از یک فریم‌ورک یا API استفاده می‌کنید تا مثلاً اینکه به Exception ها و جریان آن‌ها در برنامه نگاه کنیم تا حتی اینکه به مسائل طراحی از قبیل موارد نقض کپسوله‌سازی (Encapsulation Violation) نگاه کنیم و … .
فقط برای اینکه روشن شود، [اشاره می‌کنم که] اینطور تحلیل‌های ایستا شامل قراردادهای کدنویسی (Coding Conventions) نمی‌شود مثلاً اینکه متغیر با حروف بزرگ باشد یا حروف کوچک. و واقعاً در مورد تحلیل معنایی کاری است که برنامه می‌کند و نه چیزهای پیش‌پاافتاده.
در بهترین حالت، بله. افراد می‌توانند از تحلیل ایستا برای اجبار کردن فرمت و قرارداد‌های کدنویسی استفاده کنند. افراد در محیط‌های خاصی که در مورد این قیود، سخت‌گیر هستند از آن استفاده کرده‌اند اما من فکر می‌کنم که ارزش اصلی تحلیل ایستا نگاه کردن به نوعی از مسائل است که افراد در اطمینان یافتن از آن خیلی خوب نیستند. شما می‌توانید بازبینی کد (Code Review) داشته باشید و بسیاری از این مشکلات نگارشی را بیابید اما با بازبینی کد احتمالاً خیلی سخت خواهد بود که نشتی حافظه را بیابیم زیرا برای فهمیدن کدی که بازبینی می‌کنید نیاز به زمینه‌های دیگری دارید، اینکه چه کسی این حافظه را تخصیص داده؟ چه کسی مسئول آزاد کردن آن است؟ شاید به هیچ وجه مسئول آن نباشم و شاید اشکالی نداشته باشد که اجازه بدهم اشاره‌گری مخفیانه پاک شود [اما در غیر اینصورت] من باید زمینه‌های دیگری را بدانم و در موضوع بازبینی کد، یافتن زمینه، سخت‌ترین کار است.
ادامه مطلب ...

ارائه توسط: Dwigth Merriman
مترجم: محمد علی بزرگ زاده 1395/03/14
در این اپیزود که در آوریل ۲۰۱۲ منتشر شده است روبرت بلومن در حاشیه کنفرانسMongoSF با دوآیت مریمن در مورد مبحث رونوشت‌برداری (Replication) صحبت می‌کند. دوآیت مریمن مدیرعامل و از بنیانگذاران 10gen است که هم‌اکنون به شرکت سهامی MongoDB تغییر نام یافته است. این شرکت، مسئولیت پایگاه داده متن‌باز MongoDB را به عهده دارد.
دوآیت، دوباره به SE Radio خوش آمدی.
ممنون.
گفتم دوباره چون دوآیت قبلاً در اپیزود ۱۶۵ که در مورد NoSQL و MongoDB صحبت می‌کردیم مهمان ما بود. امروز با دوآیت در مورد رونوشت‌برداری پایگاه داده صحبت خواهیم کرد. دوآیت، برای شروع به ما بگو که رونوشت‌برداری پایگاه داده چیست؟
مفهوم خیلی ساده‌ای دارد. همانطور که در یک فرهنگ لغت در مورد رونوشت (Replica) آمده است، شما می‌خواهید یک نسخه از داده‌ها بر روی یک ماشین مجزا داشته باشید البته ما به این شکل از نسخه‌برداری عادت داریم که روی یک ماشین و بر روی چندین هارددرایو (یا همان RAID) باشد.
بنابراین رونوشت‌برداری در سطح پایگاه‌های داده‌ به معنای [نسخه‌برداری] روی چندین ماشین است. اینکه مجموعه‌ای از داده‌ها و بیش از یک ماشین داشته باشم و بخواهم که بصورت خودکار داده‌ها با هم همگام (Synched) بمانند.
بسیار خوب، رونوشت‌برداری چه مسأله و یا مسائلی را حل می‌کند؟
به نظر می‌رسد چند مسأله باشد. یکی ایمنی داده‌ها (Data Safety) است. اگر داده‌ها را بر روی چند ماشین داشته باشم نسبت به حالتی که یک ماشین باشد، امن‌تر است. اگر بر روی یک ماشین باشد و آب‌پاش‌های روی آنها شروع به فعالیت کنند حتی اگر بر روی آن ماشین درایوهای همانند (Mirror Drives) داشته باشید، برنامه، داده‌ها را از دست می‌دهد. بنابراین ایمنی داده‌ها بهبود می‌یابد. به علاوه، می‌توانید از آن برای ترمیم یافتن از سانحه (Disaster Recovery) استفاده کنید. از نظر ایمنی داده‌ها حتی بهتر است که یکی از رونوشت‌ها در محل جغرافیایی یا مرکز داده متفاوتی قرار گرفته باشد تا اگر سروری در آتش سوخت همچنان از داده‌ها ک‍پی داشته باشیم.
[رونوشت‌‌برداری] همچنین برای دسترس‌پذیری بالا (High Avalibility) هم خوب است که کمی متفاوت [با ایمنی] است. درصورتیکه ماشین خاموش شود و بعداً دوباره روشن شود و داده‌ها همچنان باقی باشد داده‌های من امن است با این حال در دسترس نیست. اما با داشتن چندین سرور، می‌توانیم دسترس‌پذیری داده‌ها را افزایش دهیم که اهمیت دارد.
در نهایت، فکر می‌کنم افراد از آن [رونوشت‌برداری] برای بزرگ کردن مقیاس هم استفاده می‌کنند. رونوشت‌برداری راه‌حل کاملی برای مقیاس‌پذیری نیست. به نظر من بیشتر راه‌حلی برای ایمنی و دسترس‌پذیری بالا است. اما می‌توانید با آن تا حدی، مقیاس‌پذیری برای عملیات‌‌های مربوط به خواندن را بدست آورید. در‌واقع من فکر می‌کنم تکنیک‌های دیگر از قبیل پارتیشن کردن یا چندپاره کردن (Sharding) داده‌ها راه‌حل‌های عمومی‌‌شده‌تری نسبت به رونوشت‌برداری برای مقیاس‌پذیری هستند.
آیا از رونوشت‌برداری برای این هم استفاده می‌شود که بخواهید داده‌های قرارگرفته بر روی رونوشت‌ها را به دلایلی به شکل دیگری تبدیل کنید؟
به نوعی بله. البته می‌توانید مستقیماً داده‌ها را از مبدأ خوانده، تبدیل را انجام دهید و در جای دیگری بنویسید اما فکر می‌کنم گاهی افراد رونوشتی دارند که نسبت به نسخه اصلی، کار متفاوتی بر روی آن دارند. ممکن است وظیفه‌های دسته‌ای (Batch Job) بزرگی بر روی نسخ فرعی داشته باشید بنابراین چنین الگویی مطرح می‌شود.
یعنی مشخصه‌های تأخیری متفاوتی در ارتباط با جریان کاری یکسانی دارید؟
بله، یکی از کارهایی که افراد انجام می‌دهند این است که رونوشت‌هایی در محل‌های مختلف جغرافیایی تهیه می‌کنند تا یک کپی از داده‌ها را در نزدیکی مشتری داشته باشند. این یک دلیل دیگر برای داشتن رونوشت است.
شما گفتید که رونوشت‌برداری، راه‌حل کاملی برای مقیاس‌پذیری نیست. ممکن است بیشتر توضیح دهید که منظورتان چیست؟
قطعاً. اول از همه موضوع «نوشتن‌ها» است. رونوشت‌برداری کمکی به مقیاس‌پذیری نوشتن‌ها نمی‌کند. فرض کنید که می‌خواهید سند یا رکورد جدیدی را در پایگاه داده‌ای که مثلاً n رونوشت دارد بنویسید. شما آن نوشتن را بر روی همه رونوشت‌ها انجام می‌دهید. بنابراین در واقع مقیاس‌پذیری بدست نمی‌آوریم چون داریم n بار می‌نویسیم. بنابراین بیشتر برای مقیاس‌پذیری خواندن‌ها مفید است به این ترتیب که اگر n ماشین داشته باشیم که همگی یک رونوشت از داده‌ها را داشته باشند و هرکدام ظرفیت مشخصی داشته باشند باید بتوانیم از لحاظ تعداد خواندن‌های در ثانیه، n برابر ظرفیت بدست آوریم اما میزان افزایش مقیاسی که به این روش می‌توانید داشته باشید محدود است. یکی از این محدودیت‌ها این است که باید نوشتن‌ را در همه این جاها انجام دهید. اگر ۱۰۰ رونوشت داشته باشید به نسبت ناکارآمد می‌شود که بخواهید همه نوشتن‌ها را ۱۰۰ بار انجام دهید. اگر نوشتن‌ها خیلی خیلی نادر باشد ممکن است اشکالی نداشته باشد اما اگر بازاء هر ۳ خواندن یک نوشتن داشته باشید، خیلی منطقی نیست که فقط برای اینکه خواندن‌ها مقیاس‌پذیر شود، نوشتن‌ها را ۱۰۰ مرتبه انجام دهید.
ادامه مطلب ...

ارائه توسط: Simon Brown
مترجم: محمد علی بزرگ زاده 1395/03/02
در این اپیزود که در ژوئن ۲۰۱۵ منتشر شده است، سوئن جوهان با سیمون براون مصاحبه می‌کند. سیمون براون یک مشاور و مدرس مستقل و خالق مدل معماری نرم‌افزار C4 است. او همچنین کتاب Software Architecture for Developers را نوشته است.
چطوری سیمون؟
خوبم. ممنون. و شما؟
من هم خیلی خوبم. چیزی هست که بخواهی به معرفی‌ات اضافه کنی؟
نه، همانطوری که گفتی من یک مشاور مستقل هستم. پیش‌زمینه من در مشاوره و تولید نرم‌افزار، بیشتر در لندن و بیشتر به جاوا و برای بانک‌ها است. اما طی چند سال گذشته کارم مشاوره، تدریس و کمک به تیم‌ها بوده است که فرابگیرند که معماری نرم‌افزار چیست و چگونه می‌توانند آن را با روش‌های چابک (Agile) سبک ترکیب کنند.
شما طرح کشیدن (Sketching) را به عنوان روش مؤثری برای تولید و انتقال معماری نرم‌افزار مطرح کرده‌اید. اول اینکه چرا معماری نرم‌افزار را منتقل کنیم؟
اگر به ۱۰-۲۰ سال قبل برگردید، ما مراسم خیلی پرفرآیند و پرمستنداتی برای طراحی کردن داشتیم به این ترتیب که اول همه نیازمندی‌ها را استخراج می‌کردیم، بعد همه طراحی‌ها را انجام می‌دادیم و همه آن طراحی‌های زیاد را مجبور بودیم که مستند کنیم. بعد UML آمد و همه، ابزارهای UML و مدل‌سازی را خریدند و ماه‌ها و ماه‌ها فقط برای طراحی کردن صرف کردند. حال اگر از این ۲۰ سال با سرعت رد شویم، می‌بینیم الان از آن منتها به منتهای دیگر رسیده‌ایم. الان اغلب تیم‌ها اساساً هیچ کاری نمی‌کنند. کاری که من دارم می‌کنم این است که سعی می‌کنم که زبانه را به نقطه‌ای در این بین برگردانم.
ما دوره‌ی از پیش خیلی زیاد طراحی کردن را داشته‌ایم و بعد، از پیش اصلاً طراحی نکردن را داشته‌ایم و حال شما تلاش می‌کنید که به مقدار کافی آن برسید.
بله، البته [رهیافت‌های] چابک (Agile) نمی‌گویند که طراحی نکنید اما تعبیر خیلی از افراد از آنچه رهیافت‌ها و مانیفست چابک می‌گوید، این است. بنابراین من تلاش می‌کنم که افراد دوباره به طراحی فکر کنند و سعی می‌کنم بینش و مکانیزم خوبی فراهم کنم که افراد بتوانند استفاده کنند تا ایده‌ها را به اشتراک بگذارند چون بهرحال شما ایده شگرفی برای سیستم نرم‌افزاری دارید و نیاز است که تیم آن را بفهمد، همه مقصود از طرح کشیدن در‌واقع همین است.
بنابراین ذینفعان معماری، تیم [توسعه] است.
درسته، ما توسعه‌دهنده‌های نرم‌افزار بزرگترین ذینفعان معماری نرم‌افزار هستیم. بنابراین برای مثال در مورد طرح کشیدن، این‌ها مخاطبین اصلی در صحبت‌های من هستند.
بسیار خوب، مزایای این طرح‌ها (Sketch) چیست؟
قادر می‌سازد که تصویری که از طراحی یا معماری که می‌خواهیم بسازیم را منتقل کرده و به اشتراک بگذاریم. نکته طرح‌ها این است که سبک هستند. آنچه من تلاش می‌کنم این است که از رسیدن به یک فرآیند برآمده از مدل بزرگ طراحی از پیش، اجتناب کنم که مجبور باشیم به چیزهای خیلی زیادی فکر کنیم. [طر‌ح‌ها] در اینباره است که خیلی سریع عمده ایده‌ها را به روشی که در دسترس توسعه دهندگان باشد، انجام دهیم.
بنابراین اشکالی ندارد که [برخی] چیزها بیرون بیافتند. بهتر است که کامل نباشیم اما سبک باشیم.
درسته، ما قطعاً اینجا خصوصاً در مورد انتزاع‌های سطح بالا، به دنبال ریزبینی هستیم اما آنچه نمی‌خواهم انجام دهم این است که این کار را در مورد جزئیاتِ در سطح کلاس‌ها داشته باشم. بنابراین اگر افراد برای نمودارهای کلاسی، طرح بکشند شاید باید بپرسیم که چرا اینکار را می‌کنند یا چه ارزشی ایجاد می‌کنند؟
طرح‌ها، فرموله نشده‌اند بنابراین شاید راه‌های خیلی خیلی زیادی وجود داشته باشد که بتوانم یک طرحی بکشم که ناکارا باشد. یک طرح بد یا ناکارا کدامست؟
در این مورد پاسخ‌های زیادی وجود دارد. بخشی از کارگاه من این است که از افراد می‌خواهم که راه حلی طراحی کرده و تصاویری بکشند. من هرگز هیچ راهنمایی به آن‌ها نمی‌کنم و می‌توانم بگویم شاید ۹۰٪ طرح‌ها ناکارا می‌شود. به چندین دلیل ناکارا هستند. فکر می‌کنم اولینش به خاطر نمادگذاری‌ها (Notation) باشد. افراد به استفاده از UML گرایش ندارند اما UML نمادگذاری فرموله استاندارد است. وقتی از UML استفاده نمی‌کنند به ناچار، انتزاع خود از نمادگذاری‌ها را ابداع می‌کنند و همانطور که می‌توانید تصور کنید این منجر به سردرگمی‌های زیادی می‌شود.
ادامه مطلب ...