程序员高手和菜鸟的区别
随着做软件的时间越来越长，我发现，做软件越来越难。难在哪？难在怎么做出一个好的软件。好的软件标准是什么？两个词，好用，好看！程序员的最大价值在于做出好用又好看的软件的能力。因此，我觉得程序员的价值绝对不在于技术本身，而在于做出好用且好看软件的能力。这是一个开放性的话题，每一个人都是菜鸟过来的，我希望和祝愿每一个技术人员都能尽快成为高手，也希望更多老鸟来分享经验。在这篇文章，我将根据自己的经验来分享，期望能给人有更多的有帮助的信息。在这里，我只想从技术角度来分析，技术不一定和收入相关联的。
1 命名
从程序代码的命名，我们就可以看出一个人的水平。最差的命名就是使用中文、拼音、拼音缩写、中英混搭，接下来要么是模仿式命名，要么干脆就随意命名。模仿式命名典型的就是“××DAL”，说实话，我觉得类似于“UserDAL”这样的名字，我觉得太不美观了，一般这我就知道这是典型分层架构的模仿者，说明他是有些经验的人了。随意命名，就是写代码的时候，名字压根就没有意义，比如var list = new List<User>，其实完全可以写成var users = new List
<User>的。想要命名的更有意义，你只需要将每一个类、每一个方法、每一个单词的名字都用你开发时的意思直接描述出来就行了。
                
程序员和编程员的区别     
2 模型抽象能力
模型决定一个系统的可用性、稳定性、易用性、可维护性、可扩展性！
这个模型不是UML建模，而是软件的核心。就是你设计一个软件时，为其所抽象出来的原理性的描述。模型决定一个软件的质量、易用性和扩展性。凡是优秀的软件，都有一个共同特点，就是其模型构建的非常漂亮，当然也有不怎么优秀的软件，模型也很漂亮。微软MEF，我个人觉得其模型构建非常的漂亮和优雅，有兴趣同学可以看看《体验Managed Extensibility Framework精妙的设计》这篇文章。MEF的核心就是组合基元，如下图所示，它简单的定义了动态组合的支持基础，然后一层一层的进行扩展。
当然了，因为文章是我写的，我也得得瑟的显摆一下OSGi.NET的设计。可以说，OSGi.NET的设计。OSGi.NET的设计也是类似于MEF，内核很简单，只是为了实现三大功能：动态插件化、面向服务、扩展。不过，我们却可以从简单的OSGi.NET来支撑WinForm、ASP.NET、ASP.NET MVC等任意应用，从简单控制台扩展到iOpenWorks这样的自动化部署与软件生产线平台。它的扩展方式是：
WinForm等桌面插件应用 = OSGi.NET + 应用插件
ASP.NET应用 = OSGi.NET + WebExtension + Web插件
MVC应用 = OSGi.NET + WebExtension + MvcWebExtension + Web插件
自动部署 = OSGi.NET应用 + iOpenWorksBundleRepository + iOpenWorksBootstrap + 自动升级插件
远程服务 = OSGi.NET应用 + 远程服务宿主插件
负载均衡 = OSGi.NET应用 + 远程服务宿主插件 + 负载均衡客户端插件
在OSGi.NET之上的任何应用，都是基于组合和扩展的方式，并没有去不断变更OSGi.NET内核本身的代码。此外，OSGi.NET内核能够支持.NET Framework、Mono、.NET Compact Framework，因为它设计的模型非常小，没有用过多的类库支持。
3 谦虚随和
我们的客户都是一些大的企业，接触了很多各种类型的技术人员。你可以发现一个非常有趣的现象，那些懂得尊重别人、比较谦虚的人经过深入接触后，会发现他们的技术往往都很了不起；而那些说话刻薄无礼，觉得这个技术也不怎样，那个技术没什么了不起的，这个技术没有什么用，我自己的东西已经挺好的，这样的人水平、经验和见识一般都不怎样。软件的问题，并不是简简单单解决一个技术问题，从技术的角度上看，只要学会了使用技术，那么我们就已经掌握了技术，因此，单纯的技术是很简单的。相反的是，软件的协作开发、管理，软件的易用性，软件是否美观，这些东西才是最麻烦的，也往往是技术水平一般、经验短缺的程序员意识不到的东西。我曾经接触过不少一般的程序员，大体都是这一类，他们觉得软件太简单了，没有什么了不起的。对于什么思想，也不屑一顾，他们已经觉得自己掌握了很多真正的技术。
4 异常处理与稳定健壮
通过异常处理可以看出一个程序员程序设计的严谨与扎实的基础知识。对于Java开发人员而言，会发现每一个方法都有可能需要强制的处理异常和声明这个函数需要处理的异常，这中强制的约束，会强迫开发人员来习惯性的考虑和思考它。不过，对于大部分人来说，它处理异常的方式就是简单的使用try { … } catch(Exception anyException) { // 忽略异常 }，用这种方式来捕捉所有的异常信息。这样做的好处就是快，傻，缺点就是一旦出现问题，就不知道问题在哪发生，怎么回事，如果有靠谱的QA还好一些，比如外企，他们都有规范的测试方法和测试流程，一旦发现问题，就会将重现捕捉完整的描述出来给开发者看。不过，在国内没有严格的测试是很正常的，那么出现问题时，就傻了。客户是绝对不可能把出现问题的方式给你完整的Repro的，一旦出现问题，客户会干的就是急眼，那接下来怎么办？你就老老实实加班，老老实实的去猜去问题。当“try { … } catch(Exception anyException) { // 忽略异常 }”这样的代码充斥整个软件系统时，你就可以想象有多可怕，这个软件能稳定就怪了！
我曾经在一个热电公司，在半夜12点，好几个厂家的人聚在热电，等待0点时刻数据采集，一旦数据少了，那么你就麻烦了。我到现场之后，发现有很多开发人员拿个本子，需要不停
的看数据库，或者需要将软件Debug打开，然后看看每一个时刻数据是否正常上来。这真是让我喜出望外，因为竞争对手太弱了！！你们的软件在此之前，难道对它7×24小时不间断稳定运行那么没有信心？我们的软件，我通过系统运行过程的消息和日志，我就可以看出所有的东西，如下，消息窗口能够展示系统后台运行的详细过程。此外，还有非常完整的日志，任何异常我都可以到，并想办法重现。
关于异常处理，另一面，就是菜鸟程序员在写代码或者实现功能的时候，一般不考虑反面情况，一个软件按照正常步骤可能能走通，但是一旦出点意外，就麻烦了。以下就是一个典型的代码。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。