想要的都拥有，失去的都释怀，2020鼠于你
内容目录1，写代码容易吗
代码容易写，也不容易写。但做人不能一直太中立，那我选择好代码不容易写吧。
比如会写字，不一定能写出诗歌词赋。但你说写字难吗，对于牙牙学语时难的，对于现在的你，不难，只不过可能是自成一派，没那么好看。代码要能随着业务成长，方便做出拆分合并更新等，好的代码就要保证正确性前提下有更好的维护性。
说到好代码一般都会涉及设计模式，有些经验的程序员已经不谈设计模式了，因为慢慢都习以为常了，他们开始向架构看去。
模式就是发现一种可识别的规律，比如色彩模式、简历模版也算。模式往往和抽象思维有关，分析事物共性，抽取事物共同的部分来帮助人们认识规律。设计模式就是对事物的重新定位整合来解决问题的一种模版一种套路。它是成熟的解决方案，解决类似的问题。
《设计模式：可复用面向对象软件的基础》一书中描述了23种设计模式。分为三类，创建型结构型行为型，其实都是对对象生命周期的再拆分，把创建过程独立出来，结构组合成功能，行为表达对象之间的交流，比如常用了观察者模式。当然设计模式也不是银弹，拆分会让架构变得复杂，但灵活性提高了，主要应对需求的变化。需求总会变，拆分让关注点分离，也慢慢架构产生了设计模式。
软件生命周期中两个重要的子周期就是开发和运行生命周期。前者为后者服务，结合运行生命周期来决定代码如何组织编写。软件是对现实业务的模拟，虚拟化。运行生命周期就是对业务生命周期的模拟，当然外加上用户访问生命周期。所以如果一个甲方单位的业务组织越清晰，职责越明了，项目相对越容易做。
首先业务模型必须放在后台，用户不去接触的地方，好比你去饭店点餐，菜品的制作流程你是不知晓的，去银行存钱，你也不用关心钱交给柜员后去哪了，你只需关心你账上余额。银行柜员就是对外服务的窗口，用户访问的地方，银行为了效率可能会按业务划分不同的柜台，存钱的一个，办信用卡的一个，其他的一个这样，以满足不同的用户访问。然后业务模型的后面是仓储用于存放状态和数据，其实这就是典型的三层架构，想象一下银行柜台是各种服务接口，柜台玻璃的后边是各种的业务逻辑，再后面的防盗门后面就是金库档案。
用户服务接口一方面要组合业务模型，一方面还要持久化数据，任务太多，代码容易失控，开发人员容易996。这时可以针对用户访问生命周期再做拆分，比如分为业务获取、业务访问、业务保存等，也能提高开发的并行度。
4，技术业务架构百科上已经总结的不错了。技术就是通过人为的创造条件，让指定的规律按照人类的意愿发生。火的发现本是自然打雷闪电产生，当时人类只能靠不停地添加木材来保持火不熄灭。后来发现了钻木取火，钻木就是技术，取火就是业务了。所谓业务，就是要解决人类的问题，目的是为了支撑人类自身的生命周期，使人类获得利益。
技术出现后也就会形成相应的工具。用双手快速转动木棍取火是需要很大的力气和速度的，体质差的人压根生不起来火。就有人采用弓弦来提高转动速度，所以在发现钻木效率不高时，人类对转动生命周期进行拆分，改进转动方式，一只手负责往下压，一只手负责转动，两手的分工产生了架构，拆分形成架构。和企业组织架构一样，企业初期可能只有CEO大小事物全权负责，后面生长为有CTO，运营，人力，研发等组织结构。
首先如果你的软件系统没有分层，那也就没有所谓的轮子，开源世界gayhub对你是没有什么意义的。只有在拆分过程中，才能去匹配是否有恰当的工具轮子，如果拆分到某一层级发现还是没有轮子，就要考虑要不要造轮子了，如果有轮子的功能大于当前拆分的，就看维护这个轮子值不值当了。想敲钉子没有找到锤子时，但发现了高跟鞋，勉强也能敲一敲，但高跟鞋比锤子又昂贵又易耗。如果刚好有恰当的轮子，那可以开开心心安装到自己的系统中，运行过程中发现轮子有些缺陷，着手维护它，就像汽车轮子，你发现每次制动时总会滑行很远，容易撞到，你就可以给它加上一个卡钳制动系统。拆分出来的问题和技术相匹配时，就是最完美的。比如有日志服务，权限管理等。
6，开源