ارائه توسط: Seven Johann, Eberhard Wolff
مترجم: سید مرتضی هاشمی 1395/09/12
در این اپیزود که در آوریل ۲۰۱۵ منتشر شده است، سوِن یوهان و ابرهارد ولف در مورد بدهی فنی (Technical Debt) صحبت می‌کنند. آن‌ها در نوشتن مقاله‌ای در مورد بدهی فنی با هم همکاری کرده‌اند. این اپیزود به شکل مصاحبه نیست بلکه سوِن و ابرهارد با هم بحث را پیش می‌برند.
سوِن، چند کلمه در مورد خودت به ما بگو.
اسم من سوِن یوهان است و به عنوان توسعه‌دهنده‌ی نرم‌افزار در Trifork در آمستردام کار می‌کنم. همچنین دست‌اندرکار کنفرانس‌های GOTO هستم و خوشحالم که میزبان ریزسرویس‌ها در جلسه‌ی آمستردام هستم.
بله، خیلی جالب به نظر می‌رسد. من ابرهارد ولف هستم. من مستقل کار می‌کنم (Freelance). همچنین رئیس هیأت مشاوره‌ی فناوری در Adesso AG هستم. من در کنفرانس‌ها (اکثراً در آلمان) سخنران هستم و اخیراً کتابی در مورد تحویل مستمر نوشتم. همچنین دست‌اندرکار کنفرانس‌های GOTO و چند کنفرانس دیگر هستم.
اجازه بدهید به موضوع بپردازیم. بدهی فنی به وضوح با کیفیت نرم‌افزار ارتباط دارد. بنابراین قبل از این‌که وارد عمق بحث بدهی فنی بشویم باید در مورد کیفیت صحبت کنیم. وقتی در مورد کیفیت صحبت می‌کنید، انواع مختلفی از کیفیت وجود دارد. یک نوع از آن کیفیت خارجی است. این کیفیتی است که می‌تواند توسط کاربر یا مشتری مشاهده شود. ممکن است کارایی، امنیت، مقیاس‌پذیری، پایداری و ... باشد. [این نوع کیفیت] می‌تواند توسط کاربر اندازه‌گیری و مورد آزمایش قرار بگیرد؛ چون ویژگی‌ای از محصول است. چیزی است که باید توسط مالک محصول یا افرادِ حوزه‌ی کسب و کار مدیریت شود. چون آن‌ها هستند که به کیفیت و چگونگی دریافت آن توسط مشتری علاقه‌مند هستند. مثل خریدن یک خودرو است که ویژگی‌هایی دارد؛ [کیفیت] صرفاً یکی از ویژگی‌های محصول است.
قسمت پیچیده‌تر در توسعه‌ی نرم‌افزار کیفیت داخلی است. کیفیت داخلی فقط توسط توسعه‌دهندگان یا افراد فنی قابل مشاهده است. [کیفیت داخلی] هر چیزی است که گسترش و نگه‌داری کد را سخت‌تر یا آسان‌تر می‌کند. ممکن است تست‌هایی باشد که وجود دارند یا ندارد، چون اگر تست داشته باشیم، تغییر کد آسان‌تر است. ممکن است سبک معماری یا مشکلات آن باشد. همچنین مربوط به مشکلات کد است، این‌که کد بیش از حد پیچیده یا بیش از حد ساده است. شبهه‌ای که در مورد آن وجود دارد این است که توسط هیچ‌کس به جز افراد فنی قابل مشاهده نیست. این به آن معنی است که مدیریت کیفیت داخلی در واقع دشوار است. چون اگر فردی فنی نباشید، درک این کیفیت و تأثیر آن روی فرایند توسعه سخت است. این چیزی است که در مورد بدهی فنی هم مهم است.
سوِن می‌خواهی در این مورد صحبت کنی؟
بله. اساساً می‌توان گفت بدهی فنی تشبیهی برای توصیف کد نامطلوب است. [اصطلاح] بدهی اشاره‌ای به بدهی مالی دارد و از آن استفاده می‌کنیم تا [مفهوم] این کیفیت داخلی و ریسک کد را به افراد غیرفنی منتقل کنیم. توسعه‌دهندگان همواره در مورد کدهای باکیفیت و خوب صحبت می‌کنند اما افراد غیرفنی عموماً فایده‌ی آن را درک نمی‌کنند. به نظر آن‌ها «نرم‌افزار خوب کار می‌کند، چرا باید در کیفیت سرمایه‌گذاری کنم؟!». تشبیه بدهی فنی به ما کمک می‌کند که توضیح دهیم اگر بخواهیم بر اساس کد نامطلوب چیزی بسازیم، این باعث می‌شود توسعه‌های بعدی گران تمام شوند؛ زمان بیشتری صرف پیاده‌سازی یک ویژگی به کدی که خیلی خوب نیست، می‌شود. همچنین دیر یا زود این کیفیت داخلی تبدیل به کیفیت خارجی می‌شود؛ این هم مسئله‌ی است که باید بفهمانیم. مثلاً اگر کد بدی داشته باشیم، باگ‌های بیشتر و بیشتری خواهیم داشت و کند می‌شویم و این مشکل به تدریج به ذی‌نفعان و پروژه هم منتقل می‌شود. بنابراین بدهی فنی در حقیقت مشکل توسعه‌دهنده نیست، یک مشکل در سطح شرکت است. اگر بدهی فنی زیادی داشته باشید، در شرایط بحرانی تمام تیم مهندسی متوقف می‌شود. فکر می‌کنم خیلی از شرکت‌ها این را تجربه کرده باشند؛ فرضاً سامانه‌های [نوشته‌شده] با COBOL که امکان تغییر چیزی را در آن نداشتند.
بنابراین می‌شود ادعا کرد که بدهی فنی یکی از موارد کلیدی در موفقیت تجاری نرم‌افزارهای توسعه‌داده‌شده است. این اصطلاح توسط وارد کانیگهام در سال ۱۹۹۲ ابداع شد. او چنین چیزی گفت: «انتشار اولین کد مثل بدهکار شدن است. کمی بدهی، سرعت توسعه را بهبود می‌بخشد؛ به شرطی که در اولین فرصت با بازنویسی کد، تسویه شود... خطر زمانی رخ می‌دهد که تسویه نشود. هر دقیقه که صرف کد نامطلوب شود به عنوان بهره تلقی می‌شود. تمامی یک سازمان مهندسی می‌تواند تحت بار بدهی این کد نامستحکم، به حالت توقف کشانده شود، [خواه این اشکال] از نوع شئ‌گرایی باشد یا نباشد.» (متن کانینگهام را می‌توانید از این لینک ببینید -مترجم)‌ این به وضوح می‌گوید که تشبیه بدهی فنی ارتباط نزدیکی با بدهی مالی دارد و مربوط به انتشار سریع یک چیز و در نتیجه بدهکار شدن است. بعداً باید این بدهی را با بهبود کیفیت، تسویه کنید و اگر این کار را نکنید مجبور به پرداخت نرخ بهره هستید چون بهره‌وری شما کاهش پیدا می‌کند و توسعه‌تان کند می‌شود. و همان‌طور که سوِن الان گفت این تشبیه مناسبی برای صحبت با مدیریت است چون آن‌ها با اصطلاحات مالی آشنا هستند. با استفاده از این اصطلاحات راحت‌تر است که به آن‌ها بگوییم این مثل رفتن به بانک است. برای مدتی سود دارد اما در نهایت باید آن را بازپس دهید؛ اصل و بهره‌ی آن را. این‌طور بود که این اصلاح ابداع شد. اما تعریف دیگری هم وجود دارد. درست است سوِن؟
دقیقاً، دقیقاً. انجمن محقین ترجیح می‌دهند از تعریف مک‌کانل استفاده کنند. او می‌گوید: بدهی فنی‌ای که رویکردی در طراحی یا ساخت باشد در کوتاه‌مدت عملی است. اما یک زمینه‌ی فنی ایجاد می‌کند که در آینده انجام کار در آن به نسبت الان زمان بیشتری خواهد گرفت، این شامل افزایش هزینه در گذر زمان هم هست. فکر می‌کنم این تعریفی است که اکثر ما از بدهی فنی می‌دانیم. کاری را سریع و کثیف انجام می‌دهیم و چیزی در کوتاه‌مدت به دست می‌آوریم اما می‌دانیم که در درازمدت گریبان‌گیرمان خواهد شد.
این بیش از حد معمول است. فکر می‌کنم بعد از توضیح تشبیه، مهم‌ترین بخش این است که چطور با بدهی فنی برخورد کنیم؟ همان‌طور که گفتم، [بدهی فنی] یکی از کلیدهای [ کسب و کار موفق در توسعه‌ی نرم‌افزار است. بنابراین سؤال این است که چطور با آن برخورد می‌کنید؟ احتمالاً اولین سؤال این است که آیا اصلاً چیز بدی است؟
اگر درباره‌اش فکر کنید، بدهکار شدن اغلب چیز بدی نیست. اگر برای مثال یک خانه بخرید، می‌توانید مقداری از پول‌تان را پس‌انداز کنید چون دیگر اجاره پرداخت نمی‌کنید و این نوع از سرمایه‌گذاری ممکن است چیز خوبی باشد. به همین‌خاطر است که در صنعت، وام وجود دارد. به شما پول می‌دهند تا در ماشین‌آلات بهتر یا هر چیز دیگر سرمایه‌گذاری کنید و بهره‌وری را بهبود دهید و تولید را بیشتر کنید و آن را پس دهید. بنابراین بدهی لزوماً چیز بدی نیست. در برخی موارد -اگر دوباره به تشبیه بنگریم- ممکن است بد باشد. اگر صرفاً برای خرید کالاهای تجملی، یا هدیه سال نو یا ... بدهکار شوید، این پول سرمایه‌گذاری نشده است، صرفاً خرج شده و رفته است. بنابراین در ارتباط با تشبیه در توسعه‌ی نرم‌افزار همیشه معنی ندارد که بدهی را پرداخت کنیم. چرا این‌طور است؟ علت این است که در مقایسه با بدهی عادی نرخ بهره‌ای که شما پرداخت می‌کنید تنها زمانی تغییر می‌کند که شما کد را تغییر می‌دهید. بنابراین همان‌طور که گفتیم کیفیت داخلی مربوط به این است که کد چقدر قابل تغییر است. اگر کد را تغییر ندهید کیفیت داخلی و بدهی فنی اصلاً اهمیت ندارد. بنابراین تسویه‌ی بدهی فنی در بخش‌هایی از کد که تغییر نمی‌کنند اصلاً معنی ندارد.
مسئله‌ی دیگری هم وجود دارد که یکی از بخش‌های نامهربان بازیِ توسعه‌ی نرم‌افزار است و آن، این است که شخصی که بدهی را پرداخت می‌کند لزوماً کسی که آن را تحمیل کرده نیست. بنابراین اگر در یک پروژه، یک تیم نرم‌افزاری را تولید می‌کند و تیم متفاوتی قرار است بعداً نگه‌داری را انجام دهد، تیمی که پیاده‌سازی را انجام می‌دهد نرخ بهره و بدهی فنی را پرداخت نمی‌کند؛ تیم نگه‌داری این کار را خواهد کرد. در این مورد ممکن است به نفع تیم پیاده‌سازی باشد که بدهی فنی را انباشت کند، چون سریع‌تر پیش می‌روند و هرگز به جنبه‌ی منفی آن برنخورند، چون این کار تیم نگه‌داری است. این یکی از مشکلاتی است که ممکن است در رابطه با بدهی فنی داشته باشید؛ کسی که بدهی فنی را به وجود می‌آورد ممکن است بعداً مسئول آن نباشد.
همچنین مدتی پیش گفتگویی با وارد کانینگهام درباره‌ی بدهی فنی داشتیم و او گفت: خب، در واقع بدهی فنی یک راهبرد است. چرا یک راهبرد است؟ چون می‌توانیم با بدهکار شدن به سرعت به هدف کسب و کار برسیم. چون ممکن است به بازار فرستادن چیزی خیلی مهم‌تر از مثلاً داشتن کد بی‌نقص و دیر رسیدن باشد. اما می‌توانیم چیزی را در بازار بفرستیم و اگر اولین بار باشد ببینیم که اصلاً به درد می‌خورد یا نه. فکر می‌کنم جالب است که مثلاً اریک ریس نویسنده‌ی کتاب The Lean Startup در کتابش توضیح می‌دهد که وقتی در استارتاپ کار می‌کرد همیشه خوشحال بود که کد بی‌نقصی نوشته است اما در نهایت هیچ‌کس از آن استفاده نمی‌کرد. بنابراین عملکردی که با کد بی‌نقصش ساخته بود کاملاً بدون استفاده بود. پس بهتر است چیزی را سریع بنویسید و به کاربر برسانید و ببینید که آیا برای کسی مفید است؟ اگر برای کسی مفید است آن وقت است که بدهی فنی را پرداخت می‌کنیم. اگر کد بی‌نقصی برای عملکردی که نمی‌دانیم مفید است یا نه بنویسیم هدر دادن زمان است. هنریک نیبرگ از Spotify حدود یک سال پیش در بلاگش چیزی نوشت: اگر عملکرد کد بی‌نقص «واقعاً» مفید نباشد، ما آن را زباله در نظر می‌گیریم. کاری که آن‌ها می‌کنند این است که یک عملکرد را خیلی سریع راه‌اندازی می‌کنند در حالی که ظاهر خوبی ندارد و آن را به مشتری می‌رسانند. اگر کاربر آن را دوست داشت و خواست از آن استفاده کند، آن را پیرایش (Refactor) می‌کنند و بهبود می‌دهند. این راهبردها را مدام و مدام می‌بینیم. فکر می‌کنم یک نمونه‌ی مشهور آمازون و تویتر باشد. فکر می‌کنم در تویتر این حس وجود دارد که انگار همیشه دارند سامانه‌شان را بازنویسی می‌کنند :-) چون فکر می‌کنم در ابتدا یک برنامه Ruby on Rails بود و الان یک سامانه‌ی اشتراک پیام است. آمازون هم در ابتدا سامانه‌ی کاملاً متفاوتی به نسبت آن‌چه که الان هست، بود. بله، فکر می‌کنم یک راهبرد باشد.
ادامه مطلب ...

ارائه توسط: Adrian Cockroft
مترجم: سید مرتضی هاشمی 1395/09/05
در این اپیزود که در دسامبر ۲۰۱۴ منتشر شده است، استفان تیکف با ادریان کاکرافت در ارتباط با پلتفرم‌های پیشرفته ابری مصاحبه می‌کند. آدریان بیشتر به خاطر رهبری Netflix برای انتقال به یک معماری کاملاً ابری، و به شدت پویا شناخته شده است. همچنین به عنوان یک مهندس برجسته در Sun Microsystems کار می‌کرد و یکی از بنیان­گذاران آزمایشگاه‌های تحقیقاتی eBay است. در حال حاضر آدریان به عنوان یک مشاور فناوری در Battery Ventures مشغول به کار است.
آدریان به برنامه خوش آمدی. طبق معمول از شما می‌خواهم که با معرفی خودتان شروع کنید. که هستید و چه می‌کنید؟
سلام، متشکرم که من را به این برنامه دعوت کردید. من یک فن‌شناس (Technologist) و توسعه‌دهنده‌ی نرم‌افزار هستم و مدت زیادی است که این کار را انجام می‌دهم. اجازه بدهید از ابتدا شروع کنم. من کارم را با گرفتن مدرک فیزیک از انگلیس شروع کردم و حدود ۵ سال به عنوان مهندس نرم‌افزار کار کردم. در این مدت، در شرکتی به نام Cambridge Consultants در انگلیس سیستم‌های تعبیه شده‌ی بلادرنگ و انواع نرم‌افزار را تولید می‌کردم. ما در دهه‌ی ۸۰ یکی از اولین کاربران ایستگاه‌های کاریِ (WorkStation) Sun بودیم که به عنوان بستر توسعه از آن استفاده می‌کردیم. به تدریج Sun دفتری در نزدیکی ما افتتاح کرد و من به آن‌ها پیوستم. پس از آن حدود ۵ سال به عنوان مهندس سیستم در شرکت Sun در انگلیس کار کردم. بعد از آن حدود ۲۰ سال پیش به آمریکا نقل مکان کردم و در بخش‌های مختلف مهندسی Sun کار کردم. اساساً تمرکز من روی طرح‌ریزی ظرفیت کارایی (Performance Capacity Planning) بوده است. در راستای این هدفِ Sun من یک مهندس برجسته در موضوع برنامه‌ریزی ظرفیت کارایی بودم و کتابی با عنوان Sun Performance and Tuning نوشتم که خیلی‌ها آن را دارند و بیشتر مردم به جای اسم کتاب طرح روی جلد آن را به خاطر می‌آورند. آخرین شغلی که در Sun داشتم، معمار ارشد در ارتباط با پردازش‌های با کارایی بالا (High Performance) بود.
در سال 2004 شرکت Sun یک کوچک‌سازی انجام داد و تعدادی از افراد را در فازهایی کنار گذاشت و آن گروه به طور کلی کنار گذاشته شد. بعد از آن به eBay پیوستم. کمی با eBay کار کردم و کمک کردم در طول سالیان در مقیاس رشد کنند. در آن‌جا به عنوان یک معمار دسترس‌پذیری متمایز روی مسائل مقیاس‌پذیری و دسترسی‌پذیری کار کردم. چیزهایی زیادی در مورد سیستم‌های مقیاس بزرگ که با مشتریان سروکار دارند -بر خلاف سیستم‌های سازمانی که با سازمان‌های دیگر سروکار دارند- یاد گرفتم. من به تشکیل آزمایشگاه‌های تحقیقاتی eBay کمک کردم و در سال ۲۰۰۷ به Netflix پیوستم. فکر می‌کنم Netflix به زودی در آلمان و پس از آن در فرانسه راه‌اندازی می‌شود. این‌که [سامانه] چطور پاسخ می‌دهد جالب خواهد بود.
من به Netflix پیوستم و حدود ۳ یا ۴ سال گروهی از توسعه‌دهندگان نرم‌افزار را مدیریت کردم. در اواخر این دوره تصمیم گرفتیم به فضای ابری (Cloud) منتقل شویم و من هدایت یکی از تیم‌ها را بر عهده داشتم تا بخشی از بستر را به فضای ابری منتقل کنیم. سپس تیمی تشکیل دادیم و من معمار آن شدم در عوض اینکه بخواهم بیرون بروم و در مورد این‌که ما چه کار می‌کنیم و چطور به ابر منتقل می‌شویم صحبت کنم و به دیگران توضیح دهم و مراحل گذشتن از سوء تفاهم‌ها و انکارها و پذیرفتن‌ها را طی کنم.
ادامه مطلب ...

ارائه توسط: 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) داشته باشید و بسیاری از این مشکلات نگارشی را بیابید اما با بازبینی کد احتمالاً خیلی سخت خواهد بود که نشتی حافظه را بیابیم زیرا برای فهمیدن کدی که بازبینی می‌کنید نیاز به زمینه‌های دیگری دارید، اینکه چه کسی این حافظه را تخصیص داده؟ چه کسی مسئول آزاد کردن آن است؟ شاید به هیچ وجه مسئول آن نباشم و شاید اشکالی نداشته باشد که اجازه بدهم اشاره‌گری مخفیانه پاک شود [اما در غیر اینصورت] من باید زمینه‌های دیگری را بدانم و در موضوع بازبینی کد، یافتن زمینه، سخت‌ترین کار است.
ادامه مطلب ...