REINFORCED_SC Telegram 34
Сегодня я рефакторил код (ч.2)

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

И занимаюсь я этим подолгу. Над рефакторингом большого проекта я могу работать и по 12 и по 20 часов. Потому что контекст большой, в голову его подгружать долго - надо сделать пока не забыл, пока держу в голове взаимосвязь сущностей и 4 последних стектрейса от эксепшонов. И мне это, кстати, нравится. Потому что видишь ты перед собой кусок говно-софта с дебильным внутренним устройством. Или бессмысленный код, дублирующий друг друга приводишь к единому виду. И раз, становится с проектом работать удобнее. Его структура становится проще и понятнее. Раз - и билд начинает проходить чуть быстрее. Раз - и метод, который раньше подвисал, потому что при определённых условиях лезет в инфраструктуру начинает работать шустрее потому что использует дотнетовский Lazy<> при доступе к одному из локальных полей.

Если вы считаете что это бесполезное занятие - идите-ка в жопу.

Чёрта-с-два. С юнит-тестами понятно - они от багов спасают. Тем более такие, написанные по результатам боевого применения. Распихал большой файл по нескольким маленьким - и вот уже всем коллегам стало с проектам работать быстрее потому что IDE плохо дружит с большими файлами. А время - деньги. Внедрил пару интерфейсов - разбил проблемное место на две части и хоп - параллельный билд начал проходить лучше. Версии собираются быстрее - работа во всей команде ускоряется.

Или пошёл в код какой-то тупой библиотеки, из которой мы используем одну-две функции (привет, MoreLinq) и перенёс их к себе в код - раз и зависимость качать и обрабатывать не надо. Тоже плюс к скорости. А это всё тоже в конечном итоге экономит кровные нефтедоллары. Временами - кучу нефтедолларов. И пусть эти изменения будут маленькими и с точки зрения функциональности бессмысленные, однако они увеличивают производительность всего RnD. Время, которое раньше тратилось на сборку проекта - теперь может быть потрачено на бессмысленные созвоны новую функциональность.

Ну и историй, когда инфраструктура (виртуальные машины на которых собирается код и гоняются тесты) начинает влетать в такую некислую копеечку тоже полно. Особенно это становится заметно, если стартап начинает играть по правилам энтерпрайзной разработки. Тут хочется стартаперам, конечно, внушение сделать: ну не гугл вы блин. И не банк. И все эти многословные паттерны проектирования не для вас. И с билдами, идущими по 3 часа вы помрёте блин. Это вот для тех ребят из банков и бигтеха, которые ещё переименование переменной неделю согласуют и нормально живут. А вам расти быстро надо, пользователей удерживать, а не этой хернёй заниматься.

Вот так и обстоит у меня дело с рефакторингом. Интересно, а как этот процесс проходит у моих читателей?

Такие дела



tgoop.com/reinforced_sc/34
Create:
Last Update:

Сегодня я рефакторил код (ч.2)

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

И занимаюсь я этим подолгу. Над рефакторингом большого проекта я могу работать и по 12 и по 20 часов. Потому что контекст большой, в голову его подгружать долго - надо сделать пока не забыл, пока держу в голове взаимосвязь сущностей и 4 последних стектрейса от эксепшонов. И мне это, кстати, нравится. Потому что видишь ты перед собой кусок говно-софта с дебильным внутренним устройством. Или бессмысленный код, дублирующий друг друга приводишь к единому виду. И раз, становится с проектом работать удобнее. Его структура становится проще и понятнее. Раз - и билд начинает проходить чуть быстрее. Раз - и метод, который раньше подвисал, потому что при определённых условиях лезет в инфраструктуру начинает работать шустрее потому что использует дотнетовский Lazy<> при доступе к одному из локальных полей.

Если вы считаете что это бесполезное занятие - идите-ка в жопу.

Чёрта-с-два. С юнит-тестами понятно - они от багов спасают. Тем более такие, написанные по результатам боевого применения. Распихал большой файл по нескольким маленьким - и вот уже всем коллегам стало с проектам работать быстрее потому что IDE плохо дружит с большими файлами. А время - деньги. Внедрил пару интерфейсов - разбил проблемное место на две части и хоп - параллельный билд начал проходить лучше. Версии собираются быстрее - работа во всей команде ускоряется.

Или пошёл в код какой-то тупой библиотеки, из которой мы используем одну-две функции (привет, MoreLinq) и перенёс их к себе в код - раз и зависимость качать и обрабатывать не надо. Тоже плюс к скорости. А это всё тоже в конечном итоге экономит кровные нефтедоллары. Временами - кучу нефтедолларов. И пусть эти изменения будут маленькими и с точки зрения функциональности бессмысленные, однако они увеличивают производительность всего RnD. Время, которое раньше тратилось на сборку проекта - теперь может быть потрачено на бессмысленные созвоны новую функциональность.

Ну и историй, когда инфраструктура (виртуальные машины на которых собирается код и гоняются тесты) начинает влетать в такую некислую копеечку тоже полно. Особенно это становится заметно, если стартап начинает играть по правилам энтерпрайзной разработки. Тут хочется стартаперам, конечно, внушение сделать: ну не гугл вы блин. И не банк. И все эти многословные паттерны проектирования не для вас. И с билдами, идущими по 3 часа вы помрёте блин. Это вот для тех ребят из банков и бигтеха, которые ещё переименование переменной неделю согласуют и нормально живут. А вам расти быстро надо, пользователей удерживать, а не этой хернёй заниматься.

Вот так и обстоит у меня дело с рефакторингом. Интересно, а как этот процесс проходит у моих читателей?

Такие дела

BY Novikov on Soapbox


Share with your friend now:
tgoop.com/reinforced_sc/34

View MORE
Open in Telegram


Telegram News

Date: |

Over 33,000 people sent out over 1,000 doxxing messages in the group. Although the administrators tried to delete all of the messages, the posting speed was far too much for them to keep up. With the “Bear Market Screaming Therapy Group,” we’ve now transcended language. Matt Hussey, editorial director at NEAR Protocol also responded to this news with “#meIRL”. Just as you search “Bear Market Screaming” in Telegram, you will see a Pepe frog yelling as the group’s featured image. Public channels are public to the internet, regardless of whether or not they are subscribed. A public channel is displayed in search results and has a short address (link). Add up to 50 administrators
from us


Telegram Novikov on Soapbox
FROM American