目前 ie6 用户的份额已经很低。所以主流互联网公司也会从降低工作量做为出发点去推动更新的。

作者坐我隔壁，让他本人来回答了~

作为一个内部人员. 其实我没开新帖,就是这个原因..我不喜欢被打扰也不喜欢打扰别人..开个主题贴就够了.嘈嘈闹闹真烦人.

由于必须用svn, 目前还徘徊在smartgit/hg,不过确实挺好用的

求加 hitsmaxft ~ 搜索工程师没朋友阿。

codeblock试试？ 不知道jetbrain系列对错c++支持如何。

求加好友 hitsmaxft~
其实目前来往处理web稍微比微信有点差异化， 其他的还很弱，除了这次恐吓来劳役员工，真没啥办法了。
来往开发团队最近肯定是要累死的了，但后面的薪资肯定是各种飞腾。

如果是要涉及到统计 -xx 的个数，顺手写了个工具函数

function test () {
count=0 ;
for arg in "${@[@]}" ; do
[[ "$arg" != "${arg#-}" ]] && count=$(( $count +1))
done
echo $count
}

ARG_NUM="${#@[@]}"

摆脱一个当程序员屌丝的命. 努力提高社交的技能点. 写代码就是一个技能, 能打发时间, 能不被饿死, 但是光吃饭不吃菜也会死人的.

要嘛努力写代码, 等你年入百万, 自然有女人找你.
要继续死等愿意找你的妹子, 如果你信天上掉馅饼的话.

半分比 -> 百分比

重构, 是看你对实际整体逻辑的把握情况, 所以.. 预想时间 * all/你实际了解的半分比 * 传说中预估时间放大因子(约为2) = 最终时间

@LTaoist 手上有上百台都是2.4的路过. 唉

vagrant ~ 自带标准镜像. 而且是基于virtualbox.随时可以做快照. 练习还是用虚拟机, 就算文件系统挂了也问题不大, 随时重建

看应用的实际场景 如 @echo1937 说的, 开发速度也是个问题.

就我所在部门负责的应用, 引擎返回大概要占用200ms(商品搜索, 很复杂的说, 而且引擎请求个数在1-15之间浮动) , 这种情况下, 其实应用层做不了什么..

那么我们改的目的就是, 就是出于可维护和可扩展, 一方面改善应用的业务处理速度, 另一方面也适应业务的发展.

而且, 一个应用往往是多层的, "开发者却乐此不疲地讨论如何更换不同的编程语言和框架来改进速度", 这种话往往是站着说话不腰疼, 改个框架语言, 能提一点是一点, 但是依赖其它组件, 不见得能一起更新, 木桶效应还是存在的.

当然不排除"创新"赚kpi...

@kenneth 我看大伙的说法都是觉得phpfpm服务能力达不到当前并发的水平.

但是我感觉问题的关键并不是php业务的性能问题. 因为发生问题的时间都在深夜流量低谷, 而不是流量高峰.

你的这种情况, 我最近也遇到, fpm没有可用进程, 不断启用新的进程, 但是新进行往往都没有提供服务. 最后到达最大子进程数, 而能够正常服务的进程又到达访问次数上限, 最后所有fpm下挂载的进程都不可用.

结果就是 nginx 连不上 fpm, fpm挂着一堆不可用的进程.

不过我还没定位到故障原因, 临时解决方案就是重启fpm

数亿pv 产品线, 随便改了小东西都要一堆流程保证.
这往往不是水平问题, 而是根本不能犯错.

规划, 讨论, 开会, 完成原有的维护工作.
公司这么大, 除非boss驱动, 否则很难有完全自主支配的时间, 大部分人还要维护相关的产品线, 不见得新项目就能100%的去贡献代码. 另外等待其它部门的就绪也是要花时间的(法务, 机器采购,存储等等, 后台服务等等)

所以. 速度快慢要看项目的资源情况如何.

回到产品本身. 随便写个能用的东西那是很快, 要上线不出大问题, 前端流量支撑住, 后台服务稳固不down机, 你来试试? 1w pv 和 100w pv 的差距, 不是什么人都能随便hold住的. 而大公司往往人的工程水平参差不齐, 也需要一些时间支付修bug等额外成本

再者, 不是各个都想加班, 慢工出细活不好吗? 互联网时代强调快, 这是有病. 都是打工的, 又不能带来很多收益, 相煎何太急.