Я начал свою карьеру в Java с J2EE 1.2. У меня возникли вопросы: почему для каждого bean-компонента было четыре класса и сотни строк сгенерированного кода? Почему компиляция крошечных проектов заняла полчаса? Это не было ни продуктивно, ни весело. Эти двое часто идут рука об руку: вещи кажутся неприятными, потому что мы знаем, что это трата. Подумайте о встречах, на которых ничего не решено, отчеты о состоянии никто не читает ...
Если не-веселье - это плохо, что такое? Это хорошо? А как нам это получить? У веселья могут быть разные лица:
- разведка (целенаправленное расследование)
- играть (само по себе, без гола)
- пазлы (правила и цель)
- игры (правила и победитель)
- работа (удовлетворительная цель)
Java позволяет все это - рабочая часть очевидна, и любой, кто отлаживал Java-программу, знает о головоломке. (Отладка не обязательно увлекательна, но найти решение - это здорово.) Мы учимся через исследование (когда мы в чем-то новички) и играем (когда мы знаем достаточно, чтобы что-то делать).
Не говоря уже об удовольствии, которое мы можем получить с ним, разве Java по своей сути интересна? Java многословен по сравнению с более молодыми языками. Boilerplate - это не весело, но кое-что поправимо. Например, Lombok аккуратно генерирует геттеры и сеттеры, а также методы hashCode и equals (в противном случае это утомительно и подвержено ошибкам). Записывать трассировку входа и выхода вручную - это неинтересно, но аспекты или библиотеки трассировки могут работать динамически (и значительно улучшить читаемость кода).
Что делает использование чего-то интересным? Отчасти речь идет о выразительности и понятности, но это еще не все. Я не уверен, что лямбды обычно короче или яснее, чем альтернативы на основе классов. Но они веселые! Когда вышла Java 8, разработчики погрузились в лямбды, как дети в яму с мячом. Мы хотели узнать, как это работает (исследование) и как сложна задача выражения алгоритмов в функциональном стиле (головоломки).
С Java часто самое интересное - это тоже самое лучшее (победа). Автоинструментальная трассировка позволяет обойти неприятности, исключая ошибки копирования и вставки имени метода и улучшая ясность. Или подумайте о производительности. Для нишевых сценариев необходим странный сложный код, чтобы очистить каждый дюйм скорости. Однако в большинстве случаев самый простой код также самый быстрый. (Что не обязательно верно для таких языков, как C.) Java JIT оптимизирует код во время его выполнения; это умнее всего для чистого идиоматического кода. Простой код хорошо читается, поэтому ошибки будут более очевидными.
Код, вызывающий страдания, имеет эффект подделки. Психологические исследования показывают, что счастье и успех на рабочем месте идут рука об руку. Одно исследование показало, что люди с позитивным мышлением на 31% более продуктивны, чем люди с нейтральным или негативным мышлением. Вы добьетесь меньшего, используя плохо спроектированные библиотеки, и потом продолжите добиваться меньшего, потому что плохой код сделал вас несчастными.
«Развлечение - это хорошо» - оправдание безответственности? Нисколько! Подумайте, всем ли нравится: все - это заказчики, коллеги и будущие сопровождающие ваш код. По сравнению с динамически типизированными языками сценариев, которые могут быть быстрыми и свободными, Java уже ставит галочки в безопасном и ответственном поле. Но программы, которые мы пишем, также должны быть ответственно написаны.
Хорошая новость заключается в том, что практически со всеми скучными задачами компьютеры могут выполнять работу быстрее и точнее, чем люди. Компьютеры (пока) не ждут, что им будет весело, поэтому воспользуйтесь ими! Не принимайте скуку. Если что-то кажется неприятным, поищите способ получше. Если его нет, придумайте. Мы программисты: мы можем исправить скучное занятие.
