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

资本家的任务罢了。

我也是这么认为的.....

针对大部分 curd 的需求

一个人说话就能代表公司文化 吗？

西安一码通，需求和问题早就定义好了，但有人因为代码丢官了

先有需求，才有代码实现。
除非你有顶尖技术，比如硅谷里的独有压缩算法（设定）。才能根据技术找需求。

对于大多数公司来说不都是这样的么，毕竟开发是看不到利润的，而销售可以。

@zhaokun 待的比较久而且比较高的 level ，有一定的代表性

程序猿说白了就是手艺人、匠人。古话说做事不由东，累死也无功。

大多公司是业务为主吧，正常。毕竟谁最能挣钱谁就有话语权。

商业公司，一定是这样的。
代码如果能够 100%的描述合理的需求，那么其就有了作为成功产品的根基。
更多的情况是需求本身就有问题，或者是因为成本等原因代码实现不了需求。

但话说回来，这其实是一句正确的废话。
这就像是，吃饭是因为饿，喝水是因为渴。

代码是业务的翻译，需求也是业务的翻译
代码是实现层不代表可以瞎瘠薄提需求

代码本来就是需求的翻译啊
但是翻译也有水平的高低 翻译本身就是一门艺术啊

没毛病啊

需求像建筑设计，代码是结构设计。建筑设计除了美观，还需要考虑抗震、抗剪、承重、实用性等各个方面，脱离实际想建空中楼阁也是不现实的。

代码是需求的翻译，没毛病，但是让他能不能把“只”去掉， 就像你可以叫我跑龙套的， 但不能叫我死跑龙套的。

这个需求很简单，怎么实现我不管，明天上线

金融皮条公司，有俩名词，和楼主说的很像了：
承揽和承做。
一般承做都是技工，对应码农。
待遇的话，一般承揽要好过承做很多

语言就是需求的翻译，最重要的是什么定义问题。

打工人就是老板需求的翻译，最重要的是什么定义老板的需求。

肉体只是灵魂的承载体，最重要的是什么定义灵魂的意义。

毫无违和感，放之四海而皆准。

屁股决定脑袋罢了。
要是代码（工具）都消失了，看他一堆定义需求的方法有什么用？
年纪也不小了，这是给小朋友洗脑，还是自己也被洗脑了？

如果最终是通过代码解决问题，那代码就是基本功。很多时候基本功不行，问题定义得再好也执行不到位。反过来也是，基本功再好，不能正确地定义问题，做出来的东西没什么用。没有谁轻谁重，应该是相辅相成。

说的没错，你得把需求卖出去，要不苹果怎么这么，国内做手环血压，垃圾，比不过 100 的欧姆龙

苹果的心电图，牛逼，老年人必备，每天自测避免猝死

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

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

我只在乎谁给的钱比较多

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

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

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

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

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

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

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

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

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

@kaedea 这么多层就你最刑

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

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

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

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

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

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

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

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

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

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

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

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

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

不要因为自己是写代码的就觉得代码很神圣。
本质上，代码是负债，产品才是资产。
对于一个公司来说，代码越少越好，（可以带来营收的）产品越多越好。
而产品正是因为满足了某种需求才有价值。

所以你同事说的完全没错，至于需求定义是否准确，那是另一个问题。

我认为代码只是一种语言表述。优美的语言可以更好的描述问题。但是问题的核心解读是另外一个问题，也就是架构，算法，数据结构。

说得没毛病，但是翻译有高有低罢了

@RiverMud
稳定不崩这样的需求，应对多少用户的需求，不会没提吧

没毛病

@devinww 这就是大多数公司的沙雕之处。

粗略来说：

利润=销售额-成本

销售只是带来销售额，开发代表的是成本，如果销售在带来销售额的同时带来一堆垃圾需求导致成本上升，实际利润有可能是降低的，只是大多数公司不认为这种成本上升是销售造成，只会通过压缩开发成本来挽救。

这不废话么

这句话也许是真理。但是作为一个程序员把这个当真理，天天挂在嘴边，那可真是个笑话。

当你看懂了这句话，表示你比 8 成的程序员好一点点。至于还有那剩下的 2 成，早已开始指挥那 8 成的在搬砖了

技术解决需求。
科学探索未知。

就看你是技术型还是科学型了。
肯定技术型是大多数。

写代码应该向写作一样，是一种创造性的工作，也许不是一个好“作家”
但是不能把写代码当作翻译需求，这种机械的工作让人感觉到绝望

看项目，越是技术难度高 /复杂的项目技术占比就越重，技术难度高的不用说，复杂的项目如果仅仅是翻译需求后面肯定 hold 不住，这种项目里单纯的翻译需求就是组里的反面教材 :/