Appearance
专业主义
责任和义务
“专业主义”不但象征着荣誉和骄傲，而且明确意味着责任和义务。这两者之间有着紧密的关系，因为你无法负责的事情上不可能获得荣誉与骄傲。
做个非专业人士可轻松多了。非专业人士不需要为自己所做的工作负责，他们大可把责任推给雇主。如果非专业人士搞砸了，最后收拾摊子往往是雇主；而专业人士如果犯了错误，只好自己收拾残局。
🌰
一次对客户推出了新版本，主要是修复了几个故障，还增加了客户要求的新功能。之前承诺在截止日期之前提供那项新功能，我连夜赶工，总算在约定日期交付了。
2 天后我接到的现场服务经理 Tom 的电话，说程序已经有客户投诉例行程序没有执行成功，他们没有收到任何报告。收不到报告问题可大了，工作人员一会无事可忙但随后又要超负荷的工作，并且有客户可能发现故障并投诉。
我不由得心头一沉：为了按时交付，我没有测试例行程序。测试了系统的其他大部分功能，但是测试例行程序需要耗费好几个小时，而当时又必须交付。因为修复故障的部分都不涉及例行程序的编码，所以我也没担心有什么不妥。
我给 Tom 打电话，可以复现问题。他问我什么时候可以解决问题？我说没有把握，但是正在努力。同时告诉他建议用户倒回去使用旧版本。Tom 发火了，对客户来说无疑个双重打击，不仅为此丢了一晚上数据，而且无法使用事先承诺的功能。
故障排除很苦难，并且每次测试都需要几个几个小时，Tom 没隔几个小时就打电话问什么时候可以解决，问题解决的时候已经过去几天了。Tom 之后平静下来没再提这个事情，不过我老板过来跟我说：“你最好别再犯同样的错误”。
经过反省，意识到没有对例行程序进行的是就交付是不负责的。为了如期交付，我忽略了测试的环节。整个过程都只考虑保全自己的颜面（我要按时完成），却没有顾及客户和雇主的声誉。我本应该早点儿承担责任，告诉 Tom 测试还未完成、自己不能按时交付。这么做绝非易事，Tom 一定会不高兴，但是客户不会因此丢数据，客服经理也不会打电话轰炸。
首先，不行损害之事
那么，我们应该怎样承担责任呢？作为一个开发人员，的确，我们的首要职责和目标不应该是尽其所能行有益之事吗？在此之前，我们先探讨一下如何避免破坏软件的功能和架构。
要专业就不能留下 bug
“等等！”你肯定会说，“那是不可能的呀，软件开发太复杂了，怎么可能没有 bug 呢！”
当然你说的没错，但是这并不是我们可以开脱的理由，我们需要对自己的不完美负责。所谓的专业人士就是对自己犯下的错误负责的人，哪怕这些错误实际上在所难免。我们需要先学会道歉，这是必要的但是还不足够，不能一而再再而三的犯同样的错误，我们的失误率应该逐渐减少。
- 让 QA 找不出 bug
发布软件时，应该确保 QA 找不出问题。故意发送有缺陷的代码时很不负责的！哪些代码容易有缺陷？就是那些你没有把握的代码！有些家伙会把 QA 当作啄木鸟，没有检查过自己的代码就提测了等 QA 找出 bug 再处理。且不这样会增加成本，这本身就是不专业的。
QA 会发现 bug 吗？可能会吧，所以准备好道歉吧，然后反思那些 bug 是怎么逃过你的注意的，想办法防止它再次出现。
- 要确信代码正常运行，测试它
你怎么知道代码能否正常运行呢？很简单，测试！一遍遍的测
你可能会担心测试会占用很多时间，毕竟你需要赶进度，如果不停测试，就没有时间写代码了。言之有理，所以需要实行自动化测试。写一些随时都能运行的单元测试，然后尽可能多地执行这些测试。
这不是在建议进行百分百的覆盖，而是在要求！你写的代码就是想执行它，如果你希望代码可以执行，那你就该知道它是否可行。而想知道是否可行，就一定对它进行测试！
设计易于测试的代码，可以在开发前先写好测试，这一方法就是测试驱动开发（TDD）
- 自动化 QA
即是执行单元测试和验收测试。作为开发人员，你需要有个相对便捷可靠的机制，以此判断所写的代码可否正常运行，而且不会干扰系统的其他功能。
不要破坏结构
不要为了新功能而破坏结构，结构良好的代码更灵活。软件项目的根本知道原则，软件要易于修改。简而言之，你必须能让修改不必花太高代价就可以完成。
不幸的是，已经有些项目应糟糕的接口而深陷泥潭。那些本来需要几天就能完成的任务变成了几周，而为了加快进度，会招聘更多的开发人员来开发，但这样容易会进一步破坏结构。
如果创建灵活可维护的代码的设计原则和模式已经有很多了，但是其中一条是在没几个软件程序员会认真去做，那就是，如果你希望自己的软件灵活可变，那就应该时常修改它！
想证明软件易于修改，唯一的办法就是做些实际的修改。如果发现这些改动并不像你预想的那么简单，那就应该改进设计，使后续修改简单。
我们可以随时关注代码的维护性！开发的时候、每次读代码的时候...。这里有一个规则：对每个模块，没检入一次代码，就要让它比上次检出时变得更加简洁。
让软件保持不变时很危险，如果一直不重构代码，等到不得不重构的时候，代码已经僵化了！而为什么大部分开发人员不敢不断修改他的代码？因为他们怕破坏代码！为什么会担心呢？因为他们没有测试！
所以话题又会回到测试上了！如果我们有一套覆盖全部代码的自动化测试，这套测试可以随时快速执行，那我们根本不用害怕！
职业发展
职业发展是你自己的事。
雇主没有义务确保你能再职场能够立于不败之地。有些雇主愿意为员工购买各种书籍或举行各种培训和会议，这样挺不错，这说明雇主待你不薄，但千万不要认为这些雇主该做的。另外，雇主也没有义务给你留时间给你学习。
雇主除了钱，你就必须付出时间和精力。为了说明为你，以每周工作 40 小时的标准来参照。这 40 小时应该用来解决雇主的问题而不是你的问题。
你应该计划每周工作 60 个小时，前 40 个小时给雇主，后 20 小时给自己，也就是大约每天 3 小时。你应该看书、练习、学习，或者做其他能提升职业能力的事情。
这不是说要占用你的业余时间，而是指每周增加 20 小时，如果你每天午饭时间看看书，通勤路上听听播客，花时间学一门新语言，那你兼顾到了。
或许你不愿这么勤勉。没问题，只是那样的话你就不能自视为专业人士。因为所谓的“术业有专攻”是需要投入时间去追求的。
当然有时候这 20 个小时有时候和工作并不矛盾，有时你为雇主做的工作对你个人的职业发展受益匪浅，这种情况下，在这个 20 个小时里为雇主工作也是合理的。
或许你觉得这样会让人精力枯竭。恰恰相反，假设你是因为热爱而成为软件开发者，渴望成为专业人士的动力也正是对软件的热情，那么在这 20 小时里应该做能够激发、强化你热情的事情，它应该充满热情！
了解你的领域
近 50 年来，各种观点、实践、技术、工具和术语层出不穷，你对这些了解多少呢？想成为一名专业开发者，就得对其中相当大部分有所了解，而且要不断扩展这一知识面。
这些改变说多也多，说少也少。旧见解过时这种说法是不对的。“不能铭记过去的人，注定要重蹈覆辙”。下面是一些每个专业人士必须精通的实现：
- 设计模式。必须能够描述全部 24 中模式，同时有想过的实践经验
- 设计原则。必须了解 SOLID 原则，而且要深入了解组件的设计原则
- 方法。必须掌握看板、结构化分析、结构化设计等
- 实践。必须要掌握测试驱动开发、面向对象设计、结构化编程、持续集成
- 工件。必须了解 UML 图、结构图、流程图
坚持学习
必须坚持学期才不至于落伍。不学习新语言的程序员会遭殃，他们只能眼睁睁看着软件行业一路发展，把自己抛在后面。学不会信规矩和新技术的开发人员更可怜。他们只能日渐沦落的时候看着身边的人越发优秀。
读书、看相关文章、关注博客，参加技术大会，不懂就学不要畏难。
练习
业精于勤。只完成日常工作，不足以成为练习，那只能算执行性质的操作，而不是练习。练习指的是在日常的工作之余专门练习技能，以期提升自我。
合作
学习的第二个最佳方法就是与他人合作。一起编程、学习、设计，这样可以从其他人身上学到很多东西，而且能更短时间完成更高质量的更多工作。当然独处时间也很重要。
辅导
想迅速的掌握某些概念，最好的办法就是与你复杂的指导的同事进行交流。这样，在传授知识的过程中，我们也可以从中受益。
了解业务领域
每个专业的人士都应该有义务了解自己开发的解决方案对应的业务领域。如果编写财务系统，那么你就应该了对财务领域有所了解。
最糟糕、最不专业的做法是，简单按照规格说明来完成编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。相反，你应该对这一领域有所了解，能辨别、质疑规格说明书中的错误。
与雇主/客户保持一致
雇主的问题就是你的问题。你必须弄明白这些问题，并寻求最佳的解决方案。每次开发应该站在雇主的角度来思考问题，确保开发的功能能够满足鼓足的需要。
谦逊
编程是一种创造性活动。专业人士也会犯错误，他不会因为别人犯错误而横加贬损，自己有可能是下一个犯错误的人。如果真的遭遇挫折，最好的办法就是——一笑了之吧！