Способность писать код конечно измерима: цикломатическая сложность, процент дублирования, число варнингов в линтере, число багов, найденных в этом коде, наконец. Но это и для структурного программирования подходит. Мне не приходит в голову ни одной метрики, по которой можно было бы "объективно" отличить хороший ООП-код от плохого при прочих равных.
Как там у вас в 70-х? Доллар по 15 копеек? Хотя какой доллар, о чем я... Просто уже довольно давно все полезное, что было в обмене сообщениями, называют модель акторов. А ООП - это теперь немного про другое: наследование, полиморфизм, вот это вот все.
Возьмите непрограммистов, да возьмите даже программистов - вы не сможете объективно проверить их способность организовывать ООП код. Вы сможете высказать свое субъективное мнение об их способностях организовывать ООП код, Алан Кей сможет высказать свое субъективное мнение, Вася с горы тоже сможет высказать... Про какую "объективно измеримую величину" речь?
А что вы здесь назвали "объективно измеримой величиной", интересно? Определение и тем более понимание ООП - это по-моему одна из наиболее субъективных вещей в индустрии. Возьмите 30 программистов, дайте им сколь-нибудь нетривиальную задачу на ООА, и вы не увидите двух одинаковых решений.
Конкретно для рекордов final не при делах. Там поля неизменяемые и это нельзя контролировать. Но мне правда кажется отсутствие контроля в данном случае - скорее плюс джавы, чем минус.
Если говорить про бумажные книги, то все книги, которые вы в жизни прочитали, вы либо купили сами из своей зарплаты, либо купили выши родственники или друзья с их зарплаты. Ну или вы взяли книгу в библиотеке, соотвественно ее купила библиотека на налоги с вашей зарплаты. Ничего ужасного в этом нет.
Там еще на картинке нарисована Akka. Как человек, однажды пробовавший юзать ее джава-апи, рассматриваю это не иначе как пасхалку от скучающего копирайтера, у которого нейросети отняли всю работу.
Интересно, есть ли какая-нибудь статистика по использованию GraalVM и AoT на реальных проектах? Я всегда думал, что это маргинальные технологии, потому что те, кто гонится за быстрым временем старта, просто не будут выбирать джаву изначально.
Еще одна проблема с их подходом к геймификации в том, что вопросы, на которые можно ответить "из головы", уже по большей части исчерпаны, большинство новых неотвеченных вопросов довольно узкоспециальные. Их можно условно разделить на 2 категории: "новичок не туда поставил скобку" и "уровень курсовой работы, а иногда и кандидатской".
Выходит, что тот, кто 15 лет назад красиво ответил на вопрос "как написать цикл в питоне" сейчас сидит с шестизначным рейтингом. А тебе для ответа на вопрос про хитрый корнер кейс в каком-нибудь редком фреймворке надо потратить несколько часов на ресерч (который автор поленился провести), написать красивый и понятный ответ. Причем автор вопроса получит за это зарплату и съэкономленное время. А ты - потраченное время, и может быть немного рейтинга. Почему "может быть"? Потому что авторы вопросов (особенно, если им несколько дней) далеко не всегда берут на себя труд отметить твой ответ как правильный. Вы можете спросить "а как же чувство глубокого удовлетворения, причастности к сообществу и т.п." - здесь я говорю именно про слабые места геймификации и системы рейтинга.
Именно поэтому лично я отвечаю только на те вопросы, которые я сам искал, и в итоге пришел к решению лучше, чем уже есть в ответах.
Вот кстати да. EJB ведь тоже шел путем добавления абстракций и приводил к кратному увеличению сложности системы. Где сейчас EJB?
И да, я не пытался сказать, что сейчас хуже. Я пытался сказать, что в целом позитивный движ как будто свернул немного не туда. Надеюсь, на следующем витке прогресса народ додумается как получить те же преимущества, но без этой сложности.
А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом. Да, это было не круто. Но этому можно было за час на пальцах научить любого джуна, и дальше они вполне справлялись с поддержкой.
Современные подходы к инфраструктуре, типа service mesh, пошли по пути добавления новых и новых слоев абстракции. Теперь у вас три экземпляра приложения, каждое в своем поде, каждое - за своим прокси, гейтвей, лоад балансер, собиралка логов, собиралка метрик, физическая машина, на которой это в конечном счете крутится (часто, все так же одна единственная, ведь "мы же не гугл"). И у каждого компонента естественно есть свои логи, свои метрики, своя конфигурация при деплое. Каждый компонент - потенциальная точка отказа. Теперь, для того, чтобы с этим всем справится, нужен отдельный специалист. Джун-программист не просто не сможет выполнять такую работу, он скорее всего даже не сможет коммуницировать с таким специалистов в рамках своих задач. Стало ли как-то лучше глобально? Для супер большиъ проектов - наверное да. Остальные и 10 лет назад, и 20 лет назад тоже как-то работали, вполне нормально. Что точно изменилось - современные практики DevOps создали огромное количество рабочих мест собственно для девопсов. Не вижу в этом ничего плохого.
Люди используют Windows не потому, что они провели объективное сравнение технологий и сделали рациональный выбор. Они используют Windows, потому что первый компьютер, который они увидели дома/в школе/в университете был на Windows, потому что у всех их знакомых тоже стоит Windows. Большинство в принципе не задается вопросом Windows vs Linux, потому что этот вопрос не имеет для них смысла.
И эта данность обусловлена событиями 40-летней давности, когда MS-DOS подмял под себя рынок 86-процессоров, а потом ранние версии Windows выиграли конкуренцию у Macintosh. Linux в 90-х, особенно UI-часть, был достаточно сырой поделкой энтузиастов. Как он должен был обойти к тому времени уже корпорацию-монополиста на рынке десктопов не очень понятно. А дальше, по-видимому, как я написал выше, популярность Windows сохранялась за счет инерции, "эффекта утенка".
Что интересно, на рынке серверов Linux довольно легко обошел Windows. Видимо, дело в том, что серверы использует бизнес, поэтому там априори больше профессионализма и рационализма при принятии решений по сравнению с рынком ширпотреба.
"Архитектура" в контесте прикладной бекенд-разработки отвечает на вопросы примерно такого рода:
на какие модули/сервисы/микросервисы разбить систему?
по каким протоколам они будут взаимодействовать (синхронные, асинхронные)?
какое хранилище данных выбрать (реляционное, нереляционное, несколько разных)?
что и где надо кешировать?
и т.п.
Архитектура очень важна, она определяет ключевые характеристики системы. Но она имеет мало отношения к ООП. Да, в готовой архитектуре можно найти вещи, напоминающие паттерны GoF, принципы SOLID или GRASP. Но сами по себе они не приведут вас к готовой архитектуре с нуля. Гораздо лучше работает банальный опыт и знание best practices.
Организация конкретных классов и методов обычно называется словом "дизайн". В контесте прикладной бекенд-разработки дизайн как правило диктуется фреймворками, которые вы используете. Причем чем больше ваша свобода ограничена фреймворками и практиками, принятыми на проекте, тем легче вашим коллегам разбираться в вашем коде, а вам - в их коде. На типовом Java-стеке Spring/Hibernate (который вы упомянули) можно успешно написать десятки проектов и ни разу не потренироваться в "ООП-мышлении" - все было продумано до нас.
Казалось бы можно попробовать применить все эти чудесные методологии при проектировании структуры базы. Но нет, там тоже есть довольно строгие подходы: нормальные формы, денормализация. За любые отклонения от верного пути база больно бьет по рукам потерей консистентности или производительности.
Это было про типовую бекенд-разработку. Если вы вдруг пишете свой фреймворк или библиотеку, тут другая история. Если это хоть немного нетривиально, вы не сможете задизайнить его правильно с первого раза, прочитай вы хоть все книги мира. Только многолетняя полировка на всевозможных сценариях использования приведет вас к пониманию, как это надо было делать изначально.
Спасибо за статью! Хотелось бы еще добавить, что с первой характеристикой функционального программирования в вашем списке, а именно с иммутабельностью данных, в джаве все весьма так себе. Особенно в стандартной библиотеке.
Обычно, когда видишь такие статьи, машинально прокручиваешь до комментариев в надежде, что вот там-то умные люди напихают полную панамку автору, который даже в терминологии не разобрался.
И что там? Половина комментаторов вслед за ним называет процедурное программирование функциональным. Вторая - комментирует так, как будто его статья реально про ФП ("математический стиль" в альтернативно-одаренной терминологии автора).
Спасибо вам за этот комментарий! Я до него доскроллил, и моя вера в здешнюю публику не умерла окончательно.
Интересно было бы посмотреть на другие метрики, типа количества уникальных юзеров в месяц, количество оценок вопросов и ответов и т.п. Показывают ли они такой же тренд?
По тем же причинам Java может стать привлекательным выбором и для исследовательского программирования, но инструментарий для этого ещё не совсем готов.
Хорстманну надо бы почитать про scala-cli: вот удивится, наверное.
Это грубейшая ошибка, которая говорит о том, что вы не понимаете, как правильно использовать Java Time API, и даже не читали официальную документацию. А в ней вполне конкретно написано: "LocalDateTime is a description of the date, as used for birthdays, combined with the local time as seen on a wall clock. It cannot represent an instant on the time-line without additional information such as an offset or time-zone."
В вашем случае должно быть:
private ZonedDateTime createdAt;
Но тогда большая часть страданий и "полезных советов" из статьи становится неактуальной.
Способность писать код конечно измерима: цикломатическая сложность, процент дублирования, число варнингов в линтере, число багов, найденных в этом коде, наконец. Но это и для структурного программирования подходит. Мне не приходит в голову ни одной метрики, по которой можно было бы "объективно" отличить хороший ООП-код от плохого при прочих равных.
Как там у вас в 70-х? Доллар по 15 копеек? Хотя какой доллар, о чем я... Просто уже довольно давно все полезное, что было в обмене сообщениями, называют модель акторов. А ООП - это теперь немного про другое: наследование, полиморфизм, вот это вот все.
Возьмите непрограммистов, да возьмите даже программистов - вы не сможете объективно проверить их способность организовывать ООП код. Вы сможете высказать свое субъективное мнение об их способностях организовывать ООП код, Алан Кей сможет высказать свое субъективное мнение, Вася с горы тоже сможет высказать... Про какую "объективно измеримую величину" речь?
А что вы здесь назвали "объективно измеримой величиной", интересно? Определение и тем более понимание ООП - это по-моему одна из наиболее субъективных вещей в индустрии. Возьмите 30 программистов, дайте им сколь-нибудь нетривиальную задачу на ООА, и вы не увидите двух одинаковых решений.
Конкретно для рекордов final не при делах. Там поля неизменяемые и это нельзя контролировать. Но мне правда кажется отсутствие контроля в данном случае - скорее плюс джавы, чем минус.
Если говорить про бумажные книги, то все книги, которые вы в жизни прочитали, вы либо купили сами из своей зарплаты, либо купили выши родственники или друзья с их зарплаты. Ну или вы взяли книгу в библиотеке, соотвественно ее купила библиотека на налоги с вашей зарплаты. Ничего ужасного в этом нет.
Там еще на картинке нарисована Akka. Как человек, однажды пробовавший юзать ее джава-апи, рассматриваю это не иначе как пасхалку от скучающего копирайтера, у которого нейросети отняли всю работу.
Интересно, есть ли какая-нибудь статистика по использованию GraalVM и AoT на реальных проектах? Я всегда думал, что это маргинальные технологии, потому что те, кто гонится за быстрым временем старта, просто не будут выбирать джаву изначально.
Еще одна проблема с их подходом к геймификации в том, что вопросы, на которые можно ответить "из головы", уже по большей части исчерпаны, большинство новых неотвеченных вопросов довольно узкоспециальные. Их можно условно разделить на 2 категории: "новичок не туда поставил скобку" и "уровень курсовой работы, а иногда и кандидатской".
Выходит, что тот, кто 15 лет назад красиво ответил на вопрос "как написать цикл в питоне" сейчас сидит с шестизначным рейтингом. А тебе для ответа на вопрос про хитрый корнер кейс в каком-нибудь редком фреймворке надо потратить несколько часов на ресерч (который автор поленился провести), написать красивый и понятный ответ. Причем автор вопроса получит за это зарплату и съэкономленное время. А ты - потраченное время, и может быть немного рейтинга. Почему "может быть"? Потому что авторы вопросов (особенно, если им несколько дней) далеко не всегда берут на себя труд отметить твой ответ как правильный. Вы можете спросить "а как же чувство глубокого удовлетворения, причастности к сообществу и т.п." - здесь я говорю именно про слабые места геймификации и системы рейтинга.
Именно поэтому лично я отвечаю только на те вопросы, которые я сам искал, и в итоге пришел к решению лучше, чем уже есть в ответах.
Вот кстати да. EJB ведь тоже шел путем добавления абстракций и приводил к кратному увеличению сложности системы. Где сейчас EJB?
И да, я не пытался сказать, что сейчас хуже. Я пытался сказать, что в целом позитивный движ как будто свернул немного не туда. Надеюсь, на следующем витке прогресса народ додумается как получить те же преимущества, но без этой сложности.
А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом. Да, это было не круто. Но этому можно было за час на пальцах научить любого джуна, и дальше они вполне справлялись с поддержкой.
Современные подходы к инфраструктуре, типа service mesh, пошли по пути добавления новых и новых слоев абстракции. Теперь у вас три экземпляра приложения, каждое в своем поде, каждое - за своим прокси, гейтвей, лоад балансер, собиралка логов, собиралка метрик, физическая машина, на которой это в конечном счете крутится (часто, все так же одна единственная, ведь "мы же не гугл"). И у каждого компонента естественно есть свои логи, свои метрики, своя конфигурация при деплое. Каждый компонент - потенциальная точка отказа. Теперь, для того, чтобы с этим всем справится, нужен отдельный специалист. Джун-программист не просто не сможет выполнять такую работу, он скорее всего даже не сможет коммуницировать с таким специалистов в рамках своих задач. Стало ли как-то лучше глобально? Для супер большиъ проектов - наверное да. Остальные и 10 лет назад, и 20 лет назад тоже как-то работали, вполне нормально. Что точно изменилось - современные практики DevOps создали огромное количество рабочих мест собственно для девопсов. Не вижу в этом ничего плохого.
Пример со скайпом игнорируете. Там у вас нет даже опции "make it yourself", только "gtfo".
Так возьмите и напишите сами. Не можете? Задонатьте тому, кто может.
Вот типичный пример closed-source разработки из этой же ниши: Microsoft решили закрыть скайп. И вы ничего не можете с этим сделать.
Люди используют Windows не потому, что они провели объективное сравнение технологий и сделали рациональный выбор. Они используют Windows, потому что первый компьютер, который они увидели дома/в школе/в университете был на Windows, потому что у всех их знакомых тоже стоит Windows. Большинство в принципе не задается вопросом Windows vs Linux, потому что этот вопрос не имеет для них смысла.
И эта данность обусловлена событиями 40-летней давности, когда MS-DOS подмял под себя рынок 86-процессоров, а потом ранние версии Windows выиграли конкуренцию у Macintosh. Linux в 90-х, особенно UI-часть, был достаточно сырой поделкой энтузиастов. Как он должен был обойти к тому времени уже корпорацию-монополиста на рынке десктопов не очень понятно. А дальше, по-видимому, как я написал выше, популярность Windows сохранялась за счет инерции, "эффекта утенка".
Что интересно, на рынке серверов Linux довольно легко обошел Windows. Видимо, дело в том, что серверы использует бизнес, поэтому там априори больше профессионализма и рационализма при принятии решений по сравнению с рынком ширпотреба.
"Архитектура" в контесте прикладной бекенд-разработки отвечает на вопросы примерно такого рода:
на какие модули/сервисы/микросервисы разбить систему?
по каким протоколам они будут взаимодействовать (синхронные, асинхронные)?
какое хранилище данных выбрать (реляционное, нереляционное, несколько разных)?
что и где надо кешировать?
и т.п.
Архитектура очень важна, она определяет ключевые характеристики системы. Но она имеет мало отношения к ООП. Да, в готовой архитектуре можно найти вещи, напоминающие паттерны GoF, принципы SOLID или GRASP. Но сами по себе они не приведут вас к готовой архитектуре с нуля. Гораздо лучше работает банальный опыт и знание best practices.
Организация конкретных классов и методов обычно называется словом "дизайн". В контесте прикладной бекенд-разработки дизайн как правило диктуется фреймворками, которые вы используете. Причем чем больше ваша свобода ограничена фреймворками и практиками, принятыми на проекте, тем легче вашим коллегам разбираться в вашем коде, а вам - в их коде. На типовом Java-стеке Spring/Hibernate (который вы упомянули) можно успешно написать десятки проектов и ни разу не потренироваться в "ООП-мышлении" - все было продумано до нас.
Казалось бы можно попробовать применить все эти чудесные методологии при проектировании структуры базы. Но нет, там тоже есть довольно строгие подходы: нормальные формы, денормализация. За любые отклонения от верного пути база больно бьет по рукам потерей консистентности или производительности.
Это было про типовую бекенд-разработку. Если вы вдруг пишете свой фреймворк или библиотеку, тут другая история. Если это хоть немного нетривиально, вы не сможете задизайнить его правильно с первого раза, прочитай вы хоть все книги мира. Только многолетняя полировка на всевозможных сценариях использования приведет вас к пониманию, как это надо было делать изначально.
Спасибо за статью! Хотелось бы еще добавить, что с первой характеристикой функционального программирования в вашем списке, а именно с иммутабельностью данных, в джаве все весьма так себе. Особенно в стандартной библиотеке.
Обычно, когда видишь такие статьи, машинально прокручиваешь до комментариев в надежде, что вот там-то умные люди напихают полную панамку автору, который даже в терминологии не разобрался.
И что там? Половина комментаторов вслед за ним называет процедурное программирование функциональным. Вторая - комментирует так, как будто его статья реально про ФП ("математический стиль" в альтернативно-одаренной терминологии автора).
Спасибо вам за этот комментарий! Я до него доскроллил, и моя вера в здешнюю публику не умерла окончательно.
Интересно было бы посмотреть на другие метрики, типа количества уникальных юзеров в месяц, количество оценок вопросов и ответов и т.п. Показывают ли они такой же тренд?
Хорстманну надо бы почитать про scala-cli: вот удивится, наверное.
Это грубейшая ошибка, которая говорит о том, что вы не понимаете, как правильно использовать Java Time API, и даже не читали официальную документацию. А в ней вполне конкретно написано: "LocalDateTime is a description of the date, as used for birthdays, combined with the local time as seen on a wall clock. It cannot represent an instant on the time-line without additional information such as an offset or time-zone."
В вашем случае должно быть:
Но тогда большая часть страданий и "полезных советов" из статьи становится неактуальной.