-
Notifications
You must be signed in to change notification settings - Fork 0
review
每个项目都有自己的独特性，某种程度上技术在早期看到的各种问题或困难（引入复杂数据结构、图数据库、长连接、内容检索）其实可以反过来推动产品更好地思考，因为我们无法做到大而全还什么都能做好，所以需要不断精简产品，把重点的有优势的东西开发到极致才有可能在现在这个环境下获得更多的用户。
之前这些经验基本上也让技术帮助产品思考了不少。有很多东西需要确定下来才能更好推进。
特别是现在前后端技术栈其实已经相差的很远了，远不是只要懂一门语言就可以跨端开发的状态，相反语言是最容易过的关，后续的第三方框架的熟练使用才是最花时间的，无论是后端涉及到数据库、还是前端vue这些。所以相比于“在使用最广的语言群体”中找到潜在的后端开发，“在使用最广的后端语言群体”中找到后端开发的可能性会更高一些。
也正因为人员的流动性考虑，项目复杂度一定要控制好，减少“历史遗留问题”的可能性，从这个角度思考的话相比于scheme free的数据结构来说，SQL的数据结构就有它的必要性，新人看到的代码就是当下大家用的代码，新人看到的数据库里的字段就已经是当下正在用的字段。想想看如果若干时间之后某个新人看到mongodb里某个document里面的字段和其他的都不一样，而当时的开发人员如果已经不在而且没有做好数据的migrating的话。这就是个无人知晓的东西存在了。
所以新开工程重写我这边最重要的一个原则就是保持项目的可传承性，也因此对于文档、单元测试、代码规范等方面都会有很强的要求，在架构复杂度上也会极力控制，不轻易在代码里加入花哨的功能，能把工作交给第三方平台实现的就交给第三方平台来做，也许在短期看上去会影响开发进度，但这可以保证这个项目的可持续发展。
非常欢迎大家加入开发，既然这次是使用Java重写项目，我就来简单介绍一下项目周边的一些历史和思考，希望对大家有帮助。
-
706因为想要做线上社交，开发了一个小程序，小程序是完成度较高的遗留项目，实现了发帖发图自动审核搜索之类的功能。
-
因为小程序产品上想要控制用户群，对用户进行政审，影响了使用体验和推广。
-
因为小程序涉及交友类目，需要ICP证才能过审， 没证根本过审不了，开发停滞。
-
因为想要做线上社交，小程序又受阻，就想弄一套论坛系统自己独立运行，不受制于微信。
-
部署了一两种论坛，但因为难以实现对活动报名的良好支持和体验，wfr不愿进行推广，项目停滞。
-
既然如此，自己做一个网站，专门搞活动报名吧
-
继承了大部分小程序后台代码，另外新起前端，弄成了目前的样子。
-
前期选用了GraphQL，后来发现是个错误，不想用了，转换中， 我自己时间经历不似从前那么多，而有些事我不做好像就真的没人做了，项目停滞。
-
706是一个公益性很强的组织，难以组织成建制的劳动密集型开发团队，如何剑走偏锋，减少各类成本和人员消耗，我个人认为非常重要。
-
Javascript是无法避开的，既然如此，后端选择node.js，可以最大程度利用可用的人力资源。 另外开发时使用TypeScript，避开Javascript工程化方面的问题，同时吸引有进取心的前端工程师加入。
-
706的项目在相当长的时间内都不可能摆脱原型期，功能说变就变，说改就需要改，MongoDB更符合场景，不适合使用SQL数据库，不停改表结构自讨苦吃。
-
从初代开始项目愿景中就包括n度关系这种图应用场景，按理应引入图数据库，或加入邻接表，在小程序中是使用邻接表处理。MongoDB具备单表图查询优化，避开早期投入图数据库。
-
从初代开始项目愿景中就包括文字聊天、站内信、通知等实时消息场景，按理应引入消息队列，或redis pub/sub之类的方案，并应用websocket。 原计划在MongoDB中通过监听oplog获得类似效果，但没有真正实现。
-
从初代开始项目愿景中就包括文字搜索，按理应引入垂直搜索引擎如ElasticSearch之类并做好数据同步。 在小程序中通过在应用中直接完成分词，将倒排索引数据和原数据一同存储在MongoDB，再利用MongoDB实时算分排序，避开了外挂系统。
-
本代项目愿景中包括相互引用的动态数据，如果想要良好处理，又避免大量投入人力手动实现，需要设计一种对象引用关系自动处理、内容自动落库的机制，这是我目前正在研究实现的东西。