软件开发心得-谈谈软件意识和编程习惯

1.工程意识

以前，接到一个小项目，自己总是自鸣得意，觉得这是个小case，用不了多久就能做出来了。

实际上，并不是这样的。一个项目无论大还是小，它终究是个软件工程。既然大项目要走需求

分析，需求评审，概要设计，详细设计，编码/调试，后期维护等软件工程的流程，那么小项目

也是如此。你总不能不了解需求就能做软件设计，不了解需求就开始编码，也不可能说你写的

代码没有bug而不需要debug，更不能保证你的项目交付客户使用后一直相安无事。更何况，在

软件行业，需求会变的，客户的使用环境变数是未知的，等等因素，你如何敢小瞧一个小项目？

只是说大项目的开发周期更长，参与的开发人员更多，更加难以把控软件开发过程中的各个小细节。

而小项目，有时候你未必需要走完软件工程中的每个流程，比如你可以不进行概要设计直接详细设计。

还是乖乖的告诫自己：我做的是一个工程！

2.产品意识

当我意识到我正在开发的项最终是个产品时，我总会更多的站在客户的角度去思考问题，总会发现

开发的项目中还有很多细节没有去实现，而这个细节是客户评论同类型软件好坏的关键点。

作为同类型软件，大家的主体功能都会具备，因为这些主体功能是业务需求必须具有的。当我想到

这里，我总会想，用户为什么使用我的软件而不使用其他同类型的软件？

细节，决定了用户体验。就因为我愿意的在完成主体功能后去实现这些细节，客户就觉得我做得好。

就因为我比别人做多了那么一点点。而这一点点，对于开发人员来说，压根不具备挑战性。（程序员

很多是崇尚技术的，对于这种低技术含量的活不放在眼里，这是程序员与生俱来的傲慢）

3.团队意识

我曾经在一个团队，领导很着重团队成员的竞争，谁做得好又快，谁的绩效就越高。这本来无可厚非。

可领导忽视了一点，团队成员因为只顾自己的一亩三分地，做完自己的就万事大吉。在出现问题时，就

相互推卸责任，扯皮条，到最后领导不得不出来追踪这是谁造成的。在这样的团队里面，每个成员都不愿意

分享自己负责过的模块的技术，因为一分享自己就贬值了，谁愿意呢？

可相互之间的闭门造车，造成了每个团队成员的学习/开发/维护某个模块的成本变得越来越高了，领导

你可曾想过？程序员们编码越来越吃力了，程序员们，你们后悔曾经自己的自私吗？

我以自己有过这样的领导为耻，我以自己曾经如此自私为耻！

4.分享意识

在一个公司里面，不是每个模块你都负责过，你总会有些模块，某些API，某些业务不知道如何使用，如果

此时时间又紧，想曾经负责过，或者很熟悉这个模块/API/业务的人请教，这何乐而不为呢？

不要吝啬你手头上的那半点技术，那总会过时的，唯有在分享中获取多一份信任，才能让你驰骋职场。

我曾在在的一个公司就做得不错。总会定期由每个开发成员分享自己负责的模块中涉及到的业务以及技术。

每次的分享的准备，总会让自己认真地去总结自己负责的模块，从而每次对自己做过的模块有更深刻的理解。

很庆幸能在这样的一个乐于分享的团队，感觉团队中的每个乐于分享的成员！

5.不要吝啬你的注释

我曾在在一个项目里面看到这样的注释：“今天我感冒了，思路不是很清晰，特地写下XXX模块的实现思路”。

顿时，我就笑了，而且没看一次就笑一次，这样的话也写在注释里面？不过当我看完他注释写的XXX模块的实现

思路后，我就不笑了。因为XXX模块的业务逻辑很复杂，单靠阅读去理解模块的思路很是困难，但当阅读那又长

又搞笑的注释后，我深深地感激作者！在他注释的指导下，我很快就理解了XXX模块的实现思路。

对于注释中如此搞笑的对白，我暂不作评论。但他不吝啬注释的态度，让我甚是感激和佩服。

试问，有多少个程序员愿意在时间很紧的情况下，为自己的代码写下如此详细的注释呢？

当然，不是所有的注释都需要那么详细，但当你的模块很复杂时，你的详细注释是维护人员的福音阿！

6.不要急于运行你刚刚修改完的代码

我以前，包括现在有时候，一旦发现自己的代码有错误，马上急于修改，甚至没有对引起错误的原因进行分析，

就敲键盘了。在匆匆修改完代码后，马上运行，看看效果是否如自己所愿。如果是这样的状态，很多时候事与愿违，

你不得不再次修改代码，这样周而复始，直至解决。这种解决方法，带着试试看的态度去尝试，完全是个愚蠢

的做法，耗时耗力。何不缓一缓，出现问题时，先分析一下出现错误的原因，修改完代码后，何不检查一下刚刚

修改过的代码？问一问自己语法是否有问题，会不会造成内存泄露，会不会造成内存溢出，业务逻辑对了没，

修改的代码对其它模块是否造成影响？

相信，这样的习惯会让你节省不少时间！

7.简单就是美

我曾经为封装一个跨机型/跨OS的项目设计一个UI库，当时为了避免耦合/解决兼容性/代码复用而费尽心思，

定义了很多平台/机型的宏，针对不多的平台/机型使用不同的API，绝对不重复造轮子。等到投入使用时，发现

用户在显示文本时，用户很难随心所欲的控制文本的显示位置。这是因为我提供的接口里面定义了居中，居左，

居右三种位置的选择，提供了左对齐间距，右对齐间距接口。从设计层面上来看，这的确满足了软件的设计。

可正是这种过多的想法阻碍了用户的使用，如果我提供的接口是定位x，y坐标的，用户用得着那么纠结吗？

用得着纠结对齐/定位的问题吗？

不用了，过于复杂了。殊不知，简单就是美！

8.善于发现和利用工具

曾在一个公司里面，使用的公司自己的SDK和ToolKit。

这一整套工具中满足了开发中的各种需要，你可以使用的公司的集成开发环境，也可以自己编写脚本文件编译，

但无论无何，在打包参数文件时，你总得一个一个的加载参数文件进去。我也曾因为这样而咒骂这鬼SDK，后来我

发现，你只需要将所有的参数文件放置在特定的目录下，SDK就会帮你自动加载，还有你可以编写加载参数文件

资源文件的脚本，并将脚本提交给SDK的某个路径，SDK就会自动读取。这些都是一些技巧，在公司工作很久的

老员工都未曾发现这个，正因为这个，我节省了很多的时间，感谢自己多了那么个心眼！