|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
最近公司研发部门提出了公司级技术平台的建设规划(下文以ABC平台指代),我将个人想法笼统地归结为七个问题,以自问自答的方式表述了对平台研发的一些个人见解,现分享出来供大家参考,欢迎讨论,欢迎拍砖。& [& X) l, l& d2 i8 }1 D
6 M* ]+ ~7 d0 r0 r$ j" o7 e
首先列举出七个问题(欢迎大家分享自己的想法):
: o( w3 x. z2 O) ~% ]8 `& t. o
' ?9 H( l2 l: r$ L/ O' D; ^6 R•ABC平台是什么?近期、远期目标是什么?+ ~4 P, E. T8 L* o: M
•如何保证研发方向不偏离预定轨道?2 j1 x# I8 }5 M% W/ W$ O* b4 q
•架构风格、技术选型等方面的倾向性指导意见有哪些?
" p- o8 O q0 i5 i•平台选用迭代的方式开发,模块的优先级应如何定义?2 W% l$ M v+ W5 a$ p9 P
•针对平台模块,可否抽象出统一的作业指导说明书?
" x( W( M( j% c: F0 L•平台模块可否委托研发?如何施行?& E+ }" o0 x# A6 ^& P& K
•ABC平台研发的产出是什么?除了平台本身还应该有什么?4 r( O: e: x' O" z+ } k# Z
. O' [1 j) K* Z# Y+ }% R+ S
2 ]& c; _) ~" S+ C% |- Z下面我将依次作答,表述近期的思考结果并归纳为一个关键词。
' M# h2 w1 |9 P& V. _( ]( c9 |
1 R6 X, V6 b/ S$ I! W3 H2 x r7 C8 N, ^* E9 n, C
v; p( W, y% V' c: j问题一:ABC平台是什么?近期、远期目标是什么?- b- t I; i- f: @( z
针对第一个问题,我提取“定位”作为关键词。
: c6 P" H: H" x% E
9 c; M4 D/ I7 _; k; {& Q5 q) E& J+ y( [& ^: U
& N; ~% ^2 h# g0 g4 N% @
8 ~" _4 W4 O7 ]
首先,ABC平台处于操作系统和基础环境之上,这里基础环境是Java、.NET、PHP或其它;其次,ABC平台(Platform)应该包含一个通用的技术框架(Framework)和一些通用模块(Component);ABC平台与特定的业务领域相结合可以形成应用平台(例:针对“人力资源”进行领域建模,然后在ABC平台的基础上进行外延开发,最终形成人力资源应用平台);应用平台提供二次开发支持(继承自ABC平台,可能包含泛化的成分),具体项目按现场要求扩展后形成应用系统。- d1 Q9 {) s; h q
T/ c2 x2 C4 j' ^6 ]4 F0 @
在理想的情况下,业务部门只配备实施工程师不承担开发工作,因而ABC平台应该是“一组隐含层级继承关系的应用平台集合”,实施工程师在项目现场主要承担系统初始化相关的配置工作,其次是有限的二次开发定制。但现实和理想之间还有相当大的差距,所以ABC平台在近期只是“一个技术型的开发框架和一组可供自由装配的通用模块”,业务部门选用ABC平台可以节省相当一部分开发成本,但开发资源的投入仍是必不可少的。
: C3 s2 [/ g1 C
, I5 y" b7 A, i( X8 A* B5 \6 B( T
0 J4 v2 x, S$ D3 F
! Y; Z5 I1 Y* N$ l7 x, J问题二:如何保证研发方向不偏离预定轨道?
/ h0 l) V' T8 |设当前位置为点A,近期目标为点B,远期目标为点C,两个箭头连起来即为我们的预定轨道。$ U- k' t0 p2 ^* ?; I% q
' a& `: n" I* B9 @4 b
* n' P. A5 @6 O) W4 E) u. M4 P: D0 Q5 G4 e
: M# l# Y4 C& J8 t% b; h& r
我将箭头视作一条水渠,我们当中绝大多数人的任务在微观上看就是挖坑,按照点动成线的规则,坑挖够了渠也就修好了。前提条件是不能乱挖,乱挖一气莫说修渠,即便别人修好了也可能会挖断。$ ^, X" c* s" C/ t/ D* p q9 q8 q' v
5 b2 L9 N, x7 s5 g' i迄今为止,我们一直都在兢兢业业地“挖坑”,每个“坑”都挖得眉清目秀,可惜若以“渠”的标准衡量就惨不忍睹了,“眉清目秀的坑,惨不忍睹的渠”原因何在?我个人认为根本原因是大家眼里“只有坑而没有渠”,“坑”首先应该是“渠”的一部分,如果不符合“渠”的要求,再漂亮的“坑”也不是好“坑”。我们需要定义一个标准,说明什么样的“坑”是好的,每个挖“坑”的人在开挖之前不但要拿“坑的标准”严格要求自己,并且要把自己的“挖坑”规划拿出来集体评价,甚至是在“开挖”之后也随时展示“坑的进度”,看是否跑偏了(水渠要求坑深1米宽2米,当前状态是深2米宽1米,下一步还要计划深挖显然是不合适的)。
( P; I* w" i3 k0 u9 w
9 S6 \; F7 |0 @& U说了半天挖坑问题,再次回到ABC平台开发,我觉得保证研发方向的关键是“协作”,我们需要引入一套行之有效的协作模式并切实有效地贯彻执行(标准是死的,人是活的,标准可以变,执行是关键),这里的协作模式可以是业界流行的标准开发模式的变种(例如我们选择敏捷开发中的Scrum进行适度调整),具体如何尚需开发团队集体探讨。; N+ K- a8 H1 I4 Y4 t$ |" w7 S" X
# R* r6 p% G; P" x+ `; e7 N# {9 Y
3 `& \2 W7 r- G- K( O: V* Z% M
问题三:架构风格、技术选型等方面的倾向性指导意见有哪些?9 z( H& ?% w6 N' B" j- h
这里继续沿用问题二中“挖坑”的理念,我们需要明确“什么样的坑是好坑”,因而我选择“标准”用作问题三的关键词。
2 L; z' J2 I0 M' T* G" i% O
# E; W" o: V7 e8 a8 l2 s4 L架构风格是描述某一特定应用领域中系统组织方式的惯用模式,附加上技术选型,我将其理解为倾向性的指导意见,具体条目仍需集体讨论,这里列举我个人的部分观点用作示例。" P: `+ @) u9 D/ r
# M$ t, }3 o1 F/ X% h& N& ~: ]6 o; B/ D; ?' _
% f x/ `1 E, a- E$ K! b
& a' o* @# m; L规约方面的倾向性意见:
" U6 \- I' H9 n! @0 w* i( m1 y, f3 G; `* d$ m( e! R2 v" r7 V
1) 平台整体基于SOA设计,引入企业服务总线(ESB);
- p6 ^ Q) x7 E1 e/ M
0 z. c. z$ E+ E6 N% ]! T2) 针对具体应用系统,采用分层架构风格;
5 o1 P2 c" X! y) q7 g2 X
( o1 R: l# d! j: V4 w" L g, c3) 层次之间通过接口进行协作;
9 _( T4 T# e+ w3 t6 O3 H( I5 g, C3 f
4) 层间传递的对象是为实体类,在规约层定义;
) d9 P2 P. ^- R" e8 R( w* z3 Q- y0 Z$ p1 f$ l
5) 实现层依赖于规约层,业务逻辑层的具体实现依赖于本模块相关数据层接口、实体类,与关联模块的业务逻辑层接口、实体类也可能存在依赖关系,不引用其数据访问层接口;
, L+ Z9 X& }' u1 L! X# K1 j9 Y# G8 }! _3 V5 K4 P' A
6) 作为消费者引用外部模块时,须在内部定义提供者接口(归属于业务逻辑层),然后针对外部模块按提供者接口标准设计专用适配器完成数据转换;
; E0 p3 {7 e# | K3 f
: j7 ]; i% A$ D( m0 q" T. U7) 层次之间采用IoC的方式实现整合;
& V* x E Y/ ]6 _( S9 S+ `$ v1 `' ~3 M b; o! b& Y$ H( a: O ]
8) 作为生产者对外提供服务时,须将服务接口封装形成应用支持SDK。
8 D- L6 U$ I" f9 U; D+ ]4 @1 w! a+ b4 q2 q! ~: I* ]# x. s
实现方面的倾向性意见:
% d5 g) l" `. i( ?/ z! n$ d
4 o+ k# L* M$ d4 @1 q C6 ca) 技术路线选择java,提供.NET应用支持;# p5 T2 z5 V2 @0 v. c- J
& |( [( [8 u: _
b) IoC框架选用Spring;
8 K! z' Q9 H& N8 P+ l6 q4 \. V% E( s6 e" m4 c6 w
c) 数据库以Oracle和Sql Server为主,预留扩展接口;8 l( e# `( F' j. z; [
0 t: L' R$ S5 G# b9 s, J( {$ ]* F2 Qd) 数据访问层以Hibernate为基础进行封装实现;* \2 w" j: G) u) q; s: [
3 q# Z9 ^7 i+ Xe) 基于Web的前端展现以Extjs为核心,允许引入Jquery;$ s2 G6 f: ]$ F: |' p' A
5 |, u7 s% j1 f( _. Q/ nf) 浏览器和web服务器端的ajax交互以extjs的direct为主;
. w$ F! H% X' Q$ l2 L4 A) e; }+ x* k3 e8 J
g) 为了增强用户体验,需统一界面风格和配色标准。
+ y! H& m) D) n; W9 A% Q0 l
. s4 A4 Q3 C( A5 l
( i9 y" \4 X, ~( Z* l
% V$ k8 k! H4 |" H, |! p& w1 O' N" l此外,诸如“分页查询的适用场景”、“存储过程的引入原则”、“事务控制的指导意见”、“安全通讯的备选方案”之类的指导意见库也需要不断的完善和丰富。9 S3 y; \/ L- V6 _) X+ F- I2 P* D
1 C+ d/ {* K; A7 i9 {
- y, E" s, k" F( L
4 p6 d3 _; W9 n! d/ J问题四:平台选用迭代的方式开发,模块的优先级应如何定义?. o4 x9 y+ c3 @+ x$ I1 H* ~
ABC平台的用户是业务部门,基于ABC平台开发的应用系统才会面对真正的终端用户,为了“在达成最终用户要求的基础上降低个人工作强度”,实施工程师必然会综合考虑最终用户的“应用级”需求,传递到平台研发这里,形成了平台开发要求。这里我没有使用“需求”,因为用户提出的永远都是要求,需求是由项目组相关人员分析获得的(个人观点),提交用户确认的需求分析报告中已经包含了功能优先级的定义。/ S( V: C6 w! h6 O2 b
K2 O- x9 E) m+ J8 R. i% b7 I
由于着眼点的不同,开发团队和用户理想中的功能模块优先级很难获得统一。用户采用“哪个先上线带给我的好处最多”来判断,而开发团队则用“如何安排次序最能节约研发成本”来评判,最终的选择结果一般是二者相互妥协的折中。
! c' V! i9 C' c; ?/ ^4 { |: l5 T! C
& S3 ~9 q& q& `对于ABC平台的研发,我觉得可以尝试考虑“最小可用版本包含什么功能”、“再扩大一下范围呢”、“先不做aa,直接做bb,能否满足可用要求”这几个问题来定义模块优先级。显而易见,业务部门眼里的“最小可用版本”应该不会包括系统服务总线,这就是冲突,需要讨论,需要权衡。
" Y4 l* ?: w4 o; h7 {& o! X
6 h ~ F4 V3 Z& _本节关键词:权衡。
+ M' x: ?+ U3 k8 W& u3 I- `/ j% t
# q! _* H3 G1 c% U5 U6 s f4 p
7 k* ~* E7 { x8 s- T7 R
7 z* O3 g+ Y' B2 g问题五:针对平台模块,可否抽象出统一的作业指导说明书?) e& c5 A5 ]5 C8 m8 L
作为具备多年实践经验的软件工程师,我们都熟悉软件工程中定义的开发方法和开发流程,然而直接用作平台模块的作业指导却显得过于遥远,虽然我们理应遵循软件工程的各项原则,但我觉得依然需要一个可行性较强的作业指导说明书作为补充,或称之为操作指南。* i8 d9 S, {9 ^/ p3 X# U( M4 h4 u
: ~' Z) p1 z9 q" t }( v2 p
我尝试着为这个操作指南罗列了如下条目(当然,若真的施行,还是需要研发团队集体的力量):
/ ]- e# o4 r) B' N# B* L! G4 P9 x
$ C/ H7 E9 c7 f, h! H( {1) 模块需设置“产品经理”之类的岗位角色,对整体功能和研发路线负责;
/ k; u8 I) ]" z- _' Q# x
9 X! L5 {, S6 `6 ]) D9 ]2) 产品经理主导需求调研和分析过程,是需求规格说明书的责任人;5 }# B( {* G7 f3 o% j3 C# _
# G/ Z+ F- \( E3) 模块的技术架构遵循统一的平台标准;+ P$ N+ ~, ^. ^ D! z( E. d
1 j7 \$ \! T7 N7 d" z7 V; {* N4) 模块首先确定其功能定位和设计目标;
! |: j j$ d7 h/ V
0 f3 M0 ~, K; J$ t8 }5) 模块第二步要明确的是关联系统和交互接口;! C6 R9 p+ t* g! z; U
: y8 v2 a! j. T Z7 ^6) 将模块需求分类,为非通用需求设置辅助工具单独设计;
: e% S7 _* ^" f2 p/ b/ J; E$ U. S# O
7) 模块内部功能细分形成逻辑独立的子模块,按实际需要提供剥离支持;; c) ]0 f+ q. C5 r* q
, V0 |5 b0 N: i+ c( }, O
8) 外部接口的定义和伪装实现优先于内部设计;
, s4 Y, i8 a# `- i* d4 w$ u0 G
本节关键词:指南。
1 l9 i4 `7 `, B1 z: L# Q' v2 v3 k# I
) o! T- d: r7 ]# L4 o) a, e1 i0 u1 {: w
问题六:平台模块可否委托研发?如何施行?( s: ^' \0 D; a
对于不能直接产出利润的平台研发,公司的资源总是紧张的,人手总是不足的,除了补充人员之外,我们可否选择委托研发呢?这里我没有使用“外包”,因为委托研发除了外包,还有“交由业务部门自行设计开发”的一层意思,而且我个人认为编码实现外包是可以的,而系统设计最好在公司内部实现,至于具体模块的产品经理(Product Owner)必须是内部人员。
3 z6 p, e) `$ D0 h: s9 y5 a; }: u7 q5 V) H# S! y" F
委托研发的核心思想是研发任务“分流”,而工作“分出去”的重点在于如何“收回来”,这就需要制定一套评价体系(就是问题三的输出结果)用作任务回收时的验收标准,向业务部门分派任务时申明验收标准(他们无须理解水渠的规划,只需保证挖的坑符合特定要求即可)并附带作业指导说明书(诸如“如何挖坑更省力”、“论铁铲和䦆头在挖坑工作中的效用”之类的东西),只要业务部门遵循这些规范进行开发,最终就可以顺利地纳入ABC平台达到“水到渠成”的效果。
; l: N r0 c* `* |. m2 m. }
/ C8 I/ t2 `, k/ Z本节关键词:分流。- j) D8 a7 t4 e4 A9 o! j
E4 L$ i& ]% b& d( K8 A3 t1 U0 m, _
6 U+ k# a' g6 z' q9 d2 C3 P问题七:ABC平台研发的产出是什么?除了平台本身还应该有什么?- m# D9 r( F& a8 z6 j# {% n
虽然我们当前的主要任务是研发一个切实可用的优秀平台,但本着效用最大化的原则,还应当考虑一下平台研发的附带产出。对于这个问题,我首先想到的是“锻炼队伍”,后来又归纳出了“求渔”一词。. \" p9 j3 M- I& X$ v
- o2 G6 V9 Y* N2 M1 r话说“授人以鱼不如授人以渔”,这是从赠予方的角度解读的,假设我们是接受方呢?于是想到了“求渔”一词,然后ABC平台在我眼里就成了一条鱼,如果通过这次捕鱼(不挖坑修渠,改结网捕鱼了)的经历进行有意识地总结,提升到渔的境界岂不更好?我们总结一套适合公司现状的行之有效的系统开发规范,新成员加入时首先参加流程培训,而后即可以最快的速度融入团队开发,虽然这些已经超出了ABC平台的范畴,但我还是觉得非常有必要分析讨论一下。0 K9 g% [6 T. D! `4 f- `0 Z
- l# L: x$ R- L5 f3 w
本节关键词:求渔。
+ L4 k- n' C# \% }5 N: }. Z
* E* z$ T9 i k9 v2 k
& h6 {, w* X7 H" {9 _
5 g) C4 G: p/ k# i6 n- W最后总结一下,我对平台研发的个人想法主要集中在“定位”、“协作”,“标准”、“权衡”,“指南”、“分流”,“求渔”七个关键词上,或有词不达意之处,仅供参考,欢迎拍砖。
- m0 y- i* ]* m' |# S |
|