分享一下，自己关于一个项目的编程思路，和大家交流一下，希望多多指正。

在某篇文章看到过，编程是对已存在的规律逻辑，进行了进一步思考，以达到和使用者分离。在这个过程中，前人已经有了丰富的方法论。那么学会这些，有一些依靠经验来达到的事情，就可以短时间按轻易达到。
我自己 在编程小白到自己设计项目的流程中。心理路程，从被动的需要人带（来个大神带我呗），到舔着脸找别人学习，一直到现在自己主动的读书思考。 现有这篇文章，自己个人的编程思路。分享下，希望对大家有所帮助，也希望有人指正下我的思路误区。

1. 编程第一个攻克难点，需求分析，看了很多书，采用面向对象分析。

将产品的需求列出来

2. 寻找合适的对象，分析业务

3. 会惊奇的发现，对象就是数据库，数据库的字段就是他的属性。

上面的例子只是简单的逻辑，不这样做一般也可以做出。但是，当有做特别复杂的业务模块的时候，只是想想就不行了，没有经历过几个项目经验的，一年半载的不敢下手。但是，在公司能经历完整项目的好事少。

4. 框架中sql的写法

既然已经知道数据库就是对象，那么ORM的使用，与理解，简直水到渠成。再让你写DB，或者原生，简直是煎熬。

5.业务写在哪里好

初学时喜欢写在controller，之后想写在model，这样更方便复用。时间长了，我发现传说中的23中设计模式，好像非常遥远。感觉能写框架的简直神了。
而且，公司程序总在迭代，写在model中的业务函数，缺少向前兼容的良好设计。只能新建函数，最后发现一大堆函数，难以理解，代码长得雷人。
我的解决思路，再来一层，写业务。业务层怎么写，一个功能一个类，前面的restful controller对外接口调用就好。23中设计模式什么的，也能看明白，懂起来很快了。最近这样使用，感觉到了好处。比如我使用责任链模式，这个设计向前兼容性非常好。也整洁好管理。在我对项目思考中，到现在已经充满了一切皆对象的概念。但是，这方面经验生涩，写的类不如我意。

这个选择，不知道是否对的，希望大家指点下

6. 不用说了，组建化开发嘛

7. 项目的模式选择，采用分布式项目，对接口的进一步解耦

分布式项目，以服务为主体，每个接口都有潜在的被使用的机会。这个是比mvc要好，可以轻易的嫁接各个平台使用。

8. 分布式项目的思考

1.通信模式选择，Java有二进制、HTTP，RPC、Socket，也有框架花样多。咱PHP也有HTTP、Socket、还有一个好引擎Swoole（怎么使用，我还不知道呢。暂且咱用curl发送HTTP，留以后研究）
2.序列化的思考，看了一些书，对于序列化和反序列化有很多例子。


选自分《布式服务框架原理与实践》
Protobuf咱PHP有，Json也不错而且大家一般都懂。

10.剩下就是加上前端，码代码了

11.最近盛传微服务，那么怎么分这个服务，有点自己的想法

我们的功能，皆由对象组合而成。而我们的对象其实，是一组一组来着的。就好比我们人，有手和脚，但是我们的系统有呼吸道系统，内分泌系统等等。通过，本文前三步骤分析项目，你能非常清楚的感觉到，也能非常清晰的划分其中边界。提出来，每个系统做一个服务。至于注册服务，发现服务等，从未接触过，无从思考，等以后什么时候想通在另作分享

12.完成一些项目自然还要一些别的东西
搭建GItLab使用git呀，搭建nginx环境呀。使用jenkins部署项目。
一些面试常有的，什么redis，消息队列，常驻任务等等....
最近在看Docker...这些东西网上都有教程，以后有时间我也会做分享...

这就是我最近几个月思考结果，其中过程，没有人带我教我，周围伙伴也不甚理解我的想法，还有说我这样写的麻烦。这些都是自己摸索中过来的。分享出来，大家都是高手，希望你们，看看我的思维有没有跑偏。万一我没跑到正道，帮一下，把我掰回来