اعضای مجلس دست کم دو بار از من پرسیده‌اند «آقای بابیج، اگر اعداد نادرستی وارد ماشین کنی، آیا پاسخ درست نتیجه خواهد داد؟» واقعا نمی‌فهم چه نوع اغتشاش ذهنی‌ای می‌تواند به طرح چنین سوالی منجر شود!  -  چارلز بابیج (Charles Babbage)
کامپیوترم مرا در شطرنج شکست داد، ولی در مشت و لگد حریفم نشد!  -  اوم فیلیپس
تعیین محدودیت‌های «ممکن» فقط با رفتن به آن سوی «ناممکن» میسر می‌شود. -  آرتور سی. کلارک (Arthur C. Clarke)
1) شما اجازه پرینت این کتاب را ندارید. 2)  شما اجازه واگذاری این کتاب به غیر را ندارید. 3) شما مجاز نیستید این کتاب را بلند بلند بخوانید.  -  متن مجوز شرکت ادوبی!
خود بشر هنوز شگفت‌انگیزترین کامیپوتر است.   -   جان اف کندی (John F. Kennedy)
در بیشتر موارد، اشکال از شیوه تفکر افراد است، نه فناوری.  -   کریسفوتر جی. بوشولتز (Christopher J. Bucholtz)
یکی از محسنات داشتن کامپیوتر این است که اگر کار را خراب کند، هیچ قانونی نیست که شما را از ضرب و شتم آن منع کند.  -   اریک پورترفیلد (Eric Porterfield)
تنها استفاده مشروع از کامپیوترها بازی‌های کامپیوتری است.   -   اوژن جارویس (Eugene Jarvis)
کامپیوترها اساسا به درد نمی‌خوردند. چرا که فقط می‌توانند جواب بدهند.  -  پابلو پیکاسو (Pablo Picasso)
ریبوت کردن کامپیوتر داروی شگفت‌انگیزی است؛ تقریبا هر دردی را درمان می‌کند.   -   گارت هیزل (Garrett Hazel)

جان کوک (John Cook)
مترجم: سید محمدرضا کلانتری

از ظاهر مباحث پیرامون معماری نرم‌افزار این گونه برمی‌آید که تنها نگرانی موجود به حوزه مساله محدود شده است: این که چگونه یک سیستم مدیریت محتوا یا یک واژه‌پرداز و جز آن را سازمان‌دهی کنیم. از همین حیث یکی از مباحث مهم از نظر دور می‌ماند: برنامه‌نویسان نرم‌افزار.

16 - P23شما چقدر به طراحان نرم‌افزار خود اطمینان دارید؟ چقدر به مهارت‌ها و درستی آن‌ها اعتماد می‌کنید؟ آیا می‌خواهید مزاحم کار طراحان نشوید یا می‌خواهید از خودتان در برابر طراحان نالایق حفاظت کنید؟
صحبت در این باره کمی ناخوشایند است و در نتیجه این تصمیم اغلب تلویحی و در حاشیه باقی می‌ماند. هیچ کس نمی‌خواهد با صدای بلند بگوید که در حال طراحی نرم‌افزاری از سوی لشکری از برنامه‌نویسان متوسط هستند، اما این پیش‌فرض همیشگی است. بی‌دلیل هم نیست. بیشتر طراحان به طور طبیعی توانایی متوسطی دارند.
در این نقطه می‌توانیم کمی صحبت اضافی درباره علت و معلول داشته باشیم. افراد بر اساس انتظارات رشد (و افول) می‌کنند. شاید بتوان گفت که فرض متوسط‌الحال بودن، خود علت تحقق خودش می‌شود و واقعا هم تا حدودی همین طور هست. از سوی دیگر، نباید گمان کرد که اگر با یک بچه‌کدنویس مانند دانلد کنوث (Donald Knuth) برخورد شود، از او یک پروفسور کنوث جدید خواهد ساخت.
وقتی برنامه‌نویسان زبده از رویکردهای رایج در طراحی نرم‌افزار شکایت می‌کنند، در نظر نمی‌گیرند که بیشتر نرم‌افزارها را برنامه‌نویسان زبده نمی‌نویسند و این موضوع تا چه حدی می‌تواند تفاوت ایجاد ‌کند. برای مثال، بسیاری از برنامه‌نویسان بزرگ را دیده‌ام که از جاوا انتقاد کرده‌اند. اما جاوا برای برنامه‌نویسان بزرگ نوشته نشده، بلکه برای برنامه‌نویس عادی نوشته شده است. همان محدودیت‌های زبانی که برنامه‌نویسان بزرگ از آن ناراضی‌اند، برای برنامه‌نویسان متوسط مزایایی به همراه دارد.
16 - P23 - 2شما با وجود طراحانی بسیار توانمند و منضبط، قادر به سازمان‌دهی نرم‌افزار خود به گونه‌ای کاملا متفاوت و حرفه‌ای نسبت به زمانی هستید که طراحانتان از مهارت و نظم کمی در کار برخوردارند. یکی از جاهایی که این موضوع خود را نشان می‌دهد، میزان تمایل شما به تکیه بر عرف به منظور حفظ نظم است. برای مثال، معماری پشت Emacs به شکل قابل توجهی ساده و بسیار وابسته به عرف است. این رویکرد به‌خوبی به کمک Emacs آمده است، اما برای یک گروه بزرگ از طراحان متوسط جواب نخواهد داد. (همچنین برای نرم‌افزار کنترل‌کننده ترمزهای اتومبیل نیز مناسب نخواهد بود. خطا‌های یک ویرایشگر متن آن‌چنان تاثیر مخربی ندارند، اما خطاهای سیستم ترمز خودرو، چرا!)
به طور کلی، در پروژه‌های متن‌باز بیشتر از پروژه‌های تجاری تکیه روی عرف به چشم می‌خورد. یک توضیح احتمالی آن است که پروژه‌های متن‌باز طراحان باانگیزه‌تری دارند. همه طراحان متن‌باز داوطلب نیستند، اما بسیاریشان چنین‌اند. داوطلب‌ها نه تنها انگیزه بیشتری دارند، بلکه مرخص کردن آن‌ها از ادامه پروژه نیز راحت‌تر از کارمندان است. اگر کدهای کسی در حد استاندارد نیست، پروژه به‌راحتی از استفاده از کد آن‌ها سر باز می‌زند. به طور نظری می‌توان همین را در مورد یک پروژه نرم‌افزار تجاری نیز بیان کرد، اما در عمل قضیه به این سادگی نیست.

 

شماره 17