|
|
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 |
|
/1 
发表于 2020-8-17 15:10
收藏
淘帖
支持！
反对！