Skip to content

Commit 79b87c7

Browse files
ahangchenahangchen
committed
Merge pull request braydie#92 from aidewoode/improve-chapter-two-readability-in-zh
improve readability in zh for chapter two
2 parents 297fa59 + ef87802 commit 79b87c7

26 files changed

+64
-64
lines changed

‎zh/2-Intermediate/Judgment/01-How to Tradeoff Quality Against Development Time.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
11
# 如何在开发质量与开发时间权衡
22

3-
软件开发总是在工程该做什么与完成工程间妥协。但你可能被要求以牺牲你的工程适用性或商业适用性的方式，去交换工程的开发速度。例如，你可能被要求做一些糟糕的可能导致大量维护问题的软件工程实践。
3+
软件开发总是在工程该做什么与完成工程间妥协。但你可能被要求以牺牲你的工程适用性或商业适用性的方式，去交换工程的开发速度。例如，你可能被要求做一些糟糕的软件工程实践，但这将会导致大量维护问题。
44

5-
如果这发生了，你的首要任务是通知你的团队，然后清楚地解释降低质量的代价。在这之后，你对这个问题的理解会比你的boss的理解还要更清晰。明白将会失去什么以及将要得到什么，以及在这次失去的东西，能在下一轮中得到什么。在这个过程中，由一个好工程提供的可见性应该会很有用。如果质量交换影响了质量保证工作，(向你的boss和质量保证部分)指出这个问题。如果质量交换会导致在之后的质量保证周期中出现更多的bug，指出来。
5+
如果这发生了，你的首要任务是通知你的团队，然后清楚地解释降低质量的代价。在这之后，你对这个问题的理解会比你的 boss 的理解还要更清晰。明白将会失去什么以及将要得到什么，以及在这次失去的东西，能在下一轮中得到什么。在这个过程中，由一个好工程提供的可见性应该会很有用。如果质量权衡影响了质量保证工作，(向你的 boss 和质量保证人员)指出这个问题。如果质量权衡会导致在之后的质量保证周期中出现更多的 bug，指出来。
66

77
如果她仍然坚持，你应该把劣质部分隔离到特殊的你可以在下一个开发周期计划重写或优化的组件中。向你的团队解释这个问题，这样他们可以为此做些计划。
88

9-
忍者程序员在Slashdot写下了这样的格言：
9+
忍者程序员在 Slashdot 写下了这样的格言：
1010

1111
> 记住，一个好的设计会被糟糕的代码实现弹回。如果好的接口和抽象在代码中到处存在，最后的重写会更加痛苦。如果写难以修复的清晰代码很困难，考虑是什么与核心设计冲突的东西导致了这个问题。
1212

‎zh/2-Intermediate/Judgment/02-How to Manage Software System Dependence.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
现代软件系统趋向于依赖大量的非直接可控的组件。通过协同与重用，这增加了生产效率。然而，每个组件会带来一些问题：
44

5-
- 你该如何修复组件中的bug？
5+
- 你该如何修复组件中的 bug？
66
- 组件限制你使用特殊的硬件或软件系统了吗？
77
- 如果组件完全坏掉了，你该做什么？
88

‎zh/2-Intermediate/Judgment/03-How to Decide if Software is Too Immature.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# 如何判断软件是否太不成熟了
22

3-
使用其他人写的软件是一种最有效率的构建一个坚实的系统的方法之一。这本不该被排斥，但与此相关的危机必须被检验。最大的一种风险在于，它通过使用变成一个可用产品成熟前的，bug周期和与软件相关的故障时期。在你考虑将软件系统集成前，不论是你自己写的还是第三方的，考虑它是否足够成熟以使用是非常重要的。这里有十个你应该自问的相关问题：
3+
使用其他人写的软件是一种最有效率的构建一个坚实的系统的方法之一。这本不该被排斥，但与此相关的风险必须被检验。最大的一种风险在于，它通过使用变成一个可用产品成熟前的 bug 周期和与软件相关的故障时期。在你考虑将软件系统集成前，不论是你自己写的还是第三方的，考虑它是否足够成熟以使用是非常重要的。这里有十个你应该自问的相关问题：
44

55
1. 它是蒸汽吗？（那肯定是不成熟的）
66
2. 有可用的懂这个软件的人吗？

‎zh/2-Intermediate/Judgment/04-How to Make a Buy vs Build Decision.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# 如何做购买还是构建的决定
22

3-
一个尝试用软件完成一些任务的企业级公司或工程必须不断做所谓的*buy vs. build*的决定。这个问题的不幸在两个方面：似乎忽视了不必*被购买*的开源软件和自由软件。更重要的是，这可能应该被称作*获取与集成 vs. 购买与集成*决定，因为集成的代价需要被考虑。这需要商业上，管理上，工程理解上的大量结合。
3+
一个尝试用软件完成一些任务的企业级公司或工程必须不断做所谓的 *buy vs. build* 的决定。这个问题的不幸在两个方面：似乎忽视了不必*被购买*的开源软件和自由软件。更重要的是，这可能应该被称作*获取与集成 vs. 购买与集成*决定，因为集成的代价需要被考虑。这需要商业上，管理上，工程理解上的大量结合。
44

55
- 你的需要与它的设计意图有多接近？
66
- 对于你购买的软件，你想要怎样的可移植性？
@@ -9,7 +9,7 @@
99
- 购买会增加还是减少长期维护代价？
1010
- 构建会把你放在一个你不想要的商业位置吗？
1111

12-
三思，如果你想要购买一些大到足够成为另一整个商品的基础的东西。这样的想法通常是乐观积极的将会对你的团队做出许多贡献的人提出来的。如果他们的想法很引人注目，你可能会想要改变你的商业计划，但不要在没有周全考虑前就投资一个比你自己的商业还大的解决方案。
12+
在你构建一些大到足够成为另一整个商品的基础的东西前请三思。这样的想法通常是乐观积极的将会对你的团队做出许多贡献的人提出来的。如果他们的想法很引人注目，你可能会想要改变你的商业计划，但不要在没有周全考虑前就投资一个比你自己的商业还大的解决方案。
1313

1414
在考虑了这些问题后，你可能应当准备两个工程计划草案，一个给购买，一个给构建。这会强迫你考虑集成代价。你也应当考虑两种措施的长期维护代价。为了评估集成代价，你必须在购买软件前对它做一个彻底的评估。如果你不能评估好它，你可以假设购买它会有一个不可预料的风险，你应该以此决定是否购买特定的产品。如果考虑后有几个购买决定，需要花一些精力去评估每个决定。
1515

‎zh/2-Intermediate/Judgment/05-How to Grow Professionally.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,11 @@
11
# 如何专业地成长
22

3-
承担超过你的权威的责任。扮演你想要扮演的角色。对人们对更大组织的成功的贡献以及对你个人的帮助表示感谢与欣赏。
3+
承担超过你的权力的责任。扮演你想要扮演的角色。对那些对更大组织的成功做出过贡献以及对你个人提供过帮助的人表示感谢与欣赏。
44

55
如果你想成为团队的领导，去激励与团结。如果你想成为一个经理，担起规划的责任。你通常可以在和领导或经理在一起时，舒服地完成这些事情，因为这使得他们可以抽空去承担更大的责任。如果这太多了以至于你不能尝试，一次只做一点点。
66

7-
评估你自己。如果你想要变成一个好的程序员，询问一些你欣赏的人你怎样才能变成他们那样。你也可以问你的boss，他可以告诉你的东西会少一些，但对你的事业会有更大的影响。
7+
评估你自己。如果你想要变成一个好的程序员，询问一些你欣赏的人你怎样才能变成他们那样。你也可以问你的 boss，他可以告诉你的东西会少一些，但对你的事业会有更大的影响。
88

99
计划学习新技能的方式，包括琐碎的技术类型，比如学习一个新的软件系统，和困难的社交类型，像漂亮的写作，把它们集成到你的工作中。
1010

11-
Next [如何评估面试](06-How to Evaluate Interviewees.md)
11+
Next [如何评估面试者](06-How to Evaluate Interviewees.md)

‎zh/2-Intermediate/Judgment/06-How to Evaluate Interviewees.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,15 @@
11
# 如何评估面试者
22

3-
评估可能的员工，却没有得到它应得的能量。一个糟糕的雇佣，就像糟糕的婚姻，是非常糟糕的。每个人的能量的一个重要的部分应该用于补充，尽管这很少发生。
3+
评估可能的员工，却没有得到它应得的能量。一个糟糕的雇佣，就像糟糕的婚姻，是非常糟糕的。每个人首要的一部分精力应该投入到招聘上，尽管这很少发生。
44

5-
有不同的面试风格。有的是折磨人的，设计用来把候选人放在巨大压力下。这是为了这样一个有用的目的：在压力下折射出性格缺陷和弱点。候选人不会对他们自己之外的其他面试官更诚实，而且，人的自欺能力是令人惊奇的。
5+
有不同的面试风格。有的是折磨人的，设计用来把候选人放在巨大压力下。这是为了这样一个有用的目的：在压力下折射出性格缺陷和弱点。候选人对待面试官不会比对待他们自己更诚实，而且，人的自欺能力是令人惊奇的。
66

7-
你应当，最少，对候选人进行两个小时的与口头考核等价的技术技能考核。实践后，你会能够快速了解他们知道什么，快速收缩他们不知道的来标明边界。面试者会尊重这件事请。我有几次听面试者说面试的质量是他们选择公司的一个动机。聪明人会因他们的技能而被雇佣，而非他们之前工作过的地方或他们上了哪个学校或者一些无关紧要的特征。
7+
你应当，最少，对候选人进行两个小时的与口头考核等价的技术技能考核。实践后，你会能够快速了解他们知道什么，快速收缩他们不知道的来标明边界。面试者会尊重这件事情。我有几次听面试者说面试的质量是他们选择公司的一个动机。聪明人会因他们的技能而被雇佣，而非他们之前工作过的地方或他们上了哪个学校或者一些无关紧要的特征。
88

9-
做这些事情，你也应当评估他们的学习能力，这比他们所知道的要更加重要得多。你也应当不同的人散发出来的硫磺味。你可能能够在面试后通过比较笔记来识别这一点，但在面试的热烈环境中这很难分辨。人们交流的能力以及与人合作的能力比在最新的编程语言上领先更为重要。
9+
做这些事情，你也应当评估他们的学习能力，这比他们所知道的要更加重要得多。你也应当留心那些难以相处的人所散发出的火药味。你可能能够在面试后通过比较笔记来识别这一点，但在面试的热烈环境中这很难分辨。人们交流的能力以及与人合作的能力比在最新的编程语言上领先更为重要。
1010

11-
一个读者有“在家”测验面试的经验。这有一个优点是揭露了一些面试者能良好地自我表现但不能写代码的缺点 - 这样的人是很多的。我个人没有尝试过这种技术，但这听起来挺合适的。
11+
一个读者有“在家”测验面试的经验。这有一个优点是揭露了一些面试者能良好地自我表现但不能写代码 - 这样的人是很多的。我个人没有尝试过这种技术，但这听起来挺合适的。
1212

13-
最后，面试也是一个销售的过程。你应该把你的公司或工程销售给候选人。然而，你是在与程序员谈话，所以不要尝试改变事实。从没有坏员工开始，到与好员工一起强大而结束。
13+
最后，面试也是一个销售的过程。你应该把你的公司或工程销售给候选人。然而，你是在与程序员谈话，所以不要尝试改变事实。从坏的事物开始讲起，最后以好的事物作为强有力的结束。
1414

1515
Next [怎么决定什么时候使用奇妙的计算机科学](07-How to Know When to Apply Fancy Computer Science.md)

‎zh/2-Intermediate/Judgment/07-How to Know When to Apply Fancy Computer Science.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# 如何决定什么时候使用奇妙的计算机科学
22

3-
有这样一些，算法，数据结构，数学，还有其他极客范的大多数程序员知道但很少了解的东西。实践中，这种奇妙的东西太复杂了，通常是不需要的。例如，当你花费大多数时间在低效的数据库调用上时，提高算法是没有什么用的。不幸的大量编程由让系统相互交流以及使用非常简单的数据结构去构建漂亮的用户界面组成。
3+
有这样一些，例如算法，数据结构，数学，还有其他极客范的大多数程序员知道但很少使用的东西。实践中，这种奇妙的东西太复杂了，通常是不需要的。例如，当你花费大多数时间在低效的数据库调用上时，提高算法是没有什么用的。不幸的大量编程由让系统相互交流以及使用非常简单的数据结构去构建漂亮的用户界面组成。
44

55
高科技什么时候是合适的科技？你什么时候应当打开一本书去找一些东西而非一个毫秒级算法？做这些有时候是有用的，但这需要被小心评估。
66

@@ -10,6 +10,6 @@
1010
- 好处是否是令人惊奇的（例如，成熟系统的两倍或新系统的十倍？）
1111
- 你能够高效测试和评估它吗？
1212

13-
如果一个充分独立算法使用了些许奇妙的可以减少硬件消耗或增加整个系统的两倍性能表现的算法，不考虑它可能是有罪的。争论这样一个方法的一个关键是，证明风险确实是相当的低，因为目标技术可能被充分研究过了，唯一的话题是集成的风险。在这里一个程序员的经验和评估可以真的与奇妙的算法协作使得集成变得容易。
13+
如果一个充分独立算法使用了些许奇妙的可以减少硬件消耗或增加整个系统的两倍性能表现的算法，不考虑它可能是有罪的。争论这样一个方法的一个关键是，证明风险确实是相当的低，因为目标技术可能被充分研究过了，唯一的话题是集成的风险。在这里一个程序员的经验和评估能够真的协同奇妙的算法让集成变得容易。
1414

1515
Next [如何与非工程师交谈](08-How to Talk to Non-Engineers.md)

‎zh/2-Intermediate/Judgment/08-How to Talk to Non-Engineers.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -6,14 +6,14 @@
66

77
非工程师可能太渴望以至于不能被取悦和与你亲近，他们可能在不是真的对你满意的时候却对你说“是”，或者是因为他们有点怕你，然后不会对你说实话。
88

9-
非工程师可以理解技术的东西，但他们不会做那件甚至对我们来讲都很困难的事情 - 技术评审。他们确实理解技术是如何工作的，但他们不能理解为什么一个特定的方法需要花三个月而另一种方法要花三天。（毕竟，程序员对这种估计也感到事多得可怕。）这代表了一个巨大的和他们协作的机会。
9+
非工程师可以理解技术的东西，但他们不会做那件甚至对我们来讲都很困难的事情 - 技术评审。他们确实理解技术是如何工作的，但他们不能理解为什么一个特定的方法需要花三个月而另一种方法要花三天。（毕竟，程序员对这种估计也感到事多得可怕。）这相当于一个巨大的和他们协作的机会。
1010

11-
与你的团队交谈时，你会，不假思索的，使用一种捷径的形式，一种简单的语言更有效率，因为你通常对技术或者特别是你的产品会有许多的共享经验。
11+
与你的团队交谈时，你会不假思索地使用某种程度上的简略表达方式，一种简单的语言更有效率，因为你通常对技术或者特别是你的产品会有许多的共享经验。对于那些没有这些共享经验的人不使用简略表达方式是需要作出一些努力的，特别是你团队内部的人员也在场的时候。这些简略的词汇会让你与那些没有分享到相关经验的人之间构建出一道墙，甚至更糟的是，浪费着他们的时间。
1212

1313
与你的团队一起，基本的假设和目标不需要经常重申，大多数谈话集中于细节。与外人一起，就是另一回事了。他们可能不理解你认为理所当然的东西。由于你把这当做理所当然，并且没有重申它们，使得你们的谈话陷入这样一种情况：你可能认为你们相互理解，但事实上有一个巨大的误解。你应当假设你会有错误的交流，并且仔细观察去找出这样的误解。试着总结或将你说的东西分点，来确保他们能够理解。如果你有机会经常与他们见面，花一点时间询问你是否在有效地交流，以及你可以怎样把它做得更好。如果交流有问题，在对他们失望前，寻找方法去提高你自己的实践。
1414

15-
我喜欢与非工程师工作。这提供了绝大的机会来学习与传授。你可以经常由实例得到关于你的交流的阐述的指引。工程师被训练于从混乱中梳理秩序，从困惑中得到解释，非工程师会因此喜欢我们。因为我们有技术评审，并且通常可以理解商业话题，我们经常发现一个简单的方法来解决问题。
15+
我喜欢与非工程师工作。这提供了绝大的机会来学习与传授。你可以经常由实例得到关于你的交流的阐述的指引。工程师被训练于从混乱中梳理秩序，从困惑中得到解释，非工程师会因此喜欢我们。因为我们有技术评审，并且通常可以理解商业话题，我们经常可以发现一个简单的方法来解决问题。
1616

17-
很多时候非工程师会出于好意以及一种正确做事情的欲望去规划他们认为会让我们更容易的事情，事实上存在一个仅能通过借助你的技术评审协助外人的观点看到的好得多的方法。我个人喜欢极限编程因为它处理了这种低效，通过将估计快速与主意结合，使得发现成本与好处最佳结合的方法更加容易。
17+
很多时候非工程师会出于好意以及一种正确做事情的欲望去规划他们认为会让我们更容易的事情，事实上存在一个仅能通过借助你的技术评审协助外人的观点看到的好得多的方法。我个人喜欢极限编程因为它处理了这种低效，通过与快速评估相结合，使得发现成本与好处最佳结合的方法更加容易。
1818

1919
Next [高级技能](../../3-Advanced)

‎zh/2-Intermediate/Personal-Skills/01-How to Stay Motivated.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,13 @@
22

33
创建美丽，有用，聪明的东西的欲望能高度调动程序员的积极性。这是奇妙而令人惊奇的。这种欲望对程序员既不特殊也不普遍，但在程序员中，它是如此强烈而普遍以至于它把程序员与其他角色的人们分割开来。
44

5-
这有一个现实而重要的推论。如果程序员被要求做一些不美丽/有用/漂亮的事情，他们会斗志低落。做丑陋，愚蠢，无聊的员工可能可以赚很多钱，但最后，乐趣才会为公司赚最多的钱。
5+
这有一个现实而重要的推论。如果当程序员被要求做一些既不美丽，也没有用，也不漂亮的事情，他们会斗志低落。虽然可以通过做丑陋的，愚蠢的，无聊的东西赚很多的钱，但最后，乐趣才会为公司赚最多的钱。
66

77
很明显，有一些完全由动机技术组织起来的工业适用这里的情况。这些我可以识别的特定的编程中的事情有：
88
- 为工作使用最好的语言
99
- 寻找机会去使用新技术，新语言，新科技
1010
- 尝试在每个工程里学习或教授一些东西，即使很小
1111

12-
最后，可能的话，估量个人激励的东西对你工作的影响。例如，修复bug时，数一数我完全不感兴趣的bug的数目，因为这和仍然存在的bug数目是独立的，并且也影响我在最小可能的方式上影响我对我公司的顾客的增值。把每个bug和一个高兴的顾客关联起来，*是*对我个人的激励。
12+
最后，可能的话，估量个人激励的东西对你工作的影响。例如，修复 bug 时，数一数我完全不感兴趣的 bug 的数目，因为这和仍然存在的 bug 数目是独立的，并且这也是影响我对公司的顾客的增值的最小的可能方式。把每个 bug 和一个高兴的顾客关联起来，*是*对我个人的激励。
1313

1414
Next [如何被广泛信任](02-How to be Widely Trusted.md)

0 commit comments

Comments
 (0)