三盛都会城网站 html5,电子商城网站的设计与实现,为什么自己做的网站打开是乱码,网站怎样投放广告位概述
设计模式的理论部分已经学完了。我想你一定蠢蠢欲动#xff0c;想要赶紧实践一下#xff0c;把这些理论知识应用到自己的项目中。不过#xff0c;要注意下面两点#xff1a;
一种是过度设计。在开始编写代码之前#xff0c;花很长的时间做代码设计#xff0c;在开…概述
设计模式的理论部分已经学完了。我想你一定蠢蠢欲动想要赶紧实践一下把这些理论知识应用到自己的项目中。不过要注意下面两点
一种是过度设计。在开始编写代码之前花很长的时间做代码设计在开发过程中应用各种设计模式希望代码更加灵活为未来的扩展打好基础。这其实是过度设计未来的需求并不一定会实现变相地增加了代码的复杂度。还有一种是设计不足。怎么简单怎么来写出来的代码能跑就可以顶多算式 demo看似在实践 KISS、YAGNI 原则实则忽略了设计环节代码毫无扩展性、灵活性可言添加、修改一个很小的功能就要改动很多代码。
所以本章和你聊聊在实际的项目开发中如何避免过度设计以及如何避免设计不足。 设计的初衷是提高代码质量
应用设计模式只是方法最终的目的是 “初心”是提高代码的质量。具体点说提高代码的可读性、可扩展性、可维护性等。所有的设计都是围绕着这个初心来做的。
所以在做代码设计的时候你一定要先问下自己为什么要这样设计为什么要应用这种设计模式这样做是否能真正地提高代码质量能提高代码质量的哪些方面。如果自己很难讲清楚或者给出的理由比较牵强没有压倒性优势那基本上就可以断定这是一种过度设计是为了设计而设计。
实际上**设计原则和思想是心法设计模式只是招式**。掌握心法以不变应万变无招胜有招。所以设计原则和设计思想更加普适、重要。掌握了设计原则和思想我们能更加清楚的了解为什么要用这种设计模式就能恰到好处的应用设计模式甚至我们还可以自己创造出来新的设计模式。
设计的过程是先有问题后有方案
如果我们把写出的代码看作作品那做产品时我们先要思考痛点在哪里用户的真正需求在哪里然后再看要开发哪些功能去满足而不是先拍脑袋相处一个花哨的功能再去东搬西凑编出一个需求来。
代码设计也是类似。我们要先去分析代码存在的痛点比如可读性不好、可扩展性不好等等然后再针对性地利用设计模式去改善而不是看到某个应用场景后觉得跟之前在某本书中看到的某个设计模式的应用场景很相似就套用上去也不考虑是否合适最后如果有人问起了就再找几个不痛不痒、很不具体的伪需求来搪塞比如提高了代码的可扩展性、满足了开闭原则。
实际上很多没有太多开发经验的新手往往在学完设计模式之后会非常 “学生气”那原理当真理不懂得具体问题具体分析手里拿着锤子看哪都是钉子不分青红皂白上来就是套用某个设计模式。写完之后看着自己写的很复杂的代码还沾沾自喜甚至到处炫耀。这完全是无知地炫技半瓶子不满大抵就是这样子的。等你慢慢成长之后回过头来在看自己当年写的代码我相信你应该会感到脸红。这里主要是告诉你要防止过度设计。
所以在之前的文章中一直都是从问题讲起一步一步的给你剖析为什么要用设计模式而不是一开始就告诉你最终的设计。实际上最重要的是想培养你分析问题、解决问题的能力。这样看到某段代码之后你就能自己分析得头头是道说出它好的地方、不好的地方为什么好、为什么不好不好的如何改善可以应用哪种设计模式应该之后有哪些副作用要控制等等。
相反如果你只是掌握了理论知识即便是把 23 种设计模式的原理和实现都背的滚瓜烂熟不具备具体问题具体分析的能力在面对真实项目的千变万化的代码时很容易就会滥用设计模式过度设计。
设计的应用场景是复杂代码
很多设计模式的教程都会举一些简单的例子这些例子仅仅只有教学意义只是为了奖设计模式的原理和实现力求在有限的篇幅内给你讲明白。而很多人误以为这些简单的例子就是这些设计模式的经典应用场景常常照葫芦画瓢地应用到自己的项目中用复杂的设计模式去解决简单的问题还振振有词地说某某书中就是这么写的。这是很多初学者因为缺乏经验在学完设计模式之后在项目中过度设计的首要原因。
前面我们讲到设计模式要干的事情就是解耦也就是利用更好的代码结构将一大堆代码拆分成职责更单一的小类让其满足高内聚低耦合等特性。
创建型模式是将创建和使用解耦结构型模式是将不同的功能代码解耦行为型模式是将不同的行为代码解耦
而解耦的主要模式是应对代码的复杂性设计模式就是为了解决复杂代码问题而产生的。
因此对于复杂代码比如项目代码量多、开发周期长、参与开发人员多我们前期要多花时间在设计上越是复杂代码花在设计上的时间就要越多。
不仅如此每次提交的代码都要保证代码质量都要经过足够的思考和精心的设计这样才能避免烂代码效应每次提交的代码质量都不是太好最终积累起来整个项目的质量就变得很差。
相反如果你参与的只是一个简单的项目代码量不多开发人员也不多那简单的问题用简单的解决方案就好不要引入过于负责的设计模式将简单问题复杂化。
持续重构能有效避免过度设计
我们知道应用设计模式会提高代码的可扩展性但同时也会带来代码的可读性的降低复杂度的升高。一旦我们引入某个复杂的设计之后即便在很长一段时间都没有扩展的需求我们也不可能将这个复杂的设计删除整个团队都要一直背负着这个复杂的设计前行。
为了避免错误的需求预判导致的过度设计我非常推崇持续重构的开发方法。持续重构不仅仅是保证代码质量的重要手段也是避免过度设计的有效方法。在真正有痛点的时候我们再去考虑用设计模式来解决而不是一开始就为不一定实现的未来需求而应用设计模式。
当对要不要应用某种设计模式感到模棱两可的时候你可以思考下如果暂时不用这种设计模式随着代码的演进当某一天不得不去使用它时重构的代码是否很大。如果不是那能不用就不用怎么简单怎么来。说句实话对于 10 万行以内的代码团队成员稳定对代码涉及的业务比较熟悉的情况下即便所有的代码都推到重写也不会花太多的时间因此也不必为代码的扩展性太多担忧。
避免设计不足的 3 个必要条件
前面讲的都是如何避免过度设计下面再稍微讲讲如何避免设计不足。
首先你要有一定的理论知识储备。
比如你熟练掌握各种设计原则、思想、编码规范、设计模式。理论知识是解决问题的工具时前任只会的结晶。没有理论知识就相当于游戏中没有厉害的装备虽然可以靠身手徒手打怪但肯定会影响你最高水平的发挥。
其次你还要有一定的刻意训练。
很多同学很苦恼说理论知识都学过但是很容易忘记遇到问题也想不到对应的知识点。实际上就是缺乏理论结合实际的刻意训练。没有经过刻意训练知识积累不了能力也锻炼不了等于白学。
最后你一定要有代码质量意识、设计意识。
在写代码之前要多想想未来会有哪些扩展的需求哪部分是会变的哪部分是不会变的这样写会不会导致之后添加新的功能比较困难代码的可读性好不好等代码质量问题。有了这样的意识你就里写出高质量的代码不远了。
不脱离具体场景去谈设计
设计是一个非常主观的事情不夸张地讲可以称之为一门 “艺术”。相应的好坏就很难评判了。如果真的要评判我们就要放到具体的场景中。脱离具体的场景去谈论设计是否合理都是空谈。
比如一个手游项目能否被市场接收往往非常不确定。很多手游项目开发出来之后市场反馈很差立马就放弃了。此外尽快上市占领市场也是一款手游致胜的关键。所以对于手游项目的开发来说往往前期不会花太多的时间在代码设计、代码质量上。
相反如果你开发的是大型端游一般都要投资上亿资金几百号人开发好几年推倒重来的成本很大。这个时候代码质量就非常关键了。前期就要多花点时间在设计上否则代码质量太差bug 太多后期无法维护也会导致很多用户弃用而选择同类型的其他家的游戏。
再比如开发的是偏底层、框架类、通用的代码那代码质量就比较重要因为一旦出现问题或者代码改动影响面就比较大。相反如果我们开发的是业务系统或者不需要长期维护的项目那稍微放低点代码质量的要求也是没有问题的而且自己的代码跟其他项目没有太多耦合即便出了问题影响也不大。
