一个半月软件开发的经验谈--

一个半月软件开发的经验谈

--回顾过去,有利于了解未来的路。

九天雁翎

对于程序员(自己)

C++相关经验:

1. 基类需要虚析构。

2. C++的接口实现分离通过头文件和Cpp文件方式还不是太完美,但是加上纯虚的接口就接近完美了。

3. 函数调用时会将原函数的信息压入堆栈,再将esp赋给ebp,再将ebp压入堆栈。(不知道记错没有)最后堆栈中会形成一个原有函数调用的序列信息。可以回溯到main函数。

4. 永远要知道Unicodeansi不能混淆,不然哪怕一个参数的传递都会出问题。Debugrelease也不能搞混,不然一样也会出问题。

Windows相关经验

1. windowsC++的异常处理实际调用结构化(SHE)异常实现。

2. windows有一族设定程序异常时调用函数的API函数,可以指定出现异常时的处理。

3. dump可以用writeminidump函数实现。Dump文件可以直接用VS2005打开debug

4. windows有一族获得程序运行时系统状态的函数,包括CPU信息,内存信息,用户电脑信息等。

5. 网络通信不了解的时候非常高深,了解后也就是一个套路。无非就是那么几步。

其他:

1. 文件无非就是2进制代码,无论是真的一个一个字节的处理还是通过序列化的方式。只要知道不过都是2进制代码,知道每个字节的含义,就一样可以处理了。

2. 软件开发很重要的是看清需求,需求可以用用例分析,弄清用例,利用用例驱动开发。需求不清,只会导致糟糕的设计,导致最后的大规模修改。

3. 不仅是需求不清会导致糟糕的设计,对实现没有大局的掌握也会导致糟糕的设计。比如我当时将读写文件的单位定为一个DWORD一样。

4. 文件的打包,无非就是通过文档头记录文档信息,找到索引表,索引表记录其中的文件信息,找到文件。无论多少个文件放在一起,效果还是一样,从很多个打包在一起的文件读出来的文件和一个单独的文件都一样,无非是2进制代码。

5.序列化的时候打开文件一定要用二进制,不然出现在0x<chmetcnv unitname="a" sourcevalue="0" hasspace="False" negative="False" numbertype="1" tcsc="0" w:st="on">0A</chmetcnv>(一个回车符)前加一个0x0D的情况,debug到你吐血你都不知道为什么。就算你以整数给出0x<chmetcnv unitname="a" sourcevalue="0" hasspace="False" negative="False" numbertype="1" tcsc="0" w:st="on">0A</chmetcnv>去序列化,windows一样会给你加0x0D

6.当一个设计定下来后,不是出现重大问题,不要随便更改,因为可能下面的人因为你的一个看似小的更改而改动很多。

7.文档不是写给自己看的,是写给别人看的。好的文档可以节省你给别人解释的时间。好的文档是应该在几个月,几年后再看,也能很快的了解自己在做什么。

8.概要设计分清模块关系及接口,详细设计定好类的关系及实现流程。

9.弄清自己需要做什么然后才开始做。

10.不要在实现流程都不清楚的情况下盲目编码。

11.宁愿出现断言,也不要出现莫名的错误。宁愿编译时的错误也不要运行时的错误。运行时出错了也应该能很容易的知道出现的是什么问题。(给出出错代码)

12.这世界上有个叫steven的人,太牛了,他写的书作为开发服务器的我应该都要拜读。

13.虽然对于侯捷,看过他的一篇自己为是,价高有理的文章后我有成见,但是不应该就此否定他的翻译和他的书都还是不错的,该看的还是要看。

对于项目经理(总监)

1. 好的项目经理能在老总训人的时候主动承当责任而不是推卸责任。这样下属才能死心塌地的跟着你。

2. 应该在分配任务的时候让下属明白其该做什么不该做什么,在这个时候多用1分钟,也许可以为下属省一天的时间。

3. 了解下属的能力,知道其能做好什么,不能做好什么。不能做好的部分也不能强求,就算是培养也不可能出现跨越性。

4. 对于一个复杂的系统,可以先实现一个简单但是走的通的系统,再考虑进一步的优化和功能的提升。(比如对文件的读写时可以先做到能读写,再考虑分块)

5. 只有合理的分配任务才能调动下属的积极性而不是反过来打击积极性。

老总

老总有两种做法:

轻松的:相信项目经理,只关心指导项目经理的工作和其应该做的工作。

累的: 指导项目经理,也指导项目经理所管的每一个人。

轻松的,自然轻松,但是要求有足够的对项目经理能力的信任,项目经理也的确需要有足够的能力。这样的好处是,职责明确,下属只有直接上级,下属的任务也明确,指令也清楚,不会出现老总与项目经理指令不一致而不知所措,两边挨批而导致混乱的情况。缺点是,无法对每个实现进行了解和指导,无法真正掌握开发进度和实现细节。与间接下级脱节,不能了解他们。

累的,要求本身技术实力非常强,不仅能对整个大的项目有大局观,对于大项目中每个小的模块也都要有从大局出发的看法,而且对其实现细节能有足够的了解和对其优劣的看法。好处是能保证项目的整体性能,掌握开发进度,了解每个下属的能力和他们都在做什么。在下属对一些实现没有考虑大局的时候可以及时做出指正,也有利于自己的知识,看法,观点越过项目经理直接传输给下一级的下属,对员工的工作能力培养有一定的益处。缺点是,容易在和项目经理沟通不足的时候导致对其下属的指令混乱,在对细节实现没有下属清楚时有可能做出错误的决定,也太累。

阅读更多

没有更多推荐了,返回首页