在这防疫期间，大家都闲下来了，都 总结总结了。 最近开发一个个人兴趣项目。就总结一下这个项目给我带来的思考。java程序员们，是否有这样情景，使用第三方软件，特别是工具性，框架性的软件，或者jar包。经常报一些莫名其妙的错误。然后再网上搜半天，查半天。实在不行，开官方文档，开原理。甚至去看源码。这样场景熟悉吗？在痛苦中挣扎，侥幸解决了无数问题，却发现还有无数的问题，无数的jar等待着自己。无数的坑在等待自己。疲惫总是会在未来的某一天必定袭来。在无数个疲惫，无数个叹气中，能不能思考一下为什么 ？这个世界真有这么多的问题，真有这么多的坑？
或许java世界出问题了吧，如果是，那究竟问题出在了哪里呢？
我长期的开发经验，和见识，个人有个印象：开发人员有一大部分时间在修改类的定义，存储。现有的JavaWeb开发，不论是基于传统的War包模式，还是SpringBoot的微服务模式。设计类，设计持久层ORM,数据库设计这是占用了30%左右的工作量。特别是开发初期。以及后续的变动，CRUD业务逻辑。
任何一个系统，一个项目都有自己独特的领域，针对这个系统，总是会去设计一套概念，然后再这个系统不断打磨。每跨一个领域。都得去设计这么一套：概念，模型，类体系，持久层，数据库。还得由开发人员不断的调试，联调。在拥抱变化的同时，也得随时进行补充设计，也就意味着，系统需要不断迭代开发，不断的被编译，不断的部署与发版。
多年经验，OOP风格的代码，特别的冗长。冗余。即使是重用相关代码后。在不断重构后，仍然不能从本质上解决这些问题。
OOP最大的问题是任何数据都以类的形势进行表达，这就意味着随着业务的变化，随着结构的变化，不断发展。动态变化的世界，需要这样一群为了满足业务需要，随时更新代码，以达到业务的正常表达。用这样一群人的青春来拥抱变化。道生一，一生二，三生万物，在表达万物的道路上，多少程序员的青春被耗在这生万物的过程中。
开发人员不应当翻译员，不应是传声筒。让着生万物的工作交个相关的业务人员，相关领域的专家和专业人士。
程序员应该是提供这种生的可能，让业务的生，让万物的生，成为一种有迹可循、有规可循的模式。查询员是发现规律，并让规律程序化。架构师，程序，不应该是去堆叠万物，堆叠业务，堆叠信息化的某一种直译编码。良好的重构，重用率高的程序也许要人去做。知识型的项目，重用率高的项目，需要不断的打磨。在直译世界里，我们再多的重构，再多的重用率。都没有从根本上解决这个生万物，造万物，建模万物的直译过程。
java程序就特擅长直译。一一对应世界。 特别是一些数据，数据就是数据，被面向对象的概念给弄成了数据就是对象，对象就是数据。还生成了一套ORM层。然后再ORM的世界里无限沉沦。自我陶醉。
从ORM的世界里离开吧。那么多的Select，Update，Delete,你写的过来嘛？这些都不应该是程序员做的事情。把这部分交给业务人员，运维人员。回归程序设计上来。程序是规律，是大规律，不是细枝末节。细枝末节是业务，业务的东西交给业务人员。
良好的程序，不应该是直译，而应该是知识型，数据型，精简的项目。好的软件，不是直译型项目，软件体积是不会随着业务变化或者成长程正相关增加的。
好的软件，不应该耗掉年轻程序员的梦想，兴趣，爱好，甚至生命。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
