ورود/ایجاد حساب کاربری
   منوی اصلی
· خانه
· لیست کاربران
· جستجو
· آمار مشاهدات
· آرشیو مقالات


- شرح
· راهنمای نویسندگان
· درباره ما

   همکاری با نشریه
در صورتی که مایل به همکاری با نشریه هستید، می‌توانید در لیست پستی نشریه عضو شده و در جریان امور قرار گیرید. برای اطلاعات بیشتر، اینجا کلیک کنید.

   کاربران
سردبیر
هیچ مدیر کمکی حاضر
همکاران
هیچ مدیر کمکی حاضر
اعضا:
جدیدترین:جدید امروز:0
جدیدترین:جدید دیروز:0
جدیدترین:مجموع:2471
جدیدترین:جدیدترین:
ufumenarayu
اعضا:حاضر
اعضا:اعضا:0
مهمان‌ها:مهمان‌ها:6
مجموع:مجموع:6
کاربران حاضر
هیچ کاربر حاضری وجود ندارد

   ورود کاربران




 


 برای ورود مشکل دارید؟
 ثبت نام کاربران جدید

کلیسای جامع و بازار - قسمت سوم

(725 مجموع کلمات موجود در متن)
(4406 بار مطالعه شده است)  نسخه چاپی

کلیسای جامع و بازار، بخش سوم


زمانی که برنامه دیگر آن برنامه قبلی نبود

با درک نحوه عملکرد لینوس و خلق یک فرضیه درباره دلایل موفقیت آن، تصمیمی هوشیارانه برای تست این تئوری در پروژه جدیدم گرفتم (که در قیاس با لینوکس، مسلما بسیار ساده‌تر و کوچکتر بود).


اما اولین کاری که انجام دادم، سازمـاندهی دوبـاره و ساده سازی نرم افــزار popclient بود. پیــاده ســازی کارل هریس (Carl Harris) خیلی دقیق بود، اما نوعی پیچیدگی اضافی در قیاس با خیلی از برنامه نویسان C در برنامه‌اش به چشم می‌خورد. او با کد برنامه به عنوان بخش اصلی و ساختمان داده‌ها به عنوان پشتیبان کد برخورد می‌کرد. نتیجتا، برنامه بسیار زیبا سازماندهی شده بود، امــا نــوع طــرح ریــزی ســاخـتــمان داده بـرنــامه، روشــی معمـول نبود و تقریبا زشت سازماندهی شده بود (حداقل در قیاس با استاندار های سطح بالای این هکر قدیمی LISP).


جدای این مسائل، دلیل دیگری برای بازنویسی برنامه درکنار بهبود طرح برنامه و ساختار ساختمان داده آن داشتم. در واقع، میخواستم برنامه را کاملا درک کنــم. زیــاد جالب نیست که مسئول درست کردن برنامه‌ای باشــی که آن را درک نکرده‌ای!


حدودا در ماه اول، به پیروی از ساختار پایه‌ای طرح کارل پرداختم. اولین تغییر اساسی که در برنامه انجام دادم، اضافه کردن پشتیبانی از پروتکل IMAP بــه برنامه بود. این کار را بوسیله سازماندهی مجدد پروتکل‌ها در یک درایور عمومی و سه جدول متد (برای POP2، POP3 و IMAP) انجام دادم. این تغییر و تغیــیــرات قبلی نمایانگر یک اصل کلــی هسـتند که خوب است برنامه نویسان آن را بــه خاطر بسپارند، به خصوص در زبان‌های برنامه نویسی از قبــیل C که بــه طــور پیش فرض با انواع پویا کار نمی‌کنند:


ساختمان داده ی خوب و برنامه ضعیف بسیار بهتر از برنامه خوب و ساختمان داده بی ارزش کار می‌کند.


فصل نهم از کتاب بروکس: "اگر می‌خواهی مرا گیج کنی، برنامه ات را به من نشان بده ولی ساختمان داده برنامه‌ات را پنهان کن. اما اگر ساختمان داده برنامه‌ات را به من نشان دهی، اغلب دیگر نیازی به دیدن کد برنامه‌ات ندارم؛ همه چیز واضح و مشخص است."


البته منظور او "فلوچارت‌ها" و "جداول" بود. البته بــا درنظر گرفتن حرکت ســی ســاله علــمی و فنی/فرهنـگی، ایــن دو تقریبا یکی هستند.


در این زمان (اوائــل سپتامبر سال 1996، حدودا شش هفتــه پس از شروع کار)، بــه این فکر افتادم که بهتر است که نام نرم افزار را تغییر دهم. پس از همه این تغییرات، برنامه مذکور تـنها یک POP client ساده نبود. اما دچار تردید شدم، چرا که تا آن زمان هیچ کار کاملا جدیدی در ساختــار بــرنــامه انــجــام نـداده بودم. نسخه popclient من، هنوز هویت قبلی خود را داشت.


این تغییر بنیادی زمانی بوجود آمد که برنامه fetchmail قادر به ارسال کردن نامه های دریافت شــده به پورت SMTP شد. درباره اش خواهم گفت؛ اما قبل از آن: قبــلا گفتم که تصمیم داشتم کـه این پروژه را برای تست تئوری‌ام دربــاره آنچه که لینوس توروالدز انجام داده بود، به کار بگیرم. ممکن است بپرسید چطور این کار را کردم؟ به روش های زیر:


۱) برنامه‌ام را زود و به تناوب منتشر می‌کردم (تکرارش تقریبا کمتر از هر ده روز یک بار نمی‌شد، اما در طی دوران اوج برنامه نویسی، هر روز این کار انجام می‌شد)

۲) هر کس را که با من به نحوی درباره fetchmail درتماس بود را به لیست بتای خودم اضافه می‌کردم.

هر زمانی که نسخه جدیدی را انتشار می‌دادم، آگهی‌های زیادی را به لیست بتای خودم ارسال می‌کردم تا آنها را به مشارکت در پروژه تشویق کنم.

۳) به تست کننده‌های نسخه بتای نرم افزارم گوش می‌کردم، نظــر آنها را درباره تصمیماتم جـویا می‌شدم و هر زمان که آنها بسته‌های نرم افزاری و یا نظراتشان را برایم ارسال می‌کردند، از آنها تشکر می‌کردم.


نتیجه نهائی این کمک های کوچک، بسیار سریع اثر خود را نشان داد. از آغاز پروژه، بـا گزارش‌های با ارزشی در ارتباط با خطاهای برنامه مواجه شدم که برنامه نویسان حاضرند به خاطرش جان بدهند! کــه اغــلب بــا راه حــل‌هـای خــوبی نیز همراه بود. من متفکرانه مورد نقد قرار گرفتم، نامه های بسیاری بدستم رسید و نظرات هوشمندانه‌ای نیـز دریافت کردم. که همگی مرا به این نکته هدایت کرد:


اگر شما با تست کننده‌های نسخه بتای برنامه‌تان، چنان که آنها با ارزشترین منبع شما هستند، برخورد کنید، آنها به عنوان با ارزش ترین منبع شما به شما پاسخ خواهند داد.


یک نکته ارزشمند از موفقیت fetchmail، تعداد اعضای لیست نــسخه بتــای پــروژه، یعنــی دوستــان fetchmail-friends است. در زمان نوشتن این مقاله، لیست مذکور ۲۴۹ عضــو داشت که هر دو یا سه هفته یکبار به تعداد اعضای آن اضافه می‌شود.


عملا، با اصلاح نرم افزار در اواخر ماه مه سال 1997، لیست مذکور از آن تـعداد زیـاد اعضایش که به سیصد نفر می‌رسید، به دلیل جالبی تعدادی از اعضایش را از دست داد. خیلی از افراد از من می‌خواستند تا آنــهـا را از لیــست خارج کنم، چرا که برنامه fetchmail به حدی خوب عمل می‌کرد، کــه دیــگـر نیازی به بودن در لیست احساس نمی‌کردند! شاید این یک بخش از چرخه حیات پروژه کاملی باشد که در سبک بازار نوشته شده است.


ترجمه: نیما ابوطالبی nima717a@yahoo.com

منبع:

http://www.catb.org/~esr/writings/cathedral-bazaar/

PDF Version

تمامی مطالب و مقالات این سایت تحت مجوز GNU FDL قرار دارند. بنابراین کپی و ایجاد تغییر در آنها مطابق شرایط این مجوز آزاد می‌باشد.