软件工程师的能力大约可以从三个方面概括，代码、文档、沟通。就现有初级软件工程师常见的问题，分析如下。

首先是代码。代码有许多好的属性。有些属性，必须经过千锤百炼才能获取，称之为锤炼属性。有些属性，一开始写代码时，就应该具备，称之为初始属性。下面只讨论初始属性的一些问题。

第一从代码安全的角度。分如下几点。

尽量不用使用指针别名。同一段内存区域，用尽可能少的指针指向。避免内存错误的发生。

使用最高级别的warning level。在VC2008最高级别为level4，而缺省级别为level3。如果使用，最好使用静态分析工具分析代码。消除潜在的隐患。

设计算法时，尽可能考虑周全，尤其是边界条件。比如在读写(或遍历)文件数据数据，应该考虑文件末尾。

第二，从代码可读的角度，分如下几点。

以层次分解复杂度。在代码效率允许的范围内，为了代码可读度，应该将其中逻辑复杂的功能单元提炼出来，以使每一层代码的逻辑更加简单。不要把一堆复杂的逻辑，堆积在一个模块内。

不要直接注掉代码。大量的代码注释，非常影响代码阅读。我们已经有了先进的代码管理系统(比如svn、Git等)，这些会为我们记住这些注掉代码，无需以注掉的方式供未来之用。详见<<代码整洁之道>>的4.4.12。

不要在if中直接使用太复杂的逻辑表达式。太复杂的逻辑表达式，很难理解。应该用一个解释性的变量，将复杂的逻辑表达式赋给这个解释性变量。

不要写超前代码。在阅读代码时，经常发现一些当前系统无关的代码，一问才知道，是为了将来的某个时候的需求。一是以后的需求具有不确定性，当前写的代码很难满足未来的需求。二是大量冗余的代码，严重影响了代码的阅读。但注意，设计必须具有前瞻性，这一点和代码不同。

代码命名含义清晰、短小。如何才能是变量名短小而含义清晰。查阅了相关文献，想不到，小小的变量命名，竟然涉及到英语语法的问题，实在是有点小题大作。对于一个特定的领域而言，如图像处理、数据挖掘、加密和解密等，90%以上命名是经常使用的。只要平时注意总结、严格使用统一的命名风格。就能达到良好的命名。对代码中经常出现的命名单元，应使用统一的单词或其缩写方式。比如img和pic，都可以代表图像，但一般来说用img。提高代码的可读性。

第三从代码重用的角度。底层的函数或类，尽可能少的和系统关联，以便随时提出重用。开源代码x264和jm，在这一点做得非常不好。

第四是其他方面。分如下两点。

测试框架流程和集成框架流程尽可能保持一致。包括接口使用和实现的流程等。在最近的重构中，发现某个接口的一个参数，是专为测试流程准备的，对集成流程毫无影响；这是非常不合适的，因为这样可能造成一个后果:集成框架的 bug在测试框架无法测试出。

接口的特殊性。接口是程序员之间，团队之间交互的模块，如果修改和使用接口，必然牵涉到多个程序员或团队，其所付出的成本比一般模块要高许多。首先接口应该尽可能的少。太多的接口意味着使用方需要理解更多的知识，增加了使用复杂度。其次，接口应可能考虑全面，保证以后不修改或少修改。因为其修改，需要多个程序员，以密切协作的方式进行修改。而非单个程序员的行为。

其次是文档。关于文档，分如下几个方面。

第一是，文档一定要注意专业术语准确表达。一定要用大家统一的，公认的专业术语表达。人非圣贤，每个人的知识，特别是专业知识是有限的，所以仅仅凭借即时发挥，很难写出专业化的文档。一方面，要具有专业术语意识，写文档时，如果遇到相关词汇，一定要查阅准确的专业术语表达，而非凭空臆想。另一方面，要注意总结，将常用的专业词汇总结成文档。

第二是，在代码(包括注释)中能够说明的，没有必要写在文档上。一方面避免文档罗嗦。另一方面避免相同的内容即出现在文档中，也出现在代码中，给维护工作带来了一定的困难。比如关于，接口的详细说明，尽可能在h文件中用注释说明，在文档中点到即可。

第三是，在代码中不能说明的，必须出现在文档中。比如系统框架，我们无法从庞大复杂的代码中迅速感悟到系统的框架，所以，文档必须清晰介绍系统的框架。更多精彩内容见李云的博客，该死的，代码就是文档http://yunli.blog.51cto.com/831344/966154。

最后是沟通。分如下几个方面。

第一要不要怕别人不高兴。经常出现这种情况，有人在和别人沟通时，怕别人不高兴。这个有多方面的原因。一是沟通的结果不可预测，害怕出现不利于自己的结果，这是一种因噎废食的心理。二是中国传统文化中，提倡内敛稳重，也是一个重要方面。

第二要善于处理别人的批评。批评大体可分为四种，恶意不正确、恶意正确、善意正确、善意不正确。对于批评，首先要表示快乐的接受，然后区分处理。不要一听到恶意不正确的批评，就火冒三丈、心中不快，即破坏了团队的和谐，又损害了自己的形象。