初级会员
  • 第 22836 位会员
  • saberlong
  • 2018-09-14 13:09:18
  • Offline
  • 45 40

最近发布的主题

    暂无

最近发布的文章

    暂无

最近分享的资源

    暂无

最近发布的项目

    暂无

最近的评论

  • 除了自己fork外,还应该准备个本地仓库。可以使用athens之类的搭建本地仓库。然后设置GOPROXY通过本地仓库获取包。这样仓库里就会保存当时的版本
  • 无论哪种,我都能习惯,并不会感到不好。 只是觉得你这种panic的用法很不合适。 我的实际代码中,很少会出现panic,每次写上panic都是经过深思熟虑的
  • 真心没必要,按我来说,不如一个spring的事务传播特性如何实现的实在。 知道什么是代理,什么情况下使用,有这思想就行了。 至于实现,各个语言采取的形式不同。java下,jdk自带的代理也好,cglib也好,asm也好,注解的内容也好。 只要有思想,稍微看下相关内容就会使用东西。
  • #16 @tiaen 不,楼上的那些不少是正确的。 这个是建立在硬件基础上的,而不是单纯的软件实现。 磁盘IO速度,软件性能,网络传输速度都要考虑。 而软件性能是最容易的部分,现在随便拿个http服务器都是支持断点续传多线程下载的,如果不是特殊需求,可以直接用。 接着磁盘也容易实现,高性能磁盘或者低性能组raid等,方法多。当然也可以靠自己软件实现分布式存储,将问题转嫁到软件层面,这样客户端也就需要制定了。 网络带宽,这个上面的回复就明确说了满足一个并发的最低要求,你可以去查查价格成本。 上面还提到了CDN也是解决方案,比直接提高带宽成本低。 上面的评论都是认为前2个问题都容易处理,所以才直接忽略的。
  • #10 @qlaall 这点,我只能说各有优势。 try-catch我就举个反例,对于开发经验不足的人来说,try-catch会埋下无数坑。 他们不太喜欢错误处理,也不会花费精力思考每个调用异常的处理。 然后就会出现几种情况,外层捕获了,打印了日志以及错误堆栈对大多情况还是可以的。 但是偏偏有人喜欢吃掉堆栈,或者就不捕获。code review时,随着调用层数增多,就得花费更多的精力里里外外看一遍,思考是否存在问题。也就是开发人员将大量本应做的工作转嫁给review的人。如果没有review,那么就祈祷不会出错吧,至少祈祷日志包含了错误堆栈吧。 golang的这个不优雅,但是能告诉使用的人去正视错误,并思考如何处理