Как и написание тестов

Или вы запрашиваете отдельно время на написание тестов?

Рефакторинг это такая же часть работы как написание кода с нуля.

Я не претендую на истину в первой инстанции, во всяком случае на нашем проекте так работает. Просто я не в первый раз слышу (в том числе и от своих разработчиков), что «У меня нет времени на рефакторинг». Но при это новые фичи делаются в 2 раза дольше, потому что в коде уже можно трупы закапывать.

И да у нас есть файлы по 150к строк в проекте примерно с 2001 года они развивались в append only style.

Но если эти файлы не меняются их не трогают.

у бигдата в полне себе есть определение. подходит под 3 V. значит биг дата

если ты о Volume, Variety, Velocity, Variability, Veracity то их как бы 5

тогда все будут считать проект хайлоад у кого 128 мб сервер не выдерживает . 3.5 посетителя

ну и отлично, я с удовольствием побеседую с человеком у которого проект на PHP на сервере с 128 мб и 3.5 rps

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

не

Коллеги, какие коробочные (бэк+фронт) либы/пакеты вы используете для браузерных пуш-нотиков?

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

У меня локалхост не отвечает моим требованиям по скорости ? значит теперь у меня дома хайлоад?)

У меня локалхост не отвечает моим требованиям по скорости ? значит теперь у меня дома хайлоад?)

Ага, только local-ьного масштаба)

Ага, только local-ьного масштаба)

?

если ты о Volume, Variety, Velocity, Variability, Veracity то их как бы 5

было 3 потом 5 это не так важно

а если данные не влезают на флеху, то big data

?

ну и отлично, я с удовольствием побеседую с человеком у которого проект на PHP на сервере с 128 мб и 3.5 rps

3.5 человека это не совсем 3.5 rps. да и 3.5 rps выдержит сервер с 128 мб. если у него одна статика

3.5 человека это не совсем 3.5 rps. да и 3.5 rps выдержит сервер с 128 мб. если у него одна статика

какая статика может быть на канале про PHP?!

какая статика может быть на канале про PHP?!

окей echo '<h1></h1>' . так будет лучше ? 1 Раз срегенировалось через пхп. положили в статику

3.5 rps на 128мб и динамика с базой потянет ;)

окей echo '<h1></h1>' . так будет лучше ? 1 Раз срегенировалось через пхп. положили в статику

уже интереснее :) но генерация статики - это не интересно :)

3.5 rps на 128мб и динамика с базой потянет ;)

а какая база? sqlite или mysql сможешь затюнить?

вопрос не сколько в том, какая база, а в том - сколько данных и какие выборки

уже интереснее :) но генерация статики - это не интересно :)

мы отошли от первоначальной темы. да и не проблема 3.5 rps держать в динамики на 128. Вопрос же какая динамика.

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

@miksir например я не смог добиться от mysql работа на конфигурации менее 162M (MySQL version 5.6.37)

отключи innodb :)

не спортивно :)

хз в общем... 128М виртуалки еще не так давно в ходу были, и ничо, что-то даже делали на них ;)

правда уже никто не помнит что и как ;)

мы отошли от первоначальной темы. да и не проблема 3.5 rps держать в динамики на 128. Вопрос же какая динамика.

так расскажи какие бы ты настройки сделал для fpm пула, при условии что приложение хочет не менее 32Мб оперативки

без времени отклика приложения не сказать ;) если оно отпуливается за 250ms, то pm.max_children=1 :)

ну не подсказывай, интересно же как это "легко" ;)

у меня есть своя конфигурация под dokuwiki - интересно выяснить как оно правильно :)

К слову, у меня вот легаси приложение стало под 1.5-2Гб на запрос жрать, да еще время отклика секунд 5 ;) Хайлоад и биг дата в одном флаконе ;)

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

на одном сервере бывает выгодно вполне делать, даже при условии что он очень дорогой - тут еще нужно учитывать стоимость обслуживающего персонала

так расскажи какие бы ты настройки сделал для fpm пула, при условии что приложение хочет не менее 32Мб оперативки

откуда требование в 32 и ngnix ? в свое время жил такой сервер с lightttpd и 128 рам. и даже не сдыхал. и вообще это куда-то не туда. я это начал из-за вашего ответа когда сервер/сервера загружен на 146% это получается что любой сервер котрый не выдерживает нагрузку хайлоад . что далеко не так

на одном сервере бывает выгодно вполне делать, даже при условии что он очень дорогой - тут еще нужно учитывать стоимость обслуживающего персонала

и будет на нем тонна виртуалок чтобы ресурсы распределить и изолировать все, тоже надо обслуживать

ну если гет убрать не праввильно считает LengthAwarePaginator {#413 ▼ #total: 1 $posts = $this ->user() ->posts() ->where('posts.option', 1) ->orderBy('created_at', 'DESC') ->distinct()->where('message_validate') ->paginate(10);

решил https://laravel.ru/forum/viewtopic.php?id=2602 ->user() ->posts() ->getQuery() ->where('posts.option', 1) ->orderBy('created_at', 'DESC') ->groupBy('message_validate') ->paginate(10); бонус - https://gist.github.com/vluzrmos/3ce756322702331fdf2bf414fea27bcb

откуда требование в 32 и ngnix ? в свое время жил такой сервер с lightttpd и 128 рам. и даже не сдыхал. и вообще это куда-то не туда. я это начал из-за вашего ответа когда сервер/сервера загружен на 146% это получается что любой сервер котрый не выдерживает нагрузку хайлоад . что далеко не так

откуда nginx то взялся?! fpm отлично с лайти работает. я считаю именно так, а цепляться к фразе чтобы доказать что-то. ну я даже не знаю о чем дальше можно говорить. если можешь предложить каноничную формулировку для слова highload - то давай. к слову если посмотреть не только на мое понимание слова highload, то станет ясно, что это не только мое видение - https://ruhighload.com/post/Что%20такое%20highload%20и%20что%20с%20ним%20делать - http://highload.guide/blog/highload-for-beginners.html

откуда nginx то взялся?! fpm отлично с лайти работает. я считаю именно так, а цепляться к фразе чтобы доказать что-то. ну я даже не знаю о чем дальше можно говорить. если можешь предложить каноничную формулировку для слова highload - то давай. к слову если посмотреть не только на мое понимание слова highload, то станет ясно, что это не только мое видение - https://ruhighload.com/post/Что%20такое%20highload%20и%20что%20с%20ним%20делать - http://highload.guide/blog/highload-for-beginners.html

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

и будет на нем тонна виртуалок чтобы ресурсы распределить и изолировать все, тоже надо обслуживать

не обязательно, я знаю как миниум одну систему с 192Гб оперативки которая работает на голом железе. но это сервер субд, а не app сервер

Нет, обычно рефакторинг делается в рамках какой-то задачи.

вот за это иногда руки хочется отрывать

когда приходит пулреквест на новую фичу, а там в дифах не только фича, а куча рефакторинга и хрен прочитай что произошло в конечном итоге

вот за это иногда руки хочется отрывать

поясните

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

откуда эта цитата?

когда приходит пулреквест на новую фичу, а там в дифах не только фича, а куча рефакторинга и хрен прочитай что произошло в конечном итоге

Это вопрос не рефакторинга а оформления комитов. Разделите на пулреквеста и т.д.

откуда эта цитата?

не откуда

Или вы на рефакторинг и тестирование выделяете специальное время (вне задач)?

Это вопрос не рефакторинга а оформления комитов. Разделите на пулреквеста и т.д.

если ты во время задачи делаешь рефакторинг, как ты разделять будешь? по факту тебе нужно сразу сделать задачу (1 PR), потом рефакторинг (2 PR)

чтобы не было мешанины

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

с появлением облаков "тушить железом" можно практически до бесконечности

Допустим, но при этом вы считаете, что вы в таком случае делаете рефакторинг вне задачи?

откуда nginx то взялся?! fpm отлично с лайти работает. я считаю именно так, а цепляться к фразе чтобы доказать что-то. ну я даже не знаю о чем дальше можно говорить. если можешь предложить каноничную формулировку для слова highload - то давай. к слову если посмотреть не только на мое понимание слова highload, то станет ясно, что это не только мое видение - https://ruhighload.com/post/Что%20такое%20highload%20и%20что%20с%20ним%20делать - http://highload.guide/blog/highload-for-beginners.html

по формулировки ruhighload 9 из 10 проектов являются им.

Без задачи за рефакторинг я и не возьмусь. Зачем что-то менять если нет необходимости?

Допустим, но при этом вы считаете, что вы в таком случае делаете рефакторинг вне задачи?

рефакторинг бывает разным. но часто стоит его выполнять отдельно от задач

и если задача требует изменения текущего кода, это не рефакторинг. это часть фичи

по формулировки ruhighload 9 из 10 проектов являются им.

не вижу в этом какой либо проблемы, ну только если у некоторых IT "генеев" корона слетит от того, что теперь у всех highload

и если задача требует изменения текущего кода, это не рефакторинг. это часть фичи

Рефакторинг по определению — это изменение кода без изменения функциональности

новая фича это и есть изменение функциональности

как ты узнаешь что твой рефакторинг ничего не сломал, если ты делаешь параллельно еще и фичу новую?

а вообще основная проблема как раз таки в код ревью

ревьювить 100 измененных файлов куда тяжелее десятка

как ты узнаешь что твой рефакторинг ничего не сломал, если ты делаешь параллельно еще и фичу новую?

тесты для этого пишутся

новая фича это и есть изменение функциональности

без новой фичи нет необходимости что-то рефакторить, согласны?

тесты не все покрывают, и не всегда показывают то что нужно

тесты не все покрывают, и не всегда показывают то что нужно

Если вы рефакторите, будте любезны покрыть тестами, иначе как вы поймете что-ничего не сломали даже без новой фичи?

с появлением облаков "тушить железом" можно практически до бесконечности

вертикальное и горизонтальное масштабирование будет работать до поры до времени и рано или поздно нужно разрабатывать новые протоколы, алгоритмы, инфраструктурное и системное ПО (брокеры, кэши, СУБД)

Те проблемы, который вы описываете — это лишь проблемы органицации cr.

без новой фичи нет необходимости что-то рефакторить, согласны?

м, нет. есть такое понятие как тех.долг, и с ним не стоит затягивать. примерно так, делается фича, потом костыль, потом еще костыль и 3й костыль со скрипом влезает и в этот момент уже следующая задача будет на "ребейс костылей" в связи с тем что стали известны все требования и тогда рефакторится все и цикл начинается по новой

Если вы рефакторите, будте любезны покрыть тестами, иначе как вы поймете что-ничего не сломали даже без новой фичи?

вы тесты вообще пишете?

А я писал о том, что за кодом надо ухаживать и «выпрашивать время» на это это глупость — рефакторинг — часть работы.

я и не говорю что "выпрашивать"

А я изначально и не вам писал.

задача делается 6 часов, 2 часа рефакторинг. все в рамках задачи, но разные коммиты и реквесты. чтобы команде было проще вникать

вы тесты вообще пишете?

Да пишем.

задача делается 6 часов, 2 часа рефакторинг. все в рамках задачи, но разные коммиты и реквесты. чтобы команде было проще вникать

Теперь вы уже пишите, что в рамках задачи.

Да пишем.

тогда должны понимать, что когда у вас bloated класс на 10 зависимостей покрыт тестами и вы пытаетесь его отрефакторить, то тесты у вас тоже меняются. и где гарантия того что все работает? пока это звучит как слоган с рекламы

Теперь вы уже пишите, что в рамках задачи.

в джире задача одна, для пмов тоже, а для разрабов нет

У нас проблемы с терминологией — у вас своя, у меня своя. Под задачей я понмиаю бизнесс-задачу. Так что тут у нас все одинаково.

Все делается в рамках одной бизнес задачи.

у вас нет понятия технического долга в беклоге?

т.е работаете по принципу "работает, не трогай"?

тогда должны понимать, что когда у вас bloated класс на 10 зависимостей покрыт тестами и вы пытаетесь его отрефакторить, то тесты у вас тоже меняются. и где гарантия того что все работает? пока это звучит как слоган с рекламы

Предлагаете его не трогать? Тесты никогда не дают 100% гарантию что все ок.

т.е работаете по принципу "работает, не трогай"?

более сложно, но в целом да. Если код не нуждается в изменении и не вызывает боли, то его не будут трогать просто так.

Предлагаете его не трогать? Тесты никогда не дают 100% гарантию что все ок.

это был элементарный пример что тесты не гарантия того что код будет работать как и работал. так как тесты это тоже код, который меняется во время рефакторинга 90% вероятности

Если вы про юнит тесты, то да они будут меняться, более верхне уровневые тесты не будут.

можете конечно рассказать за интеграционные тесты, функциональные и тд более высокого уровня, которые проверят весь модуль.. но тогда у вас либо куча дублирования в тестах, либо эти тесты нихрена не проверяют

скажем если класс на 10 зависимостей, то проверить все ветки логики и все исключительные ситуации с интеграционным тестами это то еще веселье

Если у вас класс с 10 зависимостями, то с ним явно что-то не так.

вертикальное и горизонтальное масштабирование будет работать до поры до времени и рано или поздно нужно разрабатывать новые протоколы, алгоритмы, инфраструктурное и системное ПО (брокеры, кэши, СУБД)

это способы достижения цели, а не способ ответить на очень абстрактный вопрос "Скажите какой проект считается высоконагруженным?" если у меня свои протоколы и алгоритмы это уже хайлоад? нет четкой границы и не может быть. википедия или хабр это хайлоад?

Но в целом никто веселья не обещал.

У нас есть оочень сложные классы (100к loc).

И их рефакторить боль

один класс на 100к?