当其他人希望跳过官方接口并直接访问底层实现细节时，我有时会遇到困难。
他们认为这样做可以让他们更快地解决问题。我认为这样做会导致我们的架构变得更加紧密耦合，并且随着新需求的出现难以改变。
我指出了当前设计中的所有工作以及设计理念和灵活性的价值，尝试维护和更改脆弱代码的成本，封装和数据隐藏和分层架构的价值以及健壮性，所以规范的微小变化会导致代码的微小变化。他们说“但这会更容易。”
你怎么对付这些人？
Glomek
问问题
535 次
11 回答
7
让他们处理一些修复其中错误的遗留代码。这几乎就是我认识的大多数人学到这些非常有价值的课程的方式......艰难的方式。
于 2008-10-16T22:10:28.683 回答
6
说服他们走捷径是一种虚假的经济。
说明最初的编码工作不到初始开发工作的 30%，不到整个项目工作（包括维护）的 10%（根据我的经验）。
如果他们仍然不相信，而你有权这样做，那么告诉他们按照你的方式去做。如果你没有权限，那就什么都不做。最终你的主管，如果她有价值的话，会认识到这一点，然后你将处于权威的位置。
于 2008-10-16T21:56:52.363 回答
4
“更容易”什么时候？现在，当一切都没有变化时？或者从现在起三个月后，当客户的要求发生变化并且他们有一个不再是解决方案的“解决方案”时？
为了结构和规则，我不太喜欢结构和规则，但很高兴知道 A）谁在驾驶船 B）规则是什么以及 C）为什么我们选择这样做。
在我的商店里，我们不喜欢重写代码，因为我们搞砸了一堆东西并对其进行了硬编码，或者为问题创建了一些脆弱的“解决方案”。一旦人们意识到，当事情被一堆需求更改颠倒时，它会减少以后的挫败感，遵循更灵活的方法往往不会变得更加困难。通常，我们为“长期”而不是“今天需要”而编码，因此设计是有原因的，设计也是出于同样的原因。
我花了一周的时间（连续 7 天）重写一个模块，因为我处于“快速完成”模式。7 天的艰苦时间，10 到 12 小时的正确方法，在比赛后期，那时我本可以观看超级碗。那个臭 我在那里吸取了教训。可能你的“朋友”也需要体验这种大开眼界。
祝你好运！
于 2008-10-16T22:01:46.580 回答
4
我实际上讨厌对此持不同意见，但是...
引用范海伦（引用陈词滥调）的话，“每件事都有时间和地点。” 虽然我当然不提倡写得不好，但有时你确实需要完成它，并在健壮/持久和被黑客入侵/记录之间找到快乐的媒介。（记录在案的部分特别重要，在两个方面：第一，你清楚地表明无论你在做什么，只是为了完成它，并采取某些捷径；第二，一个粗略的想法至于解决问题的更正确方法可能是什么。
作为程序员，我们经常努力编写完美的代码（嗯，我们中的一些人这样做），有时会忽略大局 - 有很多原因可以（在一定程度上）快速和松散地玩使用代码，同时最大限度地减少未来的影响。
请不要以此为理由——当然，这里适用 80/20 规则。大多数时候，您绝对想打破这些路线的任何捷径；但有时候...
于 2008-10-17T02:01:30.233 回答
3
最好的办法可能是将他们提拔为管理层，这样他们就不会造成太大的损害。
于 2008-10-16T21:47:59.090 回答
3
给他们看！让他们在“但这会更容易”中做一个小模块。风格，而你以正确的方式去做。然后要求他们对需求进行 2 到 5 次更改（必须是他们进行更改），并就实施更改进行定时竞赛。这可能需要一两天，但他们会得到它。如果您不这样做，您将对每个新项目或任务进行相同的讨论。
于 2008-10-16T22:18:35.797 回答
3
您可以尝试对它们进行类比....
国际象棋的规则很简单。你可以教孩子：“马像这样移动”、“城堡像这样移动”等。
如果这就是你所知道的，你可以下一些棋并且可能会玩得很开心，但是对游戏有更深入了解的人每次都会和你一起擦棋盘。你会被打败，甚至不再有趣，因为你不知道他们是怎么做到的。
同样的原则也适用于编程。了解语言的语法和一些简单的数据结构就足以让您获得一个工作程序，但是对于必须在多个发布周期中存活的大型应用程序，您不会有太多的运气。
国际象棋有开局、进攻策略等。我们有设计模式。
于 2008-10-16T22:48:24.583 回答
2
问题是除了最基本的概念和拖放式开发之外，大多数人甚至不了解软件设计。对于每一个研究和教育自己所有最好的新概念和技术的开发人员，有十个回家不看电脑。你必须教他们。
于 2008-10-16T22:18:26.767 回答
2
大约五年前，我设计了一个庞大而复杂的系统。在接下来的五年里，我将自己注入到每个影响“我的”系统的项目中，以防止野蛮人玷污我的建筑。只要我施加持续、无情的压力，我就能保持架构相当干净，但我正在打一场失败的战斗。原因如下：
1) 大多数人的评判标准是他们今天是否完成了工作。从来没有人因为三年前为了按时完成一个项目而偷工减料（或两年）而受到谴责。另一方面，许多人因没有按时完成项目而受到谴责。
2）您可能希望保持系统整洁，因为您对代码、应用程序或用户等有一种主人翁意识。很多人没有主人翁意识，因此很乐意破解一些东西所以他们可以完成它。你可以把马牵到水边，但你不能让他在意。
3）如果你说服每个人正确地维护代码，新人就会加入进来，需要被教导如何正确地做事。所以即使你成功了，你也会觉得自己失败了，因为你总是在与新对手进行同样的战斗。
4）你可能真的错了。微软花费两倍的程序员时间使 MS-Paint 健壮和可维护是否具有经济意义？有时，一个丑陋的黑客系统已经足够好了。大多数优秀的程序员很难理解这一点，但这通常是因为他们是优秀的程序员。
5) 我发誓有些人喜欢把东西拼凑在一起，或者因为他们可以更快地完成，或者他们将是唯一理解它的人，或者他们有打破规则的幼稚需要。你不能和这些人讲道理，你和他们争论的时间越多，项目截止日期就越近，这将迫使你无论如何都要一起破解一些东西。
6) 你很有可能比他们更了解这个系统。对你来说看起来像一个丑陋的 hack，对于一个不熟悉系统的人来说可能看起来像是“轻描淡写”。或者使代码健壮的额外努力将保护程序员免受他以前从未遇到过的问题，因此无法理解。在出现问题之前，您不会学习检查返回码，因为您没有检查返回码。那时，它不再是“额外的工作”，而是开始成为“必需的工作”。
如果你有一个小而紧密的开发团队，这是可能的。但组织越大，你成功的可能性就越小。如果你设法让一个拥有 250 人的 IT 商店重视做事正确而不是快速做事，那么你的说服力就是传奇。
于 2008-10-17T04:24:18.853 回答
0
http://catb.org/jargon/html/L/LART.html SCNR 等 pp ;)
于 2008-10-16T23:47:31.267 回答
0
告诉他们阅读（他们永远不会）封装理论： http ://www.edmundkirwan.com/
于 2008-10-17T15:50:09.873 回答