程序员其实是程序设计师吧？（一些胡思乱想）

[Cbdy]

程序员中的超人

我发现，有很多知名的项目都是一些大佬程序员发起、设计并且完成第一版的

• Git、Linux Kernel 之于 Linus
• gcc、Emacs 之于 Stallman
• Ruby 之于松本行弘
• Node.js 、deno 之于 ry
• Spring Framework （ Java ）之于 Rod Johnson
• Vue.js （ Web 前端）之于尤雨溪
• Caffe （机器学习）之于贾扬清

等等

这些项目有的发展至今可能绝大多数代码已经不是原作者写的，但是似乎看起来没太多变化

---

程序设计师

我前一段时间看到一句话

程序源代码其实是给人阅读的，只是恰好机器可以编译运行而已

这个有点夸张了，但是换句话说，程序员写的代码只是承载程序员对程序的设计，程序员的主业应当是设计，而非编程：

程序员应当是程序设计师

比如，设计一个社区软件，比如 V2EX，Livid 更多的可能需要去设计社区的一些原则，用户如何交流（比如不允许用户删帖😂）等。然后把这些设计转化成程序，如果哪天 V2EX 不用 Python 写了，用更加新兴的语言重构，V2EX 依然是 V2EX

---

所以我看到一些程序员纠结语言框架和工具，其实如果没有设计和思想，做出的东西会不会东施效颦、毫无灵魂呢？

或者当我们真正要去做出一个东西，是不是应该让我们先具备像超人程序员那样的执行力（或整合资源的能力）？

[Violienk]

从根本角度来说,这些人是技术层面的产品经理



creater
builder
designer
programmer
code famer
project manager

这些都是区别的

[Yanni0507]

袁隆平先生和我老家隔壁老头都是种田的，那隔壁老头想种点口粮，怕不是得先研究杂交育种哦？

[no1xsyzy]

编程是一门古老艺术的别名，那门古老的艺术名字叫思考。

语言框架和工具 唯一的功能就是表达思想。至于其中的选择，就是尽可能不拖累其他的东西（包括不拖累你的思考（开发效率）、以及不拖累机器的理解（运行效率））。
（不存在哪个语言可以使得你产生新的思想，如果你发现了这一情况，那只是你以前用的语言拖累了你的思想。但思想永远会被语言所限制，所以你只能让它尽可能不拖累。）

最不拖累思考的语言是伪代码。最不拖累机器的理解的语言是机器语言。
其他大部分都在这两极之间。但并不是说一侧是 (1, 0) 另一侧是 (0, 1) 中间的全都是 (x, 1-x)，可以有 (0.9, 0.9) 这样的神器（可能 chez scheme ？），也可以有 (0.1, 0.1) 这样的废物（求例子）。

[reus]

什么鬼逻辑，语言和框架难道和架构是对立的？讨论语言和框架，难道就等于无视架构设计？
你不编码实现不试验，怎么知道设计有没有问题？实现到一半，发现所用语言或者框架没法好好地将设计表达出来，难道不是语言和框架有局限性？难道在实现之前讨论下工具，和设计就有冲突了？
可以类比为建筑结构设计和工程施工，你有好的设计，就不需要良好的施工了？讨论施工技术，就等于不重视设计了？设计难道不需要考虑现有的施工技术？

[suzic]

《程序设计与软件开发》 本来就包含“设计”

[SwiftFrank]

@reus 你楼上的回复是(0.9, 0.9), 你的回复就是那(0.1, 0.1)除了看出在喷, 没看出你想表达啥

[no1xsyzy]

@Violienk 建议读一下 SICP 的前言。“家长、老师和军官编程，孩子、学生和士兵被编程。”
或许可以说，这些人是对自己编程，而项目经理则是对 coder 编程。
所以项目经理才是编程人员啊，代码人员算什么编程人员？

[no1xsyzy]

@no1xsyzy 补个 :doge:

[no1xsyzy]

@reus 纠结≠讨论，就是要注意度、不能过分
其实纠结的人多是选择困难症吧哈哈

[reus]

@SwiftFrank 原话奉还给你，“除了看出在喷, 没看出你想表达啥”。呵呵。

[SeaRecluse]

对啊，心中怀着千层封土，结果写出来一个小土堆。这时候才要考虑下要不要上挖掘机，而不是用玩具铲。

[ChefIsAwesome]

我看来是两种“设计”。
一是解决问题方面的。把要解决的某一领域的问题抽象化。设计把大问题拆分成小问题的方案（设计模块的形式，如何组合模块）。
二是 API 设计，配套的工具设计。
举例来讲，rx 是为了解决“流问题“而产生的。作者把连续变化的数据抽象成流。把流封装成 monad。rx 作者精通函数式编程，而这个库本身最早是为了 .net 开发的。rx 之后又在其他语言里实现。不同的语言有不同的开发者，有贴合那个语言使用习惯的 API。

[vipfts]

ctrl+c, ctrl+v

[wutiantong]

“小明是个程序员，Linus 也是个程序员，所以小明和 Linus 大概是差不多的吧。”

这种思考问题的方式就如同家里的长辈听说你是搞 IT 的就把你想象成隔壁电脑维修站的王师傅一般。

[fannuoer]

面向谷歌编程

[yangzhezjgs]

《软件工程》里说的很清楚啊，软件设计可以分为三个层次，高层设计是概要设计，根据约束和关键需求选择软件体系结构和进行逻辑和物理设计，中层设计是模块化，要满足高内聚，低耦合，底层设计才是具体的数据结构和算法。

[wangcansun]

到最后都是 1+1=2，不断的迭代螺旋向前

[EvilCult]

我这话放这里,不管你们讨论出怎样的结果.
我都既不生产代码,也不设计代码,我只是 github 和 stackoverflow 的搬运工.
[狗头][狗头][狗头]

[UIXX]

软件工程包括了软件设计，并不存在什么工程与设计分野的概念。

程序员在一个产品 /项目的实践中，必须面对两种接口，对人接口叫做“设计”，对机器接口叫做“编程”。它们都是程序员的职责。
机器需要“编程”，但不需要程序员的“设计”，你给他什么他执行什么，即使是写了 10000 行机器码来做的循环，只要机器能完成任务，那么这个“编程”，就是对的。如果一个程序编成后不允许浏览，不允许修改，那这段程序并没有“设计”的必要。
但人需要程序员的“设计”，人需要这些代码高性能、可移植、易维护...(无非就是两个点：人需要更好地达到软件工程的目的以及人需要更容易地理解如何更好地达到软件工程的目的)因为这些需求，所以有了软件设计的思想--规则约束、设计模式、框架、工具链...

至于你说的软件项目的失败，那可能的因素有太多了，甚至涉及到软件工程以外的命题，不作讨论。

纠结于语言框架和工具（这里讨论的是真正地考虑框架和工具的特点与优势是否对自己的项目有所提升，而不是杠精），我觉得这本身就是一种站在设计上的考虑，只不过层次更高一点。

最后，一个产品，你觉得它有灵魂，它就有灵魂。

[yangzhezjgs]

感觉楼主根本没有学过软件工程这门课，或者没有理解这门课。。
给你推荐本书南京大学软件学院的教材《软件工程与计算·卷二》，重点看看第四部分软件设计，可能会给你打开一个新世界