Автоматический рефакторинг
02.02.2020
|
Pauel |
Здравствуйте, ukrspecs, Вы писали:
С>>Вы наверное сразу всё делаете правильно, а потом не переделываете никогда. И всё помните. Вам ни Find Usages не нужен, ни переразбивка проекта на части и неймспейсы, ни создание интерфейса для какого-нибудь класса на 50 методов (фасада к куче других сервисов, а интерфейс нужен для создания кэширующей прослойки).
U>ОК.
U>- Вы наверное сразу всё делаете правильно. По крайней мере стараюсь, а вы разве нет?
Смешно и наивно.
Именно по этому код выгодно держать в чистоте. Чистый код легко изменять в любую сторону. Его даже вырезать и выбросить легче.
Более того — поскольку все вышесказаное требует рефакторинг, то очевидно, руками с этим не справиться. Нужна автоматизация.
U>- Find Usages меня устраивают, те что есть в VS. Если прям все-все искать — то стандартный поиск по solution тоже ок.
U>- Переразбивка проекта на части и неймспейсы — делаю руками. Хотя не любитель трогать, то что работает. И новых проектов тоже хватает.
И наверняка никогда не ошибаешься. А вот ведь именно эта работа дает огромное количество ручных ошибок. Поделил класс на два — надо все финты в конфигурции, инициализации и тд пофиксить руками. Кто гарантии обеспечивать будет?
U>- Создание интерфейса для какого-нибудь класса на 50 методов. Тоже редко такая задача появляется. Привык руками делать, но можно и так
Ок, расскажи, каким чудом ты будешь делать, преобразование, скажем, глубокой иерархии, скажем, в плоскую широкую. Плохая иерархия досталась от тех, неправильных девелоперов. На переписывание времени нет. Что делать?
С>>Вы наверное сразу всё делаете правильно, а потом не переделываете никогда. И всё помните. Вам ни Find Usages не нужен, ни переразбивка проекта на части и неймспейсы, ни создание интерфейса для какого-нибудь класса на 50 методов (фасада к куче других сервисов, а интерфейс нужен для создания кэширующей прослойки).
U>ОК.
U>- Вы наверное сразу всё делаете правильно. По крайней мере стараюсь, а вы разве нет?
Смешно и наивно.
- Правильно — это только сейчас. А сразу, как приступим к новыми фичам в следующей версии, уже автоматически неправильно.
Поменялись требования в ходе разработы — снова становится неправильно.
Поменялась команда — скажем, разбили на три локации, дизайн будет ломаться хотите вы там у себя или нет. Отчуждаем, скажем, ядро или плагины — это долгая и тщательная хирургия, после которой пациент должен быть жив.
Понадобились оптимизации — опаньки, их заранее предусмотреть нельзя, нужно решать дизайном, выделять узкое место в какой то управляемый формат.
По уму, любые изменения кода, особенно багфикс и оптимизации, должны начинаться и заканчиваться рефакторингом. Мелкими изменениями очень часто создают такую паутину, что крупные просто не влазат. Соответсвенно проще, дешевле следить за качеством кода.
Если менеджеры начинают жать, требовать ср
Например, мега-архитектор может придумать мега-фичу, на её реализацию уходит полгода, после чего оказывается, что фича перестала быть нужной, т.к. бизнес решил, что ему это и не было нужно. Вот такие вещи вносят чудовищный хаос в код. То есть, все особенности принятия решений в конторе оседают прежде всего в виде лишнего кода.
Вобщем, все проблемы, которые есть вокруг разработки, нестыковки, текучка, недопонимания любой природы, конфликты всех сортов, особенности принятия решения, все это и многое другое прежде всего отражается на коде.
Самое важное — стоимость сопровождения растет крайне нелинейно в зависимости от уже реализованых решений. И не важно, полезны они, или нет. Вот эта нелинейность убивает зачастую вообще весь профит.
Именно по этому код выгодно держать в чистоте. Чистый код легко изменять в любую сторону. Его даже вырезать и выбросить легче.
Более того — поскольку все вышесказаное требует рефакторинг, то очевидно, руками с этим не справиться. Нужна автоматизация.
U>- Find Usages меня устраивают, те что есть в VS. Если прям все-все искать — то стандартный поиск по solution тоже ок.
U>- Переразбивка проекта на части и неймспейсы — делаю руками. Хотя не любитель трогать, то что работает. И новых проектов тоже хватает.
И наверняка никогда не ошибаешься. А вот ведь именно эта работа дает огромное количество ручных ошибок. Поделил класс на два — надо все финты в конфигурции, инициализации и тд пофиксить руками. Кто гарантии обеспечивать будет?
U>- Создание интерфейса для какого-нибудь класса на 50 методов. Тоже редко такая задача появляется. Привык руками делать, но можно и так
Ок, расскажи, каким чудом ты будешь делать, преобразование, скажем, глубокой иерархии, скажем, в плоскую широкую. Плохая иерархия досталась от тех, неправильных девелоперов. На переписывание времени нет. Что делать?
02.02.2020 19 комментариев |
I>Здравствуйте, ukrspecs, Вы писали:
U>>- Создание интерфейса для какого-нибудь класса на 50 методов. Тоже редко такая задача появляется. Привык руками делать, но можно и так
I>Ок, расскажи, каким чудом ты будешь делать, преобразование, скажем, глубокой иерархии, скажем, в плоскую широкую. Плохая иерархия досталась от тех, неправильных девелоперов. На переписывание времени нет. Что делать?
Наследования вообще лучше избегать. И в целом любая задача решается без наворачивания абстракций на абстракции. В моих 70-ти фриланс проектах не было глубоких иерархий и нужды превращать их в плоские тоже.
Было условно 2 типа задач:
— Сделать так чтоб работало (и побыстрее). Bug fixes иначе говоря. Побыстрее — решается костылем, через какой нибудь делегат или utility class
— Написать все с нуля. Тут проблем никогда не было, все что я писал с нуля — работает до сих пор и расширяется без overengneering'а и прочей черной магии
Сейчас в меня полетят помидоры, за анти-девелоперский подход не по
фен шуюСтрауструпу. Но мои клиенты предпочтут рабочую программу, которая приносит ценность. Нежели техническое совершенство внутри.А если вы подумаете — "ха, быдлокодер", то в свою защиту могу сказать, что доход от такой деятельности раза в 4 выше зарплаты senior developer в конторе.
U>В моих 70-ти фриланс проектах ...
70 проектов Это если всю жизнь работать, то проект будет меньше года. А если за 10 лет, то по месяцу-два на проект. Студенческий по сложности.
С этого и надо было начинать. Как раз то, о чем я писал здесь — на коротких проектах в тулах вроде решарпера выхлоп ничтожный.
>Сделать так чтоб работало (и побыстрее). Bug fixes иначе говоря. Побыстрее — решается костылем, через какой нибудь делегат или utility class
U>А если вы подумаете — "ха, быдлокодер", то в свою защиту могу сказать, что доход от такой деятельности раза в 4 выше зарплаты senior developer в конторе.
Такой подход в долговременных проектах не работает, независимо от уровня ЗП.
I>Здравствуйте, ukrspecs, Вы писали:
U>>В моих 70-ти фриланс проектах ...
I>70 проектов Это если всю жизнь работать, то проект будет меньше года. А если за 10 лет, то по месяцу-два на проект. Студенческий по сложности.
I>С этого и надо было начинать. Как раз то, о чем я писал здесь — на коротких проектах в тулах вроде решарпера выхлоп ничтожный.
Где я написал, что 70 проектов были написаны лично мной? Меня бросали как правило в средних размеров проект, фиксить баги-добавлять фичи. Так чтоб с нуля писать — наверное штук 5-8. И это было больше года, и сейчас продолжается. Я параллельно на нескольких сижу. До 10 проектов одновременно.
I>Такой подход в долговременных проектах не работает, независимо от уровня ЗП.
Куча софта написано через задний проход, с одной целью — побыстрее выкатить релиз и поднять денег. Вот первое что пришло на ум — Skype, Slack, Windows 8/Vista, Xamarin тот же.
Такой подход — это то как большинство заказчиков видят разработку в целом. Х-як х-як и в продакшн.
Борцы за эталонную архитектуру и чистый код, как правило сидят уже на золотом унитазе и занимаются этими рефакторингами, абстрагированием, мета-программированием... что бы хоть чем то быть занятым в сопровождении.
I>>70 проектов Это если всю жизнь работать, то проект будет меньше года. А если за 10 лет, то по месяцу-два на проект. Студенческий по сложности.
I>>С этого и надо было начинать. Как раз то, о чем я писал здесь — на коротких проектах в тулах вроде решарпера выхлоп ничтожный.
U>Где я написал, что 70 проектов были написаны лично мной? Меня бросали как правило в средних размеров проект, фиксить баги-добавлять фичи. Так чтоб с нуля писать — наверное штук 5-8. И это было больше года, и сейчас продолжается. Я параллельно на нескольких сижу. До 10 проектов одновременно.
Сунуть нос в 70 проектов, если за всю сознательную жизнь, это с 20 лет до 70, получается целых 8 с половиной месяцев. Тащить 10 проектов одновременно, это в среднем в месяц по 16 часов на каждый. Если сидеть одновременно на нескольких, то слишком высокие издержки на переключние
Вобщем — нет ни единого шанса погрузиться на должную глубину.
Фиксить баги, добавлять фичи — это примерно то, чем занят мидл. Интересно, да? Для мидла как раз не так критично, есть решарпер или его нет, как для сеньора.
I>>Такой подход в долговременных проектах не работает, независимо от уровня ЗП.
U>Куча софта написано через задний проход, с одной целью — побыстрее выкатить релиз и поднять денег. Вот первое что пришло на ум — Skype, Slack, Windows 8/Vista, Xamarin тот же.
Так ты ж сам пишешь — наскоком, главное сделать и тд
Твои примеры крайне странные. Про Скайп и Винду еще можно как то согласиться, то Слак в целом стабильный, качественный и очень полезный. Про ксамарин — с ним не работал, но в целом от телерика впечатление крайне негативное.
U>Такой подход — это то как большинство заказчиков видят разработку в целом. Х-як х-як и в продакшн.
U>Борцы за эталонную архитектуру и чистый код, как правило сидят уже на золотом унитазе и занимаются этими рефакторингами, абстрагированием, мета-программированием... что бы хоть чем то быть занятым в сопровождении.
В майнтенансе по другому невозможно — кавалерийский наскок при выпуске следующей версии очень часто заканчивается плачевно. Я по природе что-то типа разработчик-патологоанатом или реаниматолог Приходися реанимировать упоротые вот такими ковбойскими приемами проекты. Каждый ковбой оставляет в проекте шлейф багов разного калибра, которые всплывают регулярно в течении всех последующих версий. Какая бы фича не пилилась, в ней обязательно будет баг, который ведет на строчку заминированую каким нибудь ковбоем. И как правило этот баг виден только при внятном ручном тестировании, например, бесит юзера а девелоперы его в упор не замечают. Пока тестировщик не найдет точную последовательность, баг не будет пофикшен.
I>Здравствуйте, ukrspecs, Вы писали:
I>Сунуть нос в 70 проектов, если за всю сознательную жизнь, это с 20 лет до 70, получается целых 8 с половиной месяцев. Тащить 10 проектов одновременно, это в среднем в месяц по 16 часов на каждый. Если сидеть одновременно на нескольких, то слишком высокие издержки на переключние
I>Вобщем — нет ни единого шанса погрузиться на должную глубину.
Были проекты которые делались за неделю и меньше. Были крупные на которых сидел 1.5-2 года. Незнаю что у тебя за арифметка, но для фриланса обычное дело брать много заказов.
I>Так ты ж сам пишешь — наскоком, главное сделать и тд
I>Твои примеры крайне странные. Про Скайп и Винду еще можно как то согласиться, то Слак в целом стабильный, качественный и очень полезный. Про ксамарин — с ним не работал, но в целом от телерика впечатление крайне негативное.
Слак съедает пол гига RAM'ы на минималках. И это внутри этой проги крутится еще Хромиум. Может он и стабильный, но тормозной до безобразия, не оптимизированный. Ксамарин до покупки Microsoft — это была адская боль, потому что падало все что могло упасть. Да и сейчас — это не образец стабильности.
I>В майнтенансе по другому невозможно — кавалерийский наскок при выпуске следующей версии очень часто заканчивается плачевно. Я по природе что-то типа разработчик-патологоанатом или реаниматолог Приходися реанимировать упоротые вот такими ковбойскими приемами проекты. Каждый ковбой оставляет в проекте шлейф багов разного калибра, которые всплывают регулярно в течении всех последующих версий. Какая бы фича не пилилась, в ней обязательно будет баг, который ведет на строчку заминированую каким нибудь ковбоем. И как правило этот баг виден только при внятном ручном тестировании, например, бесит юзера а девелоперы его в упор не замечают. Пока тестировщик не найдет точную последовательность, баг не будет пофикшен.
Да, мы с тобой с разных миров разработки, но даже работая в офисе — я обходился без шарпера.
I>>Сунуть нос в 70 проектов, если за всю сознательную жизнь, это с 20 лет до 70, получается целых 8 с половиной месяцев. Тащить 10 проектов одновременно, это в среднем в месяц по 16 часов на каждый. Если сидеть одновременно на нескольких, то слишком высокие издержки на переключние
I>>Вобщем — нет ни единого шанса погрузиться на должную глубину.
U>Были проекты которые делались за неделю и меньше. Были крупные на которых сидел 1.5-2 года. Незнаю что у тебя за арифметка, но для фриланса обычное дело брать много заказов.
В том то и дело, ты вещаешь с позиции не просто фриланса, а ориентированого на короткие проекты. Если у тебя было 70 проектов, то ясно, что среди них не может быть много длинных.
1.5-2 года — небольшой срок вобще говоря.
U>Слак съедает пол гига RAM'ы на минималках. И это внутри этой проги крутится еще Хромиум. Может он и стабильный, но тормозной до безобразия, не оптимизированный.
Сколько кто съедает — не интересно, со стабильностью проблема нет. Потребление в пересчете на стоимость гб памяти никакое не примечательное. Скажем, в те время, когда RAM Было 64-256мб было полно полезного софта который "выжирал" ококоло четверти этой RAM. И ничего. Полгига — это в худшем случае десятая часть.
>Ксамарин до покупки Microsoft — это была адская боль, потому что падало все что могло упасть. Да и сейчас — это не образец стабильности.
Про другие продукты от телерика аналогичные отзывы и так уже лет 10 наверное.
I>>В майнтенансе по другому невозможно — кавалерийский наскок при выпуске следующей версии очень часто заканчивается плачевно. Я по природе что-то типа разработчик-патологоанатом или реаниматолог Приходися реанимировать упоротые вот такими ковбойскими приемами проекты. Каждый ковбой оставляет в проекте шлейф багов разного калибра, которые всплывают регулярно в течении всех последующих версий. Какая бы фича не пилилась, в ней обязательно будет баг, который ведет на строчку заминированую каким нибудь ковбоем. И как правило этот баг виден только при внятном ручном тестировании, например, бесит юзера а девелоперы его в упор не замечают. Пока тестировщик не найдет точную последовательность, баг не будет пофикшен.
U>... но даже работая в офисе — я обходился без шарпера.
Так ты потому и пошел во фриланс, что он был для тебя близок Не само ведь это произошло — шел, шел в офис, и каким то чудом оказался не в офисе утром, а в разгаре фриланса на 70ти проектах разом.
U> Да, мы с тобой с разных миров разработки, ...
Если у тебя много опыта, это не значит, что он абсолютный и всеъобъемлющий. Такого не бывает. Ответ на твой вопрос на решарпер именно в этом — фриланс, короткие проекты и нежелание работать с чужим кодом.
Вот и всё — никаких чудес.
И заметь, я не пишу, что фриланс это плохо, или 70 проектов это так себе. С т.з. заработка денег это очень выгодно, как минимум в краткосрочной перспективе. И далеко не все девелоперы, и даже не большинство, вообще смогут работать во фрилансе. То есть, для твоей области с тобой скорее всего всё в порядке.
Небольшое отступление. Не бывает оценок вида "хорош вообще". Оценка всегда применима только в связке с конкретной целью, контекстом.
Например — работа в энтерпрайзе в большой команде на долгоиграющем проекте.
Другой пример — работа во фрилансе на множестве проектов разной длительности включая совмещение работы на большом количестве проектов.
Шеридан-кейс — работа в одиночку на небольшого дикорастущего заказчика без команды, процессов, инструментов и тд.
Для каждого кейса есть свои ключевые склилы-свойства-обязанности. А вот даже степень владения ЯП или VM для всех будет сильно разной. Одним надо ширина обхвата, другим глубина погружения, третьим — коммуникация, четвертым — владение мат-методами в конкретно заданой области.
И девелоперы, которые долго работают в своей области, обычно с большим трудом интегрируются в другие. Это факт, его можно только признать. Есть и исключения — суровые всемогуторы, герои легенд всех времён и народов. Теоретически, они есть в природе, но чем дальше в будущее, тем чаще в легендах.
Причем часто после таких героев-всемогуторов надо еще года два вычищать проекты Они, правда, очень сильно попогают на старте стартапов именно в силу всемогуторности.
I>В том то и дело, ты вещаешь с позиции не просто фриланса, а ориентированого на короткие проекты. Если у тебя было 70 проектов, то ясно, что среди них не может быть много длинных.
I>1.5-2 года — небольшой срок вобще говоря.
Вот последний проект на котором просидел 1.5 года, лепят 8 лет к ряду уже. Естественно чужого кода там чуть менее чем весь. Однако за рефакторинг могли бить по рукам, задача обычно сводится к тому чтобы работало. А рефакторинг по дефолту — это что-то упустить и навернуть всю систему. Первое правило ж — работает — не трожь.
U>>Слак съедает пол гига RAM'ы на минималках. И это внутри этой проги крутится еще Хромиум. Может он и стабильный, но тормозной до безобразия, не оптимизированный.
I>Сколько кто съедает — не интересно, со стабильностью проблема нет. Потребление в пересчете на стоимость гб памяти никакое не примечательное. Скажем, в те время, когда RAM Было 64-256мб было полно полезного софта который "выжирал" ококоло четверти этой RAM. И ничего. Полгига — это в худшем случае десятая часть.
Пол гига для простого чатика — это не то что много — это катастрофически неприемлимо. Тоже самое можно сказать и про Viber, Telegram и WhatsApp отчасти. Однако они нативные, не browser-based, насколько знаю.
>>Ксамарин до покупки Microsoft — это была адская боль, потому что падало все что могло упасть. Да и сейчас — это не образец стабильности.
I>Про другие продукты от телерика аналогичные отзывы и так уже лет 10 наверное.
Вы наверное что-то путаете, или я чего-то незнаю, Xamarin — самостоятельная разработка компании под одноименным названием, на основе Моно. Идея эта пришла некоему Бразильцу
Мигелю Де Иказа. Телерик — это из области создания UI компнонентов, из другой оперы совсем,
I>Так ты потому и пошел во фриланс, что он был для тебя близок Не само ведь это произошло — шел, шел в офис, и каким то чудом оказался не в офисе утром, а в разгаре фриланса на 70ти проектах разом.
Я пошел во фриланс потому что жил в жопе мира, где работы для программиста не было как таковой. А я к слову начал в начале нулевых как с рсдна, потом по книжкам учить С++ и завертелось.
I>Если у тебя много опыта, это не значит, что он абсолютный и всеъобъемлющий. Такого не бывает. Ответ на твой вопрос на решарпер именно в этом — фриланс, короткие проекты и нежелание работать с чужим кодом.
I>Вот и всё — никаких чудес.
Я и не претендую на совершенное мнение, тем более в контексте разработчика в офисе на долгоиграющем проекте. Да я вообще мало что могу рассказать про такую работу, кроме того что мне кажется это дико скучным и бесперспективным, мусолить годами один и тот же код.
I>Небольшое отступление. Не бывает оценок вида "хорош вообще". Оценка всегда применима только в связке с конкретной целью, контекстом.
Разумеется.