谈无数从0到1项目的技术感想之开篇

622 阅读7分钟

关键词:Java 应用、架构提炼、技术沉淀、通用技能

一、想法的萌芽

写了这么多年代码,经历了太多从 0 到 1 的应用技术项目,这种重复性的行为,不禁也让我感叹,工作到底是正弦函数,往复循环;还是一次性函数,日日精进......

在一个不经意的瞬间,内心深处萌发了一颗种子。 它告诉自己,你应该从大局、宏观的角度, 做一个深度的提炼; 将这些经典,可参考的、可复用的,不管是思想、还是方法,做一个沉淀。

二、架构的理解

在软件行业这么多年,时不时被问到,什么是架构?

今天我想用不一样的想法来阐释这个词: 用经验搭建出一套非常牢固的架子

图示:就像建筑房屋一样,需要先搭建牢固的整体结构

经验是什么: 经得起推敲、经得起考验的场景解决方案,干脆就叫它“套路”。踩过坑、有最佳路径。可谓是“老马识途”。将我们做过的这些项目进行总结归纳,为下一个项目提供参考,这就是经验!

牢固是什么:经典起推敲,并能够在一定的生命周期内屹立不倒。

架子是什么:最终的形状,架子就是骨架,是结构,也即软件的核心, 架子有了,软件就基本成型了。

图示:在架构搭建好的基础上,再填充各种装饰细节,就形成了不同的漂亮房子。

不可否认,软件项目就跟建房屋是一样的,每建一栋房子和每开发一个项目软件,它们都有相似的项目流程,包括设计、落地,整个生命周期管理。 开发软件就像是一堆人拿着施工图纸,夜以继日地添砖加瓦。

不管是建房还是开发软件,都会沉淀出它们各自的方法论;同时也一样会沉淀很多经验,以及避坑指南。

今天就尝试去扒开那些软件外衣下不变的东西。就像下图一样,褪去叶子后的枝干。

三、软件开发环节

软件开发有很多环节,有一些点可以讨论一下。

3.1 正确把握需求

对于开发同学,是否需要做需求分析

当然那是产品经理要干的事情,可以不用,但一定要做需求理解,并对提出需求的合理性分析

image.png

因为缺乏经验和专业度,也常常因为考虑不周提出了一些不合理的需求,研发同学不假思索地照着原型开干,做着做着才发现需求不合理。

需求阶段的职责缺失,造成资源的浪费!

那有没有破解之法呢?

战略上:透过现象看本质,抓住需求背后的本质

战术上:用例图。或者用例图驱动

3.2.1 用例驱动

用例图: 是软件工程中的一种可视化表示方法,用于描述系统角色系统本身之间的交互。它通过说明用例和与用例交互的角色来捕捉系统的动态行为。

之所以会出现一些坑,其实是缺少把需求脉络理清楚的环节。 而用例图刚好是一个不错的工具。 软件的价值是通过用户的使用过程体现的。

理清脉络的公式: 【】 用了系统什么 【功能】做什么【事情】达到了什么【效果】。

系统的角色
功能系统的功能
事情系统通过功能提供的能力
效果系统的价值

比如以电商商品搜索为例子。

购买者会员,用例系统的搜索功能搜寻特定的电子品牌得到了想要的信息

这是让我对需求理解不走偏的一个方法论。

这种方式不是将用户和功能做分开,而是结合。研发人员常常会存在一个误区,我开发了这么流弊的功能,但是为什么他们不去使用呢?


3.3.2 先有功能还是先有用户

先前有过一次失败的经历,搞了个运维预警的系统,最后没有人愿意去使用它。 后来复盘提到了一个问题。先有功能 VS 还是先有用户

1.是先把功能都开发完成,然后去寻找用户

2.还是先有用户,根据用户需求再去开发功能

几乎大部分人都认为该选择 2 。 但是实际很多开发却在干着1 。 如果不确定,我这样去描述你可能会有感触一些。

研发人员A:按照【原型】设计模型,设计功能,然后实现。

研发人员B:将用户和【原型】结合,分析能够提供什么能力,然后实现。

一种是功能,一种是能力。可能系统都能顺利上线,但是实现的过程的思维方式是不一样的。一味的堆砌功能,不贴着用户走,那么黏性就会不足。

通过用例图的思想,将功能和用户结合去看待系统,防止走偏、走错。通过这种方式,可以提前发现需求是否合理,是否需要返工等。当然这不是唯一的方式,但是一种可行的方式。

想清楚比一上来就干,然后发现不合理再返工要好不止十倍。当然这也是我的口头禅:“别急,先想清楚再干,想清楚了再干其实是简单。”


3.2 如何快速理解系统

我刚毕业的那会,我的导师告诉我一个法门。 理解一个理解最快的方式就了解它的功能权限和数据权限。当然这个经验在后来的经历中也是屡试不爽。

理解一个系统最快的方式就是:理解它的功能权限和数据权限。

当然我们对于权限系统,每一个系统可能都不一样。这一点务必要注意。不过常规的系统都是基于 RBAC 演变的。

思想都是:什么样的人能够看到什么样的功能以及什么样的数据

如果不理解权限,始终还是门外汉,甚至会因为开发某个功能没有考虑权限而翻车!

3.3 软件开发的焦油坑

"表面上看起来好像没有任何一个单独的问题可以导致问题,每个问答题都能获得解决,但是当他们相互纠缠和累积在一起的时候。团队的行动就会变得越来越慢" --人月神话

图:来自人月神话

如何不让自己的应用成为焦油坑? 直到我遇到一个系统

这个系统,大约二十个人开发;常见的开发分支大约20个;线上应用机器接近百台。 接到了一个需求,并要在这个应用上做需求开发。 初看代码发现很逻辑很绕,但跳出细节,梳理骨干却又很简单,也很美观。 “骨干是美人坯,细节是凡人像”

认真比对以后,我发现很多有趣的事。这个系统之所以能够做得不错,有它自己的特点。概括为几个点:

image.png

问:你认为团队一起开发在技术落地中最重要的是什么?

答:规范或者统一

四、本章结尾

本文作为 无数0到1项目的技术感想 系列的开篇,限于篇幅,先到这里。但后续会继续输出这些年的一些思考,算是对这几年的一个总结和沉淀。

感谢阅读,本章结束。