首页   注册   登录

ibegyourpardon

  •   V2EX 第 158321 号会员,加入于 2016-02-07 20:12:56 +08:00,今日活跃度排名 10364
    好多人喜欢用 iV2EX 的梗
    V2EX  •  ibegyourpardon  •  293 天前  •  最后回复来自 66beta
    4
    最近的 ofo 感觉变的少多了……
    互联网  •  ibegyourpardon  •  2017-05-05 09:19:23 AM  •  最后回复来自 BearD01001
    51
    同事即将离开长沙去深圳,给做个推荐, PHP
    职场话题  •  ibegyourpardon  •  2017-03-30 15:36:10 PM  •  最后回复来自 vingc723
    6
    才发现这个节点,这其实不就是个临时的 gist 么……
    问与答  •  ibegyourpardon  •  2017-03-22 17:01:33 PM  •  最后回复来自 ibegyourpardon
    1
    都在讲外设,我问下,你们觉得现在鼠标垫还有必要么?
    问与答  •  ibegyourpardon  •  2017-03-01 00:28:36 AM  •  最后回复来自 Magnus1k
    26
    今天才知道 HTTP/2 开始被人缩写成 h2 了 ……
  •  1   
    HTTP  •  ibegyourpardon  •  2017-02-20 10:54:13 AM  •  最后回复来自 zhouyg
    43
    ibegyourpardon 最近回复了
    12 小时 14 分钟前
    回复了 warcraft1236 创建的主题 程序员 测试应该对项目的上线时间负责吗?
    严格来说是项目经理的事,时间节点应该项目经理把控。

    即便是因为测试部门的原因造成了延误,那么项目经理也应该考虑到可能存在的延误,并及时协调各方沟通并知会,换句话说,理论上,即便测试部门人员有问题造成延误,项目经理也不是可以随意甩掉锅的。

    但是,这些都是理论上的,实际上——有时候开发自己还就是测试呢,你怎么办?

    现实中一般有两种解决思路。

    一个是讨价还价法,就是自己预估了 1 天完成的测试,直接报 3 天,然后通常砍价还价下,也就变 1 天了。记得在相关软件里要有明文存档留证。不然也白砍了。

    有的时候会变本加厉,3 天砍 1 天,中途跑过来再砍,说要半天。那这种时候就要注意,砍价要有底线。

    还有个注意的点,其实也是本来应该做到的内容,测试是有项目的,不可能就用测试两个字涵盖所有内容。功能列表列个 1-10,写全了,每个分别多久时间,压测要多久,等等等等写明。

    然后就变成了讨价还价的时候,你 12345 列出来,总共要多久,告诉对方。比方说往死了压都要 3 天了,对方说不行,那我们只有 2 天,必须上线。

    ok,可以,那从中做一些取舍吧,比如说某某功能我们就不测了,能省下时间,但不测可能带来的风险是什么,万一出了风险是否能承受? 你都要一五一十告诉对方,让对方做取舍,同时做书面留存。

    这样除了能按时完成任务,还有个好处,体现出你和对方是站在一起的,是为了结果考虑的,你只是个执行,根据对方要求来执行的,但同时你充分为他着想了。

    十有八九对方不敢自己完全做主,毕竟是风险哪,出了问题他那里敢背。但有了你的轻重缓急的列表,他也会和你站在一起,根据你给的建议,继续去向别的人或者领导阐述和解释,不管最后谁定夺,反正一直到有个人愿意为此承担责任才罢休。

    所以我上面多次说了,书面留存,书面留存。



    但这些套路别以为是职场生存技巧之类的,甩锅指南什么的,说到底,这确实是一种负责人的态度。把轻重缓急相关利弊都列出来,也确实能给别人做更好的决策。

    有的时候我看大家都在说,领导根本不懂一个某某小功能有多复杂,领导一句话,下面要做三天,领导只给一天,还不满意,说一天怎么只做了这么个东西出来。

    领导不理解是正常,术业有专攻,但我们不翻译下给他听,告诉他某某功能背后可能涉及的逻辑和可能性是什么,那领导怎么知道呢?如何把技术术语翻译成听得懂的人话,这真的是个技术活。尤其是,还要体现出你不是甩锅推卸责任,而是真的为了结果着想。

    这些东西学会了也确实不能提高你的专业技能,但学会了这些,大多数情况下你能更有效率更专心的来在工作中提高你的专业技能,还是不亏的,值得一试。
    12 天前
    回复了 fxsniper 创建的主题 Apple 突然想买一个 iPod Classic 3
    @lxrmido zune 的造型真是好啊。。。
    @ourzhang 设计稿类似 PSD 这种二进制文件也可以很好的处理么? 毕竟这也是有版本需求的……
    @chimingphang 是的,如果是 electron 的话,编译时候多打个包也就差不多了。没什么难度。

    但是愿意放上这么个图标,有这么份心意,就是难得。

    这么个没难度的事,还有那么多大神云集的公司不愿意做呢。
    求求你们那产品经理,别再搞什么 JB 钉钉运动,没事还红包刷存在感了,乌烟瘴气。

    当然了,说回来,看钉钉的界面能感觉到,在大前端技术栈这一块确实也已经是出类拔萃做的很不错了——仅限一个比较狭窄的办公产品类别内。

    可能主要是产品本身太不讨喜,毕竟阿里系本来就有人不喜欢,然后钉钉这种工具又有人不喜欢,然后还有运营部门没事瞎上活动虾捣蛋。。。
    @jy02201949 ……看个书有啥 low 不 low 的……
    63 天前
    回复了 uoddsa 创建的主题 PHP 各位大佬有用 laravel 寫 APP 接口的麽
    在这里跑个题,讲性能这件事,虽然也是老生常谈。

    有一句话我们可能听的比较多了,也就是绝大多数情况下,我们这些写 CRUD 做点东西的,很难触碰到一个框架本身的性能瓶颈,更多问题出现在类似数据库啊 I/O 这些地方。上面 10# 和 11# 的大佬也提到了这个观点。

    这话也没错,大多数情况下确实是这样。

    而且很多时候我们提出这样的说法,是因为有人会问出这种性能问题之类,比如楼主这样,在一个项目上手开始之前,先关心起性能问题来了。其实真没必要。

    but

    在我这一年的一些业务实践里,确实在数据库等通常我们认为先出问题的地方之外,先出现了 Laravel 这个框架的性能问题。

    我也没搞错,xhprof 等工具明明白白的告诉着你呢,就是 Laravel 慢。

    一段时间内,甚至严重影响到了我这业务的运行。 理由和 #5 楼说的差不多,大量第三方包的引入,写起来是爽了,是快了,跑起来,并发稍微上来点,就卡了。

    而且是比数据库还先挂。我们的数据库那个机器那个性能烂的哟……没事,前面高配的机器上跑的 Laravel 还挂的更快。

    考虑过 Lumen 这回事,最后还是放弃,没意义。

    目前解决方案是在已有的框架能满足业务的基础上,做一些拆分,有点类似微服务的性质,把某些重度业务用原生或者其他框架重写,既不会有非常大的工作量,又能给原先的 Laravel 减负。

    但回到楼主的问题里,我仍然坚持那个观点,只管上,没到你操心性能的时候。真的到了操心性能的时候,那是公司业务欣欣向荣你开心都来不及的时候。 像我这边 Laravel 崩到不行的时候,就是赶上了 2017 年底公司最大型的一个活动,流量远远超出我们预期,才变成那样。但给我重来一次,我仍然会在最开始选择 Laravel,写起来简单粗暴,能应付各种多变的需求,部署容易,为啥不用。。

    虽然以前说 DB 往往比 Laravel 先挂,现在我这里有个 Laravel 比 DB 先挂的反例,但还没到挂的时候,就先别操那么多心。

    真的。踩坑一年的过来人告诉你,放心踩,再来一次,我还会选择 Laravel。
    74 天前
    回复了 juoyi 创建的主题 问与答 一万多并发是什么水平?
    @harry890829 连用持久化方式跑的 php 都不服气,表示跃跃欲试。
    74 天前
    回复了 zasray 创建的主题 问与答 需要什么配置的电脑才能编程快
    确实是比较弱,毕竟看楼主描述才是一台单机,这配置也就开开记事本了吧
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   鸣谢   ·   1636 人在线   最高记录 3541   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.1 · 14ms · UTC 15:51 · PVG 23:51 · LAX 08:51 · JFK 11:51
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1