在我平时所见到的程序员中，如果纯以编码能力来看，个人觉得可以分为五类，依次是：
1. 拷贝型
拷贝型选手就是传说中的“代码拷贝员”了，他们对实现功能几乎没有思路，所作的事情就是从网上或是之前其他团队成员写的代码中拷贝出片段，然后放到项目中，如果运行项目出现了期望结果，则表示任务完成。
这类人只会改代码，却不会写代码。他们大多对编程毫无兴趣，只是希望以此糊口而已。
2. 新手型
当产品有功能需求时，由于经验有限，程序员并不完全知道要如何实现这个功能，需要通过学习、寻找资料等方式来解决问题。
这种情况下的编码过程，程序员的主要目标是“完成功能”，那么很难有多余的心思去考虑边界条件、性能、可读性、可扩展性、编码规范等问题，因此代码bug可能较多，稳定性不高。常常会发生开发花费1个月，改bug却要改上好几个月的事情。
3. 学习型
这类程序员对所在领域的语言已经比较了解，对于一般功能可以有较为清晰的实现思路，给出需求时可以通过自己的思路来实现，并且会一定程度上考虑边界条件和性能问题。但仅此而已，他们对可读性和可扩展性考虑很少，也没有项目级别的考虑，主要是希望通过实现代码来练手或是学习。
这类程序员最大的表现在于喜欢“创造代码”，即使有现成的实现，他们也希望自己来实现一套，以达到“学习”的目的。他们不喜欢复用别人的代码，看见项目中别人实现了相类似的功能，他们会以“需求不同”的借口来自己重新实现一套。这类人一般来说对技术有着较为浓厚的兴趣，希望能够通过项目来进行学习。
从项目的角度来说，这种做法最大的麻烦在于开发周期可能较长（相比直接使用现成的实现），并且会使得项目代码膨胀，影响未来的维护。但这类程序员由于有兴趣，如果好好培养或许会成为明天的牛人。
4. 实现型
这类程序员一般有较为丰富的经验，由于写得太多，因此不再追求“创造代码”来进行学习，同时对所在领域可能涉及的很多第三方框架或是工具都比较熟悉，当接受到产品需求时，对功能实现方案已经了然于胸，因此他们可以快速的实现需求，并且对边界、性能都有一定程度的考虑。因为能够快速实现需求功能，经常会被团队评价为“牛人”。但他们一般仅仅停留在“完成功能”级别上，对代码的可读性、可扩展性、编码规范等考虑较少，对项目总体把握也较少（例如控制项目膨胀、方便部署等架构级别的东西）。
这类程序员最大的表现在于喜欢“开发项目”，却不喜欢“维护项目”。他们产出的代码最大的问题就是维护较为困难，可能过上几个月回头看自己的代码都会晕头转向。因此即使是自己写的代码，仍然不愿意维护，一般会苦了后来人。
因为接口设计的缺乏，当需求变更时，发现代码要改的东西太多，然后抱怨需求变化，却很少认为是自己的代码问题。这样的项目如果经过长时间的变更维护，最终会变得难以维护（一般表现在需求变更响应时间越来越长）甚至无法维护，最终要么是半死不活，要么是被推倒重来。
5. 架构型
这类程序员比实现型更进一步，他们经验丰富，对相关框架和工具等都很熟悉，“完成功能”“稳定性”“性能”这些已经不再是他们的追求，更优美的代码、更合理的架构才是目标。
这类程序员代码设计大多建立在对需求的详细了解和对需求变更的预测上——可扩展性较好；代码细节也尽量多的考虑边界情况、性能——稳定高效；代码命名和注释都恰到好处——可读性较高；同时在开发过程中他们会不断重构，对代码做减法——保证项目可持续发展；等等
但由于考虑问题较多，单从“实现功能”阶段来看，完成速度不一定会比“实现型”要快。只是到了项目中后期优势才会慢慢体现出来
也许还有更优秀的程序员我没有见过，呵呵，欢迎大家补充
1. 拷贝型
拷贝型选手就是传说中的“代码拷贝员”了，他们对实现功能几乎没有思路，所作的事情就是从网上或是之前其他团队成员写的代码中拷贝出片段，然后放到项目中，如果运行项目出现了期望结果，则表示任务完成。
这类人只会改代码，却不会写代码。他们大多对编程毫无兴趣，只是希望以此糊口而已。
2. 新手型
当产品有功能需求时，由于经验有限，程序员并不完全知道要如何实现这个功能，需要通过学习、寻找资料等方式来解决问题。
这种情况下的编码过程，程序员的主要目标是“完成功能”，那么很难有多余的心思去考虑边界条件、性能、可读性、可扩展性、编码规范等问题，因此代码bug可能较多，稳定性不高。常常会发生开发花费1个月，改bug却要改上好几个月的事情。
3. 学习型
这类程序员对所在领域的语言已经比较了解，对于一般功能可以有较为清晰的实现思路，给出需求时可以通过自己的思路来实现，并且会一定程度上考虑边界条件和性能问题。但仅此而已，他们对可读性和可扩展性考虑很少，也没有项目级别的考虑，主要是希望通过实现代码来练手或是学习。
这类程序员最大的表现在于喜欢“创造代码”，即使有现成的实现，他们也希望自己来实现一套，以达到“学习”的目的。他们不喜欢复用别人的代码，看见项目中别人实现了相类似的功能，他们会以“需求不同”的借口来自己重新实现一套。这类人一般来说对技术有着较为浓厚的兴趣，希望能够通过项目来进行学习。
从项目的角度来说，这种做法最大的麻烦在于开发周期可能较长（相比直接使用现成的实现），并且会使得项目代码膨胀，影响未来的维护。但这类程序员由于有兴趣，如果好好培养或许会成为明天的牛人。
4. 实现型
这类程序员一般有较为丰富的经验，由于写得太多，因此不再追求“创造代码”来进行学习，同时对所在领域可能涉及的很多第三方框架或是工具都比较熟悉，当接受到产品需求时，对功能实现方案已经了然于胸，因此他们可以快速的实现需求，并且对边界、性能都有一定程度的考虑。因为能够快速实现需求功能，经常会被团队评价为“牛人”。但他们一般仅仅停留在“完成功能”级别上，对代码的可读性、可扩展性、编码规范等考虑较少，对项目总体把握也较少（例如控制项目膨胀、方便部署等架构级别的东西）。
这类程序员最大的表现在于喜欢“开发项目”，却不喜欢“维护项目”。他们产出的代码最大的问题就是维护较为困难，可能过上几个月回头看自己的代码都会晕头转向。因此即使是自己写的代码，仍然不愿意维护，一般会苦了后来人。
因为接口设计的缺乏，当需求变更时，发现代码要改的东西太多，然后抱怨需求变化，却很少认为是自己的代码问题。这样的项目如果经过长时间的变更维护，最终会变得难以维护（一般表现在需求变更响应时间越来越长）甚至无法维护，最终要么是半死不活，要么是被推倒重来。
5. 架构型
这类程序员比实现型更进一步，他们经验丰富，对相关框架和工具等都很熟悉，“完成功能”“稳定性”“性能”这些已经不再是他们的追求，更优美的代码、更合理的架构才是目标。
这类程序员代码设计大多建立在对需求的详细了解和对需求变更的预测上——可扩展性较好；代码细节也尽量多的考虑边界情况、性能——稳定高效；代码命名和注释都恰到好处——可读性较高；同时在开发过程中他们会不断重构，对代码做减法——保证项目可持续发展；等等
但由于考虑问题较多，单从“实现功能”阶段来看，完成速度不一定会比“实现型”要快。只是到了项目中后期优势才会慢慢体现出来
也许还有更优秀的程序员我没有见过，呵呵，欢迎大家补充
扫一扫
760
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
