JavaRush/Java Форум/Как вы(или у вас принято) писать читабельный, производите...

6 уровень

28.09.2023
426просмотров
19комментариев

Как вы(или у вас принято) писать читабельный, производительный код?

Начал проходить циклы и начали беспокоить следующие вопросы: 1. -Что означает "читабельность" кода и как грамотно пользоваться //комментариями? -Что должен содержать/отражать комментарий? -Как правильно расставлять скобки{ }? В конце строки или на новой отдельно? -насколько "читабельность" субъективна? 2. Как писать код, чтобы программа весила меньше на диске и слабее нагружала процессор? И имеет смысл сейчас вообще об этом думать? 3. По каким "критериям" отличают "хороший код" от "плохого кода"? Буду рад как прямым ответам на своëм опыте, так и ссылкам на чужой. Не обязательно отвечать на все сразу, если есть мысль по какому-то отдельному пункту, тоже буду благодарен.

Комментарии (19)

популярные
новые
старые

Для того, чтобы оставить комментарий Вы должны авторизоваться

Сергеев Виктор

Уровень 40

Master

28 сентября 2023, 23:30

По поводу комментарием тут много написали, но немного отойду от практики, что код с комментариями плохой код. Иногда по определенным обстоятельствам делается какое-то действие. Например мы формируем отчет. На вход нам приходят 2 даты и надо у даты от назначить время начала суток, у даты до - конец суток. Случайное присвоение разного времени двум датам не всегда понятно, тем более, что причины действия скрыты в документации к реализации системы. Вот в такой момент можно описать, что смещение времени сделано по требованиям потому что на вход приходят только даты а в БД храним таймстемпы. Либо команда решила, что некая регулярка может решить их задачу без кучи циклов и проверок, ее хорошо бы описать комментарием. Есть моменты когда лучше оставить комментарий, даже если сейчас код кажется читаемым. Просто тут есть вот это обманчивое чувство, когда ты делаешь задачу ты в контексте и понимаешь каждый кусочек. Но вот прошло полгода и тебе прилетает задача что-то там поправить. Контекст задачи утерян и то, что раньше казалось читаемым уже таким не кажется. Я бы сказал так: очень помогает ревью кода. Человек со стороны читает и пытается понять твой код. Если в этот момент он не может его понять, стоит прислушатся и узнать что не понятно. Возможно из-за контекста ты все понимаешь, а сторонний читатель нет. Это как с начальными задачами. Когда используются однобуквенные переменные. Автор все понимает, что s1 это первой спротсмен а s2 это его сумка. А читающий уже не очень понимает. Поэтому когда критикуют на ревью о нечитаемости кода не стоит воспринимать в штыки, а искать вариант, который будет понятен лучше. А ультимативные заявления, что комментируют плохой код пропускать) нормальные люди не говорят ультиматумами (ну почти, писать пароли в лог не стоит и это всегда точно). Как правильно написад Денис Код который нужно комментировать это плохой код, исходи из этого. Исходи, но не следуй дословно и всегда

Денис Enterprise Java Developer

29 сентября 2023, 08:03

Я думаю что есть разница между комментированием непосредственно кода, и комментированием неочевидного поведения обусловленного конкретным бизнес требованием. В таких случаях естественно оставить что-то типа "реализовано в соответствии с НомерТикета", но из моего опыта это больше помогает бизнесу "вспомнить" что за херню они просили год назад :) А девам прикрыть жопу соответственно. P.S. Я так подумал, и наверное это все равно не отменяет того факта что такой код пахнет... описания то требует или сомнительное, но вынужденное решение, или поведение не описанное по какой-то причине в тикете/документации. Любой из сценариев выглядит плохо.

Сергеев Виктор

Уровень 40

Master

29 сентября 2023, 16:46

я не то, чтобы спорить, скорее поделится альтернативным взглядом. полностью самодокументируемый код на мой взгляд почти не возможен. Есть вариант когда используется подходящая структура данных, но ее методы по тексту не очень подходят. Иногда в коде бывают очень длинные названия и местами технические, а могут быть еще и с сокращениями. При этом они могут быть не самописные а из библиотеки и тут два варианта, писать комментарий, а лучше javadoc или писать абстракции делающие код читаемым. Еще на мой взгляд скорее проблема локальных рынков, когда участники команды не владеют английским в достаточно форме и получается что плохо знающий английский, плохо написал, а и такой же прочитал еще хуже. Для меня, если я понимаю, что код читаем, но одна строчка вырванная из контекста не понятна и читающему придется покопать пару авбракций ради разбора, я бы лучше написал комментарий. Вот один из примеров недавнего кода. Есть задача, которая двигается по статусам. Двигается неким шедулором, при этом шедулер подхватывает не все статусы, некоторые из них обрабатываются конроллером, как реакция на интеграцию. И вот тут меня попросили указать какой шедулер обрабатывает эти статусы и я был не против. Потому что так автор быстрее найдет её, т.к. она важна, а искать сради десятков упоминаний как-то не удобно. Другой пример, интеграции с другими системами. Допустим есть некая система "Учета рабочего времени, отпусков и больничных". И вот тут будет довольно сложный момент с неймингом. Я бы ее назвал с помощью переводчика, а над классом оставил javadoc на русском (т.к. работа с команде рф и продукт в рф) что это за система.

Сергеев Виктор

Уровень 40

Master

29 сентября 2023, 16:56

Так же можно взять за пример куски кода, который обернуты в try, используют локи, мапперы if-else Есть теория, что такие методы надо делить, но в то же время понимаешь, что потеряешь в читаемости. Как обычно предлагают суть метода вынести в приватный, а try оставить во внешнем. Но тогда страдает нейминг, потому что делают они одно и тоже, но один оборачивает в try и получается выбор, либо вложенности, либо методы типа processingTask и processingTaskSafe Обстоятельства разные бывают и для себя я выбрал, что абсолютно отказываться от комментариев в коде не кажется логичным. И чаще я встречал проекты, где джава док, даже для очевидных вещей был обязателен и читались они намного лучше чем те, где автор думал, что пишет идеальный код и не оставлял никаких комментариев. Тут для себя еще важное подметил, читаемость/понятность/красота кода это субъективные понятия. Кто-то хорошо знаком с областью и переменная FGUPRSVOIntegration для него очевидна и читаема. А кто-то только пришел и пытается понять что за ФГУП РСВО и как это загуглить. А для большей части команды все очевидно.И когда этот человек пытается написать читаемый код и называет это FederalStateUnitaryEnterpriseRussianBroadcastingAndWarningNetworksIntegration, команда гордо заявляет ему, что код не читаем. И в контексте проекта я с ними согласен, а астрактно не очень И большую часть вопросов решил бы javadoc на класс гласящий "Класс для интеграции с Федеральное государственное унитарное предприятие «Российские сети вещания и оповещения»" Ну и сюда бы добавил терминологию, когда значения из разных областей путаются ) Легаси код. И я надеюсь, что мой код будет достаточно надежным, чтобы когда-то стать легаси, которая уже несколько лет работает. И мне бы хотелось, чтобы человек который спустя несколько лет читает мой код - понял его, даже если правила написания поменялись и он работает с другим языком и другой парадигмой И я прекрасно понимаю, что плохие комментарии как и плохой код вредят, но каждому свое )

Денис Enterprise Java Developer

29 сентября 2023, 19:42

> полностью самодокументируемый код на мой взгляд почти не возможен Согласен, здесь у меня скорее синдром выжившего, я работал на проекте построенном на микросервисной архитектуре, и это работало, при том сервисы действительно были микро и самодокументируемы. С другой стороны, рядом с нами был монолит где сам черт ногу сломит, благо я с ним работал исключительно редко. > Иногда в коде бывают очень длинные названия Пошли флешбеки про тесты :) shouldDoSomethingWhenSomethingAndDoAnotherWhenAnotherOn TheFirstDayOfMoth() Но согласись, это хочется удалить нахрен :) > не владеют английским в достаточно форме Снова синдром выжившего, я на локальном рынке в принципе не работал и не собираюсь, тут повезло :) > Другой пример, интеграции с другими системами Так уж вышло что это мой профиль :) Мы стараемся пользоваться готовыми моделями от внешних АПИ, схемами, если это файловая интеграция, ну или если совсем жопа просто называем правильно, все равно внутренняя кухня. Но... как я сказал, у меня рынок внешний, потому сугубо англоязычный и тут сильно проще. > Есть теория, что такие методы надо делить, но в то же время понимаешь, что потеряешь в читаемости. Умеренность важна во всём, даже в умеренности (с) Лично я, когда есть вот такое месиво стараюсь разбить код на какие-то логические куски и вынести их в разные методы, при этом у меня есть рутовый метод в котором дёргаются эти производные и просто прочитав его ты понимаешь что именно он делает, а уже сама реализация.... ну всяко проще понять когда ты заходишь в метод делающий операцию А, что именно он пытается сделать :) > и для себя я выбрал, что абсолютно отказываться от комментариев в коде не кажется логичным. Тут глупо спорить, я совершенно согласен, но думаю ты и сам понимаешь, что когда комментарии есть мера вынужденная... не от хорошей жизни ими приходится пользоваться в общем :) Вот не от хорошей.

Сергеев Виктор

Уровень 40

Master

30 сентября 2023, 00:02

Но согласись, это хочется удалить нахрен :) Тут согласен, но тут как в шутке "если пытался исправить этот код и в итоге вернулся к исходному, прибавь к числу дальше количество потраченных дней, суммарно потрачено 115 дней". комментарии есть мера вынужденная... не от хорошей жизни ими приходится пользоваться в общем ну опять же, как и во всем обсуждении, многое зависит от контекста. Иногда код как письмо из простоквашино, потому что текучка. Видел один проект, где у людей был настроек чек в мавене, чтобы каждый класс и метод имели javadoc. И в этом же проекте люди радовались этому подходу, возвращаясь к куску кода, который писали полгода назад. Опять же локализация рынка, когда вся документация на локальном языке, спецификации и постановки задач также. Еще наверно важный момент, я достаточно самокритичен и чаще всего считаю, что мой код может быть плохим, поэтому все моменты, где приходилось выбирать между примерно равнозначными, но отличающимися альтернативами, стараюсь как-то пояснить причины выбора. Особенно это было критично, когда идет работа над производительностью и стоит выбор - общий подход или производительный код. Как пример выбора, мы работаем с распределненным кешом и там есть дополнительно локи. Лок можно брать по ключу кеша, но тогда сам кеш надо перевести в атомарный режим, что снижает производительность. Альтернатива - использовать независимые от кеша локи. И если во всем проекте используется подход с локами из самого кеша, а я меняю на независимый лок, я скорее всего напишу причину такого выбора в комментарии. Кстати как пример комментарии к таблицам, колонкам бд. Как-то увидел такой подход, потом увидел утилиту schemaspy и прям очень зашло.

Сергеев Виктор

Уровень 40

Master

30 сентября 2023, 00:12

Еще наверну докину, тоже пример из текущего проекта. Использование webflux/Completable future когда бизнес код разбавляется вызовами библиотеки. И это одна из причин, почему хочется перейти на корутины котлина Пример из статьи https://blog.allegro.tech/2020/02/webflux-and-coroutines.html Webflux (и он еще аккуратно выглядит)

fun prepareGingerbread(existingIngredients: Set<Ingredient>): Mono<Gingerbread>? {
   return buyMissingIngredients(requiredIngredients, existingIngredients)
           ?.filter { succeeded -> succeeded }
           //.map(succeeded -> heatOvenToDegrees(180L)) //oven should be heated at this point
           ?.flatMap { _ -> heatButterWithHoney() }
           ?.zipWith(prepareDough())
           ?.map { heatedAndDoughTuple -> mixDoughWithButter(heatedAndDoughTuple.t1, heatedAndDoughTuple.t2) }
           ?.zipWith(prepareCakeTray())
           ?.zipWith(heatOven()) { contentAndVesselTuple,ovenHeated ->
               bake(ovenHeated, contentAndVesselTuple.t1, contentAndVesselTuple.t2)}
           ?.zipWith(prepareIcing()) { baked, icing -> Gingerbread(baked, icing) }
}

и с корутинами

fun prepareGingerbread(existingIngredients: Set<Ingredient>): Mono<Gingerbread> {
   return mono {
       buyMissingIngredients(requiredIngredients, existingIngredients)?.awaitFirstOrDefault(false)

       val oven = heatOven()
       val heat = heatButterWithHoney()
       val dough = prepareDough()
       val mixedDoughWithButter = mixDoughWithButter(heat?.awaitFirstOrDefault(false), dough.awaitFirstOrDefault(false))

       val tray = prepareCakeTray()
       val baked = bake(oven.awaitFirstOrDefault(false), mixedDoughWithButter, tray.awaitFirstOrDefault(false))
       val icing = prepareIcing().awaitFirstOrDefault(false)

       Gingerbread(baked, icing)
   }
}

Денис Enterprise Java Developer

30 сентября 2023, 07:32

Интересная статья, спасибо.

Justinian Judge в Mega City One

Master

3 октября 2023, 09:25

У любого правила есть исключения. Начинающим до первой работы комментарии категорически не нужны, по причине того что у них гипериспользование их, и они трижды комментурют очевидные конструкции. На начальных стадиях нужно просто выбивать клин клином, и потом когда оно уравновесится и по мере опыта человек сам разберется что к чему. Надо понимать, какие отрицательные стороны у комментариев, они описаны в том же Клин коде. Если говорит о практике, то до сих пор в джаве активно используется и finalize, date и swing, jsp да я разве что апплетов не видел, причем много "устаревших" или неправильных практик используют очень прокаченные дядечки, как и идентация и отступы и нейминг, я видел примеры исключений наверное по большинству правил. Правила нужно знать и нужно понимать что за ими стоит. Но у любого правила есть свой контекст и свои исключения. Мне слава богу не приходилось работать на проектах с комментариями, но опять же , джава доки я считаю больше за документацию, комментарии в джаве это

// this method calculate student
studentUtil.calculateStudent()

Не мы живем ради правил, а правила придуманы ради нас. Это как рассказывать "не лезтье в розетки, это плохо", просто стадия. Потом человек вырастет и полезет ту розетку чинить и это ок. Или если будет все работать - то не будет лезть Всему свое время и контекст

Денис Enterprise Java Developer

28 сентября 2023, 16:19

Код который нужно комментировать это плохой код, исходи из этого. Соответственно читабельный это такой код, который ты читаешь и понимаешь. Субъективность тут никакая, ты или понимаешь код или нет. Скобки расставлять правильно одинаково, и в соответствии с кодстайлом проекта. Если проект твой - расставляй как хочешь, то желательно чтобы это было одинаково по всему проекту. Ну и всегда можно почитать Дяду Боба - Clean Code

Денис Enterprise Java Developer

28 сентября 2023, 17:07

> Как писать код, чтобы программа весила меньше на диске и слабее нагружала процессор Сейчас ты скорее всего занимаешься преждевременной оптимизацией, в целом старайся избегать лишних действий и будет тебе счастье. Не дёргай метод много раз если этого можно избежать, не проводи сравнения больше чем это необходимо, если этого можно избежать не сравнивай. Простой пример: вывести в консоль четные числа от 0 до N, можно конечно в цикле пройтись по всему диапазону, проверить чётное ли число и вывести его на экран, а можно вспомнить что чётное это каждое второе число и настроишь нужный шаг цикла избежав проверки целиком. > По каким "критериям" отличают "хороший код" от "плохого кода"? Хороший код легко прочитать, легко понять, легко модифицировать и масштабировать. Ну очевидно он еще должен правильно и надёжно работать.

Justinian Judge в Mega City One

Master

28 сентября 2023, 15:49

Есть функциональные требования к коду: код должен быть рабочим код должен выполняться без ошибок код должен делать то, что от него ожидает. Есть нефункциональные требования к коду, это читаемость, производительность часто тоже, легкость рефакторинга и тд. Качественный код, это код который соответствует и функциональным критериям и нефункциональным. Почему важны нефункциональные критерии, поскольку особенно джава программы, пишутся с расчета на постоянный рефакторинг - изменения, дополнения и тд, поскольку бизнес веб приложения должны соответствовать окружающим бизнес реалиям, а они постоянно меняются. Поэтому для джавистов нефункциональные требования очень важны, без них нельзя писать большие масштабируемые приложения. Представь себе гараж, в котором все инструменты по местам. Это нефункциональное требование. (функциональное - наличие инструментов). А теперь представь эффективность СТО по ремонту авто, если вместо нормальной раскладки инструментов, будет один куб 2 на 2 метра, и в нем насыпом все инструменты. Функциональные требования исполнены - инструменты есть. Но эффективность работы будет стремиться к нулю. Со временем ты будешь узнавать все больше и больше правил, советов, лучших практик, паттернов и тд. Но в этом всем есть важная штука - контекст. Например есть правило, мыть руки перед едой. Но в поле увидев яблоню, навряд ты откажешься от яблока из-за того что рядом крана с водой нет. Тоже самое и с клин кодом, в алгоритмическом и низкоуровневом коде одни требования, там код пишется бородатыми умными дядьками для других умных дядек, там много отступлений от правил и код меняется редко. А вот если будешь делать обычное веб приложение, вот там наоборот, нужно. На самом деле, без живого человека и реального проекта с норм кодом и практиками разработки, к сожалению ты не сможешь это изучить, это знания передаются от человека к человеку. Но что можешь взять, это нужно брать. Почитай: "Clean code" Роберта С. Мартина "Рефакторинг.." - Мартина Фаулера

Justinian Judge в Mega City One

Master

28 сентября 2023, 15:59

-Что означает "читабельность" кода и как грамотно пользоваться //комментариями?

читабельность кода это насколько легко прочитает твой код другой человек. Мы пишем код для других, а другие для нас. Или как говорят классики, пишите код так, как-будто читать его будет психопат, который знает где вы живете. Читабельность кода это его самодокументируемость.

Ot<Gj> ur = new JhOt<>();
ur.f(l34)  i(k.l
30j())  j.F.R(k.o53
2
);

Вот тебе пример кода, красота правда? Утрировано, но он вполне мог бы быть рабочим,если бы джава не была читабельной. Как ты думаешь, что этот код делает, и главное - где в нем ошибка? логическая. Мягко говоря, сложно найти. А теперь сравни с читабельным:

List<Student> students = new ArrayList<>();
studentds.add(vasya);

if (vasya.canSing()) {
  System.out.println("Oops, vasya can not sing!");
}

и сравни, ты не знаешь программы, контекста, но ты можешь прочитать и понять что происходит. И даже потенциальную ошибку найти здесь достаточно легко, не зная даже требований. Это утрированный пример, но он показывает важность и в чем отличие. Программист процентов 30-40% может гуглить, 40-50% ЧИТАЕТ код, 10-20% пишет код Поэтому читабельность важна. Новичкам сложно понять по двум причинам: они пишут для себя и код никто не читает, написал как попало и так сойдет решили задачу, навеки про нее забыл. Это очень разнится с реальным программированием, в котором мы пишем код для других по сути, и читаем чужой код постоянно. А значит свои шифрограммы типа String fd4 придумывать нельзя.

Justinian Judge в Mega City One

Master

28 сентября 2023, 16:15

Что должен содержать/отражать комментарий?

есть много холиварных вопросов, комментарии относятся к ним. Для простоты я бы советовал запомнить, что комментарии могут быть, но это крайний случай. И я практически не могу себе представить ситуацию, чтобы у начинающего программиста в своих учебных проектах или задачах было основание использовать комментарии. На реальных проектах еще там можно оставлять заметки и то, опять же это зависит от проекта, контекста и холиварный момент. Но на этапе учебы просто запомни, комментарий как грязные руки, и особенно они выдают новичков, для которых это просто заметки и радостно их используют. Код должен быть самодокументируемым. Если код нуждается в комментарии - значит что-то с ним определенно не так, и не комментарий оставлять нужно, а код улучшать. Если прям нужно что-то пояснить или акцентировать, для этого есть документация или README.md проекта.

-Как правильно расставлять скобки{ }? В конце строки или на новой отдельно?

пользуйся Идеей и почаще нажимай CTRL+ALT+L, Идея тебе сама расставит. Есть разные конвеншены, опять же зависит от контекста, я встречал иногда и с новой строки, но в 99% у джава 1TBS конвеншен, то есть

public void someMethod() {

Как еще бывает можешь почитать https://en.wikipedia.org/wiki/Indentation_style Есть еще важный момент по поводу "правильно", помимо общих конвеншенов для языка, технологии и тд, есть еще конвеншен конкретного проекта. Если все на проекте будут писать по другому, и ты тоже будешь так писать, поскольку сама суть конвеншенов в единообразии подходов, тогда читается намного легче. Сравни как от руки написано 100 разными людьми и газету почитать, что легче. Стандартизированные подходы очень эффективны

Justinian Judge в Mega City One

Master

28 сентября 2023, 16:24

-насколько "читабельность" субъективна?

субъективна, как и все. Вот ты занимаешься спортом, насколько субъективно понятие "правильная техника"? Один тренер скажет вот так делай, другой сяк.. Но с опытом, ты начинаешь понимать что стоит за этим, почему и разные подходы бывают, но это на более высоких уровнях. А на начинающем уровне нужно просто следовать словам тем, кто в этом разбирается, и желательно очень, понимать почему так. Вот написал я, что Student vasya = лучше чем Gkd34 kblolkrer = , старайся в любом правиле извлекать, что оно дает. Не всегда это возможно, не все правила понятны или зайдут, это нормально. Но со временем ты будешь знать, что можно сделать одно и то же 10 способами, и с опытом ты просто сам уже начнешь видеть, почему здесь лучше подход А, и почему подходы Б и В хуже. Поэтому субъективность есть, но вопрос что за ней стоит, какая идея стоит за правилом или замечанием другого программиста. Дискуссия как правило поощряется, если не воспринимать все в штыки конечно, и у тебя есть своя позиция и ты открыт к диалогу относительно других. Ведь главная задача, как сделать код лучше. А не как чтобы было именно как ты написал.

Как писать код, чтобы программа весила меньше на диске и слабее нагружала процессор? И имеет смысл сейчас вообще об этом думать?

это не про джаву. Бывают разные кейсы, но когда к ним дойдешь ты и так будешь знать что делать. А пока не думай вообще за это, просто в пределах разумного смотри, не делать 10 раз одно и то же, избегать по возможности квадратической и больше сложности алгоритмов и тд. Да и все в принципе , если говорить про стадию до первой работы. В джава веб приложениях два основных ботл нека, это - БД - сеть и по каждому из них, количество запросов и объем передаваемых данных, либо запросов мало, но гигабайты, либо данных не так много, но запросов очень много. Вот про это думать надо.

Justinian Judge в Mega City One

Master

28 сентября 2023, 16:33

По каким "критериям" отличают "хороший код" от "плохого кода"?

критерии хорошего кода описал в первом ответе. Это соответствие твоего кода функциональным требованиям и нефункциональным. Но без менторинга и код-ревью очень сложно получить тебе такие ориентиры, ведь примеров хорошего кода в инете ты почти не найдешь в открытом доступе, мусор либо опенсорс (специфический код со своими правилами) Коммерческий код защищен соглашениями о неразглашении. + не имея понятия как их отличать, как ты поймешь где какой код, он ведь тебе и нужен чтобы различать научиться.. С другой стороны, про это особо не переживай, старайся применять те правила, которые ты понял или знаешь. не пиши код "для себя" да это черновик и тд. Нормальный спортсмен никогда не будет раскорякой гигикая дурачка валять на тренировке, ведь это же понарошку, а вот на ринг выйду и ого го как покажу. Не покажет. Ведь тренировки формируют навыки и привычку. И на ринге он покажет ровно то, что на тренировке делал, с небольшой поправкой на больше вкладывание в момент. Так и с кодом, нету для себя, для других и тд. Черновик еще ладно, и то, по бырику в другом окне набросать. Если же решаешь основную задачу, основной проект то пишешь так, как ты умеешь. Вспомнил еще один сборник типовых правил есть https://google.github.io/styleguide/javaguide.html На этапе обучения от тебя требуется изучить синтаксис, хорошо если почитаешь Клин код Роберта Мартина и код будет опрятным, насколько это можно - форматированный, с нормальными именами, не 200 строк в одном методе и тд. Писать код ты уже начнешь учиться тогда, когда будешь проходить вторую часть обучения либо даже на работе. Всему свое время.

ernest chekhov

Уровень 6

28 сентября 2023, 17:30

Брат,Мега-хорош спасибо что потратил свое время, чтобы ответить на все. Тянет прям на статью. Прошëлся и по ссылкам, жаль английский свой плох, благо гугл позволяет переводить, хоть и не совершенно. Правда не понятным остались часть с "ботлнеком" горлышком бутылки, гугл не особо помог, пожалуй пока ассоциаций не хватает. Время будет, лучше вникну. Спасибо

Justinian Judge в Mega City One

Master

28 сентября 2023, 20:14

👍 ботлнек горлышко бутылки, узкое место. То есть, есть у тебя бидон на 100 литров наполненный водой. И есть другой бидон на 100 литров пустой. Ты переливаешь воду, но отверстие там в 1 мм. Итого все будет очень медленно, и не из-за самих емкостей бидонов или что воды нету. А потому что есть одно узкое место. Для джава приложения это как правило не процессор и память, вычислительные мощности имеют значения, но они масштабируются, там свои техники, а вот именно База Данных и Сеть, это ресурсы, которые отнимают норм времени, поскольку на эти компоненты большая нагрузка, и там есть технические моменты связанные с отправкой запросов и получением ответов. Грубо говоря есть ты и твой друг в разных городах, вы готовы друг другу писать 100 писем в день, но у вас так не получится при исползьовании обычной почты, это будет узкое место в вашей коммуникации, пока почтальон принесет, почта примет, отправит, отсортирует, доставит. Но это опять же, все впереди ) Я так, очерчил, сейчас тебе нужно просто фокусироваться на синтаксисе пока. Здесь главное старайся не отрываться сильно от текущих задач. Джава объемная. Представь что ты изучаешь самолет и начал с винтиков, и у тебя еще ого го сколько нужно изучать и тем впереди. Задумываться как самолет летает правильно, это интересно. Главное чтобы не было дисбаланса и это было иногда. Иначе ты не сможешь освоить текущие темы, если мыслями будешь в будущем. Будущее ждет тебя, но для этого ты должен свой фокус опустить на текущие темы и продвижение вперед , чтобы к нему дойти ногами, а не в мыслях стоя на месте. Опять же, я не говорю что у тебя так, я на всякий случай акцентирую, что очень важно движение вперед, если что-то важное от тебя требуется здесь и сейчас - ты про это обязательно узнаешь. Если никто не требует, значит не обязательно :) На данной стадии по крайней мере

Уровень 21

28 сентября 2023, 12:15

Что бы ответить на твои вопросы думаю нужно уже обладать неким коммерческим опытом, или как минимум посвятить этой теме приличное время, поэтому оставлю место опытным чувакам =) От себя я просто поделюсь полезными ресурсами: - сodeсonventions. - jr-forum-post - Clean Code by Robert Martin. И думаю что стоит еще познакомится с такими принципами как: SOLID, DRY, KISS, YAGNI и т.п. может еще что то интерестное можно загуглить.