有没有某种方法或工具让编程变得又简单又高效？

我一直在寻找，希望能找到某种方法，或是某种工具，亦或是某种框架可以让编程变得又简单又高效，从目前来看，似乎是没有的。做起来简单的往往不高效，做起来高效的往往不简单。

mingdu.zheng at gmail dot com
https://blog.csdn.net/zoomdy/article/details/88744004

不说编程，举个简单的例子：挖土。最简单的办法就是拿把铁锹开始挖，这真的很简单，不需要任何智商吧，但明显没有效率。高效率的办法是用挖机，开挖机可是个技术活，不是谁都会开的，要先学会怎么开挖机才行，此外还需要花资金购买或租赁挖机。

高效率意味着首先要高投入，学习成本的投入，工具成本的投入。高投入才可能获得高回报，或许这才是靠谱的。

就编程而言，想提高效率就要在更高的抽象层次上做设计。从机器语言到汇编语言再到高级语言，从面向过程到面向对象到面向构件，都是在提升抽象的层次。抽象层次的提升也意味着，在着手开始干活之前要学习掌握更多的内容，还有工具。如果用汇编语言编程，那只要有汇编器和链接器就够了，使用高级语言编程还要编译器，编译器可比汇编器复杂多了。有个疑问，汇编语言简单还是高级语言（就说C语言吧）简单？

要实现需求，可以从头开始自己做，也可以在现有构件的基础上做。如果完全自己做，那就是效率的问题了，嵌入式软件可能还能这么干，毕竟代码量是比较少的，如果是手机App之类的，等自己做出来了，也没有存在的价值了，市场不等人啊。在现有的构件上做，那就是学习成本投入的问题了，如果选用商用构件，还得花钱，不过现在开源的构件也很多很不错。

要高效，那就要站在前辈的肩膀上，想要爬上前辈的肩膀那也是不容易的，是要刻苦学习的。我想学习前辈的成果总比自己去做出这样的成果要省力吧。我们做软件的，学会使用前辈做好的构件总比自己创造省力吧。

从C到C++

C++是C的超集，理论上讲C++能实现的用C语言也都能实现，不过很多东西要手工处理，例如虚函数，这在C语言中本来是没有的，通过函数指针表可以模拟出虚函数来，而在C++中则是语言本身就支持的，编译器会自动处理虚函数表。显然使用C++更高效，当然C++学起来也相对困难一些，虚函数、模版、友元等等，很多C语言里面没有的东西。C比较简单但是不高效（我指开发效率，不是运行效率），C++比较高效但是不简单。这能不能证明我前面的观点：简单和高效是矛盾的？

从C++到Java

Java从C++演化而来，但自立门户。Java抛弃了C++中很多令人生畏的东西，例如指针和动态内存管理。而且引入了虚拟机，简化了程序员在跨平台方面的工作。Java比C++更简单了，Java也比C++更高效了（还是指开发效率）。Java是怎么做到的？把一部分原本属于程序员干的活交给解释器了？

从Java到Groovy

Groovy是兼容Java语法的动态语言，连变量类型声明的活都交给解释器了？比Java简单高效啊！把例行任务交给自动化工具来完成是否可以既简化编程又提高效率呢？Java和Groovy似乎都是把本来属于程序员的工作交给解释器了，这样程序员可以专注于业务逻辑而不是例行任务。

从编译型的C++到解释型的Java，从静态类型的Java到动态类型的Groovy，这都是抽象层次的提升，抽象层次的提升让编程变得又简单又高效！

提高抽象层次可以又简单又高效？我觉得提高抽象层次可以提升效率是肯定的，但不见得会更简单，如果抽象层次越高越简单的话，那系统架构是不是就很简单呢，架构是高层次的设计啊。

抽象层次在某个中间高度和人类思维习惯最匹配，在这个中间高度，给人感觉是最简单的。就像物质世界，太大的东西，比如地球，显然是难以被认识的，太小的东西，比如分子，也是比较难被认识的，和人体差不多一个量级的就比较容易认识。

要高效就要不断提高抽象层次，要简单就要找到和人类思维习惯最匹配的抽象层次，“对象”是否和人类思维习惯相匹配？那么“事件”呢？“活动对象”？直观！直观的东西是最简单的，宏观的和微观的都是要经过学习才能掌握的！

复杂度转移

假如开发出了自动驾驶挖机，那是不是就没有驾驶员驾驶挖机这件事了，本来驾驶员驾驶挖机是一件复杂的任务，现在有了自动驾驶，这个复杂任务被转移到了自动驾驶系统那里。C++程序员需要手动管理动态内存的分配，到了Java由垃圾回收机制来处理这个任务，内存管理的任务从程序员转移到了解释器。Java程序员要处理类型问题，到了Groovy，类型问题由解释器来处理了，类型问题从程序员转移到了解释器。伴随抽象层次提高的是复杂度的转移，复杂度从程序员那里转移到了工具开发人员那里。事，就那么多，不会少去，也不会多起来，无非是谁来完成。需求决定了复杂度，复杂度可能在应用层，也可能在系统层。如果复杂度可以从应用层转移到系统层那是最好的，因为系统层的应用范围更广泛，更具有通用性，复杂度转移到系统层，那就简化了应用层。也可以理解成复杂度分解后的映射问题，需求就是这么复杂，将哪些部分映射到应用层，哪些部分映射到系统层，这是架构师要做的事情。映射到系统层的复杂度比例高了，映射到应用层的复杂度比例就低了。