工作方法------如何高效地工作

在现在的这个项目组已快三个月，可以说这是我毕业后进入这家公司的参加的第一个正式的项目，早在8月底部长就问我愿不愿做这个项目，一直到9月中下旬才正式开始，而不是像之前参加的项目，都是中途加入项目的，刚明白我要做什么，那个项目就结束了。

 

在参加这个项目的两个多月里，学到了点东西，也明白了点东西，如下(没有什么技术问题，只有工作方法)：

 

1，在项目开始时，多做准备工作，磨刀不误砍材功的道理，在这里体现出来。

     这是一个有关通信的项目，我和另一程序员的工作就是负责把一种电文转换为另一种电文，而至于SOCKET通信之类的东西，则交由另个一人负责。因为电文比较多，且文档资料经常变更，所以PL在项目开始之初，就让我们整理出两个电文之间的转换关系，比如由A电文转换为B，则整理成文档要求细分到B的第N位，由A的第M位通过计算而来，这样做，一是可以加深我们对电文转换的理解，二是在实际写代码时可以不必去理解电文怎样转换了，因为有这份文档，只须照着写就行。事实证明，这是一个很好的方法，因为在以后的工作中，遇到什么问题，就去找那份变换规则文档，节省不少时间。

 

2，在阅读文档时，把发现的问题分(1,2,3,4。。。)记录在笔记本上，在开会时就按那1,2,3,4的编号来提。

     在看客户提供的文档时，肯定会碰到不少问题。对付这种情况，我之前的做法就是直接在文档上划出来，然后等到开会时再到处找，这样做，在问题较少时还不会出现什么问题，若问题较多，往往会出现漏掉某几个问题的情况，如果再就这几个问题去问客户，则会给我方的工造成不小的麻烦，所以在最开始看电文转换的时候，PL就说我，让我把所有的问题都列成一个LIST，但是我不听，果然有一次漏到一个问题未问，使得PL在组内开会时就批评我，并对我的印象大打折扣，在那之后，就对我特别严，只要发现产生问题的原因是因为我，就会很严厉地说我。所以，把问题归类，列表，是一个很好的工作习惯。

 

3，在实际工作时，若发现自己的风格和别人不一样，在例会时提出来，并确定一个方法来修改代码。

     其实，这点根本就不用提的，因为据我所知，所有的项目，都有自已确定的一套编码规范，变量怎样命名，注释怎样写， 不同的模块之间空几行等。可是不知因为什么原因，只是在开始写代码时的一次例会时提到命名，注释的规范，但是对于代码的结构没有说明，于是我和那个一起做电文转换的哥们的代码的风格就不一样，主要区别体现在：他的是在定义类时，成员变量后紧跟着这个变量的属性，而我的呢，则是把所的成员变量定义完后，再来定义属性。很明显示，在同一个项目内，两种风格是不允许的，在一次例会时，客户提出这个问题，PL问我们解决办法，让我和那哥们商量，是由哪位改，最后，我考虑我参加工作时间不长，就退让说由我改。唉，其实在刚开始写代码时，我就发现这个问题，只是没有提出来，不然，我也不会花上两天的时间来改已经成型的代码了。其实，团队合作，这个很宽泛的概念，在这里就可以体现出来，当由几个人合作完成一项工作时，不能标新立意，哪怕是自己的方法没错或者更好，因为这项目工作，是由几个人一起来完成的。发现问题，及时提出，可以做工作效率大大提高。

 

4，确保所做的中间工具的运行结果是自己所期望的，也就是说，一定要确保中间工具的正确性。

     对程序员来说，这点就是对于一些通用的函数，一定要确保其正确性。举例说明，我所负责的编码工作中，要大量用到数组，而在要经常查某一元素在数组中所处的位置，但是C#的数组这个数据类型没有IndexOf()这个方法，于是就自己写个吧，很简单，不超过10行代码，写完后我就想当然地认为这个方法是正确的，区区10行代码，不必测试了，于是在其他地方，肆无忌惮地用，等到这几天测试时，发现这个方法的运行结果不是我所期望的，于是就狂加班，一顿狂改，PL问我进度时我都是紧张西西的，因为实在不好意思说自己已落后于进度表了，特别是在前几天还高调宣布已提前几天完成工作的情况下，没有办法，只好晚上晚点走了。其实，在写完IndexOf()这个方法后，只须拿出10分钟甚至更少时间，就可以避免这几天的加班，更重要的是，可以消除不必要的紧张感。

 

5，定期自我检查工作成果。

     其实这点和第4点差不多，但是我还是认为4和下面要说的有点差别。以项目的实际情况为例说明吧，在完成把一种电文转换另一种电文之后，还是测试一下，看看结果是否正确。但是我没有这样做，而是写完一个电文的转换后，再接着去写另一个的转换，所在，在这几天的DEBUG中，发现了不少问题，从而使得原计划最晚周二就测试的计划，推迟到今天下午才进行。虽然各个电文的转换是并行的，并不存在一种电文的转换会用到上一个电文转换的结果，所以不存在上面第4点说明的情况，可是若能在完成一个模块之后，在思维还很清晰时就自我检查，发现问题马上解决，并且在接下来的工作中，在相同的地方，可以特别小心地处理，而不是留到最后测试时再一一解决，用PL的话来说，把问题留到最后，没有一点益处，还会给自己增加不安情绪。这不，最近我就一直在紧张地加班，一听到PL叫我名字，我就发悚，以为又是哪个地方我做错了。

 

6，对应问题点时，对应完毕在提交工作成果之前，一定要再次确认后，才提交。

     每次开例会，PL总会指出几个新问题，并且询问上次的问题是否完全解决。这对于那些态度认真的人来说，没有什么，但是对于我这种有点粗心，马虎的的人来说，有时就会犯很严重的错误。因为有好几次，我都是没有对应全部的问题点，或是只是一部分对应所有的问题点，而还有一部分完全没有更改。就是因为这样，也难怪PL会很严厉地对我了。所以，在这几天的修改中， 我总是在修改完毕，上传服务器之前，用对比工具对比一下前后的结果，然后再才放心地上传到文件服务器上。

 

7，修改共通部分时，一定要通知项目组的所有成员。

     这点，在最近共碰到过两次，一次是另外两人把我要用到的一个LOG消息的参数个数给改了，而没有通知其他人，结果是我花了差不多三个小时来对应这个修改，二是我把一个常量的修改后，也是没有通知其他人，结果另一哥们花一上午来DEBUG他的代码，发现原因就是因为那个改量了值的常量。共通部分虽小，但是影响很大，所以在更改之前，勿必全员通知，确认该不该改，这样可以大大节省团队的时间。

    

8，有效的交流，听别人把话说完。

     这应该是做人的基本礼仪吧，但是我经常忽视这点，在最开始和项目组的其他成员不熟悉时，还能做到，可是到后来和大家都混熟了，工作时就放开了，往往在别人话没有说完就自以为是的知道对方的意思，于是就很粗鲁的打断对方，这样，无疑又加大的交流的成本，眼看项目的deadline越来越近，可不能在内部交流上再浪费时间。其实，不管和对方关系多好，也不能打断对方的话，这点，以后一定要注意。

 

9，在进行重大的变更之前，做好备份工作，把应该上传到版本管理服务器的。

     对于这点，特别是在进行多个改动时，再改动完一个之后， 先上传，然后再修改下一下，再上传。。。。。不然，在发现某一个修改没有必要时，到时连个哭的地方都找不到的。还是以第7点中的和共通有关的那个LOG信息来说明，最开始定义四个参数，修改后为三个参数，然后另两同事又改为四个参数，而当时我正在对应这个修改，按照三个参数来修改，花了一上午，改完，没有上传，接下来再对应第二个大的修改，改到一半时参考其他同事的代码，发现他的还是四个参数，而不是三个，于是跟他说起这样，发现才发现他们又把三个改为四个了，呵呵，这时，我要是重新取上一个版本，那我下午的修改完全白做，若再接着改，上午的工作白做。想哭，上哪找哭的地方去？

 

10，在定义常时时，最后在这个常量注明它是由谁定义的。

     这点，我不知道是否正确，只是感觉在最后整理常量时，会发现要省事得多。因为在项目进行时，没有时间去为每个常量的定义而和其他人商量，并且是在项目的中后期再去由专人来整理这些常量，这无疑给这人制造了一个不小的麻烦，因为他不清楚这个常是做什么用的，也不清楚这个常量能和其他哪个常量合并。所以在定义常量时，注明使用者，这样在修改时，若看注释还不明白的话， 就可以很方便地知晓它是由谁定义，于是这整理工作，就要轻松很多了。

 

 

---------------------------------------------------------------------------------------

 今天在公汽上想到的，好像不止这十点，等想到后，再补上来。