Борьба со сложностью - святая обязанность архитектора (да и программиста тоже), о которой, к сожалению часто забывают. Или стесняются. Конечно, каждому хочется наваять крутую архитектуру (как в очередной прочитанной книжке), или применить классный паттерн (visitor или decorator или plugin или всех сразу). Часто за этим ничего не стоит, кроме желания самоутвердиться среди коллег. Многие разработчики стесняются применять простые решения, из-за того что коллеги могут подумать, что у вас недостаточная квалификация. Например, разработчик реализует "элегантную" схему кэширования данных, не зная о том, что получаемые им данные уже и так кэшируются на предыдущем логическом уровне. Иногда надо обладать определенной смелостью для того, чтобы применить простые решения на практике. Горе вам, если вы работаете в команде, где считается крутым писать код так, чтобы никто не мог понять как он работает.
Жестокий закон разработки состоит в том, что программные системы являются сложными системами, и в ходе разработки сложность системы неумолимо нарастает. Сложность определяет тот предел, дальше которого невозможно продвинутся в разработке. Вместе со сложностью растет энтропия. Энтропия убивает систему и разрушает процесс разработки. Если с этими явлениями не бороться и программный продукт и процесс его разработки деградируют. Все последние десятилетия программная инженерия развивалась в направлении позволяющим разрабатывать все более сложные системы с приемлемым уровнем качества, производительности и т.д.
Боритесь со сложностью и вам воздастся :) Боритесь со сложностью на этапе проектирования. Ранжируйте требования, смело отметайте несущественные, и требования не подкрепленные реальными потребностями.
Всегда думайте о том - можно ли обойтись без этого блока (слоя, компонента, шлюза и.д.)? Что будет если выкинуть то или это? Достаточно прост ли этот интерфейс, нельзя ли из него выкинуть пару методов? Не будет ли гораздо проще, если в этот интерфейс добавить пару методов? Нельзя ли убрать вот эту зависимость между компонентами?
Простая программа наверняка будет работать лучше чем сложная. Однако простую программу написать гораздо сложнее, чем сложную.
Сложность опасный противник, она подбирается со всех сторон, и бороться с ней надо постоянно.
2 комментария:
Отличный пост.
"Make things as simple as possible, but not simpler"
Часто бывает так, что модуль или компонент проектируется (и реализуется) так, что бы было возможно быстро менять его поведение если вдруг изменятся требования.
Но, очень часто требования остаются такими же. Или, наоборот, настолько сильно меняются, что блок или компонент приходиться заново проектировать.
На опыте, получается, что лучше начать с очень простого решения, которое just works, а потом его усложнять. А не делать сразу сложно, так риск промахнуться - очень велик.
Отправить комментарий