Здравствуйте, Lazytech, Вы писали:
L>Ваш браузер устарел
Как круто поменялось время! Раньше веб-писаки *опу рвали, чтобы "во всех браузерах всё одинаково", а теперь наоборот — заточат своё помоечное жабоскрипное гогно на Хром и сидят — издеваются над юзерами. Ничтожные диктаторы локалхоста!
Здравствуйте, Lazytech, Вы писали:
L>Зайдя на новостной сайт, увидел в шапке сайта этот текст:
L>[q]Ваш браузер устарел
<skipped>
Никто не анализировал, какой у тебя браузер. Просто им хочется свой браузер навязать.
Ты понял, другие не поймут и установят.
Я такое сообщение получал много раз и просто не обращаю внимания.
Здравствуйте, Lazytech, Вы писали:
L>Зайдя на новостной сайт, увидел в шапке сайта этот текст: L>
Ваш браузер устарел
L>Пожалуйста, обновите его или установите новый.
L>Ваш браузер не обновлялся уже несколько лет. За это время некоторые сайты стали использовать новые технологии, которые он не поддерживает и не может корректно отобразить страницу. Чтобы это исправить, попробуйте установить новый браузер.
L>Если что, этот браузер — свежая версия Waterfox (форкнутый Firefox). Я бы еще понял, если бы мне просто предложили обновить браузер, но говорить, что мой «браузер не обновлялся уже несколько лет».
Да они уже охренели в натуре.
Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер.
Запустишь хром и можешь идти чайку попить, как раз минут через пять страничка вылезет.
Здравствуйте, Lazytech, Вы писали:
L>Зайдя на новостной сайт, увидел в шапке сайта этот текст: L>
Ваш браузер устарел
L>Пожалуйста, обновите его или установите новый.
L>Ваш браузер не обновлялся уже несколько лет. За это время некоторые сайты стали использовать новые технологии, которые он не поддерживает и не может корректно отобразить страницу. Чтобы это исправить, попробуйте установить новый браузер.
L>Если что, этот браузер — свежая версия Waterfox (форкнутый Firefox). Я бы еще понял, если бы мне просто предложили обновить браузер, но говорить, что мой «браузер не обновлялся уже несколько лет».
Весь смысл Waterfox в использовании старой версии Firefox. Этой версии как раз два года.
Здравствуйте, Ikemefula, Вы писали:
Ф>>Я не знаю на каком Марсе живёшь ты, а здесь, на Земле, сорцы по триста килобайт и методы по 5 экранов, а ещё некоторые слышали про документацию.
I>Триста килобайт это много ?
Для одного файла это очень много. Метод на пять экранов — МНОГО: внятно описать тремя словами, что именно он делает вряд-ли получится, и чаще всего такие методы называют как-нибудь типа bworker_DoWork — тебе придётся потратить некоторое время, чтобы понять что именно там происходит. Зачем там что-то происходит, и что там является фичей, а что багой — тоже придётся выяснять. Написать тесты для этого у тебя тоже вряд-ли выйдет: оно делает всё, и тестировать всё ты будешь до пенсии — там и UI'ная часть и ввод-вывод. Сильно повезёт, если он на регионы разбит.
I>Это твой выбор, что ты работаешь в таком месте. Для меня то что ты пишешь это дикая дичь, которой я не видел уже лет пятнадцать наверное или больше.
У меня в связи с этим другой вопрос возникает: вот, подходит к тебе твой руководитель, и спрашивает "А что ты сейчас делаешь?. Что ты скажешь? Код переписываешь/рефакторишь? Зачем? С точки зрения бизнеса ты в этот момент не пишешь фичи и не чинишь баги. Это ведь не принесёт прибыли, а у тебя есть другие задачи. Клиенты ждут — всегда кто-то чего-то ждёт.
Как ты объяснишь руководству своё поведение? Ты ведь понимаешь, что после рефакторинга чувак рядом не сможет вмержить в твой код задачу, которую он в момент рефакторинга делал. Вот, ты разломал монстра (некий файл "АAAAAA.cs"), а в этот момент люди с ним работали. Переписывать/переделывать им скажешь?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Ikemefula, Вы писали:
I>Приходишь ты в кондитерскую и говоришь: "нехрен убирать, мыть, наводить порядок, дезинфицировать и тд и тд и тд — надо печь пироги, потому что клиенты покупают пироги а не порядок на кухне"
Если бы не было законодательно требуемых санитарно-технических норм, никто бы порядок и не наводил, пекли бы пироги до посинения. Не удивлюсь, если и сейчас во многих местах так и происходит.
I>Далее, разве я предлагаю переписывать ? Я вроде как говорю прямо противоположное — переписывать не надо. I>Еще раз — переписывать не нужно. I>На всякий — переписывать не нужно. I>Теперь понятно, что переписывать не нужно ?
Нет, ты говоришь, что переписывать нужно.
I>А между тем любое изменение кода должно начинаться и заканчиваться рефакторингом. I>Просто потому, что это сокращает время разработки.
Время разработки чего? Время разработки конкретной фичи может удлинить на порядки.
I>И еще более странно путать рефакторинг и переписывание.
Рефакторинг — это переписывание.
I>Рефакторинг это экономически выгодный способ как достичь цели без переписывания.
What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.
Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.
Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.
The only reason why this product is still surviving and still works is due to literally millions of tests!
Here is how the life of an Oracle Database developer is:
— Start working on a new bug.
— Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.
— Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.
— Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.
— Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.
— Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.
— Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.
— Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.
— Finally one fine day you would succeed with 0 tests failing.
— Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.
— Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.
— After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.
The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).
The fact that this product even works is nothing short of a miracle!
I don't work for Oracle anymore. Will never work for Oracle again!
Где там рефакторинг, думаю, догадаешься сам. Но эти 25 миллионов строк говнокода уже много лет приносят миллионы долларов. А теперь расскажи про экономическую выгодность рефакторинга миллиардеру Ларри Эллисону.
Здравствуйте, Privalov, Вы писали:
P>Ну тут как сказать. P>Во-первых, фреймворк фреймворку рознь. P>Во-вторых, получив фреймворк, разработчики зачем-то усиленно начинают его переписывать. Вместо того, чтобы решать поставленную задачу. P>В-третьих, если во фреймворке отсутствует какая-то нужная возможность, разработчики будут искать ее в других фреймворках, и потом притянут эти другие фреймворки в проект. Со всеми вытекающими. P>Насмотрелся я на такое. Не в вебе, правда, но говорят, что и там то же самое.
В бесфремворковом мире все еще хуже — появляется свой кастомный полу-реакто-ангуляр, с экзотическим стейтменеджментом, шаблонами, билдами, конфигурацией, рендерингом, и все это спихивают на первого попавшегося миддла, иногда даже джуна.
По этому кастомному решению нет документации, неизвестно, какие фичи реализованы, какие проблемы, какие соглашения поддерживаются, неизвестно вообще ничего. Как правило, качество решения крайне низкое, т.к. все кастомное.
Очень редко бывает так, что бы кастомное решение было высокого качества, было понятным со стороны кода и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Не смеши людей, нету там мутатени, вход в реакт еще ниже, чем в jQuery.
Ты даже не понимаешь о чем речь. Дело не во входе, а в том что реакт при правке DOM делает кучу лишних действий. При этом на простых страничках разницы в объеме межу реактом и vanilla js очень мало.
Здравствуйте, Ikemefula, Вы писали:
Ф>>Для одного файла это очень много. Метод на пять экранов — МНОГО:
I>Пять экранов это очень маленькое МНОГО 300кб кода это ~10тыс строк. Что у тебя за экран такой, что на него влазит по две тыщи строк ?
Пять экранов — примерно 300 — 330 строк кода. Это нормально для класса или файла, но если это один метод, то это много. Хорошо воспринимаются методы до двух экранов, а ещё лучше, если метод влазит на экран.
I>Но вообще забавно — ты топишь за статику, но тут же голосуешь за отказ от неё Ты точно понимаешь, для чего нужна статическая типизация ?
Точно понимаю для чего она нужна. Здесь я тебе говорю почему старый код так и будет продолжать работать, и статику ты не включишь. Или таки включишь, но тебя потом "попросят".
I>То есть, без рефакторинга ты большую часть времени просто как муха в паутине, только почему то это называют 'спагетти'. Собственно именно фича обычно <10% всего времени — выяснить, что происходит, выяснить, где еще клочки функциональности, спросить коллег, кто что в курсе, сварить из этого суп и поправить N-мест, и так несколько раз подряд, потому как то тесты отваливаются, то QA заворачивает, ибо пропущено часть условий. I>Потом через пару недель все повторяется, т.к. изменения совсем в другом месте ломают старый код.
С рефакторингом будет почти тоже самое, только фича подорожает: сначала ты распутываешь паутину (разбираешься в существующих спагетти), потом наводишь там порядок (рефакторишь), а потом делаешь фичу. И при этом ты ещё и остальных задерживаешь.
Без рефакторинга ты распутываешь спагетти, и делаешь фичу — меньше на один большущий шаг.
I>И еще более странно путать рефакторинг и переписывание.
Я их и не путаю.
I>Рефакторинг это экономически выгодный способ как достичь цели без переписывания.
Неверно: Рефакторинг — экономически невыгодный способ достичь неизвестно чего.
Результат рефакторинга — это не новая фича и не пофикшенный баг. Люди, которые тебе платят зарплату не поймут. С их точки зрения ты сидел и бесполезно тратил время, а ещё вносил изменения в код, и скорее всего, занёс пару ошибок — как минимум напряг отдел QA.
I>Переписывать — не нужно I>Переписывать — не нужно I>Переписывать — не нужно...
Хлопни фронтовые 100 грамм (для храбрости), и скажи это в лицо человеку, который попытается с тобой смержиться.
Всё сказанное выше — личное мнение, если не указано обратное.
Зайдя на новостной сайт, увидел в шапке сайта этот текст:
Ваш браузер устарел
Пожалуйста, обновите его или установите новый.
Ваш браузер не обновлялся уже несколько лет. За это время некоторые сайты стали использовать новые технологии, которые он не поддерживает и не может корректно отобразить страницу. Чтобы это исправить, попробуйте установить новый браузер.
Если что, этот браузер — свежая версия Waterfox (форкнутый Firefox). Я бы еще понял, если бы мне просто предложили обновить браузер, но говорить, что мой «браузер не обновлялся уже несколько лет».
Какой ты не патриотичный. Тебе же четко сказали: иди в яндекс браузер.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Lazytech, Вы писали:
A>>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер. L>Это потому, что ОЗУ мало, что ли? Или ЦП не потянет?
Это потому что у современных фронтендеров руки из жопы. У нас тут попытались без мегафреймворков несложный UI в одном проекте сделать — так в результате остальные фронтенд-господа за это форменным образом зачмырили. Раз нет реакта или ангуляра, значит фтопку.
Здравствуйте, Ikemefula, Вы писали:
I>Если притимивный функционал тормозит на современном фремворке, то с большой вероятностью кастомное решение будет работать еще хуже. I>Что бы кастомное работало лучше фремворка, то фронтенд-девелопер должен обладать весьма незаурядной квалификацией.
Да да, чтобы написать вместо реактовской мутатени с компаратормами примитивный код по правке DOM, нужно незаурядную квалификацию.
Вот я и говорю, у фронтендеров руки из жопы, мимо своих фреймворков уже даже мыслить не могут.
Здравствуйте, alexsmirnoff, Вы писали:
A>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер. A>Запустишь хром и можешь идти чайку попить, как раз минут через пять страничка вылезет.
Ну не надо вот только преувеличивать. Десятилетние компьютеры сейчас работают с современными браузерами лучше, чем 10 лет назад.
Здравствуйте, Lazytech, Вы писали:
МД>>Какой ты не патриотичный. Тебе же четко сказали: иди в яндекс браузер. L>Если что, по ссылке предлагается несколько браузеров, так что мимо.
Ага. Кроме Яндекс-браузера там есть еще и другие браузеры, в которые изкоробки заботливо встроены: "сервисы Яндекса: Карты, Почта и Поиск", "Яндекс.Советник", "Визуальные закладки" от Яндекса, "Лента Дзена" и еще многое много другое бгг.
Так что не "мимо" а именно оно: иди на Астру в яндекс браузер
Здравствуйте, Lazytech, Вы писали:
L>Вообще-то фреймворки заметно упрощают разработку, так что...
Ну тут как сказать.
Во-первых, фреймворк фреймворку рознь.
Во-вторых, получив фреймворк, разработчики зачем-то усиленно начинают его переписывать. Вместо того, чтобы решать поставленную задачу.
В-третьих, если во фреймворке отсутствует какая-то нужная возможность, разработчики будут искать ее в других фреймворках, и потом притянут эти другие фреймворки в проект. Со всеми вытекающими.
Насмотрелся я на такое. Не в вебе, правда, но говорят, что и там то же самое.
Здравствуйте, Ночной Смотрящий, Вы писали:
A>>>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер. L>>Это потому, что ОЗУ мало, что ли? Или ЦП не потянет?
НС>Это потому что у современных фронтендеров руки из жопы. У нас тут попытались без мегафреймворков несложный UI в одном проекте сделать — так в результате остальные фронтенд-господа за это форменным образом зачмырили. Раз нет реакта или ангуляра, значит фтопку.
Махровый техно-расизм однако. Правильно сделали, что вас зачмырили Большей частью для фронта лучше взять готовое решение, а не пилить своё. "без мегафремворков" майнтейнить гораздо тяжелее.
В норме опытные фронтенды вынуждены бегать по проектам и тушить пожары, потому что ктото решил понаписывать кастомных решений. После таких вот пожаров лучше убивать подобные начинания еще в зародыше
Здравствуйте, Lazytech, Вы писали:
НС>>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
L>Возможно, надо было с самого начала уточнить, что именно тормозит: прорисовка UI или что-то другое? Если сморозил глупость, прошу извинить.
Антивирус наверное
L>К примеру, в последнее время я ради получения практических знаний пытаюсь делать простенькие веб-приложения под руководством опытного разработчика. Одно из этих приложений заметно глючит и сильно подтормаживает из-за моего неумелого обращения с асинхронными методами. При этом собственно UI работает быстро, а тормоза вызваны очень медленной загрузкой файлов на сервер и достаточно медленным получением файлов с сервера.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зато сами современные сайты стали сильно хуже. У моего не самого древнего ноута (2420М емнип) большая часть интернет-магазинов постоянно вызывает задумчивость на несколько секунд, особенно после загрузки страницы. Динамического функционала в тех магазтинах с гулькин хрен, зато скриптов запускается целая гора.
Загляни в унутрь — те магазины писаны еще десять лет назад на джиквери и с тех пор только стили меняли. Контента стало больше, вот они и дохнут, потому что на любой клик и чих перелопачивают вообще всё ибо "примитивный код по правке DOM"
Здравствуйте, Lazytech, Вы писали:
I>>JS это пример __простого__ языка. Это видно по его распространению. Именно оттого что простой, он вот так широко распространен, шире любого другого языка.
L>Я тоже по наивности считал JS простым языком, когда решал на нем тренировочные задачки. А когда пришло время для практики, оказалось, что простой там только синтаксис. По крайней мере, мне, начинающему, так кажется.
Ты путаешь "сложно" и "трудно". Программирование вообще легким не бывает. В JS есть некоторые неочевидные и противоестественные особенности. Но вообще такое есть практически в каждом из языков, только их со временем научились обходить.
L>P.S. Я про scope, closure, this, Promise, псевдоклассы и иже с ними. Кстати, не посоветуете толковые лекции по JavaScript «для тупых»?
scope, closure, this, promise есть во всех других платформах, почти один к одному. Вместо писания на чистом JS пробуй использовать ES6 а лучше TypeScript, сразу забудешь про псевдоклассы.
я привел грубую оценку для конкретного случая. Правда, там речь идет о сайте vuejs.org, и это не тот случай, когда сапожник без сапог.
Во все времена было примерно так — сайт должен загрузиться за разумное время, скажем, 1с у типичного пользователя. Сколько здесь будет кило-мега-гига-тера-байт, дело десятое. Тарифные планы провайдеров постоянно растут в возможностях. И если в начале 0-вых за 1с можно было грузануть порядка 5-10кб, то сейчас счет идет минимум на сотни килобайт.
Реальное количество кода может быть сколь угодно большим — уже лет пять как не надо весь код отдавать клиенту, а можно нарезать на бандлы, вытрясти лишнее, а остальное грузить по требованию.
Поэтому крики и стоны знатоков не стоит ни принимать близко к сердцу, ни брать в голову. Стоимость загрузки 1й страницы постоянно падает. Теперь анлим даже на телефоне стоит смешных денег сравнивая с нулевыми.
Здравствуйте, alexsmirnoff, Вы писали:
A>Запустишь хром и можешь идти чайку попить, как раз минут через пять страничка вылезет.
Я поэтому на Яндекс.Браузер одно время перешёл. И на телефоне тоже его же поставил — и вот к нынешней весне на моём телефоне он также стал делать — отправлять чай пить. Пришлось на оперу перейти.
Здравствуйте, Kolesiki, Вы писали:
L>>Ваш браузер устарел
K>Как круто поменялось время! Раньше веб-писаки *опу рвали, чтобы "во всех браузерах всё одинаково", а теперь наоборот — заточат своё помоечное жабоскрипное гогно на Хром и сидят — издеваются над юзерами. Ничтожные диктаторы локалхоста!
Здравствуйте, Lazytech, Вы писали:
НС>>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе. L>Рискну предположить, что не сами фреймворки — зло, а неумелое их применение.
Именно это я и написал, когда насильно запихивают фреймворки даже туда, где вреда от них больше, чем пользя.
Здравствуйте, Ikemefula, Вы писали:
I>Махровый техно-расизм однако. Правильно сделали, что вас зачмырили Большей частью для фронта лучше взять готовое решение, а не пилить своё.
Свое никто не пилил, оно там просто не нужно.
I>В норме опытные фронтенды вынуждены бегать по проектам и тушить пожары, потому что ктото решил понаписывать кастомных решений.
Там не было никаких пожаров, там все прекрасно работало и без фреймворков.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Несложный UI пилится быстрее всего на фремворках, сгенерил проект и половина фич идут готовыми.
НС>Каких фич?
Разных. Сгенерируй несколько приложений, сразу узнаешь что к чему. ЦА фремворка это мелкие...средние приложения. Так было во все времена на всех платформах. Вот с большими приложениями очень часто идут без фремворка или с ограниченым применением фремворка.
Здравствуйте, Lazytech, Вы писали:
L>Здравствуйте, alexsmirnoff, Вы писали:
A>>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер.
L>Это потому, что ОЗУ мало, что ли? Или ЦП не потянет?
Здравствуйте, Ikemefula, Вы писали:
I>>>А между тем любое изменение кода должно начинаться и заканчиваться рефакторингом. I>>>Просто потому, что это сокращает время разработки. ARK>>Время разработки чего? Время разработки конкретной фичи может удлинить на порядки. I>Ты предлагаешь каждое место распутывать согласно количеству изменений ?
Я ничего не предлагаю, просто спросил.
I>Стоимость разработки — количество изменений помножить на стоимость распутывания помножить на количество человек.
Как всё просто.
I>Если делать рефакторинг, то каждое место распутывается ровно один раз.
Или нет.
I>>>И еще более странно путать рефакторинг и переписывание. ARK>>Рефакторинг — это переписывание. I>Рефакториг это безопасное изменение структуры кода при гарантии сохранения поведения.
Рефакторинг — это переписывание уже рабочего кода. Из одного вида в другой.
I>А вот переписывание это когда меняешь true на false и надеешься, что это сработает.
Это уже не переписывание, а модификация кода.
I>>>Рефакторинг это экономически выгодный способ как достичь цели без переписывания. ARK>>Доказательств этому нет и никогда не было. I>Наоборот.
Тогда обоснуй свое утверждение об экономической выгодности рефакторинга.
ARK>>Вот тебе про внутренности одной из ведущих СУБД: https://news.ycombinator.com/item?id=18442941 I>С чего ты взял, что рефакторинг не применяетс ? Что, никто никогда не переименовывает переменные ? Или не разрезает длинный метод на короткие ?
Из текста можно сделать вполне реалистичное предположение, что рефакторинга там нет ни в каком виде. Может только локальные переменные в функциях иногда переименовывают.
Здравствуйте, Ikemefula, Вы писали:
ARK>>>>Время разработки чего? Время разработки конкретной фичи может удлинить на порядки. I>>>Ты предлагаешь каждое место распутывать согласно количеству изменений ? ARK>>Я ничего не предлагаю, просто спросил. I>Это вранье.
Вранье у тебя. Я никаких предложений не вносил.
I>У тебя кроме вопроса есть и конкретное утверждение.
Вот это — "Время разработки конкретной фичи может удлинить на порядки"? Да, такое утверждение у меня есть. И оно истинно.
I>>>Стоимость разработки — количество изменений помножить на стоимость распутывания помножить на количество человек. ARK>>Как всё просто. I>Именно. Все, кому надо чтото в коде, обязаны распутать. Практика показывает, что удаётся это далеко не всем.
Только вот большая часть IT-проектов не влезает ни в срок, ни в бюджет (кажется, у Макконнелла про это читал). Странно, ведь есть простая формула.
I>Более того — в большом проекте к конкретному месту можешь вернуться не скоро. А стало быть распутывать будешь заново.
Или вообще никогда не буду.
I>>>Если делать рефакторинг, то каждое место распутывается ровно один раз. ARK>>Или нет. I>Это цель рефакторинга — решить конкретную проблему с кодом. Если ты рефакторишь абы покрасивше, то для этого другой термин — саботаж
С чего ты взял, что "решение проблемы с кодом" может быть единственным? Ты кусок по своему зарефакторил, Васе не понравилось твое "решение", он переделал.
ARK>>Рефакторинг — это переписывание уже рабочего кода. Из одного вида в другой. I>Переписывание — это когда ты пишешь нечно заново. Рефакторинг это вобщем то фиксированый набор операций, который можно применять к коду. Например — переименовать переменную.
Фиксированные операции могут вызывать далеко идущие последствия. Рефакторинг в целом не сводится к фиксированным операциям. Скажем, при изменении видимости поля будет затронут другой код.
I>У тебя какая то своя терминология. Изначально рефакторинг появился как альтернатива переписыванию.
Слово "переписывание" не обязательно означает переписывание полностью и с нуля. Если ты его понимаешь только так, то, конечно, это не рефакторинг. Я понимаю под "переписыванием" в том числе и частичное переписывание, которым рефакторинг и является.
I>>>А вот переписывание это когда меняешь true на false и надеешься, что это сработает. ARK>>Это уже не переписывание, а модификация кода. I>Все изменения вместе взятые — модификация. Рефакторинг — это изменения только определенных аспектов при сохранении поведения. А переписывание не ограничивается этим — пиши что хошь, меняй поведение на новое — все равно переписывание. Но это не рефакторинг
Теперь ты вводишь еще одно дополнительное уточнение — что переписывание обязательно НЕ подразумевает сохранения поведения. А это не так.
Переписывание (скорее всего, частичное) кода c сохранением поведения — это и есть рефакторинг.
ARK>>>>Доказательств этому нет и никогда не было. I>>>Наоборот. ARK>>Тогда обоснуй свое утверждение об экономической выгодности рефакторинга. I>Ты его проигнорировал.
Я его не увидел. Будь добр, уточни, что именно ты имеешь в виду под "обоснованием экономической эффективности рефакторинга".
I>>>С чего ты взял, что рефакторинг не применяетс ? Что, никто никогда не переименовывает переменные ? Или не разрезает длинный метод на короткие ? ARK>>Из текста можно сделать вполне реалистичное предположение, что рефакторинга там нет ни в каком виде. Может только локальные переменные в функциях иногда переименовывают. I>Это додумки. Текст показывает только результат. Каким путем ты к нему пришел, рефакторингом, переписыванием — не ясно.
Текст показывает, что изменения кода очень болезненны. Это делает крайне сомнительными любые рассуждения о рефакторинге.
Здравствуйте, Ikemefula, Вы писали:
ARK>>Вранье у тебя. Я никаких предложений не вносил. I>Вот я тебя и спрашиваю — что ты хочешь предложить взамен ? Выглядит так, как будно ты предлагашь отказаться исправлять затруднения.
Я ничего не хочу предлагать и не предлагаю. Я просто подвергаю сомнению твои утверждения о природе и экономической эффективности рефакторинга.
ARK>>Вот это — "Время разработки конкретной фичи может удлинить на порядки"? Да, такое утверждение у меня есть. И оно истинно. I>А ты можешь гарантировать, что это 1 истинно для любой фичи 2 истинно для всех фич вместе взятых ?
Я написал — "может". Естественно, никаких гарантий этого не существует.
ARK>>Только вот большая часть IT-проектов не влезает ни в срок, ни в бюджет (кажется, у Макконнелла про это читал). Странно, ведь есть простая формула. I>Нужно внимательно Макконела читать. Ты не знаешь, сколько времени будешь распутывать паутину. Это неопределенность. Хочешь внятные оценки — надо устранять неопределенности.
По факту внятных оценок никто дать не может. Ну, кроме тебя, разумеется.
ARK>>С чего ты взял, что "решение проблемы с кодом" может быть единственным? Ты кусок по своему зарефакторил, Васе не понравилось твое "решение", он переделал. I> А что, у вас код-ревью нет или трудно вместе с Васей выработать внятное решение ?
Во, пошли еще дополнительные ограничения.
Тем не менее, в общем случае один и тот же кусок кода может правиться много раз.
I>Частичное переписывание с изменением поведения не является рефакторингом. А по твоему это рефакторинг.
Да, частичное переписывание с изменением поведения не является рефакторингом. Я нигде не утверждал обратного.
Хотя изменение поведения может произойти случайно — тогда получится, что был запланирован и начат процесс рефакторинга, но результат оказался как у переделки.
I>Рефакторинг это вообще говоря получение гарантий, что новый код не сломал поведение. А у тебя, внезапно, каким то чудом взялись гарантии после переписывания. Откуда ?
Никаких гарантий в общем случае рефакторинг дать не может. Потому что это модификация кода.
ARK>>Теперь ты вводишь еще одно дополнительное уточнение — что переписывание обязательно НЕ подразумевает сохранения поведения. А это не так. ARK>>Переписывание (скорее всего, частичное) кода c сохранением поведения — это и есть рефакторинг. I>А каким чудом ты эти гарантии получишь, если сел и все перехерачил ?
А каким чудом ты при рефакторинге получишь какие-то гарантии?
ARK>>Я его не увидел. Будь добр, уточни, что именно ты имеешь в виду под "обоснованием экономической эффективности рефакторинга".
I>Если n человек будут еждедневно выполнять работы, которые длятся неопределенный период, и неизвестно какой результат могут давать, то проект выйдт из любых сроков и бюджетов. I>Например, распутывание паутины в коде длится именно неопределенный период.
Это не обоснование, а некоторые поверхностные соображения.
Собственно, в программировании любое написание кода может затянуться на неопределенный период.
ARK>>Текст показывает, что изменения кода очень болезненны. Это делает крайне сомнительными любые рассуждения о рефакторинге. I>Разумеется, болезненны. Из этого никак не следует, что проблемы решать не надо.
Я не говорю, что проблемы решать не надо. Я говорю, что по тексту вполне видно, что рефакторинг в оракуле вряд ли применяется.
I>Как ты собираешься фичу вводить, раз изменения болезненны ?
Там про это тоже написано. Очень медленно они вводят фичи. Но бабло гребут лопатой при этом.
Здравствуйте, Ikemefula, Вы писали:
I>Опаньки! Тогда ценность твоего высказывания про удлиннение конкретной фичи равна нулю.
Нет. Равна нулю ценность твоего утверждения, что рефакторинг сокращает время разработки.
ARK>>По факту внятных оценок никто дать не может. Ну, кроме тебя, разумеется. I>А ты — нечитатель. Неопределенность и есть причина того, что внятных оценок никто дать не может.
Возможно. И рефакторинг никаких неопределенностей не устраняет, однако добавляет новые
ARK>>Во, пошли еще дополнительные ограничения. I>Разумеется. Если над кодом работает команда, то результат должен устраивать всех. Почему рефакторинг должен выделяться ? I>А ну как ты переписал код, а Вася его выбросил и написал свой. Чем это лучше твоего примера ?
Ничем не лучше. И рефакторинг точно так же не гарантирует того, что над этим кодом никто больше не будет работать.
ARK>>Тем не менее, в общем случае один и тот же кусок кода может правиться много раз. I>Именно — и фактор неопределенности играет ровно столько же раз.
Я тут говорил про рефакторинг, если что.
I>Поэтому и надо разделять рефакторинг — изменения с определенными гарантиями, и переписывание, где нет никаких гарантий.
На практике это одно и то же. Гарантий ты никаких не получишь ни в том, ни в том случае. Можешь разве что разделить _намерения_. Но сам процесс особых различий не несет.
ARK>>Хотя изменение поведения может произойти случайно — тогда получится, что был запланирован и начат процесс рефакторинга, но результат оказался как у переделки. I>Может. А если изначально отказаться от гарантий, то гарантировано получаешь хаос
Ну, это просто манипуляция терминами.
ARK>>Никаких гарантий в общем случае рефакторинг дать не может. Потому что это модификация кода. I> У вас похоже ни IDE, ни инструментов, ни тестов, ни тестировщиков не изобрели. Так что ли ?
Ну я понял, ты просто называешь переписывание кода без изменения поведения — рефакторингом. Это твое право, но по сути это все равно переписывание. Но ты переписыванием называешь только один частный случай.
ARK>>Это не обоснование, а некоторые поверхностные соображения. I>Это именно обоснование. Или ты думал я тебе научный труд принесу ?
Это набор голословных утверждений, не подкрепленных ничем.
ARK>>Я не говорю, что проблемы решать не надо. Я говорю, что по тексту вполне видно, что рефакторинг в оракуле вряд ли применяется. I>Ты говоришь, что у Оракла плохой код. Из этого никак не следует, что рефакторинг не применялся , неприменим и тд.
Почему же, плохой код и отсутствие рефакторинга — это сильная корреляция.
I>>>Как ты собираешься фичу вводить, раз изменения болезненны ? ARK>>Там про это тоже написано. Очень медленно они вводят фичи. Но бабло гребут лопатой при этом.
I>Я вот не в курсе, видят ли они проблему в скорости введения фич. А ты из простого факта про скорость начал делать глобальные выводы "крайне сомнительными любые рассуждения о рефакторинге" I>Да хоть по году на мелкий баг, тебе то что с того ? Рефакторинг нужен в том случае если это становится проблемой. Захочешь, скажем, фичи вводить намного быстрее. Каким таким способом ?
Не знаю, видят ли они какие-то проблемы. Я вижу, что экономическая эффективность рефакторинга под сомнением.
Здравствуйте, Ikemefula, Вы писали:
I> M>Современная веб разработка это идиотизм полнейший. Для простого сайта нужно 100 метров быкенда, и 10 фронта, и при этом "браузер устарел" I> Современная веб-разработка это будущее почти всех технологий. Большинству молодых девелоперов придется перейти писать для браузера, под браузер или просто 'на жээсе'.
Какое ужасное будущее (((
Так и до пенсии доживать не захочется.
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Какой ты не патриотичный. Тебе же четко сказали: иди в яндекс браузер.
Если что, по ссылке предлагается несколько браузеров, так что мимо.
Вот код, предлагающий обновить браузер:
<!--[if lte IE 9]>
<div class="browser-updater js-browser-updater">
<div class="browser-updater__close js-browser-updater-close">×</div>
<div class="browser-updater__title">Ваш браузер устарел</div>
<div class="browser-updater__subtitle">
Пожалуйста, обновите его или установите
<a class="browser-updater__link" href="https://yandex.ru/soft/browsers/" target="_blank">новый</a>.
</div>
<div class="browser-updater__description">
Ваш браузер не обновлялся уже несколько лет. За это время некоторые сайты стали использовать новые технологии, которые он
не поддерживает и не может корректно отобразить страницу. Чтобы это исправить, попробуйте установить новый браузер.
</div>
</div> <![endif]-->
Получается, что свежий Waterfox не дотягивает до IE 9.
P.S. Поправка: судя по этой информации, if lte IE 9 означает, что у пользователя браузер IE версии 9 или ниже (less than or equal).
A>>Комп десятилетней давности может гонять автокады и солидворксы, но не современный браузер.
L>Это потому, что ОЗУ мало, что ли? Или ЦП не потянет?
10, а то и 20 процессов, которые что-то усиленно делают.
Здравствуйте, Max Mustermann, Вы писали:
MM>Ага. Кроме Яндекс-браузера там есть еще и другие браузеры, в которые изкоробки заботливо встроены: "сервисы Яндекса: Карты, Почта и Поиск", "Яндекс.Советник", "Визуальные закладки" от Яндекса, "Лента Дзена" и еще многое много другое бгг.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это потому что у современных фронтендеров руки из жопы. У нас тут попытались без мегафреймворков несложный UI в одном проекте сделать — так в результате остальные фронтенд-господа за это форменным образом зачмырили. Раз нет реакта или ангуляра, значит фтопку.
Вообще-то фреймворки заметно упрощают разработку, так что...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
Рискну предположить, что не сами фреймворки — зло, а неумелое их применение.
P.S. Хотя да, веб-приложения, сделанные на голом JavaScript, оказываются производительнее, чем если бы их сделали на каком-либо фреймворке.
However if you want to get the best performance, benchmarks have shown time and time again, that a tuned vanilla js application outperforms any framework.
Здравствуйте, Ночной Смотрящий, Вы писали:
L>>Рискну предположить, что не сами фреймворки — зло, а неумелое их применение. НС>Именно это я и написал, когда насильно запихивают фреймворки даже туда, где вреда от них больше, чем пользя.
Ключевое слово — неумелое, а не неуемное. По-дилетантски предположу, что при умелом применении фреймворка производительность сильно не пострадает.
Здравствуйте, Ночной Смотрящий, Вы писали:
L>>Вообще-то фреймворки заметно упрощают разработку, так что...
НС>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
Если притимивный функционал тормозит на современном фремворке, то с большой вероятностью кастомное решение будет работать еще хуже.
Что бы кастомное работало лучше фремворка, то фронтенд-девелопер должен обладать весьма незаурядной квалификацией.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе. L>>Рискну предположить, что не сами фреймворки — зло, а неумелое их применение.
НС>Именно это я и написал, когда насильно запихивают фреймворки даже туда, где вреда от них больше, чем пользя.
Да нет, ты написал совсем другое: "у современных фронтендеров руки из жопы. ... фронтенд-господа за это форменным образом зачмырили"
Несложный UI пилится быстрее всего на фремворках, сгенерил проект и половина фич идут готовыми. Порылся в инете — нашел половину недостающих.
А вот сложный UI нужно пилить очень осторожно — не факт, что фремворк обладает нужными средствами, свойствами и тд.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Если притимивный функционал тормозит на современном фремворке, то с большой вероятностью кастомное решение будет работать еще хуже. I>>Что бы кастомное работало лучше фремворка, то фронтенд-девелопер должен обладать весьма незаурядной квалификацией.
НС>Да да, чтобы написать вместо реактовской мутатени с компаратормами примитивный код по правке DOM, нужно незаурядную квалификацию.
Не смеши людей, нету там мутатени, вход в реакт еще ниже, чем в jQuery. Но если в голове образовались рельсы "по правке DOM" то это отдельная проблема.
Ручная правка DOM это почти всегда неподдерживаемый код, когда всё прибито гвоздями одно к одному. В реакте все что нужно — взять минималистичный шаблон проекта и подумать, как у вас данные устроены. Если всё действительно просто, то и редух не понадобится. Студенты такое пилят по десятку за неделю при необходимости.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну так кушай тогда сайты, которые с примитивным функционалом умудряются тормозить на довольно приличном железе.
Возможно, надо было с самого начала уточнить, что именно тормозит: прорисовка UI или что-то другое? Если сморозил глупость, прошу извинить.
К примеру, в последнее время я ради получения практических знаний пытаюсь делать простенькие веб-приложения под руководством опытного разработчика. Одно из этих приложений заметно глючит и сильно подтормаживает из-за моего неумелого обращения с асинхронными методами. При этом собственно UI работает быстро, а тормоза вызваны очень медленной загрузкой файлов на сервер и достаточно медленным получением файлов с сервера.
Здравствуйте, Слава, Вы писали:
I>>Студенты такое пилят по десятку за неделю при необходимости.
С>А речь разве об этом? О скоростной разработке силами студентов?
С>Оно — тормозит.
Если тормозит маленькое приложение, то проблема точно не в Реакте. Полно внятных приложений и на ангуляре, и на реакте. Ты их используешь каждый день и даже не замечаешь.
Здравствуйте, Слава, Вы писали:
I>>Студенты такое пилят по десятку за неделю при необходимости. С>А речь разве об этом? О скоростной разработке силами студентов?
А это вот наглядная демонстрация того, о чем я писал. У них мысль в сторону от фреймворков даже не ходит, вопрос о том нужно ли его применять даже не задается. Неизвестно, про какой я писал проект, что он делает, но уже точно известно что реакт нужен обязательно.
Здравствуйте, Cyberax, Вы писали:
C>Ну не надо вот только преувеличивать. Десятилетние компьютеры сейчас работают с современными браузерами лучше, чем 10 лет назад.
Зато сами современные сайты стали сильно хуже. У моего не самого древнего ноута (2420М емнип) большая часть интернет-магазинов постоянно вызывает задумчивость на несколько секунд, особенно после загрузки страницы. Динамического функционала в тех магазтинах с гулькин хрен, зато скриптов запускается целая гора.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Не смеши людей, нету там мутатени, вход в реакт еще ниже, чем в jQuery.
НС>Ты даже не понимаешь о чем речь. Дело не во входе, а в том что реакт при правке DOM делает кучу лишних действий. При этом на простых страничках разницы в объеме межу реактом и vanilla js очень мало.
Странно, почему у меня не тормозит, раз реакт такой убогий, Ы ? И это я даже не фронтенд.
Здравствуйте, Ночной Смотрящий, Вы писали:
С>>А речь разве об этом? О скоростной разработке силами студентов?
НС>А это вот наглядная демонстрация того, о чем я писал. У них мысль в сторону от фреймворков даже не ходит, вопрос о том нужно ли его применять даже не задается. Неизвестно, про какой я писал проект, что он делает, но уже точно известно что реакт нужен обязательно.
Статистика. Кто же виноват, что вы либу с низким входом осилить не можете ?
Здравствуйте, Ikemefula, Вы писали:
НС>>Ты даже не понимаешь о чем речь. Дело не во входе, а в том что реакт при правке DOM делает кучу лишних действий. При этом на простых страничках разницы в объеме межу реактом и vanilla js очень мало. I>Странно, почему у меня не тормозит, раз реакт такой убогий, Ы ?
Здравствуйте, Ikemefula, Вы писали:
I>В бесфремворковом мире все еще хуже — появляется свой кастомный полу-реакто-ангуляр, с экзотическим стейтменеджментом, шаблонами, билдами, конфигурацией, рендерингом, и все это спихивают на первого попавшегося миддла, иногда даже джуна.
Ну, что сейчас никто ничего с нула не пишет, ясно. Я теоретик в вебе, но принципы-то везде одинаковы. Главное — правильно выбрать фреймворк. И тут вопросы к технологам, руководству проектом. Которые часто забывают о разработчиках. Был в моей практике случай, когда навыбирали такого, что было перпендикулярно решаемым задачам.
I>По этому кастомному решению нет документации, неизвестно, какие фичи реализованы, какие проблемы, какие соглашения поддерживаются, неизвестно вообще ничего. Как правило, качество решения крайне низкое, т.к. все кастомное.
Само собой. Попытки руководства заставить разработчиков писать документацию ни к чему хорошему не приводят. Часто на документирование просто времени не хватает. Сроки, бюджет, все дела.
I>Очень редко бывает так, что бы кастомное решение было высокого качества, было понятным со стороны кода и тд.
Здравствуйте, Lazytech, Вы писали:
L>И что мне теперь, на православный Chrome перебираться?
Можешь на католтческую Хромую Оперу или лютеранский Вивальди. Впрочем, по части религиозной принадлежности могу ошибаться.
L>P.S. В свое время долго не хотел уходить с Opera Presto, но увы...
В то время Огнелис был нормальным браузером. Потом испортился.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ты даже не понимаешь о чем речь. Дело не во входе, а в том что реакт при правке DOM делает кучу лишних действий. При этом на простых страничках разницы в объеме межу реактом и vanilla js очень мало. I>>Странно, почему у меня не тормозит, раз реакт такой убогий, Ы ?
НС>Я не писал что реакт убогий.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Загляни в унутрь — те магазины писаны еще десять лет назад на джиквери
НС>Заглядывал, не переживай. Где то ангуляр, где то битрикс, реже реакт.
У меня другая статистика, вот такой хитпарад, в порядке убывания vanilla, jquery, extjs, angularjs...
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Ночной Смотрящий, Вы писали:
С>>>А речь разве об этом? О скоростной разработке силами студентов?
НС>>А это вот наглядная демонстрация того, о чем я писал. У них мысль в сторону от фреймворков даже не ходит, вопрос о том нужно ли его применять даже не задается. Неизвестно, про какой я писал проект, что он делает, но уже точно известно что реакт нужен обязательно.
I>Статистика. Кто же виноват, что вы либу с низким входом осилить не можете ?
Лично я не хочу ничего осваивать — я не фронтэндер. Я хочу чтоб мой ноут не тормозил.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
I>>Статистика. Кто же виноват, что вы либу с низким входом осилить не можете ?
Ф>Лично я не хочу ничего осваивать — я не фронтэндер. Я хочу чтоб мой ноут не тормозил.
Что конкретно ты хочешь изменить или предложить ? Нету такой кнопки "нетормозить".
Если тебе надо удобную мишень для нападок, то во все времена модно было ругать всё новое. Всё новое всегда тормозило, независимо от технологий — с, с++, com, java, dotnet, python, сейчас эстафету перенял JS — всё новое пишется именно на нём.
Здравствуйте, Ikemefula, Вы писали:
Ф>>Лично я не хочу ничего осваивать — я не фронтэндер. Я хочу чтоб мой ноут не тормозил. I>Что конкретно ты хочешь изменить или предложить ? Нету такой кнопки "нетормозить".
Надо сделать такую кнопку.
I>Если тебе надо удобную мишень для нападок, то во все времена модно было ругать всё новое. Всё новое всегда тормозило, независимо от технологий — с, с++, com, java, dotnet, python, сейчас эстафету перенял JS — всё новое пишется именно на нём.
...
Compiler\run-time environment will optimize your loop so you don't need to worry about performance.
Т.е. тот, кто это написал и ещё шестьсот идиотов, которые этот ответ апнули. Don't worry, используйте самый медленный во вселенной способ — не парьтесь.
SO таким вообще переполнен. Я на работе периодически подчищаю за товарищем, который оттуда бездумно копирует.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Bjorn Skalpe, Вы писали:
BS>Поскорее бы это убожество в виде FireFox отмерло...
Увы, нельзя — Майкрософт однажды жёстко поимели за слишком большую долю на рынке боаузеров.
Гугль на эти грабли наступать не намерен. И будет поддерживать огнелиса до бесконечности.
Здравствуйте, Философ, Вы писали:
Ф>Т.е. тот, кто это написал и ещё шестьсот идиотов, которые этот ответ апнули. Don't worry, используйте самый медленный во вселенной способ — не парьтесь.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>Т.е. тот, кто это написал и ещё шестьсот идиотов, которые этот ответ апнули. Don't worry, используйте самый медленный во вселенной способ — не парьтесь.
I>Ок, значит с джаваскриптом вопрос закрыт ?
Лично я в этом плане на жабаскрипт и не наезжал. Каждой задаче свой инструмент, наиболее подходящий для неё. Однако не должен сайт с контентом на метр тянуть 10 метров скриптов из сети. И не нужно супер-мега-софт писать на языке, в котором нет ни типобезопасности, ни модульности, хотя язык при этом умудряется быть СЛОЖНЫМ. Если не согласен с тем, что язык сложный, то попробуй просто объяснить, почему arguments — не массив, и что это вообще за магия такая.
Нет, не надо мне говорить, что модульность в JS уже изобрели: десяток раз уже изобрели, потом переизобрели, а чтобы справиться с напереизобретённым, и подружить всё это друг с другом, изобрели бабел — воз и ныне там...
Слава богу, что я этой дрянью не занимаюсь.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
I>>Ок, значит с джаваскриптом вопрос закрыт ?
Ф>Лично я в этом плане на жабаскрипт и не наезжал. Каждой задаче свой инструмент, наиболее подходящий для неё. Однако не должен сайт с контентом на метр тянуть 10 метров скриптов из сети.
Для юзера имеет значение только время загрузки. И здесь дело совсем не в размере, нынче 10 мб приходит на клиент со свистом.
>И не нужно супер-мега-софт писать на языке, в котором нет ни типобезопасности, ни модульности, хотя язык при этом умудряется быть СЛОЖНЫМ.
Уже есть и типобезопасность, и внятная модульность. Непонятно, откуда у тебя сложность взялась
JS это пример __простого__ языка. Это видно по его распространению. Именно оттого что простой, он вот так широко распространен, шире любого другого языка.
>Если не согласен с тем, что язык сложный, то попробуй просто объяснить, почему arguments — не массив, и что это вообще за магия такая.
Это никакая не сложность Сложный, это такой, который состоит из нескольких частей. Например, в С++ такое было бы Vector<XXX>, где намешано кучка самых разных вещей — класс, шаблоны, внутренний контейнер, операторы... Вот это — сложное. Именно по этому С++ многим просто не под силу. Это медицинский факт.
Ф>Нет, не надо мне говорить, что модульность в JS уже изобрели: десяток раз уже изобрели, потом переизобрели, а чтобы справиться с напереизобретённым, и подружить всё это друг с другом, изобрели бабел — воз и ныне там... Ф>Слава богу, что я этой дрянью не занимаюсь.
В том то и дело, что не занимаешься, но мнение имеешь:
import {Get, Post, Put, Delete} from '@xx/http';
Вот на этом примере, покажи что конкретно тебя не устраивает ?
Вот скажем в С/С++ никаких модулей вообще не видно, а этому семейству скоро 50 лет будет.
Здравствуйте, Ikemefula, Вы писали:
I>Уже есть и типобезопасность, и внятная модульность. Непонятно, откуда у тебя сложность взялась
типа безопасность
<p id="demo"></p>
<p id="demo2"></p>
<script>
var x = myFunction(1, 2);
document.getElementById("demo").innerHTML = x;
function myFunction(a, b) {
if (a > 2)
{
document.getElementById("demo2").innerHTML = b;
return 0;
}
if (a > 1)
return a * b + myFunction(a+1, "myFunction");
return myFunction(a+1, myFunction);
}
</script>
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
I>>Ок, значит с джаваскриптом вопрос закрыт ? Ф>Лично я в этом плане на жабаскрипт и не наезжал. Каждой задаче свой инструмент, наиболее подходящий для неё. Однако не должен сайт с контентом на метр тянуть 10 метров скриптов из сети. <...>
Я правильно понял, что «10 метров скриптов» — это библиотеки и фреймворки JavaScript? Во-первых, они обычно приходят на клиент в минифицированном виде (minified) и пожатые gzip, то есть речь идет не о 10 мегабайтах, а от силы о сотнях килобайт (это все используемые в конкретном случае библиотеки и фреймворки, вместе взятые). Во-вторых, эти библиотеки и фреймворки обычно кэшируются на стороне клиента (по крайней мере, если речь идет о десктопе). Прошу поправить, если где-то ошибся.
Самым «тяжелым» оказался неминифицированный файл vue.js (333 КБ), а размер прочих JS-файлов составлял от нескольких килобайт до нескольких десятков килобайт (отчасти благодаря минификации). Суммарно набежало чуть больше 0,5 МБ, то есть ни о каких мегабайтах речи не идет. Хотя, возможно, где-то всё обстоит совсем иначе?
Здравствуйте, Ikemefula, Вы писали:
I>JS это пример __простого__ языка. Это видно по его распространению. Именно оттого что простой, он вот так широко распространен, шире любого другого языка.
Я тоже по наивности считал JS простым языком, когда решал на нем тренировочные задачки. А когда пришло время для практики, оказалось, что простой там только синтаксис. По крайней мере, мне, начинающему, так кажется.
P.S. Я про scope, closure, this, Promise, псевдоклассы и иже с ними. Кстати, не посоветуете толковые лекции по JavaScript «для тупых»?
Здравствуйте, Kolesiki, Вы писали:
K>Как круто поменялось время! Раньше веб-писаки *опу рвали, чтобы "во всех браузерах всё одинаково", а теперь наоборот — заточат своё помоечное жабоскрипное гогно на Хром и сидят — издеваются над юзерами. Ничтожные диктаторы локалхоста!
Зачем вообще нужен десктопный хром? Кто его использует, фрилансеры какие-нибудь?
Здравствуйте, Hobbes, Вы писали:
H>Зачем вообще нужен десктопный хром? Кто его использует, фрилансеры какие-нибудь?
Я так понимаю, имеется в виду не только собственно Google Chrome, но и всевозможные браузеры на базе Chromium, включая Яндекc.Браузер, Opera Blink и Vivaldi.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Ikemefula, Вы писали:
I>>Уже есть и типобезопасность, и внятная модульность. Непонятно, откуда у тебя сложность взялась
Ф>типа безопасность
Типобезопасность это TypeScript, на который переходят все JS разработчики. Итого — по существу ничего не осталось ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>Здравствуйте, Ikemefula, Вы писали:
I>>>Уже есть и типобезопасность, и внятная модульность. Непонятно, откуда у тебя сложность взялась
Ф>>типа безопасность
I>Типобезопасность это TypeScript, на который переходят все JS разработчики. Итого — по существу ничего не осталось ?
Негодный аргумент: во-первых, нельзя же переписывать сочетание CoffeScript'а и яваскрипта на TypeScrip. Во-вторых, мой пример всё равно не вызовет ошибки компиляции — в рантайме вылезет.
ЗЫ: "noImplicitAny": false
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Негодный аргумент: во-первых, нельзя же переписывать сочетание CoffeScript'а и яваскрипта на TypeScrip. Во-вторых, мой пример всё равно не вызовет ошибки компиляции — в рантайме вылезет.
Можно и нужно. Не переписывать, а мигрировать. Это очень быстро делается.
Ф>ЗЫ: "noImplicitAny": false
Невозможная сложность выставить это свойство в true ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>Негодный аргумент: во-первых, нельзя же переписывать сочетание CoffeScript'а и яваскрипта на TypeScrip. Во-вторых, мой пример всё равно не вызовет ошибки компиляции — в рантайме вылезет.
I>Можно и нужно. Не переписывать, а мигрировать. Это очень быстро делается.
Да ну брось, за это никто не заплатит.
Ф>>ЗЫ: "noImplicitAny": false
I>Невозможная сложность выставить это свойство в true ?
И за это тоже никто не заплатит.
Ты бы ещё сказал, код отрефакторить
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
I>>Можно и нужно. Не переписывать, а мигрировать. Это очень быстро делается.
Ф>Да ну брось, за это никто не заплатит.
Во первых, это делается быстро, это не с джавы на дотнет переписывать
Во вторых, типизация ускоряет разработку. Это факт. Точная навигация, точный поиск, контроль типов, точный рефакторинг — все это позволяет находить проблемы быстро, а не ловить из прода месяцами/годами.
Ф>>>ЗЫ: "noImplicitAny": false
I>>Невозможная сложность выставить это свойство в true ? Ф>И за это тоже никто не заплатит.
Унылый троллинг. Тебя послушать, так модульность и типобезопасность фичи классные, но не настолько, что бы за них ктото платил На самом деле все ровно наоброт — если девелоперы в команде приводят доводы "За", то проблем с миграцией нет. А если девелоперы приводят другие доводы, то так и сидят на древних версиях типа ES3/ES5 и тратят месяц-годы на тривиальные баги.
Здравствуйте, Ikemefula, Вы писали:
I>>>Невозможная сложность выставить это свойство в true ? Ф>>И за это тоже никто не заплатит.
I>Унылый троллинг. Тебя послушать, так модульность и типобезопасность фичи классные, но не настолько, что бы за них ктото платил ...
Это не унылый троллинг, а унылая реальность этого унылого мира.
Я не знаю на каком Марсе живёшь ты, а здесь, на Земле, сорцы по триста килобайт и методы по 5 экранов, а ещё некоторые слышали про документацию. Здесь, в моей реальности, у меня за спиной сидит человек, который может копировать код файлами: взять файл из одной папки проекта, и скопировать в другую, чтобы там чего-нибудь подправить и использовать там, а я, получая задачу, слышу пожелание не всё переписывать, а подправить несколько строчек. О том, что бывает по-другому я читал на форумах — никогда своими глазами не видел человека, у которого был бы другой опыт. Всегда либо десяток проектов в год, где нафиг ничего не надо, либо медленно растущая древняя какашка.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
I>>>>Невозможная сложность выставить это свойство в true ? Ф>>>И за это тоже никто не заплатит.
I>>Унылый троллинг. Тебя послушать, так модульность и типобезопасность фичи классные, но не настолько, что бы за них ктото платил ...
Ф>Это не унылый троллинг, а унылая реальность этого унылого мира. Ф>Я не знаю на каком Марсе живёшь ты, а здесь, на Земле, сорцы по триста килобайт и методы по 5 экранов, а ещё некоторые слышали про документацию.
Триста килобайт это много ? Ужос — целых 5 экранов, по одному экрану на палец одной руки!
Когда один файл занимает >10кб, вот здесь даже минимальная помощь от компилятора окупает издержки на миграцию. Тайпскрипт позволяет мигрировать частями, без переписывания.
>Здесь, в моей реальности, у меня за спиной сидит человек, который может копировать код файлами: взять файл из одной папки проекта, и скопировать в другую, чтобы там чего-нибудь подправить и использовать там, а я, получая задачу, слышу пожелание не всё переписывать, а подправить несколько строчек. О том, что бывает по-другому я читал на форумах — никогда своими глазами не видел человека, у которого был бы другой опыт. Всегда либо десяток проектов в год, где нафиг ничего не надо, либо медленно растущая древняя какашка.
Это твой выбор, что ты работаешь в таком месте. Для меня то что ты пишешь это дикая дичь, которой я не видел уже лет пятнадцать наверное или больше.
Здравствуйте, Философ, Вы писали:
Ф>>>Я не знаю на каком Марсе живёшь ты, а здесь, на Земле, сорцы по триста килобайт и методы по 5 экранов, а ещё некоторые слышали про документацию.
I>>Триста килобайт это много ?
Ф>Для одного файла это очень много. Метод на пять экранов — МНОГО:
Пять экранов это очень маленькое МНОГО 300кб кода это ~10тыс строк. Что у тебя за экран такой, что на него влазит по две тыщи строк ?
На самом деле уже на 300кб кода профит от статической типизации заруливает в минуса любую динамику.
Но вообще забавно — ты топишь за статику, но тут же голосуешь за отказ от неё Ты точно понимаешь, для чего нужна статическая типизация ?
I>>Это твой выбор, что ты работаешь в таком месте. Для меня то что ты пишешь это дикая дичь, которой я не видел уже лет пятнадцать наверное или больше.
Ф>У меня в связи с этим другой вопрос возникает: вот, подходит к тебе твой руководитель, и спрашивает "А что ты сейчас делаешь?. Что ты скажешь?
Скажу, что работаю над Тикетом номер такой то.
>Код переписываешь/рефакторишь? Зачем? С точки зрения бизнеса ты в этот момент не пишешь фичи и не чинишь баги. Это ведь не принесёт прибыли, а у тебя есть другие задачи.
Ну и дела С точки зрения бизнеса надо платить за фичи, а без рефакторинга Impediments всегда отнимают наибольшее количество времени, нежели работа над фичей. По этому и надо сокращать эти impediments.
То есть, без рефакторинга ты большую часть времени просто как муха в паутине, только почему то это называют 'спагетти'. Собственно именно фича обычно <10% всего времени — выяснить, что происходит, выяснить, где еще клочки функциональности, спросить коллег, кто что в курсе, сварить из этого суп и поправить N-мест, и так несколько раз подряд, потому как то тесты отваливаются, то QA заворачивает, ибо пропущено часть условий.
Потом через пару недель все повторяется, т.к. изменения совсем в другом месте ломают старый код.
Вот это типичная картина разработки без рефакторинга.
>Клиенты ждут — всегда кто-то чего-то ждёт.
Приходишь ты в кондитерскую и говоришь: "нехрен убирать, мыть, наводить порядок, дезинфицировать и тд и тд и тд — надо печь пироги, потому что клиенты покупают пироги а не порядок на кухне"
Далее, разве я предлагаю переписывать ? Я вроде как говорю прямо противоположное — переписывать не надо.
Еще раз — переписывать не нужно.
На всякий — переписывать не нужно.
Теперь понятно, что переписывать не нужно ?
Но вообще очень похоже что у тебя рефакторинг стал лишней активностью. А между тем любое изменение кода должно начинаться и заканчиваться рефакторингом.
Просто потому, что это сокращает время разработки.
И еще более странно путать рефакторинг и переписывание. Рефакторинг это экономически выгодный способ как достичь цели без переписывания.
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно
Переписывать — не нужно...
Здравствуйте, Философ, Вы писали:
I>>Пять экранов это очень маленькое МНОГО 300кб кода это ~10тыс строк. Что у тебя за экран такой, что на него влазит по две тыщи строк ?
Ф>Пять экранов — примерно 300 — 330 строк кода. Это нормально для класса или файла, но если это один метод, то это много. Хорошо воспринимаются методы до двух экранов, а ещё лучше, если метод влазит на экран.
Правильно понимаю, по твоему 300 помножить на 5 будет 300кб ?
I>>Но вообще забавно — ты топишь за статику, но тут же голосуешь за отказ от неё Ты точно понимаешь, для чего нужна статическая типизация ?
Ф>Точно понимаю для чего она нужна. Здесь я тебе говорю почему старый код так и будет продолжать работать, и статику ты не включишь. Или таки включишь, но тебя потом "попросят".
Значит ты не понимаешь какие именно бенефиты у статики. Я перевел целую кучу кода на тайпскрипт без каки либо проблем и знаю точно, что это помогает разработке.
I>>То есть, без рефакторинга ты большую часть времени просто как муха в паутине, только почему то это называют 'спагетти'. Собственно именно фича обычно <10% всего времени — выяснить, что происходит, выяснить, где еще клочки функциональности, спросить коллег, кто что в курсе, сварить из этого суп и поправить N-мест, и так несколько раз подряд, потому как то тесты отваливаются, то QA заворачивает, ибо пропущено часть условий. I>>Потом через пару недель все повторяется, т.к. изменения совсем в другом месте ломают старый код.
Ф>С рефакторингом будет почти тоже самое, только фича подорожает: сначала ты распутываешь паутину (разбираешься в существующих спагетти), потом наводишь там порядок (рефакторишь), а потом делаешь фичу. И при этом ты ещё и остальных задерживаешь. Ф>Без рефакторинга ты распутываешь спагетти, и делаешь фичу — меньше на один большущий шаг.
Без рефакторинга тебе надо будет распутывать каждый раз, когда потребуется изменение. И точно так же и у тебя, и у других разработчиков.
Соответсвенно стоимость разработки это количество change-request помножить на стоимость распутывания. Цена фич на этом фоне стремится к нулю.
Рефакторинг — одно место распутываешь один раз. Без него — распутываешь каждый раз. Все просто.
I>>Рефакторинг это экономически выгодный способ как достичь цели без переписывания. Ф>Неверно: Рефакторинг — экономически невыгодный способ достичь неизвестно чего. Ф>Результат рефакторинга — это не новая фича и не пофикшенный баг. Люди, которые тебе платят зарплату не поймут. С их точки зрения ты сидел и бесполезно тратил время, а ещё вносил изменения в код, и скорее всего, занёс пару ошибок — как минимум напряг отдел QA.
Результат рефакторинга это такая структура кода, которую легче всего понять и изменить. Например, не надо читать все 300кб текста, что бы понять где в какой строчке ошибки.
I>>Переписывать — не нужно...
Ф>Хлопни фронтовые 100 грамм (для храбрости), и скажи это в лицо человеку, который попытается с тобой смержиться.
Я уже лет 15 этим занимаюсь — ни разу не было проблем с мержем. Главное рефакторинг делать не всего проекта разом, а отталкиваться от текущей задачи.
Ну и нет никакой проблемы мержить в мастер не один раз, большим куском, а несколько раз.
Проблемы с рефакторингом случаются исключительно в тех случаях, когда его применяют бесцельно и начинают рефакторить вообще всё.
Здравствуйте, AlexRK, Вы писали:
I>>Приходишь ты в кондитерскую и говоришь: "нехрен убирать, мыть, наводить порядок, дезинфицировать и тд и тд и тд — надо печь пироги, потому что клиенты покупают пироги а не порядок на кухне"
ARK>Если бы не было законодательно требуемых санитарно-технических норм, никто бы порядок и не наводил, пекли бы пироги до посинения. Не удивлюсь, если и сейчас во многих местах так и происходит.
А ты не думал, почему такие требования появились ? Когда их не было, вся грязь рано или поздно попадала в пищу.
Как часто ты болеешь дизентерией после посещения, скажем, кафе или столовой ? А холера у тебя давно была ?
ARK>Нет, ты говоришь, что переписывать нужно.
По крайней мере хоть это понятно
I>>А между тем любое изменение кода должно начинаться и заканчиваться рефакторингом. I>>Просто потому, что это сокращает время разработки.
ARK>Время разработки чего? Время разработки конкретной фичи может удлинить на порядки.
Ты предлагаешь каждое место распутывать согласно количеству изменений ?
И это надо делать всем девелоперам, не только тебе одному.
Стоимость разработки — количество изменений помножить на стоимость распутывания помножить на количество человек.
Если делать рефакторинг, то каждое место распутывается ровно один раз.
I>>И еще более странно путать рефакторинг и переписывание. ARK>Рефакторинг — это переписывание.
Рефакториг это безопасное изменение структуры кода при гарантии сохранения поведения.
А вот переписывание это когда меняешь true на false и надеешься, что это сработает.
I>>Рефакторинг это экономически выгодный способ как достичь цели без переписывания. ARK>Доказательств этому нет и никогда не было.
Здравствуйте, AlexRK, Вы писали:
ARK>>>Время разработки чего? Время разработки конкретной фичи может удлинить на порядки. I>>Ты предлагаешь каждое место распутывать согласно количеству изменений ?
ARK>Я ничего не предлагаю, просто спросил.
Это вранье. У тебя кроме вопроса есть и конкретное утверждение.
I>>Стоимость разработки — количество изменений помножить на стоимость распутывания помножить на количество человек.
ARK>Как всё просто.
Именно. Все, кому надо чтото в коде, обязаны распутать. Практика показывает, что удаётся это далеко не всем.
Более того — в большом проекте к конкретному месту можешь вернуться не скоро. А стало быть распутывать будешь заново.
I>>Если делать рефакторинг, то каждое место распутывается ровно один раз.
ARK>Или нет.
Это цель рефакторинга — решить конкретную проблему с кодом. Если ты рефакторишь абы покрасивше, то для этого другой термин — или инфантильность, если неосознанно, или саботаж, если осознанно
ARK>>>Рефакторинг — это переписывание. I>>Рефакториг это безопасное изменение структуры кода при гарантии сохранения поведения.
ARK>Рефакторинг — это переписывание уже рабочего кода. Из одного вида в другой.
Переписывание — это когда ты пишешь нечно заново. Рефакторинг это вобщем то фиксированый набор операций, который можно применять к коду. Например — переименовать переменную.
У тебя какая то своя терминология. Изначально рефакторинг появился как альтернатива переписыванию.
I>>А вот переписывание это когда меняешь true на false и надеешься, что это сработает.
ARK>Это уже не переписывание, а модификация кода.
Все изменения вместе взятые — модификация. Рефакторинг — это изменения только определенных аспектов при сохранении поведения. А переписывание не ограничивается этим — пиши что хошь, меняй поведение на новое — все равно переписывание. Но это не рефакторинг
ARK>>>Доказательств этому нет и никогда не было. I>>Наоборот.
ARK>Тогда обоснуй свое утверждение об экономической выгодности рефакторинга.
Ты его проигнорировал.
I>>С чего ты взял, что рефакторинг не применяетс ? Что, никто никогда не переименовывает переменные ? Или не разрезает длинный метод на короткие ?
ARK>Из текста можно сделать вполне реалистичное предположение, что рефакторинга там нет ни в каком виде. Может только локальные переменные в функциях иногда переименовывают.
Это додумки. Текст показывает только результат. Каким путем ты к нему пришел, рефакторингом, переписыванием — не ясно.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Ikemefula, Вы писали:
ARK>>>>>Время разработки чего? Время разработки конкретной фичи может удлинить на порядки. I>>>>Ты предлагаешь каждое место распутывать согласно количеству изменений ? ARK>>>Я ничего не предлагаю, просто спросил. I>>Это вранье.
ARK>Вранье у тебя. Я никаких предложений не вносил.
Вот я тебя и спрашиваю — что ты хочешь предложить взамен ? Выглядит так, как будно ты предлагашь отказаться исправлять затруднения.
Типа "ну и что, что долго распутывать, главное что только над фичей работаю"
I>>У тебя кроме вопроса есть и конкретное утверждение. ARK>Вот это — "Время разработки конкретной фичи может удлинить на порядки"? Да, такое утверждение у меня есть. И оно истинно.
А ты можешь гарантировать, что это 1 истинно для любой фичи 2 истинно для всех фич вместе взятых ?
I>>Именно. Все, кому надо чтото в коде, обязаны распутать. Практика показывает, что удаётся это далеко не всем. ARK>Только вот большая часть IT-проектов не влезает ни в срок, ни в бюджет (кажется, у Макконнелла про это читал). Странно, ведь есть простая формула.
Нужно внимательно Макконела читать. Ты не знаешь, сколько времени будешь распутывать паутину. Это неопределенность. Хочешь внятные оценки — надо устранять неопределенности.
Поэтому проект, который наступает на эти грабли по десять раз на дню имеет все шансы выйти из срока, бюджета и вообще свернуться.
I>>Более того — в большом проекте к конкретному месту можешь вернуться не скоро. А стало быть распутывать будешь заново.
ARK>Или вообще никогда не буду.
Зато известно точно, что каждый день ты будешь распутывать какую то паутину. Это следует из того, что проблемы с кодом ты решать отказываешься.
I>>>>Если делать рефакторинг, то каждое место распутывается ровно один раз. ARK>>>Или нет. I>>Это цель рефакторинга — решить конкретную проблему с кодом. Если ты рефакторишь абы покрасивше, то для этого другой термин — саботаж
ARK>С чего ты взял, что "решение проблемы с кодом" может быть единственным? Ты кусок по своему зарефакторил, Васе не понравилось твое "решение", он переделал.
А что, у вас код-ревью нет или трудно вместе с Васей выработать внятное решение ?
I>>У тебя какая то своя терминология. Изначально рефакторинг появился как альтернатива переписыванию.
ARK>Слово "переписывание" не обязательно означает переписывание полностью и с нуля. Если ты его понимаешь только так, то, конечно, это не рефакторинг. Я понимаю под "переписыванием" в том числе и частичное переписывание, которым рефакторинг и является.
Частичное переписывание с изменением поведения не является рефакторингом. А по твоему это рефакторинг.
Рефакторинг это вообще говоря получение гарантий, что новый код не сломал поведение. А у тебя, внезапно, каким то чудом взялись гарантии после переписывания. Откуда ?
I>>Все изменения вместе взятые — модификация. Рефакторинг — это изменения только определенных аспектов при сохранении поведения. А переписывание не ограничивается этим — пиши что хошь, меняй поведение на новое — все равно переписывание. Но это не рефакторинг
ARK>Теперь ты вводишь еще одно дополнительное уточнение — что переписывание обязательно НЕ подразумевает сохранения поведения. А это не так. ARK>Переписывание (скорее всего, частичное) кода c сохранением поведения — это и есть рефакторинг.
А каким чудом ты эти гарантии получишь, если сел и все перехерачил ?
ARK>>>Тогда обоснуй свое утверждение об экономической выгодности рефакторинга. I>>Ты его проигнорировал.
ARK>Я его не увидел. Будь добр, уточни, что именно ты имеешь в виду под "обоснованием экономической эффективности рефакторинга".
Если n человек будут еждедневно выполнять работы, которые длятся неопределенный период, и неизвестно какой результат могут давать, то проект выйдт из любых сроков и бюджетов.
Например, распутывание паутины в коде длится именно неопределенный период.
ARK>>>Из текста можно сделать вполне реалистичное предположение, что рефакторинга там нет ни в каком виде. Может только локальные переменные в функциях иногда переименовывают. I>>Это додумки. Текст показывает только результат. Каким путем ты к нему пришел, рефакторингом, переписыванием — не ясно.
ARK>Текст показывает, что изменения кода очень болезненны. Это делает крайне сомнительными любые рассуждения о рефакторинге.
Разумеется, болезненны. Из этого никак не следует, что проблемы решать не надо.
Как ты собираешься фичу вводить, раз изменения болезненны ?
Здравствуйте, AlexRK, Вы писали:
ARK>>>Вот это — "Время разработки конкретной фичи может удлинить на порядки"? Да, такое утверждение у меня есть. И оно истинно. I>>А ты можешь гарантировать, что это 1 истинно для любой фичи 2 истинно для всех фич вместе взятых ?
ARK>Я написал — "может". Естественно, никаких гарантий этого не существует.
Опаньки! Тогда ценность твоего высказывания про удлиннение конкретной фичи равна нулю.
ARK>>>Только вот большая часть IT-проектов не влезает ни в срок, ни в бюджет (кажется, у Макконнелла про это читал). Странно, ведь есть простая формула. I>>Нужно внимательно Макконела читать. Ты не знаешь, сколько времени будешь распутывать паутину. Это неопределенность. Хочешь внятные оценки — надо устранять неопределенности.
ARK>По факту внятных оценок никто дать не может. Ну, кроме тебя, разумеется.
А ты — нечитатель. Неопределенность и есть причина того, что внятных оценок никто дать не может.
ARK>>>С чего ты взял, что "решение проблемы с кодом" может быть единственным? Ты кусок по своему зарефакторил, Васе не понравилось твое "решение", он переделал. I>> А что, у вас код-ревью нет или трудно вместе с Васей выработать внятное решение ?
ARK>Во, пошли еще дополнительные ограничения.
Разумеется. Если над кодом работает команда, то результат должен устраивать всех. Почему рефакторинг должен выделяться ?
А ну как ты переписал код, а Вася его выбросил и написал свой. Чем это лучше твоего примера ?
ARK>Тем не менее, в общем случае один и тот же кусок кода может правиться много раз.
Именно — и фактор неопределенности играет ровно столько же раз.
I>>Частичное переписывание с изменением поведения не является рефакторингом. А по твоему это рефакторинг.
ARK>Да, частичное переписывание с изменением поведения не является рефакторингом. Я нигде не утверждал обратного.
Поэтому и надо разделять рефакторинг — изменения с определенными гарантиями, и переписывание, где нет никаких гарантий.
ARK>Хотя изменение поведения может произойти случайно — тогда получится, что был запланирован и начат процесс рефакторинга, но результат оказался как у переделки.
Может. А если изначально отказаться от гарантий, то гарантировано получаешь хаос
I>>Рефакторинг это вообще говоря получение гарантий, что новый код не сломал поведение. А у тебя, внезапно, каким то чудом взялись гарантии после переписывания. Откуда ?
ARK>Никаких гарантий в общем случае рефакторинг дать не может. Потому что это модификация кода.
У вас похоже ни IDE, ни инструментов, ни тестов, ни тестировщиков не изобрели. Так что ли ?
I>>А каким чудом ты эти гарантии получишь, если сел и все перехерачил ? ARK>А каким чудом ты при рефакторинге получишь какие-то гарантии?
Известно — компилятор, тесты, код ревью, а более всего — подход, когда за раз меняешь не более одного аспекта. Например — переименование переменной. Пока нет гарантий, что ты ничего не сломал, ничег другого не делаешь.
ARK>>>Я его не увидел. Будь добр, уточни, что именно ты имеешь в виду под "обоснованием экономической эффективности рефакторинга".
I>>Если n человек будут еждедневно выполнять работы, которые длятся неопределенный период, и неизвестно какой результат могут давать, то проект выйдт из любых сроков и бюджетов. I>>Например, распутывание паутины в коде длится именно неопределенный период.
ARK>Это не обоснование, а некоторые поверхностные соображения.
Это именно обоснование. Или ты думал я тебе научный труд принесу ?
ARK>Собственно, в программировании любое написание кода может затянуться на неопределенный период.
Гипотетически.
ARK>>>Текст показывает, что изменения кода очень болезненны. Это делает крайне сомнительными любые рассуждения о рефакторинге. I>>Разумеется, болезненны. Из этого никак не следует, что проблемы решать не надо.
ARK>Я не говорю, что проблемы решать не надо. Я говорю, что по тексту вполне видно, что рефакторинг в оракуле вряд ли применяется.
Ты говоришь, что у Оракла плохой код. Из этого никак не следует, что рефакторинг не применялся , неприменим и тд.
I>>Как ты собираешься фичу вводить, раз изменения болезненны ?
ARK>Там про это тоже написано. Очень медленно они вводят фичи. Но бабло гребут лопатой при этом.
Я вот не в курсе, видят ли они проблему в скорости введения фич. А ты из простого факта про скорость начал делать глобальные выводы "крайне сомнительными любые рассуждения о рефакторинге"
Да хоть по году на мелкий баг, тебе то что с того ? Рефакторинг нужен в том случае если это становится проблемой. Захочешь, скажем, фичи вводить намного быстрее. Каким таким способом ?
Здравствуйте, morgot, Вы писали:
M>Современная веб разработка это идиотизм полнейший. Для простого сайта нужно 100 метров быкенда, и 10 фронта, и при этом "браузер устарел"
Современная веб-разработка это будущее почти всех технологий. Большинству молодых девелоперов придется перейти писать для браузера, под браузер или просто 'на жээсе'.
Браузер становится платформой и постепенно обзаводится взрослым рантаймом, конкуренты передохнут очень быстро.
Здравствуйте, morgot, Вы писали:
M>Современная веб разработка это идиотизм полнейший. Для простого сайта нужно 100 метров быкенда, и 10 фронта, и при этом "браузер устарел"
Вот уже второй человек в этой теме утверждает, что объем кода фронтенда составляет 10 мебагайт. Это реальные цифры или утрирование?
Здравствуйте, Lazytech, Вы писали:
M>>Современная веб разработка это идиотизм полнейший. Для простого сайта нужно 100 метров быкенда, и 10 фронта, и при этом "браузер устарел"
L>Вот уже второй человек в этой теме утверждает, что объем кода фронтенда составляет 10 мебагайт. Это реальные цифры или утрирование?
Ну вот трудно людям нажать F12 да посмотреть, сколько реально там всего.
Здравствуйте, AlexRK, Вы писали:
I>>Опаньки! Тогда ценность твоего высказывания про удлиннение конкретной фичи равна нулю.
ARK>Нет. Равна нулю ценность твоего утверждения, что рефакторинг сокращает время разработки.
Не понятно, где логика. Ценность моего утверждению равна нулю в том случае, если выполняются два условия
1. рефакторинг удлинняет любую фичу
2. рефакторинг удлинняет все фичи вместе взятые
А теперь читаем вместе твои аргументы:
Я написал — "может". Естественно, никаких гарантий этого не существует.
Итого — всего лишь твоё мнение, а гарантий 1 и 2 по твоим же словам не существует. Итого — в сухом остатке одно твое мнение.
I>>А ты — нечитатель. Неопределенность и есть причина того, что внятных оценок никто дать не может. ARK>Возможно. И рефакторинг никаких неопределенностей не устраняет, однако добавляет новые
Прикинь, решил ты фото детей повесить в рамку на стену. Взял дрель-перфоратор, что бы просверлить отверстие под дюбель и ненароком просверлил себ кисть. Тебя это не остановило, ты решил дюбель забитьв стену, но раздробил молотком кисть. А когда закручивал крюк, случайно напоролся глазом на отверку.
Картина понятна ? Надо ли объяснять, что подобный исход никак не говорит о том, что инструменты ничем не помогаеют ?
В перевод на руский — рефакторинг помогает в том случае, когда применяется по назначению — для исправления проблем с кодом.
А это значит, что сначала нужно идентифицировать проблему, убедиться, что есть решение, и далее это решени сформулировать.
Без этого никакой рефакторинг не поможет.
Более того любые изменения кода без этих шагов плодят хаос и увеличивают эту неопределенность.
I>>Разумеется. Если над кодом работает команда, то результат должен устраивать всех. Почему рефакторинг должен выделяться ? I>>А ну как ты переписал код, а Вася его выбросил и написал свой. Чем это лучше твоего примера ?
ARK>Ничем не лучше. И рефакторинг точно так же не гарантирует того, что над этим кодом никто больше не будет работать.
Ну ка, подробнее, что за чудо такое, когда ты выбрасываешь проблемный код, а он у тебя продолжает мозолить глаз и требовать внимания ?
Пример — у нас был небольшой компонент, на пять сотен килобайт. Изменения в нем делались от минуты до месяца и даже полугода. Эстимейты были соответствующие и пять лет никто его не трогал.
После того, как завершился рефакторинг, люди даже забыли, что с этой частью были какие то проблемы. Изменения — исчезли пять наследников, объем кода компонента ужался вдвое, появились внятные связи, повыкидывали кучу вспомогательных доеров, хелперов и полу-компонентов-помогаторов. Скажем, преобразования координат были в сотне мест кастомным кодом(это не шутка), стали в одном месте матричным способом. И это безо всякого переписывания, исключительно средствами автоматического рефакторинга.
На рефакторинг компонента ушел год. Это много. Зато следующие два с половиной года продукт развивался именно за счет этого компонента, т.к. удалось ввести оптимизации и увеличить объемы данных примерно в 10 раз, скорость отрисовки от 2 до 1000 раз, а кучка трудно-выполнимых ручных работ стала выполняться через форм эдитор.
И вот это все делалось исключительно через рефакторинг, кроме финальной интеграции, были причины.
То есть — девелоперы перестали иметь дело с проблемным кодом. То есть, с проблемным кодом больше никто не работает.
Кстати говоря, вот товарищи, которые начали писать заново, читай — переписывать, никуда не пришли, через какое то время выбросили свою поделку и все труды, перешли на 3rd party, но в итоге им это мало чего дало — выглядеть стало красивше, но ни объемов, ни фич, а прикручивание всего лишь контекстного меню превратилось в дикую содомию
Вот это все про рефакторинг, а тебя послушать, так какое то божественное чудо воскрешения мертвого кода — ты его удаляешь, а наутро он снова на месте.
ARK>>>Тем не менее, в общем случае один и тот же кусок кода может правиться много раз. I>>Именно — и фактор неопределенности играет ровно столько же раз.
ARK>Я тут говорил про рефакторинг, если что.
С твоих слов после рефакторинга проблемы почему то не уходят. Ты рефакторинг похоже путаешь не только с переписыванием, но и с улучшайзингом.
Для меня это какая то дичь — сели решать проблему, идентифицировали, поставили диагноз, подобрали лечение, лечение прошло успешно, но код каким был, таким и остался.
Каким образом такое возможно ? Старый код сам себя коммитит в мастер ?
I>>Поэтому и надо разделять рефакторинг — изменения с определенными гарантиями, и переписывание, где нет никаких гарантий.
ARK>На практике это одно и то же. Гарантий ты никаких не получишь ни в том, ни в том случае. Можешь разве что разделить _намерения_. Но сам процесс особых различий не несет.
Рефакторинг это только такие изменения, которые дают гарантии и максимальный контроль. Например, если я переименовываю переменную, то я получаю гарантии от
1 ИДЕ — переименована ровно одна переменная и сведения о отсутствии конфликтов
2 тесты — зеленые, значит все хорошо
3 ревью — такое маленькое изменение легко отследить при помощи обычного дифа.
А если ты перепилил всё тело функции и вроде бы результат тот же, то это не рефакторинг, потому как а хер его знает, какие ты внёс сайд эффекты, достаточно ли дня них тестов, нет ли трудновоспроизводимых багов и тд. Анализировать надо все изменения целиком.
I>>Может. А если изначально отказаться от гарантий, то гарантировано получаешь хаос ARK>Ну, это просто манипуляция терминами.
Это факты. У меня ощущение, что ты путаешь общее и частное, потому как отсутствие контроля и его наличие нзываешь одним и тем же словом.
С таким же успехом ты можешь себя назвать, ну, скажем, млекопитающим. Другой пример — дерево есть частный случай графа. То есть — граф, а стало быть все то же и так же, как в графе.
Надо ли объяснять, что у деревая есть свойства, которые отсутствуют в произвольном графе, и мы его используем именно ради этих свойств?
I>> У вас похоже ни IDE, ни инструментов, ни тестов, ни тестировщиков не изобрели. Так что ли ?
ARK>Ну я понял, ты просто называешь переписывание кода без изменения поведения — рефакторингом. Это твое право, но по сути это все равно переписывание. Но ты переписыванием называешь только один частный случай.
Нет, не правильно. Я считаю, что переписывание, рефакторинг и дописывание нового кода есть подмножества модификаций. Эти три подмножества всего лишь пересекаются друг с другом. Например, такая маленькая вещь, как переименование, здесь переписывание неотличимо от рефакторинга.
Но уже на уровне функции все не так однозначно. Например, переименование двух переменных одного типа переписыванием и рефакторингом уже могут дать трудно-уловимые баги.
Пример — переписываешь все разом, а рефакторингом — по одной. В итоге рефакторинг дает гарантию, а переписыавние — на помоечку. Вот этот подход и есть разница между переписыванием и рефакторингом. При рефакторинге ты никогда не меняешь более одного аспекта за раз. Никогда!
I>>Это именно обоснование. Или ты думал я тебе научный труд принесу ?
ARK>Это набор голословных утверждений, не подкрепленных ничем.
Этот набор успешно предложил и обосновал Фаулер двадцать лет назад и с тех пор это трансформировалось в целую методологию.
Судя по твоим словам, ты наверняка этого не знал
I>>Ты говоришь, что у Оракла плохой код. Из этого никак не следует, что рефакторинг не применялся , неприменим и тд. ARK>Почему же, плохой код и отсутствие рефакторинга — это сильная корреляция.
Ну и детский сад. Корреляция и причина это разные вещи!!! Переписывание и рефакторинг могут дать и часто дают один и тот же результат и это вобщем то норма.
Например, ты написал цикл, где само тело цикла скопировано сто раз. Теперь надо решить эту проблему и устранить дублирование, поскольку есть следующая фича которая затрагивает этот цикл.
В дагном примере корректное переписывание, и правильный рефакторинг дадут в итоге цикл без дублирования и код будет идентичным.
Разница только в том, какая у тебя степень уверености — в рефакторинге, если ты ничего не сломал на каждом шагу, то ты ничего не сломал вообще, уверенность высокая. В переписывании — а хер его знает, т.к. проанализировать надо надо будет одни куском.
Шашлык небось на кусочки режешь и проглатываешь. Или ты из тех, кто жарено мясо глотает килограммами не жуя ?
I>>Да хоть по году на мелкий баг, тебе то что с того ? Рефакторинг нужен в том случае если это становится проблемой. Захочешь, скажем, фичи вводить намного быстрее. Каким таким способом ?
ARK>Не знаю, видят ли они какие-то проблемы. Я вижу, что экономическая эффективность рефакторинга под сомнением.
Из твоего примера про Оракл этого не следует. Ты путаешь корреляцию и причинно-следственную связь, впечатляет.
Из твоего примера ничего не ясно, может код был качественным, понятным, но чуваки не знали про рефакторинг и просто упоролись, пытаясь все переписать с нуля.
А может он был в сто раз хуже, но рефакторингом они подтянули его к нынешнему состоянию.
А может и так — херачат себе в духе семидесятых и никаких методологий да рефакторингов знать не хотят — раз бабло есть, значит ничего менять не нужно.
Вобщем вариантов масса, а у тебя какой то невнятный аргумент про корреляцию
Здравствуйте, DenisCh, Вы писали:
I>> M>Современная веб разработка это идиотизм полнейший. Для простого сайта нужно 100 метров быкенда, и 10 фронта, и при этом "браузер устарел" I>> Современная веб-разработка это будущее почти всех технологий. Большинству молодых девелоперов придется перейти писать для браузера, под браузер или просто 'на жээсе'.
DC>Какое ужасное будущее ((( DC>Так и до пенсии доживать не захочется.
Все клиентские платформы писал "коммитет по архитектуре" по руководством менеджеров "давай давай". В итоге все они в том или ином виде зашли в тупик.
Браузер пилится от реальных, насущных кейсов, неторопливо. И он сам, и JS быстро взрослеет. Более того, уже начался экспорт из этой области в другие платформы, хотя до недавних пор было совсем противоположный тренд.
Здравствуйте, Ikemefula, Вы писали:
I> Браузер пилится от реальных, насущных кейсов, неторопливо. И он сам, и JS быстро взрослеет.
Признак взросления — это жрание памяти и неотпускание её? Тупой древний лис на ХП на трёх страничках раз в три минуты фризит весь комп на своп. И занимает полтора гига памяти. Причём по закрытию страниц — память не отпускает.
Здравствуйте, DenisCh, Вы писали:
DC>Признак взросления — это жрание памяти и неотпускание её? Тупой древний лис на ХП на трёх страничках раз в три минуты фризит весь комп на своп. И занимает полтора гига памяти. Причём по закрытию страниц — память не отпускает.
У меня так много памяти не жрал даже свежайший Firefox Quantum с его несколькими процессами, а однопроцессорный Waterfox (64-битный форк какой-то подустаревшей версии Firefox) жрет еще меньше. Сдается мне, подобные претензии лучше в первую очередь предъявлять всяким-разным хромоногим браузерам.
Здравствуйте, DenisCh, Вы писали:
I>> Браузер пилится от реальных, насущных кейсов, неторопливо. И он сам, и JS быстро взрослеет.
DC>Признак взросления — это жрание памяти и неотпускание её? Тупой древний лис на ХП на трёх страничках раз в три минуты фризит весь комп на своп. И занимает полтора гига памяти. Причём по закрытию страниц — память не отпускает.
А новый лис? Вообще, это известная проблема древнего лиса. Не совсем понятно, что ты хотел эти показать.
Какие именно три страницы ты проверял?
Здравствуйте, Ikemefula, Вы писали:
I> I>> Браузер пилится от реальных, насущных кейсов, неторопливо. И он сам, и JS быстро взрослеет. I> DC>Признак взросления — это жрание памяти и неотпускание её? Тупой древний лис на ХП на трёх страничках раз в три минуты фризит весь комп на своп. И занимает полтора гига памяти. Причём по закрытию страниц — память не отпускает. I> А новый лис? Вообще, это известная проблема древнего лиса. Не совсем понятно, что ты хотел эти показать.
Атвообновление у него включено.
I> Какие именно три страницы ты проверял?
Для примера то, что открыто у меня постоянно
forum.mista.ru
forum.infostart.ru
monitor.itgit.tu
gmail.com
Если оставить на ночь — с ута приходится бровзер перезапускать.
Здравствуйте, DenisCh, Вы писали:
DC>Атвообновление у него включено.
Откуда тогда старый лис, если он обновляется ?
I>> Какие именно три страницы ты проверял?
DC>Для примера то, что открыто у меня постоянно DC>forum.mista.ru DC>forum.infostart.ru DC>monitor.itgit.tu DC>gmail.com
DC>Если оставить на ночь — с ута приходится бровзер перезапускать.
Мелочевка. Тут или ты замусорил свой комп, или лис кривой шо сабля, или памяти 4гб в системе, или кривой антивирус. У меня, правда в хроме, в норме открыто десятка два-три сайтов, из них несколько окон с gmail, google documents, confluence, bitbucket, github и подобные. Так же открыт вайбер, скайп, слак, пару проектов в вебшторме и тунец. В фоне — доккер и антивирус.
Такое тянется неделями и никакого "перезапускать" не случается
300кб кода это ~10тыс строк. Что у тебя за экран такой, что на него влазит по две тыщи строк ? 
Ты точно понимаешь, для чего нужна статическая типизация ?
Ужос — целых 5 экранов, по одному экрану на палец одной руки!