在具体的技术层面,我们拥抱敏捷,精益,全栈和DevOps.软件行业为了探索更高效务实的技术模式已经努力了几十年,也取得了很多成果,我们没有必要拒绝那些被验证过的,对提高开发效率行之有效的技术.
当然,从整个信息产业的历史来看,软件技术处于初级阶段,从汇编(机器)语言到各种被称为第三代的高级语言,思维关注的重点仍然是机器,思路和业务逻辑隐藏在机器的执行流程后面,需要曲折的思维转换才能明白代码执行的目的.曾经被热炒的第四代编程语言并没有真正在实际应用中普及起来.我认为,这种思路和方向是对的,也是软件发展的的必然趋势.但是当时在过度炒作的背后,主要存在的问题的理论深度不够,应用质量不高.
实际上我们有更为源远流长的技术积淀,即函数式编程思想和UNIX编程哲学,老一辈的软件工作者为我们留下来了理论和实践的宝贵财富,却一直没有真正被好好挖掘并推广应用.而在今天,随着硬件性能的提高,网络的发展,软件应用范围的广泛和深入,市场需求和技术环境都在孕育着一场深刻的变革.表面上来看有炒的很火的大数据,云计算,人工智能,实际上深层的根基还是函数理论和UNIX工程哲学.
从各种主流语言纷纷加入lambda表达式,拥抱函数式,到各种函数式编程技术和理论的火热流行,都显示了一股潮流和重要的发展方向.代码应该是声明式的,关心要做什么,而底层的技术提供怎么做,而不是像之前的技术,把业务逻辑和实现混合在一起.这并不是新思想,事实上,不管使用什么技术,优秀的软件都是按照这样的思想去设计和构造的.比如Linux内核的开发,就坚持约定和实现分离的原则.没有这种清晰的划分,软件几乎总是陷于机器结构和执行流程的泥潭中.一般人搞不清楚程序员所做的工作,程序员自己也是在业务和机器的交织中艰难前行.程序员的高收入和高压力也是在这样的环境下也是一种无奈的状态.
所以业务逻辑和机器执行的交织是问题的症结,也是软件行业问题的关键.软件一定是由人所制定的业务逻辑和机器具体的执行流程组成,但是这两者如果没有清晰的划分,混杂在一起,就成为了灾难和隐患.
我的意见是,大部分人,或者说大部分程序员(未来社会人人都是程序员),没有必要关注底层的技术实现,只需要清楚的声明业务逻辑,而少部分框架级的技术人员负责实现框架,解析业务逻辑,和作一些整合,适配以及优化的工作.
理想很美好,但是现在实现到什么程度了呢?根据我使用Java和javascript进行实际业务开发的经历来看,通过使用lambda表达式和filter,map,reduced等高阶函数,在代码中几乎不会出现需要手动控制的循环.某些业务需要根据条件停止遍历,也可以使用更为完备的函数式库来解决.这样整体代码逻辑非常清晰易读.并且在熟悉了函数式思想之后,各种语言间的差别多数也只是lambda的语法细节,思路是一致的.还有一个较大的差别就是类型系统.我的建议是,如果够用的话,优先使用动态弱类型,在确有必要的情况下,使用强类型实现代码控制.尤其是在创业初期,需要快速实现功能,使用动态类型可以显著提高开发效率.等业务扩大之后,再根据情况适时重构.
当然,实际的业务场景可能更加复杂多变.但是根据二八法则,首先我们应该关注最常用的20%,基本涵盖了80%的业务场景.降低了这部分代码的复杂度,投入不高但收效显著.其他场景,如果遇到,多数情况下也可以通过简单方法的组合和变通解决.随着对业务的熟悉和经验的积累,一个零经验的学习者是可以在完成基本工作的情况下快速学习和成长的.
下面附上一些最近探索的快速开发技术,感谢各位开源作者.
Java: spring boot, spring data(重要的子项目有Jpa,rest), spring roo
Javascript: restSql alasql metetor vue wepy mpvue weweb
语言: kotlin clojure
运维: k8s nginx
版本控制: git
IDE: IntelJ Idea
看起来项数不少,但是每一项只关注基础操作都不用太长时间,基础操作熟练之后,通过模仿,练习和指导足以完成一般的开发任务,随着时间在更多实践和学习后也会持续获得更强的技术能力.降低技术的准入门槛,一方面可以减少软件的开发成本,另一方面减少了软件人才的培养成本,对于软件行业的发展来说是必要且可行的道路.
更多关于UNIX编程哲学的内容,请参考:林鹏程财务分析软件.
网友评论