您如何主张“高音”，即真正的生产级代码？
这个问题已在关于 UI 的更具体级别的类似帖子中得到解决。
我想在更一般的设计层面上讨论这个主题。
我每天都会对设计做出决定，以确保高质量。 但我时不时地与中层管理人员和缺乏经验的开发人员讨论“以正确的方式”做事的好处。
有时我只是说“相信我，我已经知道这会导致什么结果，我们正在以另一种方式做”，有时我会尝试制定一个场景，其中一组特定的选择会带来问题等。大多数时候我觉得我没有联系到正在跟我说话的人。 我还不如说“相信我”。
我觉得作为一名高级软件人员，我的能力之一应该是解释和激励我们作为一家公司做出的技术选择。 我可以在经济和用户体验水平上做到这一点。
但我似乎无法在技术和伪技术层面解释为什么某些设计选择“感觉错误”，以及为什么其他设计选择只是感觉更正确和有益，尽管一开始它可能更难实现或看起来不必要的复杂。
幸运的是，我偶尔会表现出好的结果，否则我可能会开始怀疑好设计与坏设计的整个概念。
我真的觉得阅读这里其他人对此的看法很有趣。
提前致谢！
This question has been addressed in a similar post on a more specific level regarding UI.
I would like to address the subject on a more general design level.
I make descisions on design every day to ensure high quality. But every now and then I get into dicsussions with middle management and unexperienced developers about the gain of doing things "the right way".
Sometimes I just say "trust me, I've seen where this leads to, we're doing it the other way", sometimes I make an attempt lay down a scenario where a particular set of choices introduce problems etc. Most of the time I feel I'm not reaching the person I'm talking to. I might as well have said "trust me".
I feel that one of my capabilities as a senior software guy should be to explain and motivate the technical choices we make as a company. I can do that on economical and user experience level.
But I seem to fail to explain on technical and pseudo-technical levels why some design choices "feels wrong" and why others just feels more correct and benefitial, even though at first it might be harder to implement or seem unnecessarily complex.
Luckily, I occasionally show good results, otherwise I probably would begin to doubt the whole concept of good vs. bad design.
I would really find it interesting to read about what others here have to say about this.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
这是我愤世嫉俗的回答：
有两种人——那些关心以正确的方式做事的人和那些不关心的人。 你不需要赢得那些同意你观点的人，所以你需要担心的是那些不关心事情如何完成的人。 您很可能会发现那些不关心“以正确的方式”做事的人非常关心其他事情，例如前期时间惩罚、与不同实现的混淆等。您能做的最好的事情就是确定其他人真正关心并解决的是什么。
例如，如果人们担心您会通过以正确的方式做事而预先引入过多的开发时间，那么向他们展示从长远来看，以正确的方式做事如何可以节省他们的时间。
不过，请注意一点——总是问自己一个非常重要的问题，所有纯粹主义者（包括我自己）在遇到反对“正确方法”时都必须问自己：
如果答案是“是”，那么你可能需要退缩。
Here is my cynical answer:
There are two kinds of people - those who care about doing things the right way and those who do not. You don't need to win over those who agree with you so the folks you have to worry about are those who don't care how things get done. You will most likely find that the folks that don't care about doing things "the right way" care deeply about other things like up-front time penalties, confusion with a different implementation, etc. The best thing you can do is to determine what it is that the other folks really care about and address them.
For instance if folks are worried that you will introduce too much development time up front by doing things the right way then show them how doing things the right way might save them time in the long run.
One word of caution though - always ask yourself the ever-important question that all purists (myself included) must always ask whenever they incounter opposition to "the right way":
If the answer is "yes" then you probably need to back down.
两点：
Two points:
通常，这样的讨论可能会演变成宗教或政治争论——每个人都有自己的观点，但没有人有答案。 您可以做的任何事情为您的想法添加实质内容都将帮助您推动您的想法。
阅读一些现有材料 - 关于面部，< a href="https://rads.stackoverflow.com/amzn/click/com/0465067107" rel="nofollow noreferrer">日常事物的设计等 - 看看你是否无法识别一些事实来支持你的感觉，即有些事情就是感觉不对劲。
Often, discussions like these can devolve into religious or political arguments - everyone has an opinion, but no one has the answers. Anything you can do to add substance to your thoughts will help you push your ideas through.
Read some existing material - About Face, The Design of Everyday Things, etc. - and see if you can't identify some facts to back up your feelings that some things just feel wrong.
一般来说，我发现如果我必须使用“相信我。我知道我在说什么”的论点，我需要回去重新思考我试图解释和实施的内容。 有时我会感觉到某件事是好是坏，但这表明我需要对其进行审查，因为我没有具体的理由说明为什么我应该或不应该做某事。
您应该注意的另一件事是因为“初级”人员的头衔而解雇他们。 你可能有更多的经验，但这并不意味着他们不聪明，他们所说的可能是正确的。 事实上，多年的经验几乎没有任何意义，因为它只是某人从事同一类型工作的年数。 这是一个很好的指标，可以表明某人的职业生涯处于哪个阶段，但这并不是一个自动的法令，他们实际上始终有能力做出正确的决定。
Generally, I've found that if I have to use the argument of "Trust Me. I know what I am talking about" I need to go back and rethink what I am trying to explain and implement. Sometimes I get a feeling about something being good or bad, but that is an indicator that I need to review it as I don't have a concrete reason about why I should or shouldn't do something.
The other thing you should pay attention to is dismissing "Junior" people because of their title. You may have more expierence, but that doesn't mean they aren't smart and could be correct in what they are saying. In reality, years of expierence can mean little to nothing as it is just the number of years that someone has been doing the same type of job. It's a good indicator as to where someone is in their career, but it isn't an automatic decree they are actually capable of making the right desicions all the time.
也许您不应该与中层管理人员争论技术决策：那会在错误的抽象层次上进行讨论。 例如，不要回答“需要 X 天的重构，然后需要 Y 天来实现新功能”，而只需说“需要 (X+Y) 天”。
至于和初级开发者争论，你似乎是在问修辞或者“如何争论”； 这是一个很大的话题，例如，许多技术之一是“诉诸权威”，例如说“我在
<受人尊敬的作者写的这本好书中读到了这种技术>”...或者，即使您无法证明某些事情，也可以根据它降低风险的理由进行争论...最最重要的是，倾听：找出他们为什么想争论其他事情，并解决他们的论点。 例如，也许他们想以“错误”的方式去做，因为他们想要快速完成，因为他们受到其他人的时间压力：如果是这样，请解决那个问题。
Maybe you shouldn't argue technical decisions with middle management: that would be discussing at the wrong level of abstraction. For example, instead of answering "it will take X days of refactoring and then Y days to implement the new feature", just say "it'll take (X+Y) days".
As for arguing with junior developers, you seem to be asking about rhetoric or "how to argue"; that's a huge topic, for example one of many techniques is "appeal to authority" e.g. say "I read about this technique in
<this good book by respected author>" ... or, even if you can't prove something, argue on the basis that it reduces risk ...Most importantly though, listen: find out why they want to argue something else, and address their argument. For example, maybe they want to do it the 'wrong' way because they want it quickly, because they're under some time pressure from someone else: if so, address that concern.
我尝试从成本的角度来考虑。 在某种程度上，它又回到了“快、好、便宜：任选两个”。 如果你始终选择快速和便宜，你就会得到垃圾。
我更喜欢花三四年的时间来设计和构建任何给定的功能块。 如果我有这样的自由度，并且能够彻底解释额外努力的必要性和好处，一切都会变得更好。
让我举一个具体的例子。 我被分配了一个功能来添加到一段代码中，该代码块获取图像集合并从图像生成 PDF。 现有代码简洁明了，是为了满足客户需求而编写的 - 但它并不是为了增长而构建的。 我可以并且确实使用现有代码添加该功能并将其签入，但它很丑陋，并且后续的每个功能都会变得更丑陋。 然后我又花了两周时间编写了生成 PDF 的完整功能模型，该模型也被设计为消费者。 完成后，我花了几个小时在新模型中重新实现整个 PDF 生成器。 我可以非常简洁地解释说，构建模型虽然不是绝对必要的，但它创建了一种支持技术，并且会使向现有代码添加更多功能的成本更便宜。 我们现在有四种完全基于该技术的主要产品或功能集，并且正在寻找更多产品或功能集。 灌篮高手。
I try to think of it in terms of cost. In a way, it comes back to "fast, good, cheap: pick any two". If you consistently choose fast and cheap, you will have crap.
I prefer to design and to build for three or four years out for any given chunk of functionality. If I have that latitude and can be thorough in my explanation of the need and benefits of the extra effort, everything will get better.
Let me give a concrete example. I was assigned a feature to add to a chunk of code that takes a collection of images and generates a PDF from the images. The existing code was brief and terse and had been written to fill a customer need - but it wasn't built to grow. I could, and did, add the feature using the existing code and checked it in, but it was ugly and every subsequent feature would get uglier. Then I spent an additional two weeks writing a full functional model of generative PDF, architected to also be a consumer as well. After I was done, it took a couple hours to reimplement the entire PDF generator in the new model. I could explain very concisely that building the model, though not strictly necessary, created an enabling technology and would make the cost of adding more features to the existing code cheaper. We now have four major products or feature sets that are entirely based on this technology and are looking at more. Slam dunk.
我的老板不是一个技术含量很高的人，但他也很难接受“相信我”的答案。 我花了一段时间才弄清楚，为了将问题与他联系起来，重要的是要根据时间成本、工时、花费的金钱等来量化问题。与
人们理解的内容相关通常会让他们明白更容易接受你的答案。
My boss isn't a very technical person but he also has trouble accepting "trust me" answers. It took me a while to figure out that in order to relate a problem to him, it was important to quantify the issue in terms of time costs, man hours, money spent, etc.
Relating to what the person understands will usually get them to accept your answers a lot more readily.
我也不是一个好的推销员，这似乎是你的问题。 我发现，当我想说服人们采取另一条路线时，提出引导性问题对我来说非常有效。 尝试以这样一种方式提出问题，即唯一合乎逻辑的答案就是您正在寻找的答案。 这样做的额外好处是，人们相信他们自己提出了解决方案，这意味着他们更有可能相信该解决方案。 这需要练习，但是当这不是你的性格类型时，比成为一名推销员更容易学习。 这也意味着您确实需要了解自己的知识，才能知道如何提出问题，从而得出正确的解决方案。
这种方法还有一个附带的好处，即如果他们即使面对您的主要问题也能得出不同的解决方案，那么这应该会导致您重新检查自己的解决方案。
I am not a good salesman either, which seems to be your problem. What I have found that works very well for me when I want to convince people to take another route is to ask leading questions. Try to ask questions in such a way that the only logical answer is the one you are looking for. This has the added bonus that the person believes they are coming up with the solution themselves which means they are more likely to believe in the solution. It takes practice, but is easier to learn than to become a salesman when it is not your personality type. It also means that you really need to know your stuff in order to know how to ask your questions that lead to the correct solution.
This approach also has a side benefit in that if they can come to different solutions even in the face of your leading questions, then this should cause you to re-examine your own solution.
您是否尝试过技术债务论点？ 引用链接（来自 Martin Fowler 网站）：
Have you tried the Technical Debt argument? Citing the link (from Martin Fowler site):