如何跟上技术变化的步伐
迭代和增量式学习.每天计划用一段时间来学习新技术,无需长时间,但要频繁.记下需要学习的东西—听到不熟悉的术语或者短语时,记录下来,在计划时间中去学习
了解最新行情. 社区讨论,技术博客,查看顶尖博客作者们正在关注什么.
参加本地的用户组活动, 各种技术在很多地区都会有相关的讲座
参加研讨会议,
如饥似渴地阅读,软件开发和非技术主题的书,专业的期刊和商业杂志,大众媒体新闻
- 你不可能精通每一项技术,没有必要去做这样的尝试.只要你在某些方面成为专家,就能使用相同的方法,很容易成为新领域的专家.
- 你要正确把握自己投入的精力.
- 为什么要这项新技术,解决什么问题,可以用在什么地方.
- 在每天结束的时候,测试代码,提交代码,没有残留代码.
- 记录客户做出的决定,并注明原因.
- 不要随意假设低级别的问题不会影响他们的业务.如果能影响他们的业务，就是有价值的问题。
如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。
—- 约翰.冯诺依曼
- 不需要开发你能下载到的东西
- 如果你发现自己在做一些花里胡哨的东西(比如从头创建自己的框架)，那就醒醒吧，闻闻烟味有多大，马上该起火了。你的代码写得越少，需要维护的东西就越少。
- 每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或者语言，一定要清楚它的利弊。
- 任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。代码要处于可用状态，警惕每一次改动。
防止提交可能会破坏系统的代码：
- 在本地运行测试。代码可以编译，可以通过所有的单元测试，确保系统中其他测试都可以通过。
- 检出最新的代码。在提交之前先拉取最新的代码，避免代码冲突。
- 提交代码。
每一改动应该可以进行持续集成，通过所有的测试用例。
- 绝不要做大爆炸式的集成。提早集成，频繁集成。
- 编程之前，先写测试。
- 任何一个设计都可以被改进
- 每一个抱怨的背后都隐藏了一个事实，找出真相，修复真正的问题。
- PIE原则，代码必须明确说出你的意图，而且必须富有表达力。代码应意图清晰，表达明确。
- 应该让自己或团队的其他任何人，可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制。
- 在代码可以传递意图的地方不要使用注释
- 解释代码做了什么的注释用处不那么大。相反 ，注释要说明为什么这样写代码。
- 在很短的编辑/构建/测试循环中编写代码。这要比话费长时间仅仅做编写代码的工作要好得多。可以创建更加清晰、简单、易于维护的代码。
- 简单不是简陋
- 优雅的代码第一眼看上去，就知道它的用处，而且很简洁。
- 开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式，原则和高难度技术之类的东西。
- 当你觉得所编写的代码中没有一行是多余的，并且仍能交付全部的功能时，这种感觉就对了。这样的代码容易理解和改正。
- 将命令与查询分离开来，命令可能会改变对象的状态，而且有可能返回一些有用的值。一个查询仅仅提供给开发人员对象的状态，并不会对其外部的可见状态修改。
- 绝对不能允许一个看起来无辜的”查询”去修改对象的状态。
- Liskov替换原则：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。
- 当使用继承时，要想想派生类是否可以替换基类。如果答案是不能，就要问问自己为什么要使用继承。如果只是想要重用基类的代码，可以使用聚合，通过聚合，将责任委托给聚合的对象。
- 保存曾遇到的问题以及对应的解决方案的日志，日志格式，这些日志可以用关键字进行搜索。
- 问题发生的时间
- 问题简述
- 解决方案描述
- 引用文章或网址，已提供更多细节或相关信息
- 任何代码片段、设置或对话框的截屏。
- 对问题各个击破。在解决问题时，要将问题域与其周边隔离开，特别在大型应用中。
- 要传播不能处理的异常。
- 程序员在拒绝设计的同时，也就放弃了思考。
- 代码检查列表
- 代码能否被读懂和理解？
- 是否有任何明显的错误？
- 代码是否会对应用的其他部分产生不良影响？
- 是否存在重复的代码
- 是否存在可以改进或重构的部分？