网站程序员在开发项目上的经验分享

总体设计是写给开发者的。在需求文档评审之后,开发者需要写一个设计总体设计,通常包括需求背景,设计架构,数据表结构,ER图,时序图,程序主要逻辑设计,上下游界面修改点,脚本,在线特殊步骤等。其主要功能是告诉自己,或者别人,你打算如何满足这一需求。


构架图,时序图,这两点往往需要做大需求,小需求和优化点不需要画这个东西。我做了一年银行外包,画了一次。从这个角度来看,也体现了外包开发不会做太难的事情。一般来说,困难、重要和核心不会交给外包。银行有自己的开发者,所以外包开发技术的增长空间是有限的。这方面涉及到一些商业建模知识,这也是我的弱点。如何划分需求中的各个领域?分析各个领域的事件,划分各个领域的界限,想了解这些事情,指导我们设计代码。


以前学过的,和工作写的都是很常见的面条式代码,现在在字节上做的项目都是推领域驱动DDD开发,造型更抽象,和我以前的认知差别很大,我到现在还在适应学习,以后学有小成后再分享。资料表结构及ER图,涉及表格结构变化的需求会稍微困难一些。表格结构需要精心设计,不仅包括书籍和网络上各种要求的注意事项,还包括公司内部的一些要求。比如一些大表(有30多个字段,数据数百万)不允许添加字段和索引,需要提前向前辈询问。


更改上下游界面。先说说上下游是什么,现在一个系统不太可能是一个孤岛系统,不能与任何系统进行通信(交换数据)。我们称我们系统的数据源为上游系统,我们系统的数据源称为下游系统。举例来说,假设今日头条有三个子系统,A是用户信息系统,其中存储了所有用户查看、点击、点赞、查看留存时间等操作信息,B是推荐系统,负责计算用户喜欢的关键信息,C是推送系统,负责推送新闻、视频。

对系统B来说,他的上游系统是A,因为B要从A中获取用户的各种信息,并通过自己的算法来计算用户喜欢的内容。对C系统来说,B系统是他的上游,C得到B系统用户喜欢的内容后,就会向用户推送信息,反过来C是B的下游,B是A的下游。


上游和下游的数据交换通信有多种方式,如消息队列MQ、RPC/HTTP连接、定时同步读取上游数据库等..,最常用的是RPC接口调用,一般是上游定义好一个接口,告诉下游要求地址url、参数、返回内容(这些规则是协议),下游直接使用即可。如果我们是上游系统,如果我们改变了这个界面,我们必须通知下游系统,判断下游系统是否有影响,并进行相应的调整。一般而言,如果导致上下游要调整,需要向上下游系统分配工作量,同时要注意测试。事实上,如果数据库发生了变化,还需要通知相关的上下游系统,比如有一个系统直接阅读我们系统的某个表格,而你直接改变了表格名称,导致他无法阅读。


脚本。包含了sql和shell脚本,shell我没有写,需要改也轮不到我去改。所以工作后可以学习。一般来说,sql是修数,为什么要修数,后面在处理生产问题的章节再详细说明。另外sql也有DDL建表语句,但现在一般大一点的公司都不会再直接手写DDL语句了,都是有一个数据管理平台页面,填单建表,审批通过后,自动生成DDL语句,在代码上线时,一起打包、执行。


分享: