我最近完成了每个程序员应该知道的97件事 。 坦率地说，我确实浏览了97篇文章，但是所有这一切都是非常有经验的作者对软件开发思想和主题的很好汇编。 非常值得一读。

在讨论的“ 97件事”中，有两个比其他的更加突出，以下是我排名前9位的那些事物。

1.童子军规则–罗伯特·C·马丁（鲍勃叔叔）
“在签入之前，不必使每个模块都完美。与在签出时相比，您只需要使其变得更好一点即可。”

老实说，这并不是我整个职业生涯所遵循的，尽管我当然会尽力改善代码，但我从未在每次签入时都这么做。 但是，我确实认为这是一个很棒的原则，应该成为代码审查过程的一部分。 简单地说：
“就像那样了”
“那可恶的代码已经存在了很多年，我不会去碰它。” “它从未进行过任何测试”

我在公司环境中工作时，应用程序通常会持续4-10年。 如果该过程的一部分总是要使事情变得更好，那么从删除未使用的代码到编写单个额外的单元测试，每一年，每一件事……最终将为很多人节省大量时间和金钱。

2.美丽在于简单–约恩·奥尔姆海姆
“最重要的是，漂亮的代码就是简单的代码。”

多年来，这对我来说尤其重要。 在我职业生涯的早期，尤其是在开始新的尝试时，我会设计一些废话。
它将是：“欢迎进入过度工程学派”，所有内容都将抽象为第n个学位，其中将包含模式的模式，接口上的接口以进行抽象，并提供大量的代码和组件来满足每个“如果”曾经存在，那只有我能理解。 所有这些都会导致非常“花哨”的代码，而我抚摸着我的自我，但付出了什么代价呢？
只有未成年人-一个彻底的噩梦。 我暂时支持几乎所有解决方案的最简单实现，即使它不一定是完美的技术实现。 在寿命长的软件世界中，可维护性通常应该超过其他方面的考虑。

3.后退和自动化，自动化，自动化– Cay Horstmann
我相信要实现一切可能的自动化：构建，部署，代码分析，单元测试，功能测试，集成测试。 实际上，我们谁也不想每天都去看这些东西，而自动化是摆脱这种情况的唯一方法。 不能说足够自动化。 自动化，自动化，自动化。

4.持续学习– Clint Shank
这是一个非常重要的主题，我们处于一个不断成长，变化，转变的行业中，作为一名程序员，您需要在任何可能的地方学习和改进自己。 进入舒适区很容易休息，只要一劳永逸，我做了几年，现在我为此感到遗憾。
我正在努力跟上的事情，并建议：

1. 获取Kindle……然后购买和阅读书籍。
2. 使用Google阅读器为您的特定领域以及您感兴趣的领域之外的夫妇添加流行的博客和网站RSS feed。
3. 创建一个博客，通过将我的代码和想法摆在那里，我比知道自己为自己编写代码/文章要付出更多的努力。 我还强迫自己每周做1-2个帖子，以确保我必须始终找到新内容来学习。
4. 加入开源社区，我们通常在公司环境中做不到足够的“技术”开发。

5.在指责他人之前先检查您的代码–艾伦·凯利（Allan Kelly）
就像标题中所说的一样，我们所有人都希望将责任归咎于“完美”代码以外的任何东西。 从操作系统到网络人员，从DBA到JVM，从第3方库到其他团队的界面，应始终归咎于一切。 这通常会导致无数小时的浪费时间，或者完全避免了最终会再次使您陷入困境的问题。 我们大多数人都可以提到我们完成此操作的时刻，这很常见。

6.艰苦的工作没有回报– Olve Maudal
“事实是，通过减少工作量，您可能会取得更多成就”

“如果您每周要专注于30个小时以上，并且要“富有成效”，
可能工作太辛苦了。”

我完全同意奥尔维·莫达尔（Olve Maudal）的观点。 我们很多人都去过那里，我们花了数天，数周，数月的时间上班，但我们通常看不到您每周工作50-70小时会发生什么负面影响。 从通用逻辑到动机和团队动力的所有内容都无法显示。 即使实现了短期目标，长期影响通常也要差很多。 没有人回过头来看看为什么他们必须在4年后重新编写系统，因为体系结构或代码失败了。 我想知道其中有多少是由于可笑的时间和不可能的时间表。 我可以想到我参与了至少两次“重写”，您可以看到这是长时间工作的结果。 您认识的可以编写出色代码的人会在凌晨1点进入黑客解决方案。
在某些情况下，总会有很多时间需要额外花费几个小时，只是尽量将其降到最低。

7.仅评论代码无法说的内容– Kevlin Henney
正是这样……不要告诉其他程序员他可以在代码中看到什么。 声明特定复杂算法背后的业务原因或需求的注释比//循环搜索结果并添加1有用得多。

8.了解您的IDE – Heinz Kabutz
我们很多人都感到内gui，我们每天在IDE中花费几个小时，学习快捷方式，学习功能，我们可能无法开始计算每个人都使用他们的IDE满时所节省的时间潜在。

9.学习估算–乔瓦尼·阿斯普罗尼（Giovanni Asproni）
我觉得这是经验带来的东西，我为自己的估计感到自豪，多年来，我一直在努力培养这种“技能”。 我有两点我想分享一下如何获得更好的估算值：

1. 对自己诚实，确保您知道自己认为的知识，并公开承认自己不知道。 这是解决麻烦的最快方法。
2. 跟踪您的工作及其持续时间，不一定要对项目经理而言，对您自己而言，请参见第1点。
3. 不要依赖他人的感知技能和时机，请参阅第1点。

之前，我评论了每个程序员都应该知道的97件事。 我想我会为每个软件架构师应该知道的97件事做同样的事情 。 最初，我认为这2种书可能有一些重叠之处，但是他们做得很好，可以使每本书都针对目标读者。 但是，我确实感到，这些“ 97件事”中有相当一部分在它们试图解释的原理上非常相似，因此我将它们归为相关原则。

在开始之前，我只需要评论本书的第一章：
不要把简历放在要求之上– Nitin Borwankar

我不确定我对此感觉如何。 我理解这一点，但我确实部分同意，但这并不意味着“以最新的闪亮语言或最新的闪亮范例显示最新的闪亮对象”对于公司或项目而言并不是最好的选择。 为解决方案选择某些新技术是非常困难的，不应轻易掉以轻心。 坚持使用已知的东西绝对是一个更安全的选择，并且短期内可能是项目或公司的正确选择，但是什么时候变成弊大于利呢？

转到我的前7件事：

1.了解业务领域– Mark Richards
我们这些“系统”人，通常是我们自己领域的专家，并不总是花时间来了解我们所涉足的实际业务，例如保险，金融，市场营销。 要成为一名更有效的软件架构师，适当的行业知识与了解最新技术一样重要。

2.首先，架构师就是开发人员– Mike Brown
“如果您设计它，则应该能够对其进行编码。”
我坚信上述说法。 建筑师有时没有时间或意愿保持其开发人员技能的最新性，并且随着时间的流逝，这些技能会萎缩。 然后，这可能会导致宏伟的设计，以及对不满意的开发人员的丑陋实施

3.与开发者打交道
关于与开发人员的交互，有两个主题，我决定将它们归为1点：
寻找并保留热情的问题解决者–乍得·拉维尼（Chad LaVigne） 给开发人员自治权–菲利普·尼尔森（Philip Nelson） 授权开发人员– Timothy High 架构师可能是开发人员，但无论是否愿意，他也需要领导他们，默认情况下，架构师在项目开发人员方面起着领导作用。 留给自己的设备的开发人员将疯狂（我们一直这样做；））。 因此，与软件体系结构中的大多数事情一样，所有事情都与平衡有关：

如果（控制太多）
开发人员=不满意
否则，如果（控制太少） 客户=不满意

如果（开发人员或客户不满意）
结果=不好

我相信开发人员与建筑师之间的关系是项目成功的众多关键因素之一。

4.表现
有2个有关性能的主题：
考虑性能永远不会太早–丽贝卡·帕森斯（Rebecca Parsons） 应用程序体系结构决定应用程序性能– Randy Stafford 在我当前的环境中，紧密监控事务处理时间并与具有财务影响的SLA签订合同，因此性能始终是重中之重。 但是，在许多其他团队/项目/公司中，我一直致力于系统性能的工作几乎总是到最后，有时没有足够的硬件来解决问题。

5.记录您的理由-蒂莫西·高（Timothy High）
我觉得这经常被忽略。 最近，我参与了很长时间的一个项目由于所有错误的原因而引起了人们的关注：客户，用户和管理人员的不满。 首先要质疑的不是分析，需求，测试，管理或期望，而是架构。 讨论所有决策，所考虑的方案以及采用方案的理由的文档将非常有价值。 当一切顺利时，甚至没人会知道该文档，但是当事情变糟时（有时确实如此），为所有主要决策提供理由和文档将是救命稻草。

6.站起来！ –乌迪·达汉（Udi Dahan）
“在交流思想时，使效率提高一倍以上的最简单方法就是站起来。”
这不仅仅是建筑师的一般观点，任何试图影响人和环境的人都可以从这一原则中受益。

7.伟大的软件没有建立，而是在成长– Bill de hora
“软件故障的最大预测因素是大小； 反思之后，从大型系统设计开始几乎没有任何好处。”
“有一个宏伟的愿景，但没有一个宏伟的设计。” 投入并设计总体解决方案非常诱人。 通过从基本，小型，可靠的系统实现开始，并在整个项目生命周期中始终怀着远见卓识地从该基础发展壮大，您就可以使软件不断发展，而不仅仅是紧密结合在一起。 进化对我们来说还可以，没有理由它与软件不一样。 这种方法不应与原型制造相混淆，不应采用任何质量捷径，也不应将其丢弃。

这两本书的所有贡献实际上都可以在O'reilly网站上找到：
程序员
建筑师

Wiki上的书籍中还没有包含许多“事物”。

参考： 每个程序员都应该知道的97件事中的前9个，以及每个软件架构师应该从我们的ZCG的JCG合作伙伴Brian获得的IT博客艺术中的 前7个问题 。

• 每个程序员都应该知道的事情
• 多少架构就足够了？
• 2011年最危险的25个软件错误
• 不执行代码审查？ 你的借口是什么
• 选择一种新的编程语言来学习