Миддловые джунгли
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)Владелец проекта хотел расширять функционал в угоду клиентам. Даже при том, что хотелки клиентов были не критичными, вида "а вот неплохо бы еще и такое". Этот функционал требовал не просто больших переделок в бэкенде, но еще и случались внутренние конфликты реализаций разных фич, и для обхода конфликтов приходилось все обмазывать проверками и валидацией в три слоя, что за год свело темп разработки к нулю. Весь пар уходил в свисток обеспечения совместимости новых фич со старыми.
Пришли к пониманию двух вещей. Таксономию сущностей в основе проекта нужно менять, не радикально, но существенно. И клиентов с их хотелками нужно иногда посылать нахер. Целостность продукта имеет большую ценность, чем фичастость.