مصاحبه با قهرمان جاوا

«کی هورستمن» در شمال آلمان متولد و در دانشگاه آلبرخت شهر کیل تحصیلات خود را آغاز و نهایتاً از دانشگاه میشیگان آمریکا به درجه PHD رسید. وی هم‌اکنون در دانشگاه ایالتی سن‌جوز در کالیفرنیا در رشته علوم کامپیوتر به تدریس مشغول است و در سال ۲۰۰۵ میلادی به درجه قهرمان جاوا! (Java Champion) رسید. هورستمن عضو گروه نویسندگان هسته جاوا و هسته JSF بوده و هم اکنون در پروژه Enterprise Java for Elvis مشغول بوده و نقش به سزایی در گنجاندن دروس برنامه‌نویسی جاوا در دوره‌های درسی دبیرستانی علوم کامپیوتر در آمریکا داشته‌ است. هورستمن علاوه بر آن کار مشاوره در زمینه راهکارهای مبتنی بر اینترنت را نیز به صورت حرفه‌ای ادامه می‌دهد. در زیر گفت‌وگوی «جانیس هیس» خبرنگار java.sun.com را با هورستمن می‌خوانیم.
▪ زمانی که از هانس کابوتز (Heinz Kabutz) یکی از بزرگان جاوا در مورد بزرگ‌ترین اشتباه برنامه‌نویسان جاوا پرسیده ‌شد، وی به نقص در تست واحد (Unit test) اشاره نمود. هانس بیان داشت که در کنفرانسی متشکل از برنامه‌نویسان جاوا پرسیدم که چند نفر از شما تست واحد را به درستی و کامل انجام می‌دهید و هیچ دستی بلند نشد! نظر شما چیست؟
ـ البته من هم اگر در آن جمع بودم حتماً دست خودم را بلند نمی‌کردم! من تست واحد را به صورت اتفاقی آن هم برای مواردی که خطایی رخ داده باشد و برای جلوگیری از تکرار آن انجام می‌دهم. البته جای شگفتی است که گروه بزرگی از برنامه‌نویسان تست واحد را انجام نمی‌دهند. شاید آنها به قدری متخصص هستند که کدشان هرگز به خطا برنمی‌خورد. به نظر من نقطه صحیح جایی بین استفاده کامل یا بدون استفاده از تست واحد است.
▪ در سوالی از برایان گوتز (Brian Goetz) کلید برنامه‌نویسی سریع کد جاوا پرسیده شد. به نظر وی برنامه‌نویس باید به تولید کدی ساده بسنده کند. بنا بر اعتقاد وی کد تمیزی که دنباله‌رو اصول اولیه شی‌گرایی بوده و بتواند به صورت بهینه در کمپایلر (Compiler) جاوا کمپایل شود، مطلوب است. از آنجایی که کمپایلر با بهترین الگوها بهینه شده ‌است برای دستیابی به بهترین نتیجه، کدی مطلوب است که ساده‌تر بوده و در الگوهای عمومی کدنویسی بگنجد. به نظر گوتز کدهای پیچیده و هوشمندانه، هکرانه و از این قبیل؛ خروجی مناسبی از کمپایلر نخواهند داشت. شما چه فکر می‌کنید؟
ـ من با برایان موافق هستم. چیزی که در طول سالیان آموخته‌ام به من می‌گوید که قبل از عملیات تست کارآیی (Profile) هرگز نباید به موضوع بهینه‌سازی کد پرداخت.
برنامه‌نویس عموما از پرداختن به مسائلی همانند استفاده از حافظه‌های میانی (Caching)، تفکیک لایه‌ها و از این گونه به دردسر می‌افتد در حالی که این موارد اصولاً تاثیر قابل ملاحظه‌ای در کارآیی نهایی کد نخواهد داشت و فقط عملیات خطایابی (Debugging) را مشکل‌تر می‌کند. گذشته از آن من مخالف آن هستم که تمام تیم تولید در هر سطح از دانش به فراگیری الگوهای طراحی و برنامه‌نویسی بپردازند.
الگوهای برنامه‌نویسی مسلما جزء با ارزشی از دانش یک برنامه‌نویس محسوب می‌شود اما برنامه‌نویسان مبتدی می‌بایست به تدریج با این الگو‌ها آشنا شده تا هنر بکارگیری آنها را در جای صحیح بیاموزند. الگوها به تنهایی کلید جادویی موفقیت نیستند و استفاده صحیح از آنها به مراتب نتایج بهتری را در پی خواهد داشت.
▪ وخیم‌ترین اشتباهاتی که برنامه‌نویسان در تولید کد JSF (Java Server Faced) و در مقوله تولید وب انجام می‌دهند، کدام است؟
ـ من قصد ندارم برنامه‌نویسان را در ضعف‌های چارچوب تولید وب JSF یا در قسمت برپاسازی آن (Deployment) مقصر بدانم. عمده‌ترین مطلب در زمینه تولید با JSF شاید مشکل دنبال نمودن خطا در آن باشد. اگر برنامه‌نویس یک خطای تایپی ساده در قسمت‌های مختلف کد پروتوتایپ یا صفحات JSF مرتکب شود، محیط برنامه‌نویسی وی (IDE) ممکن است قادر به پیدا کردن این اشتباه نباشد. علت آن عدم طراحی JSF برای بررسی خطاهای موجود در صفحات و پروتایپ‌ها در زمان کمپایل است. به همین ترتیب زمان برپاسازی برنامه ممکن است حجم بالایی از stack-trace خطا ظاهر شود که وضعیت Application Server شما را بیان می‌کند. در این زمان نیاز به کمی غیب‌گویی (!) وجود دارد که برنامه‌نویس تشخیص دهد خطا مربوط به کدام قسمت از کد پروتوتایپ یا صفحه JSF بوده‌است. نیاز فوق فراتر از انتظار از حد یک برنامه‌نویس ساده است.
اما مقصر کیست؟ در مرحله اول تولیدکنندگان کتابخانه‌های JSF که stack-trace مناسب و مشخصی از حالت‌های رویداد خطا طراحی و تولید نکرده‌اند.
در مرحله دوم نویسندگان Application Serverها مقصر هستند. آنها با بیان این توجیه که محصول آنها برای برپاسازی است نه گذراندن موفق مراحل تولید، در هنگام رخداد خطای ناشی از اشتباه برنامه‌نویس، فقط stack-trace کلی خطا را بیرون داده و هیچ راهی برای شناسایی فایل مربوط به تولید خطا یا شماره خط رخداد خطا در کد را به دست نمی‌دهند. البته این امر در محیط برنامه‌نویسی Netbeans با ارائه سرنخ‌هایی از رخداد خطا کمی تسهیل شده‌ است. البته اگر فرض کنیم که کمپایلر هم در وضعیت Application Server قرار می‌گرفت و برنامه‌نویس کم دقت خطاهای بسیاری در کد صفحات به جای می‌گذاشت. در آن صورت با رخداد هر کدام از آن خطاها، اجرای برنامه خاتمه یافته و در نهایت محصولی تولید نمی‌شد. این مورد، مشکلی اساسی در JSF است.
▪ بنابراین برنامه‌نویس با JSF به گمراهی کشیده نمی‌شود؟!
ـ من در اینجا دو مشکل می‌بینم. اول اینکه در تولید برنامه‌های تحت وب، راه دیگری برای جداسازی کد از نمایش وجود ندارد. در JSF با کمی مشکلات می‌توان کد را به صفحات JSP ربط داد. تجربه نشان می‌دهد که هر زمان کد جاوا به صورت مستقیم (اسکریپلت) یا حتی به صورت JSTL در JSP وارد شود، نتیجه یک کد ناخوانا و بسیار مشکل‌ساز است.
پیشنهاد من بکارگیری صفحات خالص JSF با تکنیک‌های خاص خود، بدون وارد نمودن کد مستقیم جاوا در آنهاست. دوم اینکه معمولاً بیشتر دردسرها از قسمت ارتباطی لایه‌ وب با سایر لایه‌ها مانند کد مربوط به ارتباط با بانک اطلاعاتی مانند Session Beanها در EJBهاست. پیشنهاد من بکارگیری جایگزین‌های ساده‌تر به جای آنها همانند Seam است.
▪ خطرناک‌ترین اشتباهاتی که برنامه‌نویسان جاوا در کد زدن با تِرِدها (Thread) می‌کنند در کدام قسمت است؟
ـ مجددا تاکید می‌کنم، این درست نیست که برنامه‌نویس را در مواردی که نقص در ذات طراحی نهفته‌ است مقصر دانست. به قول برایان گوتز جاوا به ابزاری شبیه به Garbage collector که پاکسازی حافظه را انجام می‌دهد، برای برنامه‌نویسی تردها نیاز دارد. شاید گروهی از برنامه‌نویسان رنج مدیریت حافظه در کد C و C++ را به خاطر بیاورند. بنابراین بزرگ‌ترین اشتباه این است که در برنامه‌نویسی ترد، به صورت عادی از منابع سیستم استفاده کنیم. از به اشتراک گذاری داده‌ها بپرهیزیم، از ساختارهای مطمئن داده در ارتباطات بین تردها استفاده کنیم و از این قبیل. برایان کتاب کاملی در این زمینه نوشته است.
▪ چه نصیحتی برای مبتدیان دارید؟
ـ اول اینکه وحشت‌زده نشوند! معمولاً دانش‌آموزان در ابتدا رابط برنامه‌نویسی پیچیده‌ای با هزاران کلاس می‌بینند. من به آنها تاکید می‌کنم که نکته مهم در این است که جاوا، زبانی بسیار آسان است. مسئله دوم خود کد است. بیشتر برنامه‌نویسان حرفه‌ای فراموش می‌کنند که چقدر کد زدن برای مبتدیان مشکل است. کد زدن برخلاف فعالیت‌های عادی روزمره است. کامپیوتر جایی برای بخشش در کد خطادار باقی نمی‌گذارد! در صورت نوشتن کد خطا بلافاصله با پیام خطای مربوط به آن مواجه خواهید شد. پس با هر خطا متوقف شده و نیاز به فکرکردن وجود دارد و راه‌حل‌های تصادفی کمتر به نتیجه خواهد رسید. دعوت به سخت‌کوشی در دانش‌آموزان امروزی تاثیر چندانی ندارد. با رخداد خطاهای پی در پی ممکن است برنامه‌نویس به مرزی از افسردگی برسد و تنها در صورت رفع مشکل و به هدف رسیدن کد است که افسردگی فوق برطرف می‌گردد. در این حالت باید به مبتدیان کمک نمود از مرحله سختی‌ها بگذرند.
▪ بزرگ‌ترین اشتباهاتی که معلم‌های برنامه‌نویسی جاوا مرتکب می‌شوند، چیست؟
ـ سمینارهای آموزشی خیلی طولانی هستند. به نظر من آموزش، بیش از مدت ۵۰ تا ۷۵ دقیقه بدون فرصت دادن به دانش‌آموز برای بررسی و مرور آموخته خود بیهوده است. این روزها تمام شاگردان من لپ‌تاپ دارند، در ابتدا ۱۵ تا ۲۰ دقیقه آموزش داریم، بعد یک کار عملی با کامپیوتر؛ سپس یک آموزش کوتاه دیگر و یک آزمایش عملی مجدد و در نهایت ۵ دقیقه زمان برای جمع‌بندی مطالب صرف می‌کنیم.
▪ دوست دارید که در نسخه آینده جاوا، یعنی ۷ چه چیزهای جدید ببینید؟ آیا شما به مخفف‌سازی (closures) در زبان اعتقاد دارید؟
ـ بله من دوست دارم مخفف‌ها را ببینم. زمانی که من مخفف‌ها را در کلاس آموزش جاوا تدریس می‌کنم، به روشنی می‌بینم که ساختار املایی کد رابطه مناسبی با برنامه‌نویس برقرار نمی‌کند. دانش‌آموزان از اینکه متغیرهای محلی گرفته شده با مخفف‌ها در طول کار معتبر باقی‌ می‌مانند بسیار شگفت‌زده می‌شوند. در حالت کلی مخفف‌ها این قدرت را به برنامه‌نویسان کتابخانه‌های جاوا می‌دهد که کد راحت‌تری برای برنامه‌نویسان نهایی فراهم سازند که این امر در امکانات گسترده‌ای که در جاوا ۵ به وجود آمد اضافه شد. به کمک آنها می‌توان به طرز سحرانگیزی در کد، حاشیه‌نویسی (annotation) انجام داد. به نظر من بحث generic کارها را در جاوا بهتر نموده‌ است ولی متاسفانه این امر ممکن است تمام توجه یک برنامه‌نویس را به جزئیات کار جلب کند. اما در بیشتر موارد genericها راحت هستند و کارها را آسان می‌کنند.
به نظر من خیلی بهتر است که به جای یک لیست ساده List یک لیست از جنس معین List داشته باشیم. اما چیزی که دوست دارم در جاوا ۷ یا ۸ ببینم، تغییرات در نحوه تعامل در کنترل خطاهاست.
▪ چه کلاسی در زبان جاواست که بدون آن نمی‌توانید زندگی کنید؟!
ـ java.lang.Object … !
▪ چه تغییراتی در چارچوب جاوا زندگی شما را شیرین‌تر می‌کند؟
ـ در حالت کلی generic، اما در حالت خاص من از بهبودهایی در گرامر کد که به ساده‌تر شدن برنامه‌نویسی کمک می‌کند خوشم می‌آید، مانند تغییر در ساختار کد مربوط به حلقه for در نسخه‌های اخیر جاوا.
▪ دیدگاه شما در مورد تولد رو به ازدیاد زبان‌های اسکریپ‌نویسی همانند Perl، PHP، Python، Groovy و Ruby چیست؟ آیا هر کدام از آنها کاربرد مخصوص به خود دارند؟
ـ شما به درستی دست بر روی نقطه حساسیت‌های من گذاشتید! به نظر من جالب است که افراد به مقاصد آموزشی پژوهشی زبان‌های جدیدی را بیافرینند و بیاموزند. اما این زبان‌ها در نهایت محکوم به نابودی هستند. چه مزیتی در بکارگیری همزمان زبان‌هایی که نام بردید وجود دارد؟ من به عنوان یک برنامه‌نویس نیاز به فراگیری و البته استفاده از یک زبان اسکریپت‌نویسی دارم، پرداختن به سایرین به نظر من وقت تلف کردن است. از دیدگاه زبان جاوا، Groovy بهترین کاندیدا برای یادگیری است. Groovy ساختار گرامری شبیه به زبان جاوا دارد و یک پروتکل شبیه به اشیای جاوا که دسترسی به Grails را ممکن می‌سازد. با وجود آنکه طراحان آن زمان زیادی را برای طراحی صرف نموده‌اند، اما قسمت‌های فراوانی از آن ضعف دارند یا حتی در حال تغییر هستند. به عنوان مثال فلسفه وجود Groovy MOP را به جز برای دسترسی به سورس کد Grails درک نمی‌کنم.
▪ در پایان، اگر موردی به نظرتان می‌رسد که در سئوالات عنوان نشده ‌است، بفرمایید.
ـ البته، مقایسه لحن موجود در وبلاگ‌های اختصاصی زبان C# با لحن جاری در وبلاگ‌های جاوایی غصه من شده ‌است! بیشتر برنامه‌نویسان C# راجع به موهبتی دوست‌داشتنی صحبت می‌کنند که از ردموند (مایکروسافت) برایشان نازل شده‌ است که آنها استفاده کنند و لذت ببرند. اما در دنیای جاوا دوستان برنامه‌نویس همیشه از ناقص بودن چیزی یا نیاز به بهبود چیزی دیگر می‌نویسند. اما آیا C# واقعاً آنچنان مخلوقی است که هیچ کاربری از آن شکایت نمی‌کند؟ البته که من اینطور فکر نمی‌کنم. اگر اینطور بود بیشتر مردم در یک انتخاب به استفاده از C# می‌رسیدند!! به نظر من انجمن برنامه‌نویسان جاوا دارای یک فرهنگ سالم از گزارش ایرادات در جهت بهبود کار است.
همه اعضا در این انجمن دارای خواسته و انگیزه برای بهبود اوضاع هستند‍، زیرا هر کدام در آن نقشی برای خود می‌بینند، بر خلاف بی ارادگی موجود در C# برای پذیرش آنچه که به آنها دیکته می‌شود. در اینجا کسی منتظر Sun یا شرکتی شبیه به آن برای برطرف‌سازی ایرادات نمی‌نشیند. ما در حال استفاده و اتصال هزاران پروژه و کتابخانه و چارچوب در جهت بهبود آنها و حتی ساختن زبانی کامل‌تر هستیم. حرکت جاوا به سوی سورس باز، گامی در جهت تحقق اهداف فوق برای سال‌های آینده است.

منبع : بنیاد آینده نگر ایران