جاوا مؤثرتر با جوشوا بلوچ گوگل

جوشوا بلوچ ، رئیس جاوا معمار Google ، یک مهندس برجسته سابق در Sun Microsystems است ، جایی که وی طراحی و اجرای ویژگی های متعدد پلت فرم جاوا ، از جمله پیشرفت های زبان JDK 5. 0 و چارچوب برنده جایزه مجموعه جاوا را بر عهده داشت. او دارای دکتری است. در علوم کامپیوتر از دانشگاه کارنگی-مولون.

بلوچ جایزه معتبر JOLT را از مجله توسعه نرم افزار برای اولین نسخه از کتاب خود در سال 2001 ، راهنمای مؤثر برنامه نویسی جاوا ، که برای بسیاری از توسعه دهندگان به عنوان جاوا مؤثر شناخته شده است ، کسب کرد ، و او همچنین همکار (با نیل گفر) از کتاب بسیار مورد توجه جاوا استمعجزه سازان

اگر یک کتاب وجود داشته باشد که توسعه دهندگان جاوا بارها از آن به عنوان مورد علاقه خود یاد می کنند ، جاوا مؤثر است.

س: در مقدمه نسخه جدید جاوا مؤثر ، شما در سال 2004 به Google رفتید و نوشتم: "من همچنین از استفاده از پلت فرم جاوا برای توسعه کتابخانه ها برای استفاده در Google استفاده کردم. اکنون می دانم چه احساسی دارددوست دارم کاربر باشم. "تجربه شما به عنوان کاربر چگونه نسخه جدید کتاب را آگاه کرد؟

پاسخ: خوب ، برای یک چیز ، این احساس من را تقویت کرد که دستیابی به درستی از طرح های API بسیار مهم است. به عنوان مثال ، من خودم را پیدا کردم که می خواهم یک اجرای جایگزین Filechannel را برای سیستم Google File ارائه دهم ، اما نتوانستم ، زیرا FileChannel یک کلاس بتونی است نه یک رابط. به همین ترتیب ، من می خواستم یک بایته قابل رشد را پیاده سازی کنم. اینها نوعی ناامیدی است که توسعه دهندگان عادی هر روز احساس می کنند.

س: شما گفته اید که یک تقصیر مشترک در بین توسعه دهندگان جاوا ، تمایل طبیعی به بهینه سازی کد است که منجر به کد کندتر می شود که بی نیاز پیچیده است. چرا توسعه دهندگان به اشتباه کد را بهینه می کنند؟

"آسان است که احساس کنید هشدارهای عمومی در مورد بهینه سازی زودرس برای شما اعمال نمی شود ، زیرا شما فقط می دانید کدام کد زمان بسیار مهم است و چگونه می توان آن را سریع ساخت..

جوشوا بلوچ نویسنده ، جاوا مؤثر ، چاپ دوم

پاسخ: برای اینکه یک توسعه دهنده نرم افزار باشید ، باید خوش بین باشید - در غیر این صورت ، این یک نبرد باخت است. به طور کلی ، این یک چیز خوب است ، اما روند نزولی دارد: خوش بینی می تواند به اعتماد به نفس منجر شود. به راحتی می توان احساس هشدارهای عمومی در مورد بهینه سازی زودرس را برای شما صدق کرد ، زیرا فقط می دانید کدام کد بسیار مهم است و چگونه می توان آن را سریع انجام داد. اما هیچ کس نمی تواند این کار را بدون اندازه گیری قبل و بعد از هر تلاش بهینه سازی تعیین کند.

س: تقصیر دیگری که به آن اشاره می کنید شامل توسعه دهندگان است که در صورت وجود کتابخانه های کاملاً خوب ، کد خود را می نویسند. چرا توسعه دهندگان این کار را انجام می دهند؟

پاسخ: دو دلیل: شایع ترین دلیل این است که توسعه دهنده نمی داند که کتابخانه وجود دارد. من برای آن توسعه دهنده احساس می کنم ، زیرا کتابخانه های زیادی در آنجا وجود دارند که پیگیری همه آنها غیرممکن است. به گفته این ، گرفتن برخی از این امکانات به درستی دشوار است که ارزش این را دارد که تلاش کنید تا دریابید که آیا یک کتابخانه وجود دارد یا خیر.

این امر به ویژه در جایی که همزمانی درگیر است صادق است. برای کارشناسان غیر معمول نیست که ماهها به معنای واقعی کلمه نوشتن برنامه های همزمانی متوسط را بگذرانند. هنگامی که با نیاز به این نوع قابلیت ها روبرو شوید ، توسعه دهنده خردمند هر کاری را که برای یافتن یک کتابخانه مناسب انجام می دهد ، انجام می دهد. اشتباه کردن کد همزمان غیر متعارف بسیار آسان است و اشکالات حاصل از آن می تواند تقریباً غیرممکن باشد.

دومین دلیل که توسعه دهندگان تمایل به اختراع مجدد چرخ دارند ، همان دلیلی است که آنها تمایل به بهینه سازی زودرس دارند: برای ماندن عاقل ، بیشتر توسعه دهندگان دارای نگرش می توانند انجام دهند و برخی آن را خیلی دور می کنند. آنها با خود می گویند ، "بله ، یک کتابخانه وجود دارد ، اما من می توانم بهتر عمل کنم."شاید بتوانید ، اما این بدان معنی نیست که شما باید. از کتابخانه استاندارد استفاده کنید مگر اینکه عمیقاً به نیازهای شما دست نخورده باشد.

نادیده گرفتن کتابخانه ها

"برای اینکه عاقل بمانیم ، بیشتر توسعه دهندگان یک نگرش می توانند انجام دهند و برخی آن را خیلی دور می کنند. آنها به خودشان می گویند ،" بله ، یک کتابخانه وجود دارد ، اما من می توانم بهتر عمل کنم. "شاید بتوانید ، اما این بدان معنی نیست که شما باید. "

جوشوا بلوچ نویسنده ، جاوا مؤثر ، چاپ دوم

س: جورج اورول مشهور پنج قانون نوشتن خوب را ارائه داد - و سپس ششم اضافه كرد: "هر یك از این قوانین را زودتر از آنكه هر چیزی بی وحشیانه بگوید ، بشکنید."جاوا مؤثر در حال حاضر از 78 مورد با عناوین متشکل از قوانین کوتاه مانند "روشهای عمومی طرفداری" یا "استفاده از یک فرم سریال سفارشی" را در نظر بگیرید تا دو را به طور تصادفی انتخاب کنید. آیا قوانین مورد علاقه ای دارید؟و چه زمانی توسعه دهندگان باید قوانین را بشکنند؟

جوشوا بلوچ امضای جاوا مؤثر در جازون

پاسخ: اول ، باید خاطرنشان کنم که من بی شرمانه هشدار اورول را به سرقت بردم. در مقدمه جاوا مؤثر ، می گوید: "شما نباید به طرز برده ای از این قوانین پیروی کنید ، بلکه آنها را فقط گاهی و با دلیل خوب نقض کنید."

من می توانم تا حدودی ناخوشایند باشم ، بنابراین اگر در یک روز دیگر از من بخواهید قوانین مورد علاقه من تغییر کند ، اما امروز من با مورد 13 می روم ، "دسترسی به کلاس ها و اعضا را به حداقل می رسانم" و مورد 15 ، "به حداقل رساندن جهش". هر دوی این قوانین از هر زبان برنامه نویسی خاص فراتر می روند.

اولین مورد به شما می گوید که اطلاعات را به حداکثر حداکثر امکان پذیر کنید. این اصل ، که در اصل به دیوید پارناس است ، یکی از اساسی ترین اصول برنامه نویسی خوب است. اگر اطلاعات را مخفی می کنید ، بدون اینکه به خطر وارد شود ، آن را تغییر می دهید. مخفی کردن اطلاعات ، اجزای سیستم را دفع می کند و به آنها امکان توسعه ، آزمایش ، بهینه سازی ، استفاده ، درک و اصلاح در انزوا می دهد.

مورد 15 به شما می گوید فضای حالت هر شی را تا حد امکان ساده نگه دارید. اگر یک شی تغییر ناپذیر باشد ، می تواند فقط در یک ایالت باشد و شما بزرگ برنده می شوید. شما هرگز نباید نگران باشید که شیء در چه حالت قرار دارد و می توانید آن را آزادانه و بدون نیاز به هماهنگ سازی به اشتراک بگذارید. اگر نمی توانید یک شی را تغییر ناپذیر کنید ، حداقل میزان جهش ممکن را به حداقل برسانید. این امر استفاده صحیح از شی را آسان تر می کند.

به عنوان نمونه ای شدید از آنچه نباید انجام شود ، پرونده java. util. calendar را در نظر بگیرید. تعداد بسیار کمی از مردم فضای وضعیت آن را درک می کنند-من مطمئناً این کار را نمی کنم-و سالهاست که منبع مداوم اشکالات بوده است.

پس چه زمانی باید قوانین را بشکنید؟برای پاراگراف اورول ، باید آنها را بشکنید که آنها به کدی که "آشکار وحشیانه" است ، آنها را بشکنید. به عنوان یک مثال ساده ، مورد 25 می گوید: "لیست ها را به آرایه ها ترجیح دهید."بنابراین چرا روش مقادیر موجود در هر نوع enum یک آرایه را برمی گرداند؟از آنجا که متداول ترین استفاده از این روش ، تکرار بیش از عناصر ارزش بازگشت آن است و تکرار بیش از یک آرایه از هر اجرای لیست بسیار ارزان تر است. با ساختار برای هر نوع ، کد To Iderate به هر صورت یکسان است:

برای (سیاره P: Planet. Values ())

ممکن است فکر کنید که این بهینه سازی زودرس از طرف طراحان enum بود ، اما اینطور نبود. این فقط کد حلقه داخلی نیست ، بلکه حلقه (درونی) است. البته ، ما (گروه متخصص JSR 201) قبل از تصمیم گیری ، اندازه گیری عملکرد گسترده ای انجام دادیم و من راضی هستم که تصمیم درستی گرفتیم.

بار دیگر که باید قوانین را بشکنید ، زمانی است که دو قانون شما را به سمت تصمیمات مخالف سوق می دهد. در چنین مواردی ، شما مجبور هستید حداقل یکی از قوانین را نقض کنید و باید انتخاب کنید که از اهمیت بیشتری برخوردار است ، که می تواند بسیار دشوار باشد.

وقتی با چنین تصمیماتی روبرو شدم ، معمولاً برای بررسی عقل با شخص دیگری صحبت می کنم. در انجام این کار شرم آور نیست و مطمئناً بهترین عمل است. برخلاف تصور عامه ، طراحی نرم افزار یک شغل انفرادی نیست - یا نباید باشد.

ژنتیک ، شمشیر و حاشیه نویسی

س: از آنچه شما معتقدید توسعه دهندگان باید در مورد ژنرال ها ، شمشیربازی ها و حاشیه نویسی ها بدانند ، به ما طعم دهید.

پاسخ: با توجه به محدودیت های فضا ، باید طعم کوچکی باشد ، اما در اینجا می رود.

برای Generics ، نیش صدا "از انواع خام استفاده نکنید" (مورد 23). اگر یک طراح کتابخانه وقت خود را برای نوشتن یک کتابخانه عمومی می گرفت ، باید از آن استفاده کنید. به عبارت دیگر ، این کار را نکنید:

"برای ژنرال ها ، نیش صدا" از انواع خام استفاده نکنید. "اگر یک طراح کتابخانه وقت خود را برای نوشتن یک کتابخانه عمومی می گرفت ، باید از آن استفاده کنید. "

جوشوا بلوچ نویسنده ، جاوا مؤثر ، چاپ دوم

در ابتدا ، این ممکن است به نظر بی رحمانه بی نیاز باشد ، اما اینطور نیست. با گفتن کامپایلر چه نوع عناصر موجود در لیست ، شما آن را قادر می سازد بسیاری از خطاها را در زمان کامپایل پیدا کنید که در غیر این صورت باعث ایجاد یک ClassCastexception در زمان اجرا می شود. شما همچنین بازیگران زشت را از برنامه خود حذف می کنید.

برای enums ، نیش صدا "همیشه از enums به جای ثابت های int استفاده کنید" (مورد 30). Enums مزایای بسیاری را ارائه می دهد: ایمنی از نوع زمان کامپایل ، امکان اضافه کردن یا حذف مقادیر بدون شکستن مشتری ، مقادیر چاپی معنی دار ، امکان ارتباط روشها و زمینه ها با مقادیر و غیره. از آنجایی که ما در آن قرار داریم ، این توصیه به همان اندازه در زمینه های بیت اعمال می شود ، که باید منسوخ تلقی شوند.

برای حاشیه نویسی ، نیش صدا "خود را تعریف نکنید ، مگر اینکه دلیل بسیار خوبی داشته باشید ، اما از موارد استاندارد برای محیط خود استفاده کنید."برای بسیاری از برنامه نویسان ، تنها مواردی که مهم هستند Override (مورد 36) و spresswaings (مورد 24) هستند. استفاده از حاشیه نویسی Override راهی آسان برای نجات خود از خطاهایی است که در غیر این صورت تشخیص آن بسیار سخت خواهد بود. نکته قابل توجه ، غیر معمول نیست که به طور تصادفی روش برابر را هنگام غلبه بر آن اضافه کنید ، و باعث خطاهای ظریف و خطرناک می شود:

اگر به کامپایلر بگویید که فکر می کنید در حال غلبه بر یک روش ابرقهرمانی هستید ، شما را از خطای خود مطلع می کند:

بهترین روشها برای اولیه سازی تنبل

س: درک در مورد بهترین شیوه های اولیه سازی تنبل چه چیزی مهمتر است؟

پاسخ: مهمترین توصیه این است که "این کار را نکنید مگر اینکه شما نیاز داشته باشید."اکثریت بزرگ کد اولیه سازی شما باید به این شکل باشد:

اگر برای صحت به اولیه سازی تنبل نیاز دارید - اما نه برای عملکرد - فقط از یک دسترسی هماهنگ استفاده کنید. این ساده و به وضوح صحیح است.

اگر به عملکرد بهتری احتیاج دارید ، بهترین انتخاب شما به این بستگی دارد که آیا شما یک زمینه استاتیک یا یک قسمت نمونه را اولیه می کنید. اگر این یک زمینه استاتیک است ، از Idiom Holder Holder Holder Lazy استفاده کنید:

این اصطلاح تقریباً جادویی است. همگام سازی در جریان است ، اما نامرئی است. محیط زمان اجرا جاوا این کار را برای شما انجام می دهد ، در پشت صحنه. و بسیاری از VM ها در واقع کد را برای از بین بردن همگام سازی پس از لزوم دیگر ، از بین می برند ، بنابراین این اصطلاح بسیار سریع است.

اگر به اولیه سازی تنبل با کارایی بالا در یک قسمت نمونه نیاز دارید ، از اصطلاح دو بررسی با یک زمینه فرار استفاده کنید. این اصطلاح تضمین نمی شد تا زمان انتشار 5. 0 ، هنگامی که این سیستم عامل یک مدل حافظه جدید را بدست آورد ، کار کند. اصطلاح بسیار سریع اما پیچیده و ظریف است ، بنابراین وسوسه نشوید که به هیچ وجه آن را اصلاح کنید. فقط کپی و چسباندن - به طور معمول ایده خوبی نیست ، اما در اینجا مناسب است:

برای اطلاعات بیشتر در مورد این موضوع ، به مورد 71 مراجعه کنید.

س: چیزی را برای ما بگویید که در نسخه دوم جاوا مؤثر به آن افتخار می کنید.

پاسخ: من افتخار می کنم که حتی با رشد زبان توانستم احساس کتاب را حفظ کنم. یکی از دلایلی که چاپ اول بسیار موفق بود این بود که کوچک و قابل دسترسی بود. علاوه بر این از تمام ویژگی های جدید زبان و کتابخانه ، این سکو را بزرگتر و پیچیده تر کرده است. به ناچار ، این کتاب رشد کرد (از 57 مورد به 78) ، اما من واقعاً سعی کردم آن را کوتاه و روشن نگه دارم. بر اساس بازخورد اولیه ، فکر می کنم تا حد زیادی موفق بودم.

عجیب ترین چیز در مورد سکوی جاوا

س: پس از هفت سال دیگر برای تأمل در مورد توسعه سکوی جاوا ، عجیب ترین چیزی که می توانید در مورد آن بگویید چیست؟

پاسخ: اوه ، سوال خوب. من می خواهم بگویم که عجیب ترین چیز در مورد سکوی جاوا این است که نوع بایت امضا شده است. من هرگز توضیحی در این باره نشنیده ام. این کاملاً ضد انعطاف پذیر است و باعث ایجاد انواع خطا می شود. به عنوان مثال ، به نظر شما این برنامه چه کاری انجام می دهد؟

اگر شک دارید ، آن را اجرا کنید. اگر برای رفتار به توضیحی نیاز دارید ، نسخه ای از Puzzlers Java را پیدا کنید و به Puzzle 24 نگاه کنید.

تست های واحد ضروری است

س: دکتر هاینز کابوت ، قهرمان جاوا ، دریافت که عدم آزمایش واحد یک مشکل بزرگ در بین توسعه دهندگان جاوا است. او گزارش می دهد ، "در کنفرانس ها ، من می پرسم ،" چه تعداد از شما آزمایش واحد برای کد خود دارید؟ "تقریباً هیچ کس دست خود را بالا نمی برد - و اینها متخصصان باتجربه هستند. "واکنش شما؟

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

توجه داشته باشید ، با این حال ، آزمایش های واحد برای اطمینان از کار کد شما کافی نیستند. شما باید کد را درک کرده و به خودتان ثابت کنید که کار می کند. و شما باید شخص دیگری را مرور کنید. وقتی صحبت از کد می شود ، دو سر واقعاً بهتر از یک است. برای بحث بیشتر در مورد این موضوع ، به مقاله جستجوی باینری من مراجعه کنید.

readresolve همه چیز شکسته نیست

س: وقتی جاوا مؤثر را تجدید نظر کردید ، گفتید که باید در نسخه اول همه چیز را به طور انتقادی بررسی کنید. آیا در ابتدا چیزی نوشتید که فهمیدید گمراه شده است؟

پاسخ: بله. از یک چیز ، من فکر می کردم که یک روش Readresolve با اطمینان تضمین می کند که یک مجرد در مواجهه با سریال سازی و دفع کردن ، یک مجرد باقی مانده است. معلوم است که این کاملاً درست نیست.(به مورد 77 مراجعه کنید.)

خوشبختانه ، یک راه حل خوب وجود دارد: Singleton Serializable خود را به عنوان یک مجموعه یک عنصر اجرا کنید. همچنین ، من در حالی که نسخه اول را با یک شانه دندان ریز ، به شکل تایپی که به مدت هفت سال از بین رفت ، شرمساری های جزئی مختلفی را کشف کردم. خوشبختانه ، من الان هیچ یک از آنها را به یاد نمی آورم.

نویسنده بهتری شوید

س: شما گفته اید که توسعه دهندگان باید کتاب Strunk و White را عناصر سبک بخوانند زیرا نویسنده بهتر شما را به یک توسعه دهنده بهتر تبدیل می کند. آیا می توانید توضیح دهید که چرا این چنین است؟

پاسخ: من معتقدم که خواندن Strunk و White شما را به یک توسعه دهنده بهتر تبدیل می کند زیرا برنامه نویسی خوب و نوشتن خوب هم در مورد وضوح و هم اقتصاد بیان است. شما نمی توانید کد خوب یا نثر خوب بنویسید مگر اینکه بفهمید که می خواهید بگویید. بسیاری از توصیه های Strunk و White دارای آنالوگ مستقیم برای نرم افزار هستند. به عنوان مثال ، Strunk و White می گویند ، "کلمات بی نیاز را حذف کنید!"جایی که اندی هانت و دیو توماس ("برنامه نویسان عملی") می گویند ، "خودتان را تکرار نکنید."Strunk و White می گویند ، "تجدید نظر و بازنویسی" ، جایی که مارتین فاولر می گوید ، "Refactor". و لیست ادامه دارد.

در حقیقت ، بسیاری از توصیه های Strunk و White حتی لازم نیست که برای استفاده از نرم افزار استفاده شوند. در اینجا چند مثال آورده شده است که از جدول مطالب عناصر سبک گرفته شده است:

• یک طرح مناسب را انتخاب کنید و آن را نگه دارید
• واضح بودن
• میانبرهایی را با هزینه وضوح مصرف نکنید

س: کدام اصول جدید در جاوا مؤثر ممکن است به عنوان بهترین شیوه ها در IDE NetBeans ادغام شود؟

پاسخ: بسیاری از قوانین در نسخه اول به عنوان "بازرسی" در IDE هایی مانند NetBeans ، Intellij و Eclipse اسیر شده اند. به همین ترتیب ، ابزار FindBugs کار خوبی در خودکار کردن این چک ها انجام می دهد. من گمان می کنم که بسیاری از قوانین جدید راه خود را برای این ابزارها پیدا می کنند.

به عنوان یک نمونه ساده ، من می دانم که IDES در حال حاضر حضور حاشیه نویسی Override را بررسی می کند و وقتی فراموش کرده اید به شما هشدار می دهد.

چگونه ژنرال ها کار کردند

س: در سال 2003 ، شما اظهار داشتید که اگر هر یک از تغییرات در J2SE 5. 0 ممکن است چالش های خاصی را برای توسعه دهندگان جاوا ایجاد کند ، این امر تولید کننده خواهد بود ، زیرا توسعه دهندگان "باید برای ارائه اطلاعات اضافی در اعلامیه ها عادت کنند."به نظر شما ژنرال ها چگونه کار کرده اند؟

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

Generics مطمئناً ایمنی و بیان زبان را بهبود بخشید ، و من بسیار خوشحالم که آنها اضافه شدند. اما آنها یک موفقیت غیرقابل قبول نبوده اند. شما فقط برای قدردانی از این امر باید سؤالات متداول Generics Generics Angelika Langer را جستجو کنید. بنابراین آرزو می کنم که بتوانیم طراحی را ساده کنیم.

من همچنین آرزو می کنم که ما راهی پیدا کنیم که ژنرال ها را با انواع ابتدایی کار کنیم ، به طوری که می توانستیم از اتوبوکس و خودکار جعبه ای که مستعد ابتلا به اشکال است ، اجتناب کنیم.

به نظر شما این برنامه چه چیزی را چاپ می کند؟اگر شک دارید ، آن را اجرا کنید:

آینده پلتفرم جاوا

س: آیا می خواهید در مورد آینده سکوی جاوا به طور کلی و به ویژه بسته شود؟

پاسخ: پیش بینی آینده سکو دشوار است. از زمان انتشار Java SE 6 ، همه چیز به آرامی حرکت کرده است ، و هیچ کس کاملاً مطمئن نیست که چه چیزی در Java SE 7 می آید ، یا چه زمانی در حال آمدن است.

من متقاعد شده ام که زبان برنامه نویسی جاوا با تغییرات معرفی شده در نسخه 5. 0 از بودجه پیچیدگی خود استفاده کرده است. این یک اشتباه بزرگ است که هرگونه ویژگی جدید زبان را اضافه کنید که پیچیدگی زبان را به میزان قابل توجهی افزایش می دهد. من بسته های BGGA را به صورت مربع در این گروه قرار می دهم. برای اطلاعات بیشتر در مورد این موضوع ، می توانید نگاهی به گفتگوی جنجالی تعطیلی بیندازید.

مجموعه ای متوسط از تغییرات جزئی زبان می تواند زبان را بهبود بخشد ، اما باید با حداکثر محدودیت انجام شود.

در هنگام توسعه زانی و مسخره

س: شما سابقه طولانی در تأکید بر تفریح در هر کاری دارید. در دفاع از دکتری خودپایان نامه ، شما به یک سؤال کاشته شده با یک آهنگ رپ پاسخ داده اید که توسط یک آهنگ ریتم ضبط شده در ضبط صوت پنهان است. و شما و نیل گافتر روال "جاوا پوززلیرز" را انجام دادید که در آن لباس های مکانیک را اهدا نکردید و خود را "کلیک و هک ، برادران نوع" نامیدید ، پس از صحبت کردن در مورد نمایشگاه رادیویی. در مورد اهمیت Zaniness ، Goodiness و شادی در روند توسعه چه چیزی می توانید بگویید؟

"من متقاعد شده ام که زبان برنامه نویسی جاوا با تغییرات معرفی شده در نسخه 5. 0 از بودجه پیچیدگی خود استفاده کرده است. اضافه کردن هرگونه ویژگی جدید زبان که باعث افزایش پیچیدگی زبان می شود ، اشتباه بزرگی خواهد بود."

جوشوا بلوچ نویسنده ، جاوا مؤثر ، چاپ دوم

پاسخ: این بخش بزرگی از من است که من هستم و چه کاری انجام می دهم. همانطور که همیشه می گویم ، علوم کامپیوتر یک رشته نابالغ است و هدف من این است که آن را حفظ کنم. من وقتی سرگرم می شوم و اشتیاق خود را دنبال می کنم ، کار بهتری انجام می دهم. من بسیار سپاسگزارم که توانسته ام خیلی از مشاغل دانشگاهی و حرفه ای خود را صرف انجام این کار کنم.

مشاوره برای توسعه دهندگان جدید

س: جاوا مؤثر کتابی است که برای توسعه دهندگان با تجربه جاوا نوشته شده است. آیا توصیه ای در مورد چگونگی بهره مندی از علوم کامپیوتر در کالج از کتاب دارید؟یا یک توسعه دهنده باتجربه که از زبان دیگری به جاوا منتقل می شود؟

پاسخ: بسیاری از برنامه نویسان می دانند که یک کپی را در میز خود نگه دارید تا بتوانند در هنگام کار به نمونه های کد و مواردی از این دست نگاه کنند. همچنین ، من دیده ام که مردم در اظهار نظر در مورد تصمیمات طراحی خود از منابع "مورد" کتاب استفاده می کنند. نیازی به گفتن نیست ، من افتخار می کنم که آنها این کار را کرده اند.

در مورد برنامه نویسان که از یک زبان دیگر حرکت می کنند ، فکر می کنم آنها قبل از مقابله با کتاب من ، یک مقدمه سریع با جاوا را بخوانند. کتاب Peter Sestoft Java دقیقاً یک انتخاب عالی خواهد بود.< Pan> س: جاوا مؤثر کتابی است که برای توسعه دهندگان با تجربه جاوا نوشته شده است. آیا توصیه ای در مورد چگونگی بهره مندی از علوم کامپیوتر در کالج از کتاب دارید؟یا یک توسعه دهنده باتجربه که از زبان دیگری به جاوا منتقل می شود؟