再出发
June 25, 2018
永远都不要太乐观，也别放弃 最近一段时间作为一个完整的开发工程师来做一个项目，一方便希望能经过一个完整的项目的锻炼把自己的工程底子建立一下，总不能一直飘在算法上，还是要掌握程序员的最低生存本钱的。 这一次的工程算是一个比较熟悉的，依然是Online Judge，只是这次不再是以一个极客的思维来对待，而是以一个解决问题的工程师的身份。 曾经用极客的思维去考虑这些部分，心里想的是怎么造出更好的轮子。在这个过程中其实需要学习很多底层的东西，尤其是对于Judge核心的设计和实现是要很多关于操作系统的交互。 但是到最后也没能自己搞出来什么比较好的东西，只能说是搞了一些还不错的玩具出来了。同时对底层的一些机制有了个粗浅的理解。 我本质是非常喜欢打通基本的原理的，有些东西没有搞懂总是不太想去动手，怕自己走歪了路，搞得不专业了。这样的追求是我的喜好，并不能作为一个常态存在，因为毕竟学无止境，更多的时候应该是做一个工程师存在。工程师是要 能够非常高效且优质的组织资源去解决问题的，而不是纠结在底层的原理如何如何。当然越是经验丰富、知识扎实的工程师的组织能力越强。 这次我的主要尝试选择了两个我比较看好的，也处于中间状态的技术： 前端： react、redux、node 后端： jerey、tomcat、redis、mysql、mybatis 前后端完全分离的架构 这样的技术选择其实是面有点大的，基本涵盖了整个前后端，因此这个项目的周期中会遇到许许多多的实际问题。 主要的会表现在： 前端 # react体系的架构 项目结构的设计 UI操作 浏览器相关问题 异步请求 这其中前期已经基本能用起来的react体系，算是已经过了一关，后面的浏览器相关的异步请求让我感觉有点头大。 一方面用的不是传统的ajax，是新兴的fetch。在使用fetch的时候又使用了redux-api的库，这个库国内很少人使用，基本没有中文的文档也没有什么人踩坑的经验，所以在理解和使用的时候都很慢。 不过这个过程中也让我学会了怎么去接触一个新的库，其实看文档是一方面，更快速的方法是搭建起来，不断的输出一些东西，这些变量是什么，什么结构的，会比文档直观很多。这个也是在后期的理解的时候才想起来，所以导致前面的搞的还是很痛苦的。 但是现在面临着一些问题，搞得我多线作战很是迷茫。 问题是这样 ： fetch原生的操作会让浏览器自动的补全content-type， 但是不知道为什么，使用redux-api库的时候就无法补全这个项，导致一些请求的请求头有问题，需要手动编写。尤其是在上传文件上。 其次后台选取的java强类型语言，对请求的type要求非常严格，如果使用的是浏览器自动生成的type，可能会不匹配。同时后台也可以使用更原始的方式，就是直接接收context的内容，得到一个request自己再操作，其实这是以前的javaweb的操作方式。 现在就面临了一个选择的问题，到底是后端做出让步还是前端做出让步？ 虽然都是我在写，但是面临这样结构改动还是很纠结。 ~~ 出去吃了一顿饭。顿悟 转变思维 # 不存在能解决一切问题的框架，所以不能一味的寻求框架解决方案。完美主义的人会比较痛苦。 因为没有什么框架能解决你的所有问题，也不是什么问题都有正解的，所以要站的高才能获得好的设计。一定要站的足够高，如果不能高到技术之上，就高到需求之上，高到架构之上，才能在设计出合理的架构。 抽出框架最优越的特性，用来实现一些需求，其他并不适合用这种框架来解决的问题就不要再死守在框架上了。 问题迎刃而解。 有的时候就是要跟自己多讲讲道理，就明白了。可能这就是分裂的好处吧。不是一个人在战斗。