程序员怎么看懂需求文档

1. 程序员喜欢什么样的需求文档

程序员实际上并不需要这个文本的需求供认书，程序员喜欢“图片”，文档的文本应该是产品学生在脑子里思考，而不应该直接把这个想法描述成文字。
程序员需要的是一个清晰的交互图,在关键位置的交互图显示,有一些边界条件,交互图不需要使用乱七八糟工具输出,一张纸和铅笔描述清晰,但恢复需求描述的所有元素就可以了,虽然没有UI设计,但程序员可以开始开发演示。
一、产品介绍和行业简介。首先，给程序员简单介绍一下产品的价值，比如产品的作用，产品可以提供的服务，以及产品相对于竞争对手的优势。还要介绍产品的目标用户和使用场景。第二点是简要说明行业的现状，未来的趋势是什么，同行业竞争对手的情况如何?

二是产品的介绍。第一，实体关系图很重要。当您将产品从0变成1时，为了使数据库开发人员更快地了解您的产品，实体关系图(e-r图)将发挥很大的作用，数据库开发人员可以参考图来做数据表结构设计。
第二是用户角色表的访问。当涉及到角色和权限时，需要一个全面的角色权限表单来促进开发人员的参考。第三是业务流程图。通过业务流程流程图，可以从总体方向了解产品的整体逻辑，通过拆卸业务流程流程图得到流程流程图。

三是各种细节问题。产品的要求、功能和交互指示。写功能描述，交互说明，不能漏掉一些细节，导致逻辑不严谨。可以从以下几个方面来考虑，它会让你更全面地思考:字段，字段描述，数据源；先决条件，排序机制，刷新机制；状态流(页面可能有多个状态，需要解释)；交互操作(正常操作，异常操作)

2. 程序员在上班时，允不允许大量的看说明文档来帮助写程序

程序员日常开发工作，基本是上离不开阅读文档，这也是很多程序员喜欢两个显示器的原因。

项目方面

技术方面
是不是很多人都认为，如果在开发过程中，还要不断地翻技术文档，说明他的开发能力不扎实。其实不是这样的。

首先IT行业技术升级换代的速度太快，当我们大多数公司还在用Java8的时候，Java11都已经出来了。如果非得要程序员熟知每一个类、每一个方法，是很不现实的。

很多时候我们只需要了解有这么一个东西，作用是干什么的，具体的细节可以在用的时候再去翻文档，比如方法名字是什么？参数有几个，都是什么类型的？

所以我们都习惯至少两个电脑屏幕，一个屏幕写代码，一个屏幕看文档；如果豪一些的话，再加一个屏幕展示日志信息。

看文档的屏幕要买竖屏！

我们团队
我这几年也带过几个团队，对于每个团队成员，我对他们的要求是：实现需求的前提下，最好能对所用的技术有一定的了解，千万不要从网上抄过来一段代码就用，这样是很危险的行为。所以鼓励大家多找一些资料，最好是阅读框架的官方文档。

现在的团队，我已经这样要求了：代码写累了，或者觉得自己没有状态写代码，可以找点儿自己有兴趣的技术文档学习学习，这个技术甚至是可以跟现在的项目没有关系的。

首先，我不是程序员，我是一个设计工作者，不过我来说一下我的观点：很多人以为程序员像电影里的一样，啪啪啪几下键盘，屏幕数据飕飕的变，其实真实情况是程序员写代码就像学生写作文，也会遇到不会的词语跟修辞手法，那这个时候就要停下来想一想，查一查，看看例子是怎样写的怎样用的，写错了还要划掉（删掉）再来，至于这个大量不大量看的情况，如果这个是个新手，那肯定是可以的，那如果是个老手，还需要大量时间查说明文档，那就说明这个项目肯定不会小，不是一两天能做完的，那一个用月做单位的项目，用一个天做单位的时间来查文档，不过分吧！程序员也是人，不是因为他的工作高端，就觉得这个人万能，他也会当机，要吃饭，要休息，也会忘记一些东西，所以请各位多多体谅，能一起工作实属不易，感恩2018，谢谢。

这个问题怎么说呢，开发过程中会遇到各种各样的问题，没有一个人是全能的，也没有人可以绝对的说自己在整个项目中不会遇到一点问题，不去查东西，自己大脑里的东西完全可以让我把这个项目测测底底的做完，并且没有任何bug。

上班的时间，也没有老板或者谁在后面一直看着你去做东西，大家都挺忙。文档是干嘛的，文档本身就是用来看的，甚至很多项目开始之前，总监都会让你去搜集一些这个项目可能会遇到的bug，可能会用到的效果，尽量在之前找到比较好用的插件，这样会节省很多时间，自己如果写代码的话不可能百分百的确定没有人和bug，但插件不一样很多插件都是前辈通过很长时间慢慢完善出来的插件，所以很多人才会用。所以你提问的可以肯定的回答你允许。

程序员上班的主要工作就是看说明文档，根据说明文档编码。如果实在没有说明文档，有时还得亲自披挂上阵写说明文档。

写接口的有API文档，写通讯协议的有协议字段说明文档，写数据库的有数据库规范文档，

总之任何一个大公司文档扮演的一个至关重要的问题，因为形不成文档，公司管理就会陷入混乱不堪的局面，当某个核心员工离职后，下一个接盘的程序员会丈二和尚摸不着头脑，一头雾水，边填坑边骂娘，有了文档就可以看文档结合代码，了解其中模块逻辑以及结构，包括哪些坑不能踩等等好处。有些公司会专门有文档工程师这个职位来专门负责整理各种文档，并且保存在服务器上。

好的文档都是程序员等人智慧的结晶，是一盏指路明灯，是一条通往光明的道路。程序员不能看说明文档等于在黑暗里摸爬滚打，有了说明文档才迎来了黎明的曙光。

说个我遇到的2个真事吧，

第一个，公司找的外包公司写项目程序，已经要交付了，发现有几个功能没做，产品经理和开发那边都找我，我一个搞运维的又不懂，只能让他们去对开发文档，我也就顺便看了看，开发文档中明确的写明怎么做，然后就让他们就重新按开发文档继续写，

另一个，由于 历史 原因业务系统处于托管状态，只有部分参考文档可用，开发那边只能按当前已有文档进行开发参考，开发那边也一直在根据现有相关文档进行开发，杯具的是这帮子不仔细看，有问题总想着我能直接给他们答案，我也只是会用而已，开发我还真搞不来，然后和他们一起看开发文档，加密算法部分给她们指出后，问题解决了。

所以我觉得，开发团队在开发中很有必要阅读开发文档，这可以避免绕圈子，也会清楚开发文档中提供的内容。

先说观点，我认为看文档没什么问题，但是“大量”这个程度很难衡量，按照需要看文档是个非常重要的事情。
需要花费时间的情况 不需要花费大量时间的情况 小结
在工作中阅读文档其实也是工作内容的一部分，而且现在大多数互联网公司都靠KPI进行考核，平时就算你把时间都用来看文档没关系，最后KPI没完成一样会被公司淘汰。所以公司不会阻拦你花费时间看文档，最多你老板会提醒你浪费这么多时间看文档而没有实际的产出会对你年终考核造成影响罢了。

题主对文档的定义不是很明确
第一个是需求说明文档
这个是在开发过程中必不可少的文档，只有清楚了开发需求，程序员高效率的开发，程序员一天的工作时间并不是都是在写代码，而是在看文档，了解需求，理清思路，只有什么都清楚了，写代码或许只要十几分钟。

再者对于一个项目新人来说不看文档了解需求，没人给你从头到尾的在讲一遍需求，你不看文档自己发挥？进入项目是和别人共同开发，你不肯能不顾及之前的代码规范。
第二个是开发文档
就拿微信开发来说，微信开发不是每个程序员必须会的东西，但是用到了怎么办，还不是去看他们的开发文档，只有将开发文档思路理清楚了，才可以进行下一步开发。
第三个是API文档
在前后端分离的开发模式中API文档是必不可少的文档。不看API不知道数据是什么样。也就是不可能顺利的和后端进行结合。

兄dei，假设你是程序员，你在写程序时，旁边会有人守着你吗？

假设你不是程序员，你在做本职工作时，旁边会有人守着你看你怎么做事吗？

答案肯定是没有的。谁会闲着招个人去监督你，看你用什么方式去完成给你的任务。

所以，其实你看不看大量文档，没有人会在乎，关键是你自己，建议自己写东西时，不要一味的复制粘贴，要有自己的想法。太依赖文档对于自己成长很不利

当然允许看文档。

要知道，随便哪个类库，都有无数的类和方法，每个方法又有若干参数，鬼知道它们都是什么意思，谁的脑子能记得那么多内容。别说是人家提供的类库，就是自己写的代码，过一段时间也不记得什么意思了。没有注释和文档，怎么看懂代码？

如果没有需求分析文档，程序员怎么理解正在开发的这个软件的基本业务流程？

如果没有架构设计文档，程序员怎么理解软件各个功能模块之间的功能与业务逻辑？

如果没有接口文档，那么多类和方法，都怎么调用，会返回什么值，难道靠猜？

……

在日常开发工作中，不仅允许看文档，还会强迫你写文档。如果你写的文档别人看不懂，别怪领导骂你不认真。文档对于软件开发的重要性是不言而喻的。

还有一个秘密告诉你，那些经常写文档的程序员，要比不写文档的程序员工资更高。

真的！！！

迎娶白富美，从会写文档开始！

这个问题要根据具体开发的功能模块来看，不过原则来说，花大量的时间看说明文档，至少给人的印象是经验不够丰富，开发能力有待提高。

具体来说，如果是普通的功能开发，技术挑战不大，这种如果还要看文档，会被认为是开发能力问题。如果是有一定的技术挑战，公司在这方面的积累比较少，开发团队也对此有共识，这种问题看文档无可厚非，当然如果能业余时间学习相关的知识，会给团队留下开发能力强的印象。对于一些前瞻性研究，公司没有任何技术积累，或者全新的技术方向，这个看说明文档是加分的，甚至可以要求公司购买相关书籍或者在线培训，当然，自己啃下来会更NB。

3. 怎样做一名高效率程序员

很多人问我，你怎么效率那么高，工作很忙，又要带娃，还写博客，还有时间运动。今天就写写这个话题：程序员如何提高工作效率
保持高工作效率，我觉得主要有一下4个方面，希望能对大家有帮助。
集中目标
工作列表
不论是开发还是设计，还是其他职业，工作列表都很重要，工作目标很明确。工作的时候才能格外专注，才不会走神。
用自己最熟悉的工具（我用Evernote），把待办工作列表（今天要做什么）记录下来，很重要的一点是记录分解后的小目标（分解任务也是一个很重要的能力）。同时也保持工作中产生的新的问题（任务），经常性地调整当前工作任务列表，根据重要性对这些任务进行划分，经常想着那些最重要的问题。
专注目标
专注目标不是那么容易做到的，需要学会分离与当前无关的任务/问题，工作中经常会碰到的问题可以首先寻找简单可用可靠的方案，并将心中的疑虑记录下来，集中成一个列表，工作之外翻翻书，系统思考和学习，而不会因为这个问题而叉开思路对相关的内容研究一番。总之，专注当前的任务，把新问题记录下来，回头再专心攻克。
学会避繁就简，在基本功的增强后，会发现很多问题可以简单阅读或查找文档，或浏览问题相关的库的源码解决；
学会简化问题
无论是在广义的工作方法/工作态度上，还是在针对具体问题上，很重要的一个个人能力就是化繁为简了。化繁为简是所有工作方法/软件设计的核心。将那些可以砍掉的工作砍掉，做到尽可能地简单。
从工作方法和态度上来讲，真正需要去做的工作才值得去做，大力砍掉那些不应该在当前工作中处理的事情。例如不必要的优化，不必要的扩展性，不必要的性能，不必要的功能，可以不要的技术，不必要的流程，不必要的文档，统统砍掉，一切可以没有的全都不能有。
工作中也可能遇到非关键的难题，通常绕过它们，使用更简单的方案就是了。纠缠于这些不重要的难题，最容易浪费时间。
从设计/实现来讲，最好的方案就是最简单直接、一眼就能看懂的方案。而且通常最简单直接的方式，通常性能也最好。
基本功
基本功的内容十分复杂。
第一项基本功是对整个计算机体系的理解，对操作系统/虚拟机/数据库本质的理解，对语言基础类和库的理解，这些是核心基本功。
第二项基本功是学习能力。通过快速阅读核心文档理解核心思想，然后其他的东西总是能从文档中查到就行。细枝末节的东西，即学即用，学过就忘可也。
第三项基本功是文档、代码、资料的搜索和收集，技术问题建议大家用Google搜索，有意识的整理出自己的代码库。
工具
选择工具核心标准，就是简单朴素可信赖，如果一个工具出几次诡异现象，那就干脆丢掉它。
熟悉工具，实际上我们工作中，就是和各种各样工具打交道，各种IDE，编辑器，版本管理工具，命令行终端，TODO工具等等。要想在工作中如行云流水，一定要熟悉工具，包括工具快捷键，命令，原理等等。
写自己工具，很多时候，我们需要重复的做一件事情，当你做第2遍，第3遍的时候，就应该想一想，能不能自动化，很多简单的几句shell就可以搞定，麻烦的一点的，可以先记录下来。比如，我就写了非常多的脚本：一个命令反编译APK并查看源码、提取当前版本号打git tag并提交等等。很多时候几分钟到几十分钟的事情可以压缩到几秒钟完成，也避免了对工作的打断。

4. 如何写一份易用的产品需求文档

产品需求文档分很多种，这里我只说一种让程序员看起来舒服的需求文档格式吧：

作为程序员，在需求文档当中，最关注的内容是哪几种呢？
1、流程：包括业务流程和基本流程；
2、数据：包括输入数据和展示数据；
3、事件流：特别是分支事件流和例外事件流，感觉很多需求文档中，缺少了这部分；

那么，文档的模板是怎么样的呢？
1、需求说明：主要阐述为什么要做这个需求；
2、业务流程：最好使用VISIO来绘制，画出整个业务的流程图，特别是其中所要涉及的判定，分支等，都要画出来，越详细越好；
3、基本流程：继续使用VISIO，画出基本流程即可，一般来说都是业务流程中的最主要部分，但是可以加入更多的细节；
4、分支事件流：VISIO，各种分支事件的详细流程，越详细越好；
5、例外事件流：这里要使用表格，示例如下：主要是系统判定和对应的提示；6、输入数据：用户可以输入数据的字段，已经相应的定义，包括是否必填，字段长度，录入方式，对应规则等；
7、显示数据：页面显示给用户的数据，对应的字段，取数规则，对应规则等;
8、补充说明；这个需求文档模板，更倾向于传统的软件模板，而不是网络上比较流行的AXURE文档。

5. 作为一名程序员，你真的理解需求吗

作为一个程序员，最重要的职责就是： 按时保质保量地完成需求开发。

像开发新业务这样的复杂需求， PM （Proct Manager，产品经理） 一般会写出详细的 PRD （Proct Requirement Document，产品需求文档） ，甚至可能会制作高保真原型。

而像调换两个按钮顺序这样的简单需求，PM有可能只会口头通知一下，最多在JIRA之类的项目管理平台上创建一条只有标题的ISSUE。

如果是有和用户交互的需求，负责设计的部门或人员一般会提供设计图。专业一点的话还会帮你把图都裁好，并准备不同屏幕分辨率下使用的多个尺寸版本。

当然，如果你在一个刚刚成立的创业公司，很有可能是创始人在白板前（或者是饭桌上）讲了半个小时，然后就问你：“需要多长时间把它做出来？”

不管提出需求的是PM还是创始人，他们的脑海中一定为这个需求设想好了一个自洽的逻辑和形态。PRD也好，口头宣讲也罢，都是在描述这个逻辑和形态。他们提出需求，就是希望程序员能够最大程度地还原他们的设想。

说起来简单，做起来难。 我们可以通过一个小实验来揭示这一点。

首先，你需要找一张长方形的纸。如果你在办公室，那就找一张A4纸；如果你在家，那就找一张纸巾。然后按照下面的步骤进行操作：

你的作品是什么样子？中间开洞了吗？边上呢？角上呢？如果再做一次，你能完成同样的作品吗？

你可以拿着同样的纸去找你的家人、同事或朋友，请他们来完成同样的操作。在你不施加影响的前提下，他们完成的作品极有可能和你截然不同。

为什么会这样呢？

如果你仔细观察他们操作的过程，就会发现：

由于每次对折都会可能产生两种不同结果，在撕第一个角时纸的朝向有四种可能性，旋转180度时有两种可能。所以仅仅两个撕角的位置，就至少有 2 x 2 x 4 x 2 = 32 种不同的可能性。

就这样，我们还没有考虑撕角的大小、角度的区别，还有极少数人是会沿对角线对折的……

上面撕纸的需求，其实是我自己拿了张纸随意摆弄，然后记录下来的操作流程。我照着这个流程，可以十分轻松地做出完全相同的作品。但是如果让别人来做，结果就完全不一样。其原因就是，我在完成作品的过程中，不光是按照流程进行操作，还隐含了自己的一些小习惯，却并没有把这些细节记录下来。

如果把所有细节都完整地记录下来的话，需求应该是这样的：

同样，PM在写PRD时，很有可能会漏掉一些自己认为应该是“常识”，无需再进一步说明的内容。比如“把一张纸对折”，我们很容易想当然地认为，应该是沿着长边对折，但事实上并非所有人都是这么理解“对折”的。

由于每个人的成长经历不同，其认知结构之间必然存在差异，因此对同一概念未必持有相同的理解。 你所认为的“常识”，我可能并不知道，或者拥有和你截然不同的理解。所以程序员在看PRD时，一定要把自己对需求的理解复述出来，跟PM确定是不是这么回事。否则就容易出现开发中、提测甚至上线后发现逻辑性错误，需要紧急修复甚至返工的情况。

此外， 很多问题在设想阶段是发现不了的，只有到了具体实施时才会暴露出来。 PRD不可能真正做到完备，也不能保证没有错误和遗漏。比如一个表单需求，很可能在做的过程中发现某个非法数据case是PRD里没考虑到的，这时的用户交互怎么做？文案怎么定？这都要和PM沟通来解决，而不能自己拍脑门决定。

PRD只是需求的一个快照性描述文档，并不是需求本身。 程序员应该对需求负责，而不是对文档负责。 只有和PM保持沟通，不断地细化需求，才能让需求真正落地。当发现PRD里有不合理或者有疑问的地方时，一定要提出来让PM进行解释。千万别视若无睹，甚至干脆将错就错，等着看PM笑话。

如果我们拿到了一份图文并茂、十分详尽的PRD，是不是应该马上照着文档开工呢？那可不一定。

一位优秀的程序员，应该在开工之前把下面这些问题想清楚：

程序员有责任对需求方案进行review，并协助PM改进设计。 要知道，PM一般不会从技术角度对需求进行考虑，所以往往提出的并非最优方案。有时只要做一点点调整，技术实现的难度就会大大降低，却不影响目标的达成效果。

比如某个业务需要用到日期选择器组件，PM为此专门设计了一个，而你知道系统中某个功能页面里有现成可用的同类组件。这时就应该和PM沟通是否可以直接复用，或者在原有组件的基础上进行功能扩展。这样既节省了开发资源，又保持了用户体验的一致。

程序员要对整个产品的可用性负责，全面评估需求可能导致的不良影响，谨慎对待有破坏性的需求。 PM由于不了解系统的底层实现和实际数据的组织方式，所以很可能无法全面地评估需求的影响面。如果程序员忽视在这方面的思考，只是机械地按部就班地执行方案，就很可能导致严重的线上事故。

比如要对某数据进行批量修改，在做的过程中时发现该数据有多个业务正在使用。这时就应该必须停下来和PM沟通，因为PM可能只了解自己负责的那一块业务，不知道修改可能会对其他业务产生影响。此类需求要和相关各方沟通协商，确认修改没有不良影响后才能继续。

程序员要有魄力去拒绝那些明显不靠谱的需求。 有的时候，PM提出需求的动机不是为用户创造更多的价值或提升用户体验，而是为了冲绩效完成自己的KPI。为此拆东墙补西墙，从兄弟业务手里抢流量入口；甚至杀鸡取卵，以严重破坏用户体验的方式拉量。遇到这种事，程序员一定要坚持自己的原则，守住自己的底线。

6. 需求分析是什么意思

需求分析就是对客户提出的“要求”或者“需求”进行深入细致地调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么，为系统设计、系统完善和系统维护提供依据。

需求分析是项目计划阶段非常重要的环节，该环节决定了需要“实现什么”，为下一步如何去“实现”提供了明确的方向。

进行需求分析需要做到以下几点：

（一）需求获取：在准备阶段，我们首先要确定需求获取的目标及范围，根据你的目标来选择对应的方式获取需求。

（二）需求分类：一般情况下，我们会根据对象的不同，将需求分为业务需求、用户需求、功能需求等。

（三）需求筛选：有些需求是伪需求，有些需求则不具备实现价值，我们可以通过真实性、价值性、可行性三个维度来筛选需求，过滤掉虚假的、不可行的、没有价值、价值不大或投入产出比不理想的需求。

（四）需求提炼：对剩下的需求进行提炼，目的在于从获取的表面需求中提炼出客户的本质需求。找出“为什么要做”比“做什么”更重要。

（五）需求优先级排序：挖掘到客户的真实目的后，我们需要根据不同维度的需求归类方法，如KANO模型分析法、投入产出比ROI等，对其进行归纳整理并排出优先级，帮助产品有条理地安排开发秩序，避免盲目排序。

（六）产出需求文档：通过以上的分析，我们需要将收集到的需求进行分析、汇总、归类，输出产出需求文档，为接下来的工作做好铺垫。

以上是对需求分析的一些理解和思路，做好需求分析工作之后，就可以对可实现的需求进行落地方案的跟进。

7. 北大青鸟java培训：如何快速熟悉项目代码

对JAVA程序员而言，换一份工作或进入一个新的公司，往往意味着要熟悉一个新的开发环境，要快速了解新的项目。
如何快速地熟悉项目代码，是每个程序员都会遇到的问题，特别是对刚进入职场的应届毕业生，这个问题更显得棘手。
下面是我自己在经历几个工作之后结束的一些方法，河南IT培训http://www.kmbdqn.cn/与大家分享一下，仅贡参考！1.通读需求文档，了解项目用途；一个企业级的项目，一定会保留一些相关文档吧！比如需求文档，设计文档，项目计划等，先通读这些文档，了解项目的用途、主要功能等。
2.熟悉开发工具、常用功能；每个公司用的开发环境都会有些不同，要熟悉新的开发环境，了解常用的功能、快捷键等，特别是前后使用习惯相差比较大的开发环境，如从MyEclipse到IntelliJIDEA。
Java的开发环境用的比较多的有MyEclipse(Eclipse)、IntellijIDEA.C++就比较多了，从VC6到VS2008、VS2010、VS2012、VS2013都有人用，还有一些用开源的开发工具如Qt。
3.部署环境，把项目跑起来；了解开发环境后，就把相关的配置部署好，把项目跑起来。
好处是：1.可以进一步实践新的开发环境；2.把项目跑起来后可以快速地了解项目的用途和功能。
4.整体浏览代码，了解代码结构；整体浏览一下代码，对项目的代码有个整体结构的把握。
最好能把类图画出来，可以用一些UML工具(如EA、PowerDesign)的逆向工程把源码导出类图。
5.抽取其中的一部分进行细读；对一个企业级的项目，特别是一些大型项目或积淀比较深厚的项目，不可一下就把所有代码都熟悉。
那就选择其中的一部分，如其中一个小功能，从界面开始，通过debug模式一步一步地跟下去，以点带面地去熟悉整个项目。
6.尝试修改一些程序bug；修改bug是熟悉项目最好的方法。
根据出现的bug，通过debug模式一步步地定位出现问题的位置，再分析出现问题的原因。
当你能够修改bug，并且已经改了好几个bug的时候，就说明你对项目有了一定了解了，基本熟悉这个项目的结构和逻辑了。

8. 要做程序员需要学会什么

要做程序员需要学会什么
程序员的岗位需求很多，例如大型网络公司、软件开发公司等等都需要程序员。
程序员需要学习：
1、掌握数据及其转换、数据的机内表示、算术和逻辑运算，以及相关的应用数学基础知识；
2、理解计算机的组成以及各主要部件的性能指标；
3、掌握操作系统、程序设计语言的基础知识；
4、熟练掌握计算机常用办公软件的基本操作方法；
5、熟练掌握基本数据结构和常用算法；
6、熟练掌握C程序设计语言，以及C++、Java、Visual Basic中的一种程序设计语言；
7、熟悉数据库、网络和多媒体的基础知识；
8、掌握软件工程的基础知识，了解软件过程基本知识、软件开发项目管理的常识；
9、了解常用信息技术标准、安全性，以及有关法律、法规的基本知识；
10、了解信息化、计算机应用的基础知识；
11、正确阅读和理解计算机领域的简单英文资料。
程序员必备技能：
1、熟练开发工具
做为一名程序员至少熟练掌握两到三种开发工具的使用，这是程序员的立身之本，其中C/C++和JAVA是重点推荐的开发工具，C/C++以其高效率和高度的灵活性成为开发工具中的利器，很多系统级的软件还是用C/C++编写。
而JAVA的跨平台和与WEB很好的结合是JAVA的优势所在，而JAVA即其相关的技术集JAVAOne很可能会成为未来的主流开发工具之一。
其次，能掌握一种简便的可视化开发工具，如VB，PowerBuilder，Delphi，CBuilder，则更好，这些开发工具减小了开发难度，并能够强化程序员对象模型的概念。
另外，需要掌握基本的脚本语言，如shell，perl等，至少能读懂这些脚本代码。
2、熟知数据库
作为程序员，他们自然有自己的理由：很多应用程序都是以数据库的数据为中心，而数据库的产品也有不少，其中关系型数据库仍是主流形式，所以程序员至少熟练掌握一两种数据库，对关系型数据库的关键元素要非常清楚，要熟练掌握SQL的基本语法。
虽然很多数据库产品提供了可视化的数据库管理工具，但SQL是基础，是通用的数据库操作方法。如果没有机会接触商业数据库系统，可以使用免费的数据库产品是一个不错的选择，如mySQL，Postgres等。
3、了解操作系统
当前主流的操作系统是Windows，Linux/Unix，熟练地使用这些操作系统是必须的，但只有这些还远远不够。
要想成为一个真正的编程高手，需要深入了解操作系统，了解它的内存管理机制、进程/线程调度、信号、内核对象、系统调用、协议栈实现等。
Linux作为开发源码的操作系统，是一个很好的学习平台，Linux几乎具备了所有现代操作系统的特征。虽然Windows系统的内核实现机制的资料较少，但通过互联网还是能获取不少资料。懂得网络协议TCP/IP。
在互联网如此普及的今天，如果您还没有对互联网的支撑协议TCP/IP协议栈有很好的掌握，就需要迅速补上这一课，网络技术已改变了软件运行的模式。
从最早的客户/服务器结构，到今天的WEBServices，再到未来的网格计算，这一切都离不开以TCP/IP协议栈为基础的网络协议支持，深入掌握TCP/IP协议是非常必要的。
至少，需要了解ISO七层协议模型，IP/UDP/TCP/HTTP等常用协议的原理和三次握手机制。
4、明白DCOM/CORBA/XML/WEBServices存在的意义
随着技术的发展，软件与网络的无缝结合是必然趋势，软件系统的位置无关性是未来计算模式的重要特征之一，DCOM/CORBA是当前两大主流的分布计算的中间平台，DCOM是微软COM（组件对象模型）的扩展，而CORBA是OMG支持的规范。
XML/WebServices重要性不言而喻，XML以其结构化的表示方法和超强的表达能力被喻为互联网上的“世界语”，是分布式计算的基石之一。
5、不要将软件工程与CMM分开
大型软件系统的开发中，工程化的开发控制取代个人英雄主义，成为软件系统成功的保证，一个编程高手并不一定是一个优秀的程序员。
一个优秀的程序员是将出色的编程能力和开发技巧同严格的软件工程思想有机结合，编程只是软件生命周期中的其中一环，优秀的程序员应该掌握软件开发各个阶段的基本技能。
如市场分析，可行性分析，需求分析，结构设计，详细设计，软件测试等。
6、需求理解能力
程序员要能正确理解任务单中描述的需求。在这里要明确一点，程序员不仅仅要注意到软件的功能需求，还应注意软件的性能需求。
要能正确评估自己的模块对整个项目中的影响及潜在的威胁，如果有着两到三年项目经验的熟练程序员对这一点没有体会的话，只能说明他或许是认真工作过，但是没有用心工作。
7、模块化思维能力
作为一个优秀的程序员，他的思想不能局限在当前的工作任务里面，要想想看自己写的模块是否可以脱离当前系统存在，通过简单的封装在其他系统中或其他模块中直接使用。
这样做可以使代码能重复利用，减少重复的劳动，也能使系统结构越趋合理。模块化思维能力的提高是一个程序员的技术水平提高的一项重要指标。
就业方向：
1、网络开发
现在网络已经成为世界通讯的一座桥梁，好像Javascript、PHP、Ruby这几类开发语言大部分是用作网络开发方面。
2、企业软件开发
JAVA、C#、VB这几类开发语言都实现了面向对象开发的目标，更多时候用于企业系统的开发。
3、系统软件
C语言、C++、Object-C这些软件更多是用在系统软件开发，嵌入式开发的方面。
当然，这分类不是绝对，像JAVA、C#、VB很多时候也用于动态网站的开发。在很开发项目都会使用集成开发的方式，同一个项目里面使用多种开发语言，各展所长，同步开发。

9. 要做程序员需要学会什么

其实简单来说，程序员的工作就是使用编程语言，根据需求写出一个程序。
但是，在这个过程中，涉及如下几个方面：

使用的编程语言 程序员需要选择一门或者多门语言来编程，不同的语言适合编写不同的程序，目前主流编程语言包括，Java、JavaScript、Python、C++、php以及其他小语种等等，每种编程语言适合开发的程序有所不同。目前从程序应用分来，主要可以分为三类a 企业应用，主要用于解决企业业务。各种企业管理后台系统，银行系统，公安系统，图书管理系统等等。
b 互联网应用，面向互联网用户，为互联网用户提供各类服务。比如现在的京东淘宝各类电商系统等。
c 移动应用，各类在移动端使用的APP，有面向互联网用户的APP，也有面向企业内部的APP。
目前相对而言，在移动应用和互联网应用方面，资本投入比较热的风口，程序员的薪资较高。企业应用，发展了很多年，相对平稳。

2. 明白需求，实现需求
需求就是编写程序的要求。一个程序要编写成什么样子，具备哪些功能，都是由需求来具体说明。程序员要需要能看懂需求文档，并且能准确地使用编程语言，根据需求中的要求来编写成程序。企业开发的项目，往往会由该程序的架构师提供一个程序框架，程序员在该框架的规范下进行编程，实现需求的功能，以确保程序的规范、可读，以及可维护性。

3. 日常工作写程序
一个软件开发一般流程是产品经理根据用户需求做一个项目出来，然后UI设计师做一些图片设计，前端开发编写页面，后台开发编写核心编程，然后介入一些大数据和人工智能，通过测试之类上线实施，后期还有运维进行相关维护。
程序员一般大多指的是前端和后台写代码程序的开发人员，除了编写代码，可能还需要通过接口和其它系统对接，实现系统间的数据交换。像单体测试，是程序员对自己写好的程序单元进行测试，检测这个程序单元数据输入和数据输出是否符合预期等等。测试出来的问题，需要修改正确，然后再测试，直至没有问题。和同事共同开发的时候也需要联合测试，以及用户测试过后如果存在BUG继续进行修改。