免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: qq12536767
打印 上一主题 下一主题

[其他] 从一个人编写的文档就能看出他是否适合做软件架构设计 [复制链接]

论坛徽章:
8
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:58技术图书徽章
日期:2013-12-04 10:48:50酉鸡
日期:2014-01-03 10:32:30辰龙
日期:2014-03-06 15:04:07
1 [报告]
发表于 2013-06-07 11:48 |显示全部楼层
本帖最后由 shan_ghost 于 2013-06-07 11:51 编辑

1、能否分层次思考问题

如果不能用较简练的语言、较为清晰的描述清楚系统所面对的问题和解决思路,不合格。

2、(同一层次中)能否清晰划分模块边界,避免过度耦合



比如,用户注册,则应为他初始化home目录、分配磁盘限额;如果出现错误,则清理未成功初始化的目录结构并提示用户:这样的说明就很好。接口状态清晰、严谨;有了这样的设计,就很难写出太渣的代码。


反之,如果说成“用户注册时,先调用adduser、如果adduser返回xx则yy....”这样就不太好。说明作者不太能区分高层设计与实现细节;遇到疑难/复杂问题时,容易被细节干扰设计,造成耦合过重甚至导致“面条设计”。


更差的,可能是“xxx模块调用yyy模块的注册用户接口;yyy模块要如何如何;如果yyy模块返回什么什么错误,则xxx要怎么怎么...”:这样的差的就比较远了。他搞的设计,耦合不重已经不可能了。

当然,做一些小的简单项目(比如万把行的、逻辑/算法较简单的[比如流程式的项目]),他还是能胜任的。


至于差到表达不清的……还是洗洗睡吧。

论坛徽章:
8
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:58技术图书徽章
日期:2013-12-04 10:48:50酉鸡
日期:2014-01-03 10:32:30辰龙
日期:2014-03-06 15:04:07
2 [报告]
发表于 2013-06-07 17:16 |显示全部楼层
pandaiam 发表于 2013-06-07 15:36
确实,分层很重要.
最后一个例子,感觉很好啊...


例子没举好……因为不习惯那种拉拉杂杂的说话方式,也懒得敲那么多字。



我的意思是,一个模块就应该是一个独立的实体;其它模块和它的关系,就应该像驾驶员和汽车一样。

对模块来说,“操纵杆/方向盘”就是它的接口;“仪表盘”则是它的返回信息。


好的文档,应该专注于描述接口和返回信息,以及它们的使用方式。而不应该去罗嗦什么“当你挂2档时,齿轮F1和齿轮H3分离,轴S5移动到Z2位置,使得齿轮R6和齿轮U7结合,于是传动比变成了XX:1,实现了挂档功能”;尤其是,不能再去指挥驾驶员“在齿轮L6磨损打滑时,应如何如何”。


这种东西,除非汽车工程师,否则没人能看懂;即便看懂了,这丫也肯定开不了汽车——他还没琢磨透“现在该接合齿轮R6和U7呢,还是转动凸盘Y9,分离离合器盘”呢。

——这就叫重耦合。


当然,没这么傻的汽车说明书;但这么傻的程序员,那可是比比皆是。


而且,照这种东西写程序,可比驾驶员和汽车恐怖得太多太多。因为首先功能的边界都搞不清。
于是乎,一个东西,似乎A应该负责,但推给B也不能算错——后果吗,对某功能,要么A/B各自都做了一份(做两次某些时候可是致命的!);要么A/B都没理;要么,A做了个73%,B做了47%:其中,16%的交集部分被做了两次;A方实现的54%和B方实现的25%互不兼容;另外还有20%的内容两边都没做——而且,再让A或B做,人家都不肯,因为会破坏他们的已有抽象!!

这种系统,肯定是越改BUG越多。最后凑合勉强能用已经很不容易了,就别再提任何“过分”的要求了。




反过来呢?

设计一个“档位”接口,用于改变传动比。其中1档为...如果挂档不成功,则回到空档状态。

有了这样的接口,这样的说明,无论是工程师还是驾驶员,还可能做错吗?

论坛徽章:
8
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:58技术图书徽章
日期:2013-12-04 10:48:50酉鸡
日期:2014-01-03 10:32:30辰龙
日期:2014-03-06 15:04:07
3 [报告]
发表于 2013-06-07 17:30 |显示全部楼层
个人观点: 架构师,首先必须是一个很厉害的程序员。不然凭什么去空谈架构?

进一步的,这个程序员得具备什么样的素质,才能去当架构师?


我认为,最为核心的一项是:必须具备化繁为简的能力。

否则,软件设计本身已经够复杂了,模块间协作、以及写这些模块的程序员之间的协作,其难度,早就让整个业界都谈虎色变了。现在,再弄个所谓的“架构师”过来横插一杠子,不是没事找事吗?


只有有了化繁为简的能力,原来复杂的系统/设计方案,被他三下两下合理切分开来,变成一组独立的简单任务,这个角色才不至于添乱——而要得到正的收益,他就必须比其他人都做的更好:毕竟,好的程序员早已习惯做尽量“解耦”的设计了;那么,额外增加这么一个角色,额外增加了协作的困难度,不能从他身上找回点正面收益,显然必然是个赔钱买卖。

论坛徽章:
8
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:58技术图书徽章
日期:2013-12-04 10:48:50酉鸡
日期:2014-01-03 10:32:30辰龙
日期:2014-03-06 15:04:07
4 [报告]
发表于 2013-06-07 18:11 |显示全部楼层
shan_ghost 发表于 2013-06-07 17:16
例子没举好……


刚想到个绝佳的例子: unix痛恨者手册里提到过的 rm -rf


这个例子恰好是:
1、unix规定了命令行扩展的方式和实现者(*扩展为路径下所有文件,扩展者是shell),以及错误处理方式
2、rm定义了可接受的参数和返回值
3、流程很明确——但是,最终呈现给用户的高层接口应该是什么?没人知道。


于是,种种悲剧……

最近且最著名的,大概是这个:
http://coolshell.cn/articles/4875.html
Optimus 是NVIDIA的“优驰”技术,其可以将您的笔记本电脑PC提升到绝佳状态,提供出色的图形性能,并在需要时延长电池续航时间。这个项目是把这个技术移到Linux上来。

这个项目本来不出名,不过,程序在其安装脚本install.sh里的一个bug让这个项目一下子成了全世界最瞩目的项目,这个bug的fix如下:
@@ -348,7 +348,7 @@ case "$DISTRO" in
-  rm -rf /usr /lib/nvidia-current/xorg/xorg
+  rm -rf /usr/lib/nvidia-current/xorg/xorg


论坛徽章:
8
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:58技术图书徽章
日期:2013-12-04 10:48:50酉鸡
日期:2014-01-03 10:32:30辰龙
日期:2014-03-06 15:04:07
5 [报告]
发表于 2013-06-07 19:34 |显示全部楼层
回复 17# qq12536767


    不好意思,保密规定,你懂的……

论坛徽章:
8
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:58技术图书徽章
日期:2013-12-04 10:48:50酉鸡
日期:2014-01-03 10:32:30辰龙
日期:2014-03-06 15:04:07
6 [报告]
发表于 2013-06-18 10:48 |显示全部楼层
smalloc 发表于 2013-06-15 10:29


好的文档必须说清楚应该说清楚的;同时,好的文档不应揣测或干涉其他模块的实现——那是其他模块相关文档的职责。


和你的工作实践一样,最令人厌恶的“领导”,是任何地方、只要他觉得“懂”就要插一杠子、但完全不管这一杠子插下去后,后果如何的家伙。

最终,每个工作/每个模块,都少不了他的身影,似乎就他必不可少一样;但实际上,任何疑难、任何需要真正的决策的地方,他都不管——这很容易理解,柿子捡软的捏嘛。



写文档也一样。

不要试图绕开那些需要决策的疑难问题,更不要试图通过东拉西扯来掩盖疑难问题(或者,因为“聊”自己最擅长的东西聊的太起劲,而无意中忽略甚至掩盖了问题)。



比如,之前那个rm -rf的例子:问题出在哪儿呢?

事实上,shell的文档很好:如果命令行有'*',怎么处理?说的清清楚楚。
rm的文档……怎么说呢,对shell来说,也很好,每个参数的含义,清清楚楚——包括'*'会被shell扩展。


但,用户呢?他需要通过shell去调用rm——开发者们,你们准备给他什么样的体验?

在把关注点放在shell和rm配合上之时,用户体验就被彻底放弃了。这是不应该的;也是喜欢描述“模块之间交互细节”的文档最容易犯的错误。



事实上,rm的文档应该忽略shell,只关注r参数是什么、f参数是什么;然后,自然而然的,由于shell的存在,'*'参数我们没有机会处理,那么万一用户在错误的地方打了'*'、或者类似那个例子,在错误的地方多敲了个空格,怎么办?

当关注点正确时,这个问题就很容易发现和解决:比如,规定当通过命令行传入多个文件/路径时(不管这多个文件/路径是*扩展来的、还是误敲空格多出来的),必须加一个M参数明确说明(激活多目标删除功能),否则就报错退出(就好像不加rf就不能用rm删除目录一样)。



一个简单的rm + shell的'*'扩展就能引出这么多麻烦;那些复杂的、软件内部模块之间的接口,如果关注点都错了,又得闹出多少问题。



比如,如果需要外部调用者辅助维护当前模块的状态(比如申请句柄/归还句柄、开启session/关闭session),那么不要描述外部模块的“正确”流程,而应该明确说明“调用open_session接口开始一个会话;会话结束后,必须调用close_session关闭会话,否则会话将长时间占用资源(直到超时)”。

因为别的模块的实现者未必会照你说的实现;或者,虽然最初设计时的确打算如此实现,但后来因为技术原因而改变了方案(哪怕整个项目都是你一个人做的,这种问题都无可避免);那么这种流程性描述只能当放屁;最终的代码不乱套才怪。

但,如果你明确要求“open_session必须和close_session配对”,对任何调用者来说,这句话都足够清晰、明确,不会出现歧义,更不怕别人更改实现(管你什么事!)
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP