Здравствуйте, Sharov, Вы писали:
M>>Стоимость решарпера — 449 евро в год. То есть 37 евро в месяц. Вы там за еду работали?
S>Откуда такие цифры? Я ~500р. в месяц за бандл плачу..
Я и за 5 рублей не куплю. Если мне будут платить за него 1000 в месяц — то, может, и подумаю.
Здравствуйте, ukrspecs, Вы писали:
С>>Вы наверное сразу всё делаете правильно, а потом не переделываете никогда. И всё помните. Вам ни Find Usages не нужен, ни переразбивка проекта на части и неймспейсы, ни создание интерфейса для какого-нибудь класса на 50 методов (фасада к куче других сервисов, а интерфейс нужен для создания кэширующей прослойки).
U>ОК. U>- Вы наверное сразу всё делаете правильно. По крайней мере стараюсь, а вы разве нет?
Смешно и наивно.
Правильно — это только сейчас. А сразу, как приступим к новыми фичам в следующей версии, уже автоматически неправильно.
Поменялись требования в ходе разработы — снова становится неправильно.
Поменялась команда — скажем, разбили на три локации, дизайн будет ломаться хотите вы там у себя или нет. Отчуждаем, скажем, ядро или плагины — это долгая и тщательная хирургия, после которой пациент должен быть жив.
Понадобились оптимизации — опаньки, их заранее предусмотреть нельзя, нужно решать дизайном, выделять узкое место в какой то управляемый формат.
По уму, любые изменения кода, особенно багфикс и оптимизации, должны начинаться и заканчиваться рефакторингом. Мелкими изменениями очень часто создают такую паутину, что крупные просто не влазат. Соответсвенно проще, дешевле следить за качеством кода.
Если менеджеры начинают жать, требовать сраочных фиксов, результатом практически всегда является технический долг. А вот желаемый эффект достигается далеко не всегда.
Например, мега-архитектор может придумать мега-фичу, на её реализацию уходит полгода, после чего оказывается, что фича перестала быть нужной, т.к. бизнес решил, что ему это и не было нужно. Вот такие вещи вносят чудовищный хаос в код. То есть, все особенности принятия решений в конторе оседают прежде всего в виде лишнего кода.
Вобщем, все проблемы, которые есть вокруг разработки, нестыковки, текучка, недопонимания любой природы, конфликты всех сортов, особенности принятия решения, все это и многое другое прежде всего отражается на коде.
Самое важное — стоимость сопровождения растет крайне нелинейно в зависимости от уже реализованых решений. И не важно, полезны они, или нет. Вот эта нелинейность убивает зачастую вообще весь профит.
Именно по этому код выгодно держать в чистоте. Чистый код легко изменять в любую сторону. Его даже вырезать и выбросить легче.
Более того — поскольку все вышесказаное требует рефакторинг, то очевидно, руками с этим не справиться. Нужна автоматизация.
U>- Find Usages меня устраивают, те что есть в VS. Если прям все-все искать — то стандартный поиск по solution тоже ок.
U>- Переразбивка проекта на части и неймспейсы — делаю руками. Хотя не любитель трогать, то что работает. И новых проектов тоже хватает.
И наверняка никогда не ошибаешься. А вот ведь именно эта работа дает огромное количество ручных ошибок. Поделил класс на два — надо все финты в конфигурции, инициализации и тд пофиксить руками. Кто гарантии обеспечивать будет?
U>- Создание интерфейса для какого-нибудь класса на 50 методов. Тоже редко такая задача появляется. Привык руками делать, но можно и так
Ок, расскажи, каким чудом ты будешь делать, преобразование, скажем, глубокой иерархии, скажем, в плоскую широкую. Плохая иерархия досталась от тех, неправильных девелоперов. На переписывание времени нет. Что делать?
Здравствуйте, bkat, Вы писали:
U>>>Попробую объяснить. Бюджета на ReSharper у нас не было, а если и было то на несколько лицензий. То есть идя на поводу у фанатов, мы либо лишались доли бюджета, который идет на зарплаты
M>>Стоимость решарпера — 449 евро в год. То есть 37 евро в месяц. Вы там за еду работали?
B>449 — это уже Ultimate с Rider. B>А так еще дешевле на самом деле.
Миллионы долларов экономят десятки и сотни долларов Недели и месяцы кодинга экономят минуты и часы проектирования.
U>Чего я не понимаю в мире разработки на C#?
При чем тут вообще C#? Это чисто психология людская. Продается товар, такой-же как и улучшатели для windows, какие-нибудь там катушки для рыбаков с керамическими подшипниками, женская косметика или модная стрижка для бороды.
Это фетишь, шиза.
Мало кто признается что реальная его производительность примерно 30 строчек отлаженного кода в день (тесты не считаются), и что он не сидит целыми днями рефакторит код.
Ну просят они у тебя решарпер и что? Жена у тебя никогда не просила какую-нибудь штуку не особо нужную(а может и совсем ненужную), или сам ты себе никогда хрень какую-нибудь не покупал?
С чего ты взял что они ведут себя рационально, а не как обычные люди?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Для С++ сильно хуже. Сам язык не позволяет на современном железе получить достаточно качественный результат.
А расскажите про Visual Assist. Я его не трогал с 2012 года, но мне стало интересно — вдруг хоть одна компания на планете сделала нечто полноценное для С++ ?
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Для С++ сильно хуже. Сам язык не позволяет на современном железе получить достаточно качественный результат.
С>А расскажите про Visual Assist. Я его не трогал с 2012 года, но мне стало интересно — вдруг хоть одна компания на планете сделала нечто полноценное для С++ ?
Коллеги пользуются, но фич у него не так много, а стоит теперь $279 первый год и $119 последующий, что не так уж и мало на фоне количества фич.
Здравствуйте, ukrspecs, Вы писали:
U>Выделение интерфейсов и методов — не уверен, правильно ли понимаю, так но за 20 лет наверное пару раз нужно было. Тогда я создаю интерфейс, делаю copy-paste из класса, убираю лишнее, затем в наследнике "Ctrl+." и методы генерятся. UPD: Да, это такая важная фича, что я даже не знал про то, что она есть из коробки в VS https://prnt.sc/qvyueo U>Это must-have функционал?
Да постоянно это надо. Вот есть готовый проект, уже всё работает, всё спроектировано грамотно. Внезапно появляется задача, которая прекрасно решается наследованием от одного из классов иерархии.
Вот только в Base слишком мало логики, а в Derived слишком много. Решарпер помогает превратить иерархию Derived:Base в Derived:Intermediate:Base, и отнаследоваться уже от Intermediate.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ukrspecs, Вы писали:
U>Сейчас времена поменялись и стараюсь брать только новые проекты. Через 14 лет на фрилансе можно-то, раз спрос есть
Вот это буквально ответ на ваш вопрос. Вы избегаете всех тех задач, где нужен решарпер. Фриланс тут ни при чем.
Здравствуйте, ukrspecs, Вы писали:
U>Выделение интерфейсов и методов — не уверен, правильно ли понимаю, так но за 20 лет наверное пару раз нужно было. Тогда я <делаю руками работу, которую может выполнитить автоматический инструмент>
Выделение метода — это постоянный, каждодневный рефакторинг. Как только нашлось дублирование — первое, о чем надо думать, это выделение метода. Выделение интерфейса, класса, абстрактного класса, базового класса, дочернего класса, утилитного класса, класса-параметра, фасада, контроллера, состояния — чего угодно, это все необходимо для трансформации дизайна.
Например — длинный метод почти всегда прячет в себе вычисление нового состояния, изменение состояния, реакцию на это изменение состояния и абсолютно всегда содержит вагон дублирования. Этот длинный метод обладает способностью создавать баги на ровном месте. Что бы распилить его на части, нужны те самые приемы, что я указал выше. В простом случае хватит выделение метода. В сложных — вообще все вместе взятое. Скажем, когда код метод преодолевает планку в 100кб, в нём обязательно найдутся наколеночные реализации алгоритмов поиска, замены, вставки, сортировки, группировки, а так же маппинг и наряду с кастомным замаскированым mvc. Что бы избавиться от всего этого, или, наоборот, выделить все указаное в отдельные классы-интерфейсы-методы-утилиты-пакеты, нужна целая куча интструментов, которые дают минимум ошибок.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Kolesiki, Вы писали:
U>>>Но вопрос (для меня) остается открытым.
K>>Брат, ты не один! Решарпер действительно БЫЛ когда-то полезным дополнением (напр, к студии 2005), потому что саму студию писали посредственности. Но сейчас, за годы улучшений, Студия получила кучу плюшек и теперь Решарпер в ней как пятое колесо — ничего, кроме тормозов не привносит.
I>Узнаю разработчика-одиночку c идеальной памятью, который реализует закат солнца вручную
Узнаю гадалок в пёстрых платьях, которые по линиям руки всё сразу о тебе знают!
Милок, не сравнивай весь мир по себе. Если ты без решарпера как без рук — ради бога, но не считай всех остальных такими же убогими!
Решарпер помогает только в древних студиях. В новых он просто не нужен.
Рефакторинг? Делаю, но не так часто, чтобы ставить это убожество. К тому же, я не пишу г***нокод, чтобы потом "экстрактить методы" по 100 штук. Как правило, рефакторю только сигнатуры. Изредка — выделяю код в отдельный метод (что вообще не проблема). Ну и накой тут решарпер?? Решарпер — для студоты, настоящие самураи пишут почти идеальный код!
Здравствуйте, _NN_, Вы писали:
_NN>На самом деле у Решарпера довольно много мелких вещей к которым привыкаешь и если работаешь без него тратишь лишнее время .
_NN>Как минимум быстрый поиск всего, текста, метолов, классов. _NN>В студии встроенного пока нет.
Чё?? Точнее, "Чё курите?" Есть там всё! Самое примитивное — Ctrl+F, это для вашего "поиска текста". Поиск методов — ради бога, найди первый метод, далее find all references. Искать классы можно прямо в солюшене.
Ну другими словами, те, кто не разбирается в VS, учат чем решарпер хорош. А может для начала выучить основной тул?
_NN>Далее рефакторинг кода. _NN>У решарпера вагон правил, которых в студии нет.
Рефакторинг — признак тухлого, бестолково спроектированного кода. Сначала проектируем В ГОЛОВЕ, потом переносим в проект. Только так. Соотв. последующие рефакторинги не нуждаются в серьёзных и умных правках.
_NN>Коллеги, которые работают без него, тратят довольно много времени когда нужно что-нибудь поменять в коде и в итоге получается кол, который двумя нажатиями можно было легко улучшить.
Ну так не нанимайте джунов! Пусть научатся проектировать, потом уже кнопки давить.
_NN>Подсказки и предложения в коде. _NN>Без этого как без рук.
Это ещё зачем? Чтобы я утону в этих "давай сделаем этот метод internal"? оно мне надо? Как и говорил выше, не умеешь проектировать — не садись.
_NN>В студим есть немного правил настраиваемых через. editorconfig и есть дополнение Roslynator но это всё не дотягивает до того что есть в решарпере.
Там нечему "дотягивать" — возможностей студии по рефакторингу — за глаза. А писать г****внокод и потом эту вермишель "сортировать" — ну извини, тут программирование обсуждают, а не индусокод!
_NN>Ну и мелочи: _NN>Подсветка protobuf, поддержка VB.NET, JS, TS.
Вообще не упёрлось!
_NN>Удобный запускатель тестов.
Студия делает это одной кнопкой — куда уж удобнее?!
_NN>И много всего.
Ну да. Хлама в рюкзаке много, а открывашки нет!
_NN>Конечно можно и обойтись без него как и адепты VIM прекрасно работают с кодом, но зачем лишать себя удобств?
VS даёт вполне удобные инструменты, причём тут вим?? Не надо ТУПО утрировать, у вас и так аргументы — ниочём.
Короче, с адептами решарпера всё понятно: банда джунов набигает на код, писаный индусскими брахмапутрами. Извините, но это далеко не главная часть программирования!
Здравствуйте, Ikemefula, Вы писали:
I> Выделение метода — это постоянный, каждодневный рефакторинг.
В индусокоде — да. У профессионалов есть определённая память, поэтому когда он пишет код, он вспоминает, что нечто похожее делается в другом месте. Поэтому дублирующий код В ПРИНЦИПЕ не создаётся. Если же он у вас есть, ну так значит вы не понимаете свой проект! Это уже не проблема VS, тут ближе к квалификации разработчика.
Насколько я понял из всего диспута, решарпер НУЖЕН ДЖУНАМ. Это у них вермишель нуждается в упорядочивании + примитивные "подсказки по коду". Для профи от "среднего" и выше, решарпер — пятое колесо в телеге.
Здравствуйте, Kolesiki, Вы писали: K>Здравствуйте, _NN_, Вы писали: _NN>>На самом деле у Решарпера довольно много мелких вещей к которым привыкаешь и если работаешь без него тратишь лишнее время . _NN>>Как минимум быстрый поиск всего, текста, метолов, классов. _NN>>В студии встроенного пока нет. K>Чё?? Точнее, "Чё курите?" Есть там всё! Самое примитивное — Ctrl+F, это для вашего "поиска текста". Поиск методов — ради бога, найди первый метод, далее find all references. Искать классы можно прямо в солюшене. K>Ну другими словами, те, кто не разбирается в VS, учат чем решарпер хорош. А может для начала выучить основной тул?
Ок. Как это сделать в студии без дополнительных добавок ?
Скрытый текст
_NN>>Далее рефакторинг кода. _NN>>У решарпера вагон правил, которых в студии нет. K>Рефакторинг — признак тухлого, бестолково спроектированного кода. Сначала проектируем В ГОЛОВЕ, потом переносим в проект. Только так. Соотв. последующие рефакторинги не нуждаются в серьёзных и умных правках.
А если меняются требования и нужно переделывать код, что делаем ? Или у вас есть тайное знания будущего ? _NN>>Коллеги, которые работают без него, тратят довольно много времени когда нужно что-нибудь поменять в коде и в итоге получается кол, который двумя нажатиями можно было легко улучшить. K>Ну так не нанимайте джунов! Пусть научатся проектировать, потом уже кнопки давить.
В условиях постоянной нехватки времени бывают неидеальные решения.
Если у вас получается писать идеальный код и в момент изменения требований ничего не нужно радикально переделывать, то вам может и решарпер не нужен.
Возможно даже и студия со своими инструментами для работы с кодом это слишком много для вас. K>Короче, с адептами решарпера всё понятно: банда джунов набигает на код, писаный индусскими брахмапутрами. Извините, но это далеко не главная часть программирования!
В любом месте которому больше пары лет есть код написанный в сжатые сроки и не до конца продуманный или требующий улучшений.
Справляетесь без решарпера замечательно.
У меня например к нему в добавок стоят и другие расширения, и я без них никуда.
Здравствуйте, Kolesiki, Вы писали:
I>> Выделение метода — это постоянный, каждодневный рефакторинг.
K>В индусокоде — да. У профессионалов есть определённая память, поэтому когда он пишет код, он вспоминает, что нечто похожее делается в другом месте. Поэтому дублирующий код В ПРИНЦИПЕ не создаётся.
Забавно, что из всех кейсов ты прицепился к одному — дублированию. А про остальные сказать вероятно нечего?
>Если же он у вас есть, ну так значит вы не понимаете свой проект! Это уже не проблема VS, тут ближе к квалификации разработчика.
Цитирую себя "Узнаю разработчика-одиночку c идеальной памятью"
K>Насколько я понял из всего диспута, решарпер НУЖЕН ДЖУНАМ. Это у них вермишель нуждается в упорядочивании + примитивные "подсказки по коду". Для профи от "среднего" и выше, решарпер — пятое колесо в телеге.
Собтсвенно джунам он нужен в последнюю очередь. Решарпер нужен для того, что бы
1 работать с чужим кодом, как со своим собственным.
2 менять дизайн под изменение контекста не затрагивая поведения
Вероятно, тут ты скажешь, что дизайн создаёшь на десятиления и он не меняется ?
Здравствуйте, Kolesiki, Вы писали:
K>>>Брат, ты не один! Решарпер действительно БЫЛ когда-то полезным дополнением (напр, к студии 2005), потому что саму студию писали посредственности. Но сейчас, за годы улучшений, Студия получила кучу плюшек и теперь Решарпер в ней как пятое колесо — ничего, кроме тормозов не привносит.
I>>Узнаю разработчика-одиночку c идеальной памятью, который реализует закат солнца вручную
K>Узнаю гадалок в пёстрых платьях, которые по линиям руки всё сразу о тебе знают!
Насколько я понял, ты топишь исключительно за инкрементный подход к изменениям, "ровно там, где надо" и никаких рефакторингов.
Такой подход обычно там, где нет никаких тестов, документации и основной мотив "а вдруг навернётся!"
Решарпер и нужен для предоставления гарантий, что изменения в чужом, незнакомом коде будут безопасны.
K>Милок, не сравнивай весь мир по себе. Если ты без решарпера как без рук — ради бога, но не считай всех остальных такими же убогими!
Ну как же, цитируем некоего Kolesiki:
"У профессионалов есть определённая память, поэтому когда он пишет код, он вспоминает, что нечто похожее делается в другом месте. Поэтому дублирующий код В ПРИНЦИПЕ не создаётся. Если же он у вас есть, ну так значит вы не понимаете свой проект! Это уже не проблема VS, тут ближе к квалификации разработчика."
Как видишь, всё сходится Ты сам пишешь, что у тебя идеальная память.
> Делаю, но не так часто, чтобы ставить это убожество. К тому же, я не пишу г***нокод, чтобы потом "экстрактить методы" по 100 штук
Начиная с сеньора основная работа идет чужим кодом, а у тебя "я не пишу г***нокод" Ты адекватен?
При чем здесь ты вообще? Кроме тебя других нет в команде? Ни легаси, ни заимствований из других проектов ? Ни изменений требований, ограничений, команды? Оптимизациями ты тоже не занимаешься?
Вероятно и дизайн создаёшь на десятиления вперёд
Здравствуйте, Kolesiki, Вы писали:
_NN>>Далее рефакторинг кода. _NN>>У решарпера вагон правил, которых в студии нет.
K>Рефакторинг — признак тухлого, бестолково спроектированного кода. Сначала проектируем В ГОЛОВЕ, потом переносим в проект. Только так. Соотв. последующие рефакторинги не нуждаются в серьёзных и умных правках.
И требования никогда не меняются? Оптимизации не нужны ? Новые фичи не добавляются ? Миграции на новые технологии не случаются? И в команде только такие же Kolesiki ?
_NN>>Коллеги, которые работают без него, тратят довольно много времени когда нужно что-нибудь поменять в коде и в итоге получается кол, который двумя нажатиями можно было легко улучшить.
K>Ну так не нанимайте джунов! Пусть научатся проектировать, потом уже кнопки давить.
Джунов не брать. Легаси не трогать. Бизнес-логику не писать. Технологии не менять. Фичи не добавлять.
Что еще посоветуешь?
K>Там нечему "дотягивать" — возможностей студии по рефакторингу — за глаза. А писать г****внокод и потом эту вермишель "сортировать" — ну извини, тут программирование обсуждают, а не индусокод!
Так ты боишься этого индусокода? С этого и надо было начинать.
K>Короче, с адептами решарпера всё понятно: банда джунов набигает на код, писаный индусскими брахмапутрами. Извините, но это далеко не главная часть программирования!