关于软件研发的一些体会总结

       都是码农是个苦逼的群体，果真如此？的确，程序员在我的印象中没有多少人能够是正常下班的，大多是需要加班加点的，有些行业的程序员高峰期需要通宵达旦来保障产品的上线，不少程序员在休息日还需要过来加班工作，不得已把家庭丢下奋战在代码的战壕里，真的我们需要理解支持程序员，程序员家属通常需要做出很多牺牲，特别是照顾小孩、老人、整个家庭。但是，这样的路要一直下去吗？程序员可不可以稍微轻松一点呢？方法总是有的，无法是提高效率，提高研发质量了，公司的研发任务是不会少的，产品要求也不会低的。为了公司的持久发展，程序员的使命也是要做出能让公司盈利的产品，否则就是从一个战壕挪到另外一个战壕，循环而已。那怎么做呢？现在市面上出现了非常多的软件开发敏捷开发的书籍，笔者也看过几本，结合笔者十余年的一线码农工作经验，凭着脑子里的印象我们来一起梳理一下我们研发路上的成功经验以及失败的经验。

/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/edsam49原创，转载请注明出处，谢谢！
/*****************************************************************************************************/

       研发过程中，作为程序员首先我们是一个个体，一个能完成一定开发任务的工兵；其次我们是团队中的一员，是为了完成团队目标的有机组成部分；再则我们是公司的一员，为达成公司发展愿景而努力奋斗的一颗螺丝钉；说得更大一点，我们是社会中的一员，为了实现个人价值，为了实现社会价值，做一个有益于社会的人，我们程序员也是有理想有目标的人。那我们来从这四个方面来逐步展开一些探讨。

作为个体，我们需要拥有一定的知识积累，在开发过程中，我们难免遇到自己的知识不够用的情况，那怎么办？还得靠我们自己啊！快速学习，快速形成能力并解决问题。对于一般的程序员来说，团队下方的工作任务是比较具体的，相对会比较专注。有经验的程序员都知道，其实对于写代码来说这个时候相对还是更幸福一点的，一些项目上的杂事、一些协调的事、公司各部门的闹心事一般还不需要去处理。安排的任务，首先我们需要充分去理解这个任务，然后再分解任务。理解这个任务，是需要了解这个任务的目的、它的设计初衷是什么、为什么要这样设计，我们发现很多时候程序员已经变成了执行的机器。老板怎么要求的、产品经理怎么要求的，一概接受，从不思考是否合理，而这样做我们往往不会把事情做错，但是很难把事情做好。没有错，是因为我们完成了别人的目标，做好是达成了这个事情更合理的做法，是充分表达了自己思考的方法在团队中达成的共识，这样才能做好。在我观念中，对于这个任务，你是第一个实践者，要有自己的感觉，要有自己的见地，有疑问需要及时的提出。比如一些应用开发的任务，只是为了按目标完成它，往往还好。完成后，返不返工呢？返工的教训应该是很多的，限于原定设计者的认识水平以及同行的做法、或者一些方面的欠缺，如果我们程序员在做的时候能够提出一些自己的看法，也许我们返工的几率会大大降低。因为返工，多数情况下累的是程序员啊！因此为了自己少累一点，我们要多主动多反馈多沟通。另外，我们在工作中可以慢慢积累一些功能的模板开发，比如JNI怎么写、service怎么写、广播怎么接收，形成模板后，自己又很熟悉，会提高我们的开发效率。

       我们作为团队中的一员，肯定是为了完成团队的总目标的。那怎么顺利的完整这个目标呢？我们肯定需要借助一些管理工具，关于使用什么工具、怎么个流程，需要大家一起讨论来决定。比如我们开发项目中用的android平台，我们首选的版本管理工具当然是git，有些人又会说用SVN用习惯了，git不会用。那么这时候团队管理者就需要站在现实跟发展的角度来召集讨论并决策，android平台代码量特别大，单个git那样的小工程，代码随便都是几百M的，如果用SVN来管理，查看一次改动的代码svn就要执行很久，哪有git diff来得快。我们需要的朝正确的方向并持续的努力。如果代码量比较小的，团队也可以采用svn这种轻量级的版本控制工具，根据项目需要来。其次，我们在设计方案选定的时候，需要充分讨论，团队成员一起来商量、分析、探讨，然后在内部达成共识。在方案选定的情况下，在编码实践时，也可以根据一些变化来做修正，在项目管理的会议上提出，然后大家通过后再实施，不要私下贸然修改。关于敏捷开发中提到的立会，也就是每天早上站着开一下会，这个有好处，但是每天都开也太频繁，很多工程师也烦。借助于内部通讯工具，比如QQ，腾讯通之类的工具在项目组的群里每天及时的沟通一下其实也挺好的。有些一个小团队在一个办公室，稍微喊一嗓子就达成目标了，项目会议也是需要定期召开一下。我们提交的代码要完整，不要造成服务器上的代码编译不过这种问题，这会影响整个团队的开发。总之，保持频繁的沟通反馈这个原则就好。再则在测试阶段，测试的bug在大公司有很多用收费的高档OA管理系统，在一般的公司里还是可以借鉴一下开源的mantis，也挺好用的。有个管理工具，大家跟踪起bug来就有章法得多。

       在整个公司中，也许你参与的项目只是公司的一个小项目小尝试，只要是公司决定去做的项目一般都是通过了讨论，在多个部门都会参与的情况下进行的。比如涉及硬件的设备程序开发，首先就需要硬件板，测试需要测试部，当然还有ID设计的结构设计，以及一些品质控制、生产控制。有时候程序员做的一个功能，是完成了功能，但是可能在生产阶段不方便不好用而要返工的，这个时候就需要我们在前期设计的时候能够倾听一下我们潜在用户的意见跟建议，这一点很有必要。不然到了生产线得到不好的反馈，我们程序员又需要通宵加班解决问题了，这又是对我们自己受伤啊。保持各个环节的沟通，让事情变得简单一些。

       作为社会的一员，我们只是分工不一样，选择了程序员也许当初是因为他好找工作、待遇高、出入高档写字楼等等原因。本人当时也是因为这些原因走上这条路的，那时候哪知道将来干点啥，一个是接触的东西少、见识也少。慢慢地干上了这个工作，后面笔者又进入了车载电子行业的开发，逐渐的我觉得自己的责任越来越大了，主要是觉得自己的智慧体现在产品上，流通在社会上帮助了我们很多的客户。比如做的行车记录仪的功能，解决了大量的碰瓷，为客户的权益提供了有力的保障。慢慢的又开始做了ADAS，高级驾驶辅助系统。这个东西对驾驶员来说价值更大，真的可以避免很多事故的发生，比如你一走神一下车开偏离车道，ADAS直接来给你一个语音提醒，你可能来得及调整回来。那么要做好这些功能是很不简单的，首先需要好的算法，好的摄像头，需要我们认真负责的配合，另外我们软硬件需要保障系统的稳定。从这个事情上我越来越觉得从心底有一种社会责任感似的，我们不仅仅是为了生活为了工作，我们是为了造福这个社会，为这个社会贡献一点自己的力量。只有心里有这个意思，我们的主观能动性才能更好的发挥，否则被动的加班效率也高不了，成绩也上不去。总的来说就是我们在思想上要提高认识，认识到我们从事的工作的社会意义，从主观意识上鞭策我们向前进，这样我们编写出来的代码的质量应该是会越来越高的!

关于软件研发的一些体会总结