对于人力资源管理者来说，职位（JOB）、岗位（POSITION）和角色（ROLE）几个概念往往混淆，其一是中文翻译的过程中，没有统一的标准，从而导致几个概念混淆，其二是对概念的含义的误解，希望通过本文的澄清，能对您认识这三者的关系有所裨益。
1、 首先来澄清三者的译文：
（1）JOB，有的文献和书籍译为“职务”、有的译为“岗位”，有的译为“职位”，在本文中统一译为“职位”。
（2）POSITION，有的文献和书籍译为“职位”，有的译为“岗位”，在本文中统一译为“岗位”。
（3）ROLE，一般被译为“角色”。
可以看出，由于翻译的原因，虽然看起来中文的名称一致，但实际应为含义就有差异了。
2、澄清三者的含义：
（1）职位是按规定担任的工作或为实现某一目的而从事的明确的工作行为，由一组主要职责相似的岗位所组成。职位在任何时候都应根据组织机构的目标和流程而设置，不能因人来设置职位，也不能因任职者调离而舍弃该职位，它是组织机构的基本单位。
（2）岗位是组织要求个体完成的一项或多项责任以及为此赋予个体的权力的总和。一份职位一般是将某些任务、职责和责任组为一体而成；而一个岗位则是指由一个人来从事的工作。
（3）“角色”一词的源于戏剧，自1934年米德（G.H.Mead）首先运用角色的概念来说明个体在社会舞台上的身份及其行以后，角色的概念被广泛应用于社会学与心理学的研究中。社会学对角色的定义是“与社会地位相一致的社会限度的特征和期望的集合体”。在企业管理中，组织对不同的员工有不同的期待和要求，就是企业中员工的角色。这种角色不是固定的，会随着企业的发展和企业管理的需要而不断变化，比如在项目管理中，某些项目成员可能是原职能部门的领导者，在项目团队中可能角色会变为服务者。角色是一个抽象的概念，不是具体的个人，它本质上反映一种社会关系，具体的个人是一定角色的扮演者。
3、三者关系探讨：
（1） 职位和岗位的关系
岗位与人对应，只能由一个人担任，一个或若干个岗位的共性体现就是职位，即职位可以由一个或多个岗位组成。比如：制造型企业的生产部门的操作员是一个职位，这个职位有很多的岗位的员工担任，如果具体到某个工序的，就是岗位了，比如钻孔操作员，操作员的职位可能有钻孔操作员、层压操作员、丝印操作员等等岗位组成。对于组织而言，岗位和职位的演变是随着组织的不断扩大而不断产生的。其演变过程和逻辑关系如下：
要素（pactor）--活动（activity）--任务（tast）--职责（duty）--岗位（position）--职位（job）
（2） 角色和职位、岗位的关系
角色可以由不同的职位和岗位担任，比如管理者角色，可以由某个职能部门的经理，也可以由某个能力达到了角色的要求的非管理职位的员工担任。最常见的就是在项目管理中的不同角色。比如：就上个例子中的钻孔操作员可能在某个工序改善项目组中扮演项目成员的角色。
从上面可以看出三者是有联系和区别的，在人力资源管理中，对三者的区分尤显必要，因为，这三者是人力资源管理中最基础的部分。对于人力资源管理者而言，职位、岗位和角色的综合表现形式就是相应的职位说明书、岗位说明书和角色说明书。前两种说明书大家已经不陌生了，而角色说明书将在未来组织形式中的显得越来越重要，尤其对于知识密集型企业来说，直线职能型的组织结构的弊端将导致企业越来越多的采用矩阵式的组织结构，对于这种组织结构而言，原有的职位说明书和岗位说明书已经不能起到有效的管理作用了，需要设计相应的角色说明书来对矩阵中的角色活动进行规范和明确。就好像给戏剧中演员的剧本一样，告诉演员如何扮演该角色。不同的演员看了剧本都可以很快就进入角色。对企业管理也是如此，角色说明书可以使员工更好的完成组织的期待和要求。
来源：http://bbs.21manager.com/dispbbs-201203-1.html
也许有多少专业Java程序员，就有多少种对于编写优良Java代码的答案！
以下可能是大多数专业Java程序员都赞同、也愿意执行的八点规则：
1) 保持类最小
还有什么比拥有较少的类更坏的事情吗？可能不会再有了。当然，最好还是有满足自己需要的类。
一般来说，一个带有大量方法的类总是具有一些不属于这里的方法，因为这个庞大的对象所做的事情太多了。如果您有一个带有 100 个方法的对象，就应该好好想想，这个对象是否应该拆成多个对象。大类通常在大学里大行其道。Java 代码与之一样。
2) 保持方法最小
小方法就与小类一样可取，并且原因也类似。
很多有经验的 OO 程序员对 Java 语言具有的苦恼之一就是，它提供大量的 OO 能力，但是却没有教他们如何做好 OO。换句话说，它给了他们很多绳子去捆绑自己（尽管至少没有 C++ 给他们的多）。能看到这一点的一个常见地方是 main() 方法离得很远的类，或者一个单个的名叫 doIt() 的方法。仅仅因为能够 将所有的代码放在类中的单个方法中，并不意味着就应该 如此。Java 语言比很多其他 OO 语言具有更多的语法糖，所以一定的罗嗦是必要的，但是不要过了度。
思考一下这些超长的方法。滚动十屏代码去了解代码所做的工作是很艰难的。该方法做什么工作？您需要泡上一杯大大的咖啡花几个小时去研究才能知道。一个小的，甚至微小的方法是一个容易看懂的代码块。运行时效率不是要具有小方法的原因，可读性才是真正的目标。这将使得代码更加容易维护，并且在需要添加功能时更加容易更改。
将每个方法局限于执行一项工作。
3) 给方法取好名称
本要求很简单，只需要花上一点时间想出一个具有描述性的方法名，足够明了但不过长。
这一技巧很简单，也许在小规模的代码行中是微不足道的，但是当代码变得越来越复杂时，它就会显露出惊人的威力。
4) 保持类的数量最少
XP 中关于简单设计的其中一个指导方针是，用尽可能少的类完成一个目标。如果您需要另一个类，尽管添加就是了。如果另一个类将使得代码更简单或者简化您的意图表达，那么就添加这个类吧。但是没有理由只是为了具有而具有类。当然，通常项目早期比结束时具有的类要少，但是一般将代码重构成更多的类比组合类更容易。如果您有一个具有大量方法的类，那么分析一下，看是否有另一个对象陷入在其中，正在等待出去。如果有的话，就创建一个新的对象。
在我经历的几乎所有 Java 项目上，没有人害怕创建类，但是我们也总是试图在不降低意图清晰度的情况下，减少类的数量。
5) 保持注释的数据最少
我过去常常在代码中编写很多的注释，读起来就像一本书。后来我变得聪明一些了。
每一个计算机科学程序、每一本编程书籍和我知道的很多程序员，都要您给代码编写注释。在有些情况下，注释是有帮助的。在许多情况下，注释使得代码维护更加困难。想想您更改代码时必须做什么。有注释吗？如果有的话，您最好更改注释，否则它会可怕地过期，甚至随着时间的推移，根本就不再能够描述代码。依我的经验，几乎会使维护时间加倍。
我的经验法则是：如果代码太难阅读和理解而需要注释，我就需要使它足够清晰，从而不需要注释。代码可能会太长，或者做太多的事情。如果这样的话，我就简化它。代码可能太隐晦。如果这样的话，我就添加助手方法，使之清晰。实际上，在与同一团队的其他成员一起进行 Java 编程的三年当中，我所编写的注释屈指可数。保持代码清晰！如果您需要系统或者某个特定组件的全景描述，就编写一个简短的注释来描述。
罗嗦的注释一般比较难维护，通常不及一个小的、编写良好的方法那么好地表达意图，并且很快就会过期。根本不要过分依赖注释。
6) 使用一致的风格
编码风格实际上是您的环境中必然的并且可接受的东西。我甚至不知道哪一种风格可以称为“典型的”。这通常是个人品味问题。
有时候，对于同一段代码，可能有好几种排列方法，实际上没有绝对的“对”与“错”。实际项目过程中，应该进行协商，挑选出一种来，然后一直坚持用这一种。惟一绝对的风格规则是一致性。如果一个项目上的每个人都用不同的风格，那么阅读代码将变得很困难。挑选一种风格并且不要改变。
7) 避免switch
一些 Java 程序员对 switch 语句情有独钟。我曾经认为它们很好，但是后来我认识到了，一个 switch 实际上就是几个 if，并且通常意味着条件逻辑出现在代码中的多个地方。这是代码重复，是应该禁忌的。为什么？因为在多处具有相同的代码使得代码比较难更改。如果我在三处具有相同的 switch，并且想要更改对某个 case 的处理，我就得在三处更改代码。
现在，如果您可以重构具有单个 switch 语句的代码，那会怎么样呢？很好！我不相信使用它有什么坏处。在有些情况下，它比嵌套的 if 更清晰。但是如果您看到它出现在很多地方，就有了应该解决的问题了。防止这一问题的一个容易的方法是，避免 switch，除非它对于该工作是最佳的工具。依我的经验，它很少是最佳的。
8) 是public的
我把最具争议的建议放在最后。做一下深呼吸。
我相信您会反对让所有的方法都是 public 的。实例变量应该是 protected 的。
当然，许多专业程序员会害怕这种想法，因为如果任何东西都是公共的，那么任何人都可以更改它，也许会以未授权的方式更改。在任何东西都是公共可访问的世界中，您就不得不依赖于程序员纪律，以确保人们在其不应该访问时不会访问其不应该访问的东西。但是在编程生活当中，很少有什么事情比想要访问一个不可见的变量或方法更受挫的了。如果您对代码中您设想其他人不应该访问的东西限制访问，您就是在设想自己无所不知。这在大多数时候是一个危险的假设。
当使用其他人的代码时，这种受挫感会经常出现。您会看到一个方法刚好做您想要做的工作，但是它不是公共可访问的。有时，这有一个很好的原因，并且使得限制可访问性有意义。但是有时，不 public 的惟一原因是，编写代码的人这样想“没有人需要访问该代码”，或者他们这样想“没有人应该访问该代码，因为……”，于是他们并没有很好的理由。许多时候，人们使用 private 是因为它可用。不要这样做。
使方法是 public 的，变量是 protected 的，直到您有一个很好的理由限制访问。
现在您知道了如何创建优良的 Java 代码，以及如何保持它优良。
关于该主题，业界最好的书籍是 Martin Fowler 编著的 Refactoring（参见 参考资料 中的链接）。它读起来甚至很有趣。重构（refactoring） 的意思是在不改变代码结果的情况下，更改现有代码的设计。Fowler 谈论了请求重构的“代码气味”，并且详细介绍了用于改变“代码气味”的各种技巧（或者“重构”）。依我的观点，重构和编写一次通过测试的代码的能力（参阅 参考资料）是新手程序员要学习的最重要的技能。如果每个人都擅长于这两点，那将彻底改变行业当前的局面。如果您 擅长于这两点，就会比较容易找到工作，因为您能比其他人产生更好的结果。
编写 Java 代码相当简单。编写优良的 Java 代码则是一门手艺。倾力成为一个手艺人。