我发现,有很多知名的项目都是一些大佬程序员发起、设计并且完成第一版的
等等
这些项目有的发展至今可能绝大多数代码已经不是原作者写的,但是似乎看起来没太多变化
我前一段时间看到一句话
程序源代码其实是给人阅读的,只是恰好机器可以编译运行而已
这个有点夸张了,但是换句话说,程序员写的代码只是承载程序员对程序的设计,程序员的主业应当是设计,而非编程:
程序员应当是程序设计师
比如,设计一个社区软件,比如 V2EX,Livid 更多的可能需要去设计社区的一些原则,用户如何交流(比如不允许用户删帖😂)等。然后把这些设计转化成程序,如果哪天 V2EX 不用 Python 写了,用更加新兴的语言重构,V2EX 依然是 V2EX
所以我看到一些程序员纠结语言框架和工具,其实如果没有设计和思想,做出的东西会不会东施效颦、毫无灵魂呢?
或者当我们真正要去做出一个东西,是不是应该让我们先具备像超人程序员那样的执行力(或整合资源的能力)?
有人提到软件工程,我认为软件开发和工程的差异性远比相似性大
可能正是“设计”和“工程”分野这种思想,导致了很多软件项目的失败(尤其是外包)
1
Violienk 2018-11-22 10:07:04 +08:00 1
从根本角度来说,这些人是技术层面的产品经理
creater builder designer programmer code famer project manager 这些都是区别的 |
2
Yanni0507 2018-11-22 10:14:52 +08:00 1
袁隆平先生和我老家隔壁老头都是种田的,那隔壁老头想种点口粮,怕不是得先研究杂交育种哦?
|
3
no1xsyzy 2018-11-22 10:20:15 +08:00 1
编程是一门古老艺术的别名,那门古老的艺术名字叫思考。
语言框架和工具 唯一的功能就是表达思想。至于其中的选择,就是尽可能不拖累其他的东西(包括不拖累你的思考(开发效率)、以及不拖累机器的理解(运行效率))。 (不存在哪个语言可以使得你产生新的思想,如果你发现了这一情况,那只是你以前用的语言拖累了你的思想。但思想永远会被语言所限制,所以你只能让它尽可能不拖累。) 最不拖累思考的语言是伪代码。最不拖累机器的理解的语言是机器语言。 其他大部分都在这两极之间。但并不是说一侧是 (1, 0) 另一侧是 (0, 1) 中间的全都是 (x, 1-x),可以有 (0.9, 0.9) 这样的神器(可能 chez scheme ?),也可以有 (0.1, 0.1) 这样的废物(求例子)。 |
4
reus 2018-11-22 10:20:28 +08:00
什么鬼逻辑,语言和框架难道和架构是对立的?讨论语言和框架,难道就等于无视架构设计?
你不编码实现不试验,怎么知道设计有没有问题?实现到一半,发现所用语言或者框架没法好好地将设计表达出来,难道不是语言和框架有局限性?难道在实现之前讨论下工具,和设计就有冲突了? 可以类比为建筑结构设计和工程施工,你有好的设计,就不需要良好的施工了?讨论施工技术,就等于不重视设计了?设计难道不需要考虑现有的施工技术? |
5
suzic 2018-11-22 10:27:28 +08:00
《程序设计与软件开发》 本来就包含“设计”
|
6
SwiftFrank 2018-11-22 10:30:36 +08:00
@reus 你楼上的回复是(0.9, 0.9), 你的回复就是那(0.1, 0.1)除了看出在喷, 没看出你想表达啥
|
7
no1xsyzy 2018-11-22 10:33:19 +08:00
@Violienk 建议读一下 SICP 的前言。“家长、老师和军官编程,孩子、学生和士兵被编程。”
或许可以说,这些人是对自己编程,而项目经理则是对 coder 编程。 所以项目经理才是编程人员啊,代码人员算什么编程人员? |
10
reus 2018-11-22 10:37:26 +08:00
@SwiftFrank 原话奉还给你,“除了看出在喷, 没看出你想表达啥”。呵呵。
|
11
SeaRecluse 2018-11-22 10:42:58 +08:00
对啊,心中怀着千层封土,结果写出来一个小土堆。这时候才要考虑下要不要上挖掘机,而不是用玩具铲。
|
12
ChefIsAwesome 2018-11-22 10:47:04 +08:00 via Android
我看来是两种“设计”。
一是解决问题方面的。把要解决的某一领域的问题抽象化。设计把大问题拆分成小问题的方案(设计模块的形式,如何组合模块)。 二是 API 设计,配套的工具设计。 举例来讲,rx 是为了解决“流问题“而产生的。作者把连续变化的数据抽象成流。把流封装成 monad。rx 作者精通函数式编程,而这个库本身最早是为了 .net 开发的。rx 之后又在其他语言里实现。不同的语言有不同的开发者,有贴合那个语言使用习惯的 API。 |
13
vipfts 2018-11-22 10:52:07 +08:00
ctrl+c, ctrl+v
|
14
wutiantong 2018-11-22 10:56:38 +08:00 1
“小明是个程序员,Linus 也是个程序员,所以小明和 Linus 大概是差不多的吧。”
这种思考问题的方式就如同家里的长辈听说你是搞 IT 的就把你想象成隔壁电脑维修站的王师傅一般。 |
15
fannuoer 2018-11-22 11:05:04 +08:00
面向谷歌编程
|
16
yangzhezjgs 2018-11-22 11:09:43 +08:00 via Android
《软件工程》里说的很清楚啊,软件设计可以分为三个层次,高层设计是概要设计,根据约束和关键需求选择软件体系结构和进行逻辑和物理设计,中层设计是模块化,要满足高内聚,低耦合,底层设计才是具体的数据结构和算法。
|
17
wangcansun 2018-11-22 11:13:47 +08:00
到最后都是 1+1=2,不断的迭代螺旋向前
|
18
EvilCult 2018-11-22 13:11:19 +08:00
我这话放这里,不管你们讨论出怎样的结果.
我都既不生产代码,也不设计代码,我只是 github 和 stackoverflow 的搬运工. [狗头][狗头][狗头] |
19
UIXX 2018-11-22 14:07:28 +08:00
软件工程包括了软件设计,并不存在什么工程与设计分野的概念。
程序员在一个产品 /项目的实践中,必须面对两种接口,对人接口叫做“设计”,对机器接口叫做“编程”。它们都是程序员的职责。 机器需要“编程”,但不需要程序员的“设计”,你给他什么他执行什么,即使是写了 10000 行机器码来做的循环,只要机器能完成任务,那么这个“编程”,就是对的。如果一个程序编成后不允许浏览,不允许修改,那这段程序并没有“设计”的必要。 但人需要程序员的“设计”,人需要这些代码高性能、可移植、易维护...(无非就是两个点:人需要更好地达到软件工程的目的以及人需要更容易地理解如何更好地达到软件工程的目的)因为这些需求,所以有了软件设计的思想--规则约束、设计模式、框架、工具链... 至于你说的软件项目的失败,那可能的因素有太多了,甚至涉及到软件工程以外的命题,不作讨论。 纠结于语言框架和工具(这里讨论的是真正地考虑框架和工具的特点与优势是否对自己的项目有所提升,而不是杠精),我觉得这本身就是一种站在设计上的考虑,只不过层次更高一点。 最后,一个产品,你觉得它有灵魂,它就有灵魂。 |
20
yangzhezjgs 2018-11-22 14:23:54 +08:00 via Android
感觉楼主根本没有学过软件工程这门课,或者没有理解这门课。。
给你推荐本书南京大学软件学院的教材《软件工程与计算·卷二》,重点看看第四部分软件设计,可能会给你打开一个新世界 |
21
murmur 2018-11-22 14:24:25 +08:00
面向 stackoverflow & google 开发
|
22
twoyuan 2018-11-22 14:33:46 +08:00
Full Stack Developer 和 Full StackOverflow Developer 的区别
|
23
jackchao7432 2018-11-22 15:15:36 +08:00
谬论
|
26
sammo 2018-11-22 16:26:11 +08:00
又在给自己贴金了。
很多软件模块的原理,不是正常人类思维的原理,需要额外理解 ( 更像是电子电器元件的原理 ) 。总之 最后拼出来的东西,是违反正常人类思维的 ( 电子电器元件的原理,是真实存在的,和人类思维不同 ) 。 不存在 “代码是写给人看的、然后是写给机器看的” 这回事 |
27
sammo 2018-11-22 16:28:57 +08:00
如果不遵循电子电器元件的原理,做出来的程序直接烧电路板,懂吗? coding 没有这么严重的后果而已,运行带 bug 的程序 不会直接把电脑烧掉。
|
28
sammo 2018-11-22 16:34:05 +08:00
1000 块的 FPGA 板子,一个程序 写挂了,板子烧了,1000 块买的东西 一个程序把板子跑烧了 白玩了。1000 块,说没就没阿!说着什么 “代码是写给人看的” 都是不知道这世界的残酷的。
|
29
youngster 2018-11-22 16:47:40 +08:00
术业有专攻好吧,永远不要低估“专业”这两个字。
|