۱۳۹۱ بهمن ۱, یکشنبه

چندتا کارمند مایکروسافت لازمه تا یه لامپ عوض بشه؟


متن زیر ترجمه ی من از یک مقاله مشهور توسط Eric Lippert است که در سال 2003 نوشته شد و من خواندنش رو به همه ی دوستان توصیه می کنم. عبارت «عوض کردن لامپ» که در عنوان مقاله آمده، کنایه از یک قابلیت غیرواقعی مورد بحث در مقاله به اسم ChangeLightBlubWindowHandlerEx است.

Joe Bork یک مقاله خوب نوشته که در آن تصمیم هایی را که برای رفع یا عدم رفع خطاهای نرم افزاری توضیح داده. این به اون معنیه که من می تونم از روی این مورد توی لیست نوشته های مهم آیندم رد بشم. ممنونم Joe!

اما حالا که بحثش پیش اومده، من می خوام یکمی درباره اون چیزی که Joe گفته بیشتر توضیح بدم. نظرات اون کلی تر از بحث صرفا رفع خطاهای نرم افزاریه. 

یک خطای نرم افزاری، نوعی تغییر در رفتار محصول است و همه تغییرات به یک اندازه هزینه دارند و روال یکسانی را طی می کنند.

پیشتر، زمانی که من برخی امکانات رو به موتورهای اسکریپتی اضافه می کردم، مردم به من ایمیل میزدن و می پرسیدن تا برخی ویژگی های خاص رو براشون پیاده سازی کنم. معمولا این ویژگی ها حالت "فعال-غیر فعال" داشتند. -- ویژگی هایی که مشکلات اختصاصی اونا رو حل می کرد. مثلا، «من ChangeLightBulbWindowHandlerEx رو برای فراخوانی لازم دارم، ولی هیچ کنترل ActiveX ای که این کار رو برام انجام بده وجود نداره و نمیشه یک Win32 API رو از توی اسکریپت بطور مستقیم فراخوانی کرد، میتونی تابع ChangeLightBulbWindowHandlerEx رو به امکانات داخلی VBScript اضافه کنی؟ احتمالا بیشتر از پنج خط کد نمیشه!»

من همیشه به این افراد یک جواب رو میدم -- اگه فقط پنج خط کد میشه، پس خودت برو اون ActiveX Object رو بنویس. بله، چون حق با توئه، احتمالا بیشتر از پنج دقیقه برای اضافه کردن اون ویژگی به کتابخانه VBScript Runtime طول نمی کشه. اما واقعا چند تا کارمند مایکروسافت لازمه که یک لامپ عوض بشه؟



  • یک برنامه نویس برای این که پنج دقیقه ای ChangeLightBulbWindowHandleEx رو پیاده سازی کنه.
  • یک مدیر برنامه برای نوشتن مشخصات [این قابلیت جدید].
  • یک متخصص محلی سازی برای برسی مسائلی که هنگام محلی سازی مشخصات ممکنه پیش بیاد.
  • یک متخصص کارایی برای برسی مشخصات [مذکور] جهت کارامدی و استفاده [آسان و] مناسب.
  • حداقل یک برنامه نویس، آزمایش کننده و مدیر برنامه برای برسی (به روش طوفان ذهنی) آسیب پذیری امنیتی احتمالی.
  • یک مدیر برنامه برای اضافه کردن مدل امنیتی به مشخصات [مذکور]
  • یک آزمایش گر، برای نوشتن طرح های آزمون.
  • یک مدیر آزمون برای به روز رسانی زمانبندی آزمون [واحد].
  • یک آزمایش کننده برای نوشتن موارد آزمایش و اضافه کردن آن به اتوماسیون [آزمایش] شبانه.
  • سه یا چهار آزمایش کننده برای مشارکت در خطایابی به هم ریخته به روش ad hoc.
  • یک نویسنده فنی برای نوشتن مستندات.
  • یک بازبین فنی برای [بازبینی و] ویرایش مستندات.
  • یک ویرایش گر رونوشت برای [بازبینی و] ویرایش مستندات.
  • یک مدیر مستندات برای جایگذاری مستندات جدید در متن مستندات موجود، به روز رسانی جدول ها، شاخص ها و غیره...
  • بیست و پنج مترجم جهت ترجمه مستندات و پیام های خطا برای تمامی زبان هایی که توسط ویندوز پشتیبانی می شود. مدیران مترجم ها در ایرلند (مترجم های زبان های اروپایی) و ژاپن (زبان های آسیایی) زندگی می کنند، که چندین ساعت ختلاف زمانی نسبت به ردموند (آمریکا) دارند که [توجیه و] هماهنگی با آن ها می تواند یک مسئله پیچیده باشد.
  • یک تیم از مدیران با تجربه، برای هماهنگ کردن همه این افراد، نوشتن چک ها و هماهنگ کردن هزینه ها با معاون رئیس.

هیچ کدام از این موارد بطور مستقل زیاد طول نمیکشه، اما روی هم رفته برای این قابلیت ساده زیادن. احتمالا دقت کردین که من همه مواردی که Joe دربارش صحبت کرده بود رو اضافه نکردم. مثلا اگه یه bug توی اون پنج خط کد بود چی؟ همون پنج دقیقه زمان برای توسعه (نوشتن کد) تبدیل به چند نفر-هفته کار میشه و هزینه هنگفتی داره، همش بخاطر اینکه در زمان چند دقیقه ای یک نفر (برنامه نویس مشتری) صرفه جویی بشه که می خواد یک کنترل VB6 کاری که اون می خواد بکنه! متاسفم، ولی این هیچ ارزش (سود) تجاری نداره. ما، در مایکروسافت، به سختی تلاش می کنیم تا یک نرم افزار ناقص منتشر نشه. برای یک نرم افزار خوب، با حساب چیزهای دیگه، اطمینان از اینکه یک نابینای کاتالانی که اسپانیولی صحبت می کنه، می تونه به سادگی از این قابلیت استفاده کنه، بدون اینکه نگران معرفی یک آسیب پذیری جدید بشه، نسبتا مشکله! اما ما باید این کار رو انجام بدیم، چون وقتی یه نسخه جدید از موتورهای اسکریپتی رو بیرون میدیم، صدها میلیون نفر اون کد رو امتحان می کنن و ده ها میلیون نفر باهاش برنامه می نویسن.
هر ویژگی جدیدی که برای درصد زیادی از کاربران ارزش نداشته باشه، در واقع دزدیدن منابع با ارزشیه که می تونه صرف پیاده سازی قابلیت های جدید، رفع خطا یا رفع آسیب امنیتی ای بشه که می تونه میلیون ها نفر رو تحت تاثیر قرار بده.
البته، KC Lemson، Raymond Chen و Chris Pratley نظراتی روی این موضوع دارند.