在讨论的“ 97件事”中，有两个比其他的更加突出，以下是我排名前9位的那些事物。
1.童子军规则–罗伯特·C·马丁（鲍勃叔叔）
“在签入之前，您不必使每个模块都完美无缺。只需要使它比签出时好一点。”
老实说，这并不是我整个职业生涯所遵循的，尽管我当然会尽力改进代码，但我从来没有在每次签到时都这样做。 但是，我确实认为这是一个很棒的原则，应该成为代码审查过程的一部分。 简单地说：
“就像那样了”
“那可恶的代码已经存在了多年，我不会去碰它。” “它从未进行过任何测试”
我在公司环境中工作时，应用程序通常会持续4-10年。 如果该过程的一部分总是要使事情变得更好，那么从删除未使用的代码到编写单个额外的单元测试的每一年，每一件事……最终将为很多人节省大量时间和金钱。
2.美丽在于简单–约恩·奥尔姆海姆
“最重要的是，漂亮的代码就是简单的代码。”
多年来，这对我来说变得尤为重要。 在我职业生涯的早期，尤其是在开始新的工作时，我会设计一些废话。
它将是：“欢迎进入过度工程学派”，所有内容都将抽象为第n个学位，其中将包含模式的模式，接口上的接口以进行抽象，并提供大量的代码和组件来满足每个“如果”曾经存在，那只有我能理解。 所有这些都会导致非常“花哨”的代码，我抚摸着我的自我，但是付出了什么代价呢？ 只有未成年人-一个彻底的噩梦。 我暂时支持几乎所有解决方案的最简单实现，即使它不一定是完美的技术实现。 在寿命长的软件世界中，可维护性通常应该胜过其他问题。
3.后退和自动化，自动化，自动化– Cay Horstmann
我相信要实现一切可能的自动化：构建，部署，代码分析，单元测试，功能测试，集成测试。 实际上，我们谁也不想每天都去看那些东西，而自动化是摆脱这种情况的唯一方法。 不能说足够自动化。 自动化，自动化，自动化。
4.持续学习– Clint Shank
这是一个非常重要的主题，我们处于一个不断成长，变化，转变的行业中，作为一名程序员，您需要学习并尽可能提高自己。 进入舒适区很容易休息，只要休息一下就可以了，我做了几年，现在我对此感到后悔。 我正在努力跟上的事情，并建议：
- 获取Kindle……然后购买和阅读书籍。
- 使用Google阅读器为您的特定领域以及您感兴趣的领域之外的夫妇添加流行的博客和网站RSS提要。
- 创建一个博客，通过将我的代码和想法摆在那里，我比知道自己为自己编写代码/文章要付出更多的努力。 我还强迫自己每周做1-2个帖子，以确保我必须始终查找新内容以进行学习。
- 加入开源社区，我们通常在公司环境中无法进行足够的“技术”开发。
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点。
- 不要依赖他人的感知技能和时机，请参阅第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个问题 。
翻译自: https://www.javacodegeeks.com/2011/07/top-97-things-every-programmer-or.html
113
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
