昨天听到同事说，代码只是需求的翻译，最重要的是什么定义问题？

[bigxianyu]

所以是不是代表这个公司文化是轻代码，重结果，重思考。这个是不是一个好的倾向。

[xz410236056]

谁说的？也有可能是解释[二哈]

[statement]

需求也是软件工程师自己的本质工作吧 好像每本和软件工程 软件设计相关的书籍都强调需要的重要

[yaojin]

我只在乎谁给的钱比较多

[Jooooooooo]

那当然, 代码是实现功能的手段. 不是目的.

[libook]

按同事的说法，顶多能推测出公司看重业务，实际上公司是看重业务带来的收益，说轻代码应该算是过度解读了。

对于公司来说，核心目标就是赚钱，所以公司并不关心代码怎么样。公司只需要有一个或几个业务，业务的综合成本低于综合营收，即有利润，那么开发团队的职责就是开发满足业务需要的程序，同时控制人力、运行成本。

代码如何写，都是服务于满足以上所有要求的；比如预期使用较复杂的架构可以有效降低已知的维护需要，使得综合成本降低，那么就值得花心思去做。

[WebKit]

本来就是这样呀。新型的农民工而已

[bigxianyu]

@sskyy 比较赞同这个观点，相辅相成，实际上这个问题有点类似做正确的事和正确的做事，缺一不可，但是就重要性而言，确实是做正确的事更重要，这个经历过职场的应该都能共鸣，这个问题背后更重要的点我觉得应该是作为一个码农如何从一个问题跨越到另一个问题，这也是个人在思考的点，如何正确的发现和正确的定义问题

[cxh116]

拿钱做事，做什么事都说不清楚，做什么事？

[kaedea]

开公司的是人民富豪，提需求的是总工程师，写代码的是建筑工人，大家都有光明的未来。

[dddd1919]

很多中文书籍也就是外文原版的翻译，看看是不是找个会外文的翻译翻译就行了

[idealhs]

@kaedea 这么多层就你最刑

[glfpes]

需求是：这个季度 CTR 涨 30%

好了，来人帮我翻译翻译吧。

[glfpes]

需求是：对所有 7 层流量支持安全校验，并且造成的开销 P99 必须小于 1ms 。

这里来人帮忙翻译一下，并且所谓的”安全校验“到底是什么东西，老板不知道。老板只知道除了问题找你麻烦。

[garvan]

代码是需求的翻译，好，需求来了，给我翻译翻译，什么叫真随机

[marsLeo]

理论上是如此，但现实情况，这么简单的模型不太可能完美执行。
首先，能把需求文档写很清楚的产品经理就很少，能先把业务需求完全分析清楚再写需求就更少，也很难在互联网行业做到；
而到代码实现这一层，能无 bug 实现需求也是很难。一方面对开发的能力水平要求很高，另一方面是开发时间周期、测试成本的问题，在代码运行时遇到的性能问题、成本问题，可能要倒逼业务上调整流程、交互。

以上种种情况，一个看似简单需求面前，如果业务的需求是持续迭代的，作为一个开发就考虑代码的可读性、扩展性、降低复杂度，用工程化提高协作效率。要做到这样，难道就是“翻译”需求就可以了吗？

[akakidz]

程序员的工作除了翻译还要纠错 因为傻逼需求还是挺多的

[RiverMud]

@felixcode 需求应该也分真需求和假需求，表面上的需求和实际上的需求。

[locoz]

没啥问题，绝大多数公司或者说绝大多数事物都是认知、思考、方法、业务、销售为主，技术为辅，只有必须要硬实力的（比如每个行业做到金字塔顶端的场景，或者是比如光刻机之类没有高精度就不行的场景）才是技术为主，但那是极少数。

毕竟一个东西能不能出来，首先得要有人认知到可以做这么一件事，然后思考出做的方法、归纳成业务逻辑，再进行开发，而有了销售才能把东西大量卖出去，技术在其中实际上是有很多替代方案的，并没有那么重要。所以不能说这个公司文化是这样，而是这个公司目前确实没有技术为主的需求，还没到需要以技术为主的时候，你同事看得很清楚。

[zxxufo008]

程序员的角色,如果按照第一次工业革命,只是个纺织工罢了,资本家喜欢的是能发明珍妮纺织机的人

[twor2]

没毛病
我个人最大的哲学就是审题，没有题目和需求，所有的努力都没用