کلیسای جامع و بازار - قسمت چهارم(1039 مجموع کلمات موجود در متن) (5431 بار مطالعه شده است)  کلیسای
جامع و بازار، بخش چهارم
نرم
افزار popclient
به
fetchmail
تبدیل
میشود
تحول
اصلی در پروژه زمانی صورت گرفت که هری
هاچیسر (Harry
Hochheiser) کد
برنامه اش را در ارتباط با ارسال نامه به
پورت SMTP
ماشین
سرویس گیرنده برایــم فرستاد.
من
سریعا به این نتیجه رسیدم که یک پیاده
سازی درست از این ساختار تمامی روش های
دیگر را به کنار خواهد زد.
هفته
های زیادی را به سرو کله زدن با fetchmail
پرداختم،
تــا طــرح واســط برنامه که قابل استفاده
اما بی قواره بود، را بهبود بخشم -
بــرنــامه
ظاهری ناهنجار داشــت، بــا گــزینه‌های
زیــادی که به طور نامنظم در سراسر آن
پراکنده بودند.
مخصوصا
گزینه‌هائی که برای کپی برداری نامه
دریافت شده بــه یــک فـایل در صندوق پستی
و یــا یـک دستگاه خروجی استاندارد تعبیه
شده بودند، خاطرم را می آزردند، اما دلیلش
را نمیتوانستم درک کنم.
آنچه
که در حین فکر درباره قابلیت ارسال SMTP
بــه
ذهنــم خـطـور کـرد، ایـن بود که نرم
افزار popclient
سعی
داشت تا کارهای زیادی را با هــم انـجــام
دهــد.
ایــن
برنامه به نـحوی طراحی شده بود تا هم یک
عامل انتقال پست الکترونیکی
(MTA)
و
هم یک عامل تحویل موضعی
(MDA)
باشد.
با
قابلیت ارسال SMTP
،
می‌توانست از حــوزه کــــاری MDA
خارج
شده و یک MTA
محض
باشد که به سادگی sendmail،
نامه را به برنامه‌های دیگر برای تحویل
موضعی تحویل می‌دهد.
چرا
تمامی پیچیدگی‌های پیکــربندی یک MDA
یا
عملیات قفل و الحاق
(Lock
and Append) بر
روی یک صندوق پستی در هم آمیخته شوند، در
حالیکه پورت ۲۵ تــقــریبا در تمامی
پـلتفرمهائی کــه از TCP/IP
پشتیبانی
می‌کنند، بــه ایـن کار اختصاص داده شده
است؟ بخصوص زمانی که این مسئله به معنی
شباهت ساختاری نامه دریافتی با نامه
معمولی یک فرستنده SMTP
باشد؛
که درواقع همان چیزی است که ما می‌خواهیم.
درس‌های
زیـادی در ایـن نکته وجود دارد.
در
ابتدا، ایده ارسـال SMTP
بزرگترین
نتیجه‌ای بـود که من از تلاش هوشیارانه‌ام
برای شبیه سازی روش لینوس گرفتم.
یکی
از کاربران، ایــن ایده فوق العاده را به
من داد – تنــها کاری کــه بــایــد
انـجام می‌دادم این بود که مفاهیم را درک
کنم.
روش
کارای بعدی برای داشتن ایده های خوب، کسب
ایده های خوب از کاربرانتان است.
بعضی
وقتها این روش دوم بهتر است.
با
کمی دقت، بسرعت خواهید فهمید که اگر کاملا
با خودتان درباره آنچه که به دیگران
بدهکارید صادق باشید، دنـیـا با تمام
بزرگی‌اش همانطور با شما رفتار کرده است
که شــما با هــر تــکه از نــوآوریتان
که خلقش کرده‌اید؛ و ایــن تـنـها شایسته
بخشی از نبوغ درونی شماست.
همه
ما دیدیم که این مطلب چقدر برای لینوس
موثر افتاد.
(وقتی
که این مقاله را در کنفرانس Perl
در
ماه اوت سال ۱۹۹۷ ارائه دادم، لری وال در
ردیف اول نشسته بود.
وقتی
که به آخرین خط پاراگراف فوق رسیدم، او
همچون مبلغ های مذهبی فریاد زد :
"بگو،
بگو براد !".
تــمامی
حــضار خنـدیـدند، چرا که می‌دانستند
که چنین چیزی برای سازنده perl
نیز
اتفاق افتاده بود.)
بعد
از گذشت تنها چند هفته از اجرای پروژه در
آن حال و هوا، تعریف و تـمجـید های مشابهی
را نه از کاربرانم، بلکه از سایر افرادی
که سخنانم به گوش آنها رسیده بود، دریافت
کردم.
من
هنوز تعــدادی از آن نامه ها را دارم.
هر
وقت حس می‌کنم که زندگیم بی ارزش بوده،
یک نگاهی به آنها می اندازم :-)
اما
دو درس پایه ای دیگر وجود دارد که برای هر
نوع طراحی نرم افزار، مناسب است.
در
اغلب اوقات، اکثر راه حل های ابداعی و
برجسته از درک این نکته ناشی میشود که
تحلیل شما از مسئله اشتباه بوده است.
زمانی
من تلاش می‌کردم تا با ادامه توسعه نرم
افزار popclient
به
عنوان یک MTA/MDA
ترکیب
شده، برنـامه‌ام تمــامـی انواع تحویل
محلی را انجام دهد؛ در واقع می‌خواستم
مسئله اشتباهی را حل کنم.
ساختار
برنامه fetchmail
می‌بایست
مجددا مورد بررسی و تحلیل قرار می‌گرفت
تا به یک MTA
محض
تبدیل شود.
زمانی
که به یک بن بست در برنامه نویسی می‌رسید،
زمانی که فکر کردن به مرحــله بعــدی
بـرایـتـان سخت میشود، آنوقت به دنبال
جواب درست نباشید، بلکه به فکر یافتن سوال
درست باشید.
احتمالا
صورت مسئله نیازمند این است که از نو بیان
شود.
با
این وجود، مشکلم را از نو مورد بررسی قرار
دادم.
بوضـوح
مشخص بود که کار درست این است که؛ (۱)
قابلیت
ارسال SMTP
را
در قــالب یک درایور عمومی بگنجانم؛ (۲)
آن
را حالت پیشفرض قرار دهم؛ و (۳)
سرانجام
تمامی حالات دیگر تحویل را نادیده بگیرم،
بخصوص گزینه های ارسال به فایل و ارسال
به خروجی استاندارد.
بعضی
اوقات در مورد اجرای بند ۳ به تردید می
افتادم، و از این می‌ترسیدم کــه کـاربران
قدیمی popclient
که
به مکانیزم های تحویل دیگر عادت کرده‌اند،
از این کار ناراحت شوند.
در
تئوری، این امکان برایشان وجود داشــت
که بـا روش‌های مشابه بتوانند مشکلشان
را برطرف کنند.
اما
در عمل، این تحول می‌توانست برایشان سخت
و دشوار باشد.
اما
زمانی که این کار را انجام دادم، بهبودی
زیادی در روند کار ایجاد شد.
مشکلاتی
که در کـد درایور وجود داشت به صفر رسید.
پیکربندی
برنامه بسیار ساده تر شد – دیــگر برنامه
بیهوده درگیــر MDA
و
صندوق پستی کاربر نمی‌شد؛ همچنین دیگر
نگرانی در ارتباط با پشتیبانی از سیستم
عامل مورد استفاده در ارتباط با قفل کردن
فایل وجود نداشت.
همچنین،
این راه تنها روش برای جلوگیری از از دست
دادن نامه ها نیز بود.
اگر
شما فایلی را به عنوان محل تحویل نامه
هایتان در نظر می‌گرفتید و دیسک پر می‌شد،
آنوقت شما نامه تان را از دست می‌دادید.
این
مسئله هیچگاه با ارسال بوسیله SMTP
اتفاق
نخواهد افتاد، چرا که شنونده SMTP
شما
تا زمانی که نامه شما تحویل داده نشود یا
حداقل برای تحویل در زمانی دیگر اسپول
(Spool)
نشود،
پیغام OK
را
برنمی‌گرداند.
کارائی
نرم افزار نیز افزایش یافت (البته
انتظار نداشته باشید که با یک بار اجرای
نرم افزار به این نکته پی ببرید).
فایده
مهم دیگری که نمی‌توان از آن به سادگی
گذشت، کاهش محسوس تعداد صفحات راهنما
بود.
بعدا،
مجبور شدم تا قابلیت تحویل از طریق یک MDA
محلی
تعیین شده توسط کاربر را برای ایجاد امکان
مدیریت بعضی از حالات نادری که در ارتباط
با SLIP
پویا
بوجود می آمد، مجددا به برنامه اضافه کنم.
اما
راه بسیار ساده‌تری را برای انجام آن
پیدا کردم.
چطور؟
در کنار گذاشتن ویژگی های کهنه در حالی
که می‌توانید بدون آنها، همچنان با همان
کارائی کار کنید، تردید نکنید.
به
گفته آنتونی سنت-اگزیوپری
(زمانی
که خلبان و طراح هواپیما بود و هنوز نویسنده
کتاب های کلاسیک کودکان نشده بود):
رسیدن
به حد کمال (در
طراحی)
در
حالتیکه که چیز دیگری برای اضافه کردن
وجود ندارد، بدست نمی آید، بلکه این مهم
زمانی حاصل میشود که نتوان چیزی را از
طرح مورد نظر کم کرد.
زمانی
که برنامه شما هم بهتر و هم ساده تر میشود،
بدانید که درست عمل کرده‌اید.
و
در پروسه انجام کار، طرح برنامه fetchmail
هویت
خاص خود را پیدا کرد، که کاملا با نسخه
قدیمی popclient
متفاوت
بود.
زمان
تغییر نام برنامه فرا رسیده بود.
طرح
جدید بیشتر از آن برنامه popclient
قدیمی
به برنامه ارسال نامه الکترونیکی می‌خورد؛
هر دو به نوعی MTA
بودند،
امــا برنامه popclient
جـدیــد
متفاوت عمل می‌کرد.
در
نهایت و پس از دو ماه، نام برنامه را به
fetchmail
تغییر
دادم.
ترجمه:
نیما ابوطالبی
nima717a@yahoo.com
منبع:
http://www.catb.org/~esr/writings/cathedral-bazaar/
 PDF Version
| 
منوی اصلی
