13、系统开发报价一定要考虑buffer,否则将会掉入无底洞,很多需求一开始乍一看很简单但是任何一个功能点可能都有海量的细节,各种检验以及相互关联的逻辑,如果大面上将无非就是数据的增删改查,所以相信很多开发者都听客户说过:我这个很简单,其实这里面的坑没填过的是不知道的,人之所以说某件事情简单无非有两个原因,一是他很熟悉,产生了文化遮蔽效应,(公号:左手Excel右手VBA)二是他一知半解,没有深度思考,细节浅尝则之,实则经不起推敲,这这种信息不对称导致的直接结果是客户觉得简单暗示预算不会高,这就为后续的沟通埋下了冲突的种子,那这种情况怎么解呢,方法只有一个,在前期未报价之前把需求捋得越细越好,然后划分功能点评估工作量,整体出个价格,如果超出客户预期那就删删删,而不是价格定了又是加需求又是加功能,最终一笔糊涂账,开发者觉得亏本出力不讨好,客户还觉得体验不好,花钱还受委屈,所以,双方多站在对方角度考虑考虑问题,其实会发现归根结底的问题是钱的问题,钱到位了,一切都不是问题。
14、对于数据库来说,当数据量大到一定程度,用不用索引性能差别非常大。大多数时候一套系统在上线之初因为数据量小,基本上不会存在性能问题。这也就导致很多开发者只注重功能而忽略性能。(公号:左手Excel右手VBA)以为实现了功能就完活了,其实是经不起压力测试的,而性能问题才是真正考验一个开发者水平的试金石。解决性能问题除了在编码端下手,更重要的是在数据库端解决,因为很多数据库本身就是天然的性能优化器,比如MySQL。我认为性能的优化比功能的开发难度要大。
15、Vba做的系统基于CS架构,有问题调试不方便,需要用户提供一些线索,虽然可以把日志打到本地文件。但毕竟不能远程直接查看,而如果把日志存入数据库,有问题就可以直接远程查看数据库,而不用让用户提供日志文件,提供截图之类的。这样就方便问题的排查。只不过需要在终端需要牺牲一些数据库的交互动作,不过只需要在关键环节加入日志捕获的动作,或者只对错误日志进行捕捉那么这点牺牲基本上是微不足道的。(原创公众号@左手Excel右手VBA)
版权声明
本文系作者原创作品,未经许可,不得转载。



评论列表
发表评论