-
Notifications
You must be signed in to change notification settings - Fork 761
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
老码农的技术理想 #16
Comments
刚才我老婆还我让我帮他侄子选一下专业,我脱口就说了一句软件开发已经饱和了,其实只是不希望他当个码农罢了 |
来看看 |
很启发人啊. 十年后编程肯定是完全不同的样子, 从现在的 Wolframe 语言, LightTable 和 Eve, Google 的 Polymer 图形制作工具, 还有 Bret Victor 设计的那些交互软件, 可以看出来已经有一部分新方法正在成为现实. "DSL和二次开发平台"这个真是啊, 编程语言之所以能够大行其道, 很大的原因就是能抽象出函数或者模块, 这些函数或者模块只需要知道外部传递的条件, 而不需要了解外部其他的所有细节的条件, 而能实现重用. 这种提升效率的方案也将出现在人们的分工当中, 把一份工作拆分成两层, 经常就给分工协作提升效率创造了空间. "高楼造一半改需求"这个例子太好笑了, 我也多少次觉得被这种问题郁闷到. 不过也许软件现在因为太小吧, 我觉得这样比更合适, 就是同时在造楼跟装修, 有些需求是钢筋混凝土, 有的需要是墙体装修.. 那么设计架构的时候想明白点还是能改一下的. 另外那个开放的问题实在没法想清楚, 十年后各种职业跟写程序的关系怎样, 现在的程序员到时候会出现怎样的分工, 渗透到哪些领域当中? |
我也有这样的理想 |
从过去中预测未来 |
只会用linux的vim和emacs开发的人路过。 |
我也是一直linux+vim,不过,思想不分平台 |
@bjzhush 这句话好屌 |
程序员比业务人员稀缺,很贵。所有老板想让程序员,懂业务。就变得不稀缺了,就便宜了。 |
从坑里来,到坑里去 |
徐总想的好多,看来最适合走技术型路线。 |
专业ios外包 |
对于dsl的看法和你不谋而合,我现在正在尝试实现你文章中提到的,“技术人员和业务人员一起定义DSL,技术人员负责DSL的底层平台实现,业务人员负责使用它来构建业务模型和业务流程,甚至业务界面”。希望能做点东西出来,让大家看到这种思路是可行的 |
受教了 |
分析的够深刻,尤其是面对企业的业务系统、管理软件,不论是客户还是开发者,有时候都忽视的需求变更所带来的高昂代价。在这一个领域,未来不久,我相信,势必会出现像您说的那样,只要客户懂业务,愿意去学习一定的DSL等编程方面的知识,就可以自己主导建立自己的管理软件。而且,那个时候,这种客户业务级的变更,成本应该会下探到一个非常低的水平。 |
“回头看自己觉得当时很天真” 这就是人成长的必然状态吧~ |
支持一下理想 |
感觉BPM系统如processmaker很符合飞哥的二次开发平台的描述。 |
让业务人员也参与软件研发过程,是有很多软件企业搞过二次开发平台,二次开发门槛有所降低,但还是存在软件抽象思考要求,还是有一套规范和规则需要学习掌握,实际上业务人员还是没有能力参与,基本是客户企业内部又养了一些开发人员来搞二次开次开发。这只不过是开发成本转移了,但这是这种理想要的结果吗?而且很多实际二次开发都是微乎其微的细枝末节调整,相比建设这种平台付出的复杂性成本,不是太划算。 |
马克· |
看完这篇文章,我想静静 |
C语言永远不倒! |
回头一想,已经敲了九年代码了...时间过的真快 |
开头三个字“小时候”改成“在我小学二年级的时候”,会不会很有趣呢,和后面提到信息化的程度相当于小学二年级对应起来了:smile: |
06年的徐老师就已经想的这么多了! |
06年我刚上大学,转眼十年了,软件定义未来 |
写的真好 |
写的不错 |
我是个想当码农的财务,当时报考大学志愿的时候,所有人都不希望我做程序员,最后屈服了,现在做财务,还是有一颗不忘code的心 |
因为在土木行业无法实现技术理想,毕业半年后下定决心转软件行业,但那时候实在找不到愿意面试我的软件公司,除了对日外包,最后就靠日语进了个外包公司,但做了一年多之后感觉很迷茫,技术能力实在是提不上去了。想好好提下自己的编程能力,时机成熟了去找一家有技术氛围的公司重新开始。 |
想学code就只管学就好了,个人觉得如此开源的时代,学起来还真是方便啊。 |
比如说,一个有经验的仓库保管员,可能文化程度不高,理解不了软件的运行原理之类,但一定对产品出库入库的流程非常熟悉,包括各种审批过程和异常状况,但这些,程序员是不懂的。那如果要促进这个领域的信息化,必然要在两者之间寻找一个结合点,程序员可以学业务,业务人员也可以尝试参与软件研发过程,目前来说,都是前者比较多,因为程序员相对来说还是比较年轻,学东西快些。但从整体社会效益来说,这其实是不利的,因为程序员是更稀缺资源,而传统业务人员非常多。 |
感觉初心没变 |
未来值得期待! |
大多数人生活中阴沟里,但总有人仰望星空 |
已经被需求逼迫得没有理想了,只想用健康换一套房子。 |
还是希望自己能写代码写到60岁 |
我的技术理想是能把我自己的意识电子化。哈哈,希望几百年后技术成真 |
真想一直写下去… |
所以徐飞大佬如今还看好 trantor 吗? 😂😂😂 |
这是来自QQ邮箱的自动回复邮件。
您好,您的邮件我已收到,谢谢!
|
你已经成功召唤了小龙虾
|
这是来自QQ邮箱的自动回复邮件。您好,我是董永*,我已经收到你的邮件,我会尽快给您回复。
|
哇,受教了(╹ڡ╹ ) |
这是来自QQ邮箱的自动回复邮件。您好,我是董永*,我已经收到你的邮件,我会尽快给您回复。
|
你已经成功召唤了小龙虾
|
现在就是接近2025年的时间,2023 低代码平台大火。懂业务也可以实现简单的系统,2025年想必那时候比较成熟了 |
这是来自QQ邮箱的自动回复邮件。您好,我是董永*,我已经收到你的邮件,我会尽快给您回复。
|
你已经成功召唤了小龙虾
|
现在是2023,chatGPT可以理解自然语言并且输出代码了 |
这是来自QQ邮箱的自动回复邮件。您好,我是董永*,我已经收到你的邮件,我会尽快给您回复。
|
你已经成功召唤了小龙虾
|
我也在积极的运用gpt,已经离不开他了。六个月前我无法想象这一切,太神奇奇妙了 |
加油 |
这是来自QQ邮箱的自动回复邮件。您好,我是董**,我已经收到你的邮件,我会尽快给您回复。
|
你已经成功召唤了小龙虾
|
老码农的技术理想
小时候,老师问我,你的理想是什么?我不假思索说是工程师,于是长大之后果然成了工程师。
工作这么多年,一直在思考工程师这三个字的意义,终于有一天恍然大悟,原来就是:用技术手段改进世界。
那么,在软件方面,目前的世界有哪些问题需要解决呢?有这么一些问题可以思考:
我想说说自己对这几个问题的理解。
虽然现在我们的生活与十年前相比,已经发生了巨大变化,比如智能手持设备已经非常普及,可穿戴设备也在蓬勃发展。十年前我们用手机收发短信或者邮件,浏览非常简单而老土的wap页面,但现在,绝大部分人的手机已经取代了电脑,成为日常生活中不可缺少的工具。
我们用手机交流,购物,欣赏影视,阅读书籍,玩各类游戏,尤其是飞速发展的移动购物和支付体系,使得我们能在任意场合购买心仪的物品,订购旅游服务和宾馆,叫快餐,打车等等,生活非常美好,那么,整个世界的信息化程度处于什么级别呢?
我觉得,才刚刚相当于小学二年级,整个世界的信息化程度仍然严重偏低。从现在算起,往前10年,往后10年,这20年时间中,面向个人的信息化服务处于高速发展期,这个领域非常吸引眼球,因为它与每个人的生活息息相关。可是,另外有一些领域,却非常需要发展,那就是传统行业的信息化。
之前有不少传统行业,进行了一定程度的信息化,但这个信息化仅仅能满足自身运作的基本要求,当它与整个社会的潮流相对接的时候,就显得非常落后,迟缓。比如说在网购这个大体系中,普通用户所能看到的是商品展示,比价,下单的过程,但背后的核心环节却是配货与物流。
我还在上学的时候,有老师这么说过,现在计算机行业非常火热,很可能要饱和了,你们不一定非要从事这方面的工作。现在回头看这句话,觉得很有趣,人真的很难有眼光看到未来。去年我入职苏宁培训的时候,孙为民副总讲了当年一个决策失误的例子。90年代末,公司统计发现全国空调的年销售量达到数百万台,觉得很可怕,这个行业可能要饱和,估计要再想办法拓展别的商品经营了,但现在,全国空调的保有量为七亿台,即使完全没有新增,十年换一轮,每年也卖得出去七千万台,当年凭什么说这就饱和了?
所以我现在看程序员的状况,仍然是供不应求,尤其是高端程序员,十分抢手。这个问题的背景就是全社会的信息化进程在加速,之前的程序员人数远远跟不上需求量。
那么,如何解决这个问题呢?一方面是继续培训,促使更多新人来到这个行业,并且认真做下去,另外还有一些别的手段需要考虑。
我想追问一个问题:世界上懂业务的人多,还是懂技术的人多?很明显,懂业务的人要多很多,什么叫业务?其实就是行业常识,生活经验。
比如说,一个有经验的仓库保管员,可能文化程度不高,理解不了软件的运行原理之类,但一定对产品出库入库的流程非常熟悉,包括各种审批过程和异常状况,但这些,程序员是不懂的。那如果要促进这个领域的信息化,必然要在两者之间寻找一个结合点,程序员可以学业务,业务人员也可以尝试参与软件研发过程,目前来说,都是前者比较多,因为程序员相对来说还是比较年轻,学东西快些。但从整体社会效益来说,这其实是不利的,因为程序员是更稀缺资源,而传统业务人员非常多。
之前见过一个问题:如何让业务人员更好地参与软件研发过程。这个问题的根本解决方法是DSL(Domain Specific Language),核心解决方案是二次开发平台。
什么是DSL和二次开发平台呢,这两个词听上去很高端,但其实大家有很常用的东西就属于这个范畴,比如Excel,它提供了各种各样的公式,还有VBA,使用这些东西的人绝大部分不是软件行业的,Excel就是一种很成功的二次开发平台,公式和VBA就可以算DSL了。
很多时候这些东西还不够直观,我们可以看到一些图形化的编程语言,比如Scratch,现在很多小学生的兴趣班就会学,这些东西相对学起来就比较容易了,我们也可以做一些类似的抽象,以图形化的方式让业务人员能够参与,比如流程配置等等。图形化的东西,是最适合非技术人员理解的。
所以,要促进社会的信息化程度,最好是能够想办法把各行业的业务人员都拖进来一起搞。具体的分工大致是:技术人员和业务人员一起定义DSL,技术人员负责DSL的底层平台实现,业务人员负责使用它来构建业务模型和业务流程,甚至业务界面。
那么,软件行业的生产力是偏高还是偏低呢?我认为严重偏低。什么叫严重偏低?如果以机械力量的变革来对比,软件行业目前的生产力水平处于蒸汽机发明之前。也就是说,生产力远远没有被解放,大家做的大部分东西将来是会被机械化的,不再需要这么多人来做这么重复的劳动。可能很多人会对这段话不满,怎么就重复劳动了,你说说我做的什么是可以被机器替代的?
换个角度看,为什么几乎所有外行都觉得软件贵呢?因为人力成本太高了,他们觉得,做出这么多东西,应该是不需要这么多时间。为什么双方的反差这么大呢?
我觉得其中的关键点在于绝大部分工作的抽象程度严重不足,另外有很大一部分效率损失在编程平台或编程语言的不完善,比如Web前端。
从第一代到第四代编程语言,每一代都是损失一定运行效率,而大幅提升编写效率。随着硬件技术的发展,软件编程必然越来越粗放,大的趋势是不特别重视细节效率,只要没有数量级的性能损耗。
所以我们可以预期,会有越来越多的人使用一些运行效率相对不怎么高的语言或框架,只是为了提高单位时间的生产力。从老板们角度想,也会明白,提升运行机器的性能,要比多雇几个程序员便宜多了。因此,从整体趋势看,追求细节性能的程序员们恐怕会离自己的理想越来越远了,除非是在某些特定领域。
那么,绝大部分软件系统都可靠吗?我换一句话来问:各位程序员朋友,如果你们住的房子质量跟你们正在做的软件一样,你敢住吗?感觉大家都在笑,笑是什么意思,我们都懂的。
那为什么软件系统的质量不容易高呢?我觉得主要原因是流程不完善。那为什么不完善?需求容易变。为什么容易变?是因为不论程序员自己,还是需求方,其实潜意识都认为自己做的东西是变更成本较低的。
试想一下,为什么没人在盖高楼盖一半变更需求?为什么没人修大桥修一半变更需求?甚至做衣服做一半的时候变更需求,理发到一半变更需求,都会被人认为是不讲理。但是在软件领域,好像这倒成了普遍现象。
因为整个软件系统的实现,都是虚拟的,看不见摸不着,并不消耗什么物料,所以从这个角度想,变起来当然是容易的。但软件系统的架构,其实也跟实体的没本质区别,变更时候要考虑很多关联因素,并不是就那么孤立的看一小块地方,当然,也会有一些不影响全局的变更。打个比方说,如果你在盖房子盖到一半,那变更外墙颜色肯定是要比变更窗户大小容易的。要是想变得太多,估计只好拆了重来。
我见过不少公司是通过加强测试的方式来试图控制质量,但个人觉得这种方式不划算,而且收效不高。要想很好地应对需求变更,很重要的一点就是不要有这个软件一定不会改的想法,然后,从架构上做拆分,隔离,组件化等等,力争做到即使要改,也只改某一块的内部,不影响别的地方。
很多软件公司,一方面不注重架构的设计与宣贯,导致变更的时候问题多多,程序员也不能很好领会架构意图,一方面忽视整个过程中对架构的管控,认为架构只是最初那张静态图。
任何一种架构方案,都需要一个良好的管控机制。没有哪个盖大楼的只认真管设计图纸,不控制施工过程。架构其实是跟施工过程严格相关的,架构并不是一张扁平的图,而是一个立体的东西,作为整个系统工程的骨架。如果能在开发的时候看到这个骨架逐渐建立,血肉充盈的过程,对整个系统的成功把握一定会大得多,这也就是开发过程中架构管控的理念,具体实现要依赖于不同场景。
所以,将来的软件开发方案,一定是会朝着几个方向发展:
有时候看现在的小孩子,会觉得他们很幸福,因为等他们这代长大,就不需要像我们现在这样编写程序了,那时候,编程已经成了一种令人习以为常的通用技能,就像现在的人用Office软件一样,所谓的编程,很可能已经不需要敲代码了,而是图形化,设置几个参数就完事了。
后记:昨晚翻以前写的东西,翻到06年写的一篇,挺有意思的,看自己年轻时候写的东西,总是挺多感慨。当年的自己充满对未来的向往,激情澎湃,十足的微软粉啊。那时候的工作基本是在用Java,不过个人还是一直关注着微软技术的发展。写完今天这篇,再对比当年的最后一段,虽然那时候有些幼稚,认识问题不深刻,所幸的是初心未改!
贴后面给大家看看:
The text was updated successfully, but these errors were encountered: