Миддловые джунгли
Oct. 8th, 2023 11:14 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoОдна из тонких, но далеко идущих ошибок, это точное выполнение требований. Если между различными требованиями есть противоречие (то есть unsound), то это противоречие останется в коде. Если новое требование отклоняется от идей системы, то эти требования (будучи точно реализованными) приведут к резкому взрыву сложности, потому что для реализации требований потребуется изобрести собственную подсистему, которая позволяет эти требования реализовать, используя абстракции нижележащего уровня (включая внесение этих "if"ов в нижележащие системы).
Более сеньёрский подход - это аппроксимация требований в рамках сохранения звучности архитектуры. Это может быть торг с постановщиком ТЗ, это может быть "наивное" игнорирование edge case'ов ТЗ, явно не описанных в ТЗ во имя сохранения архитектурной простоты.
Если торг не уместен, апроксимация не достаточно точна, то следующий этап - это рефакторинг идей во имя нового ТЗ. Рефакторинг идей - это хуже, чем "переписывание всего", потому что всё должно быть не только переписано, но и передумано; все слова, к которым привыкли люди, окажутся изменившимися, предположения будут неверными и т.д.; это невероятно дорого. Бывают ситуации, когда такое нужно делать. Но, чаще всего не нужно, так что аппроксимация и торг - вот правильные подходы. А способность это объяснить (backpressure) - это один из софтскиллов сеньёра.
... Поправка, даже не "рефакторинг", а "переустройство".
Более сеньёрский подход - это аппроксимация требований в рамках сохранения звучности архитектуры. Это может быть торг с постановщиком ТЗ, это может быть "наивное" игнорирование edge case'ов ТЗ, явно не описанных в ТЗ во имя сохранения архитектурной простоты.
Если торг не уместен, апроксимация не достаточно точна, то следующий этап - это рефакторинг идей во имя нового ТЗ. Рефакторинг идей - это хуже, чем "переписывание всего", потому что всё должно быть не только переписано, но и передумано; все слова, к которым привыкли люди, окажутся изменившимися, предположения будут неверными и т.д.; это невероятно дорого. Бывают ситуации, когда такое нужно делать. Но, чаще всего не нужно, так что аппроксимация и торг - вот правильные подходы. А способность это объяснить (backpressure) - это один из софтскиллов сеньёра.
... Поправка, даже не "рефакторинг", а "переустройство".
no subject
Date: 2023-10-08 08:34 am (UTC)Владелец проекта хотел расширять функционал в угоду клиентам. Даже при том, что хотелки клиентов были не критичными, вида "а вот неплохо бы еще и такое". Этот функционал требовал не просто больших переделок в бэкенде, но еще и случались внутренние конфликты реализаций разных фич, и для обхода конфликтов приходилось все обмазывать проверками и валидацией в три слоя, что за год свело темп разработки к нулю. Весь пар уходил в свисток обеспечения совместимости новых фич со старыми.
Пришли к пониманию двух вещей. Таксономию сущностей в основе проекта нужно менять, не радикально, но существенно. И клиентов с их хотелками нужно иногда посылать нахер. Целостность продукта имеет большую ценность, чем фичастость.
no subject
Date: 2023-10-08 08:57 am (UTC)Да, хорошее наблюдение. Часто вижу китайский стиль - буквально первый кейс, буквально второй кейс... абстрагировать и обобщать и делать гибким - задания не было.
Ко мне тут попервоначалу приставали - а вот добавь это поле к таким-то записям. И еще это поле потом. Я поглядел - эти поля вообще нигде у нас в коде не используются. Мы что скачали с одного сервера, то клиентам и показываем. Ну так какая нах разница, сделаем гибким. Что взяли, то и держим. Все равно поля опциональные. Долго впендюривал идею народу. Долго меня расспрашивали, а как это так вообще возможно. Но ничо, привыкли. Теперь мы не знаем вообще, какие там поля вставляют или убирают. Нам пох.
no subject
Date: 2023-10-09 04:53 pm (UTC)((с) я, в самом начале новой для себя карьеры наёмного работника в 2012 году)
За что я люто ненавижу физматов и вообще сервильную субкультурку въедливых постсоветских (и не только) разработчиков: дадут им гвозди и отвёртку, так они будут неделю изобретать способ забивать гвозди отвёрткой, вместо того чтобы просто отказаться это делать. "А ты это попробовал? А так? А сяк? А каком кверху?". Я понимаю, что они очень любят загадочки, паззлы и решаемые задачки, их так учили, они есть те люди, которым интересно заниматься хернёй (и даже книжка у них есть, "Как сдвинуть гору Фудзи").