Coding工作也已经好几年了，
有关设计模式几年前就有研读，
一般常用的singleton,factory,observer
也都有使用过。
在与同事讨论的时候总是会有这样的人，
嘴巴一堆去网络上看到新的专有名词，
可是真正写又不见得逻辑清楚。
文人总是相轻，程式设计师又何尝不是如此?
常常有同事批评目前开发的软件架构有问题，
可是让我很疑惑的是，如何定义好架构?
基本上的扩充性够，稳定度好，效能好
也符合基本的好程式的要件了，
问了许多人，没人能真正定义出好架构，
所以总觉得同事间的讨论好像流于打高空，
就是喜欢互相批评罢了。
到底什么叫做好架构?
有没有高手推荐一下书籍，或者帮忙说明一下?

这很主观的 所以没什么书好推荐就好像佛经圣经可兰经放你面前 可是你是信圆神的重点只在于你相信什么 这需要一点时间洗练出来

如果只是嘴砲，能发泄一下也不错啊。不过也有的是真的能讲出现在的系统会有什么问题并且提出解法，那这种就会有实际的效益

持续让它变好~就是好架构~除非是写了就不改~要不然随着时间和需求的演变~哪有可能一开始就搞出万灵丹?从一开始用到现在~某个角度来说算是没有"进步"~没有更进一步的需求和必要让它变得更好...讨论通常是为了找到较好的方案...是不是嘴砲就看他是不是能讲出优缺点~讲得有理就不是嘴砲

如果有工程师随意批评别人的架构，也只能说他还不够水准没有完美的架构，别随意批评别人的做法，谦虚求教....

基本公正报导,当有人提出批评时,也要同时请他提出建议,或是提出既有的优点

架构好不好，要从需求面来看，没有办法以一挡百，还有规划时对需求与使用的技术掌握了多少。至于楼上武断说批评就是水准不够，我想你还有很长一段路要走。

说不好没用 要说出哪里不好

看他是不是主事人 如果code是他在写 当然可以对架构提出意见 反之,如果专案跟他无关,听听就好

被人吐草了，不过学越多发觉不懂的还有更多，确实还有一大段路要走

好架构当然有其定义，像是 SOLID principle低耦合、高正交(orthogonality)、容易测试等等这些都是好架构的特色相关书籍很多，像pragmatic programmer或refactoring

如果是偶尔被批评，可以向对方求教一下，如果是经常性的可能需要重新审查一下自己的架构了

如果有人说架构不好，真的可以好好讨教一下，毕竟自己写久都有一样的模式和盲点。程式要弹性要稳定要跨平台，不就是大家梦寐以求的吗？