一个好的系统,灵活性应当体现在架构设计上,具体到代码片段,反而是简单直白的好。
单个乐高积木,远不如一小块橡皮泥灵活。但上千个乐高积木,却可以拼出各式各样的模型,而上千块橡皮泥堆在一起,却不一定能支撑自身的重量。
为什么?
因为乐高类积木的灵活性体现在架构上,规定了标准的尺寸和接口,只要符合规定,不同品牌的积木亦可以拼插进来。而具体到单块积木,则形状简单,接口明确,稳固可靠。而小块的橡皮泥,虽可以捏成任意形状,但当系统变大时,则无法维护。
好的代码模块,也应像单块积木那样,简单,健壮,可靠,接口明确,可以把一件事做好,可以在任何环境下做,单线程,多线程,IO延迟,垃圾输入... 不崩不怂,才是好的,也是重用的基础。
具体到题主的情况,不妨考虑一下,新加进去的配置别人是否遵守,如果不是所有人都采用,其他人是所有的操作都进日志,只有题主的模块根据某个flag决定写或不写,系统集成后,debug 时会相当的困惑,将来也不易维护。
如果是这种情况,我也是建议不加的。
KISS-Keep IT Simple, Stupid
代码和程序员必然有一个 Simple and Stupid 定律。
每增加一个间接层都可以解决更通用的问题。
但软件设计中各种指标都是互相影响的,更高的弹性可能增加复杂性、开发/维护成本、代码体积、性能开销等。
所以,设计的难处在于平衡各种指标,而你和上司所想的平衡点可能是不同的。
避免 overengineering。
图片来自 xkcd
The General Problem不不不,代码写的很灵活没什么问题,但是不要让用的人知道。
现在老板要你去做个电饭煲,你做一个智能淘米煮饭炒菜一体机出来是没有问题的,问题是你那玩意儿得和电饭煲一样按一下按钮就能煮出饭来并且可靠性不比电饭煲差。
如果你确信你那玩意儿确实如上面所说的那样简单,那就是你上司管太多了。