博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
[design decision] user awareness: 自动安装还是不自动安装?
阅读量:6332 次
发布时间:2019-06-22

本文共 643 字,大约阅读时间需要 2 分钟。

觉得有必要记录一下这类问题,都打个[design decision]的标签吧。
 
目前项目中遇到这么个问题:
我们build system的用户,需要为他的每个项目提供一个文件,用来描述该项目产生的libary,以及依赖的其他项目。 这个文件很重要,需要在install的时候与最终产生的库文件放在一起,以便被其他项目使用时访问,从而把整个依赖链串起来。 已知该文件总是放在一个固定的位置,之后gmake install时会被安装到一个固定的位置。
 
好,问题来了,既然文件在哪里,要被安装到哪里都是已知的,是不是build system可以自动把这步包含进来,无须用户做任何事,从而提供了方便?
 
我一开始的想法是这样的: 这的确非常天经地义,何乐而不为呢?
但和同事们讨论之后,觉得从另外一个角度来考虑:user awareness也是非常靠谱的:
这个文件是用户提供的,如果build system在用户不知情的情况下,自动(magically)帮用户做了这个事,可能对用户来说是个supprise(least supprise?),会造成一定的混淆,所以这不一定是个好事情, 有用户显示指定这个操作为好。 相反来讲,如果某个文件是build system产生的, 比如最终的library,或者中间产生的库依赖信息文件,那么build system自动安装是比较合理的。
 
当然,对于这个具体的问题,是否自动我并没有强烈的偏向,但从user awareness来考虑问题是个不错的角度。

转载地址:http://eonoa.baihongyu.com/

你可能感兴趣的文章
Highcharts X轴纵向显示
查看>>
windows 注册表讲解
查看>>
【算法】论平衡二叉树(AVL)的正确种植方法
查看>>
基于DDD的现代ASP.NET开发框架--ABP系列之1、ABP总体介绍
查看>>
react 从零开始搭建开发环境
查看>>
scala recursive value x$5 needs type
查看>>
ps -ef |grep 输出的具体含义
查看>>
markdown编辑
查看>>
ASCII 在线转换器
查看>>
Linux内核同步:RCU
查看>>
Android逆向进阶——让你自由自在脱壳的热身运动(dex篇)
查看>>
Java设计模式之五大创建型模式(附实例和详解)
查看>>
60 Permutation Sequence
查看>>
主流的RPC框架有哪些
查看>>
Hive学习之路 (七)Hive的DDL操作
查看>>
[转]mysql使用关键字作为列名的处理方式
查看>>
awesome go library 库,推荐使用的golang库
查看>>
树形展示形式的论坛
查看>>
jdbcTemplate 调用存储过程。 入参 array 返回 cursor
查看>>
C++中的stack类、QT中的QStack类
查看>>