79 | 开源实战二（中）：从Unix开源开发学习应对大型复杂项目开发

codeReviewer 是否可以借助一些地方工具来进行是不是更好些呢？

课堂讨论: 保持代码质量的经验: 1. svn/git 少量多次提交, 写清晰的commit: 有助于版本管理/bug追踪/code review. 2. 前后端业务命名统一: 没啥说的, 前端头像叫avatar, 后端叫face_icon就很别扭. 3. 适当的工作节奏: 小团队难免遇到加急的任务, 每天大十几小时的实际编码工作让人无暇考虑什么规范, 优雅, 可读性可维护性...心里只想去tm的.(既然老板不想好好用我的技能, 那我就一路平A呗.) 4. 良好的工作氛围: 技术/产品/设计/运维/市场都是无产阶级, 屁股要坐端正了, 要搞清楚谁是战友谁是阶级敌人, 非暴力沟通, 不要甩锅/埋怨/为难对方. 大家工作的开心才是硬道理, 开心的重要性远远高于规范/流程/制度等等. 当然不是说每天傻乐呵, 程序员作为无产阶级单兵作战单位, 要想清楚一件事: 吾辈为何而战? 相信有缘读到这里的各位都有自己的答案. 我的答案是: 为了更好的生活.

1.代码质量这个，目前真的只能落到个人追求。 2.中高级开发是开发主力。对于中高级开发，就升职加薪来看，技术的效益远高于编码设计能力。设计的好坏，在外行来看终究不也只是翻译了业务逻辑，所以希望他们认可买单挺难的。而烂代码对自己的影响还是比较有限的（自己写的，可读性再差也多少能读懂。扩展性不好导致难改，直接技术实现不了，历史原因，也就过去了）。 3.所以就两三年的工作来看，是加班重构承担风险。还是下班学习稳步提升呢？ 4.存在既合理，该重视的会在该重视的时间被重视。

其实现在很重要的一点是，写出规范代码的能力不值钱！我写代码写的很规范，能提升收入么？在我的了解里，大概率并不能。所以很难有人会重视。 比起代码规范，还不如去多背几道面试题来得直接。我曾经专门去考了阿里云的Java代码规范认证，不完全正式的认证，自认为自己的代码规范程度应该能排程序员前20%至少。但是结果呢？甚至没有一个公司仔细看过这个。 重视代码规范，代码质量，我觉得更大程度上应该通过公司管理层从上到下执行。说实话，对于一个初级程序员，问他Spring底层原理，倒真不如能写出优秀的代码来的性价比高。但是结果就是，Spring原理背几道题面试效果一下就上升了， 但是代码质量却无人问津，，，

之前在的项目组做的是银行的项目，十几人的团队，属于项目维护。项目不紧急，三个月一小版更新，半年一大版。拿到需求的时候首先是分析需求，然后是写开发文档，开发文档组长检查通过后才能开始写代码提交。组长负责merge代码，同时做了code review的工作，觉得小团队这样做还是挺有效的。

从开发技巧来看，我觉得除了文章中提到的哪些点，我们还可以尝试阅读优秀的开源框架，如Spring，Netty等，看看这些优秀的框架是怎么做的，我觉得是能够从中学习到一些东西的。

1.待研发团队的leader很重要，如果他要只是一个做管理或者业务的leader，那保持代码质量很难的，甚至技术氛围都不会太好 2.团队的中高级开发有代码洁癖就好了，可以不断地重构代码，review其他人写的代码 3.团队成员开发过程中，不能随便提交代码。要建一个自己的分支，提交后做merger request，leader或高级开发在这个过程中进行review后做些修改的comment 4.不断改善团队的技术氛围，这个很重要 5.团队成员要熟悉业务，这个也非常重要。尤其是一些专业性强的业务，比如征信系统、信贷核心系统等。熟悉了业务，才能在开发过程中更好地使用设计模式和原则

1.需要二次开发的项目,每个模块都应该包含必要的说明文档 做过一个媒体项目的二次开发,当项目需要对接新模块时,项目经理会甩给我一个jar包,一套源码,然后我自己研究如何打通模块之间的通讯,沟通补充那些公司内部的依赖,打包模块,部署到某台机器上,这个过程中沟通成本特别大,找人要依赖,找人问业务流程,有的资料老大没给全,得靠自己去猜,劳心费神,有的模块代码实现里还有bug,有的模块的实现细节try-catch把异常吞掉,导致很难发现问题,对接的时候相当吃力,如果在一开始就能提供一个说明文档,简单描述一下模块的业务范围,对接方式,几句话的事就能帮忙解决大部分问题 2.不论是管理者还是工作者,工作中都不能携带情绪 我刚工作的时候,什么代码规范都是一头雾水,工作难度又高,一犯错我老大就要开始批评我了,那一阵真是很难受,每天上班都是严阵以待,随时准备跟他打一架的感觉,现在想一想,其实只要大家都不要携带情绪,他以一个过来者的身份指导我,我以一个学习者的身份接受指导,他就能保时保量把项目交付给客户,我也能得到成长 3.对经典源码的阅读,有助于提升设计水平 阅读源码的关键点在于掌握设计原则,设计模式的应用,以及某些特殊场景的解决方案.我在项目中遇到一个摄像头的管理模块,一个模块要管理多个摄像头,一个摄像头的方法有建立连接,停止连接,心跳校验等通用的方法,连接后回调方法的的行为各不相同,这让我想起了先前阅读过的tomcat源码,它用到了模板方法模式,用接口定义行为,用抽象类封装具体实现,然后在具体的每个摄像头的bean里实现了不同的回调方法.遵循这个方式,从我拿到需求,到完成这个设计,一共就用了一两个钟头 在这个模块之后的扩展中,发现很多摄像头有共同的回调行为,而且摄像头的数量经常变动,最好通过配置文件来配置bean.然后我用在专栏学到的工厂模式的代码,不到半天就完成了这部分的重构

的确要看人，所以很多招聘还会写，希望招一些对代码有洁癖的人

代码质量真的最应该负责的人就是开发人员自己，而不应该是质控人员。 质控人员应该变成另外一种的开发和运维人员，修建部门内的“耻辱墙”，将代码的测试覆盖率、CI的成功率、自动化的代码风格、缺陷扫描结果在部门内及时公开透明。只有知耻而后勇才能创造动力。 有效且全面的测试用例是重构的重要保障，王争老师提到的持续重构中，有些团队在代码腐朽后直接推倒重来，那是因为团队根本没有信息能够在祖传代码里面重构出来。如果祖传代码有高质量的测试用例，那就能够为持续重构提供安全网，能够使得重构可以持续和零散地进行。五分钟修改一个有坏味道的类才能变得可能，只要测试不通过，就可以马上回滚这5分钟内的修改。