1700452350
这里的技术人员涉及面很大，可以是开发人员，也可以是维护人员，甚至是应用软件的顾问人员（如数据库顾问、App Server的顾问）等。一个系统出现问题，或者是投产前后立刻出现的性能问题，或者是运行中突发的性能问题，或者是逐渐增长的数据（用户或业务数据）导致的性能问题，只要我们肯用心查找，并且拥有适当的资源（如源码和支持资源），一般都是可以解决的。最可怕的是我们的技术人员对性能问题漠不关心，对时间效率不够敏感，导致使用者怨声载道，三人成虎，最终致使此系统成为一个“慢得无法使用的系统”。
1700452351
1700452352
这也要求我们在开发初期就适当考虑一下性能问题，但不要把性能排为头号任务，它不是，它只是我们的一个关注点而已。
1700452353
1700452354
（4）没有慢的系统，只有不愿意投入的系统
1700452355
1700452356
这里的投入指的是资源，包括软硬件资源、人员资源及资金资源等，这不是项目组能够单独解决的问题，但是它会严重影响系统的性能。曾经遇到一个运行超过8年的分析系统，从1年前开始只要是高峰期它的速度就会慢下来，分析下来，发现是因为并发用户超过了许可的数量，造成系统阻塞，性能缓慢，唯一解决的法就是购买更多的许可数量，但是8年了，一个系统的生命期还能有多少呢？—所以最后采用了自由放任的办法，让其自行走到寿命的终结点，然后建立新的分析系统。
1700452357
1700452358
当然，我们也会碰到查不出原因的性能问题，这不可否认，毕竟现在的系统越做越大，源代码动辄就十万、百万级别，让一个人或一个小团队将其彻头彻尾地查清楚也不现实，而且性能问题涉及面非常广，如操作系统、数据库、网络、存储等，要想对这些技术都非常熟悉也很困难，但查不出问题并不代表我们解决不了，是的，这与治疗癌症相似，我们现在的科学还不知道它的发病机理，不知道为什么会产生癌细胞，但我们知道割除病变部位能够避免癌细胞扩散，性能问题也一样：我们可能不知道问题产生的原因，但我们可以有N种手段来解决它。能够解决的问题还算是问题吗？
1700452359
1700452360
而且，性能只是衡量系统的一个辅助指标，而不是主指标，如果您与业务人员交流，说“我们可以把系统的响应时间提升到0.001秒内，但前提是不实现您提出的需求”，您猜业务人员会同意吗？—不把我们这些“火星人”撵出门外已经算是客气的了！
1700452361
1700452362
注意 对现代化的系统建设来说，性能就是一个大“咕咚”—看清它的本质吧。
1700452363
1700452364
1700452365
1700452366
1700452368
编写高质量代码：改善Java程序的151个建议 第11章 开源世界
1700452369
1700452370
You deserve to be able to cooperate openly and freely with other people who use software.You deserve to be able to learn how the software works, and to teach your students with it.You deserve to be able to hire your favorite programmer to fix it when it breaks.
1700452371
1700452372
You deserve free software.
1700452373
1700452374
你可以公开、自由地与其他软件使用者合作，你有权了解软件的工作原理，并将其传授给你的学生，当软件发生问题时你完全可以雇用你所喜爱的程序员对它进行完善。
1700452375
1700452376
你理应得到自由的软件。
1700452377
1700452378
——Richard Matthew Stallman（理查·马修·斯托曼，自由软件运动的精神领袖）
1700452379
1700452380
很难想象一个项目不使用开源产品的情形，所有的框架都自己写，所有的工具类都自己堆砌，所有的运行容器都自己建立—这不是一个健康的项目，这个世界是分工合作的世界，有分享也有贡献，有索取也有回报，这才是Java人的理想世界，而且我们也正朝着这个方向前进。
1700452381
1700452382
不，我不想回到那个没有Struts、Spring、Hibernate、Tomcat的年代，绝对不想。
1700452383
1700452384
1700452385
1700452386
1700452388
编写高质量代码：改善Java程序的151个建议 建议139：大胆采用开源工具
1700452389
1700452390
我们经常会看到一个项目的lib中包含了大量的工具、框架包，要想看懂项目代码还应该对这些工具包有一个大致的了解，开源工具包确实会对我们的项目有非常大的帮助，比如提升代码质量，减少Bug产生，降低工作量等，但一旦项目中的工具杂乱无章时就会产生依赖的无序性，这会导致代码中隐藏着炸弹，不知何时就会突然引爆了。
1700452391
1700452392
而且，在Java世界中从来就不缺乏重复发明轮子的例子，MVC框架有Struts，也有Spring MVC、WebWorker；IoC容器有Spring，也有Google Guice；ORM既有Hibernate，也有MyBatis；日志记录有经典的log4j，也有崭新的logback。可是选择多了，也会导致我们无从选择。因此，在选择开源工具和框架时要遵循一定的原则：
1700452393
1700452394
普适性原则
1700452395
1700452396
选择一个工具或框架就必须考虑项目成员的整体技术水平，不能有太大的跨度或跳跃性，要确保大部分项目成员对工具都比较熟悉，若一个项目中的成员大部分是新员工，那么在持久层框架的选择上，使用MyBatis就比Hibernate要合适，因为MyBatis相对简单、方便；再比如在一个熟悉SSH开发的团队中，就不应该无故选择Guice作为IoC容器，除非是行政命令或为了尝鲜。
1700452397
1700452398
唯一性原则
1700452399
[
上一页 ]
[ :1.70045235e+09 ]
[
下一页 ]