……多学几个又不会死。

@csx163 跑得动。
但我那天升级到了 8，上面一个 Laravel 5.4 还是 5.3 来着我忘了，然后一堆错。想了想不打算改，又换回去 5.6 了。。。

肯定不会没人要。

增删改查是基本功，但绝大多数公司和业务真的也只需要增删改查，不丢人。

C# 可能受点限制，但只要你能写出东西来，还是会有公司要的。

边当管理边自学也不是做不到，挺好的。

我觉得还挺好理解的…

架构应该和业务独立，否则完全业务要 123，你就给个 123，那其实根本就没有架构可言了，这样的架构或者说代码大家多少都碰过，有多恶心就不提了。

架构还是应该从业务要的 123 里提炼出来，如果发现业务经常要的是 123 345 567 789，OK，找到规律了，提炼出来，和业务的耦合度减轻，无论为以后扩展还是更好的服务于业务都是应该做的。

然后说回来，服务与业务，意味着架构不是只是设计的爽就行，还是要为业务落地服务。业务只需要 123 345 这样的序列，你搞个架构设计到能提供 123 345 还能提供 1234567 3456789 这种业务上根本用不到的东西，那也是浪费，甚至可能给更贴业务层的开发人员带来额外的困扰。

严格来说是项目经理的事，时间节点应该项目经理把控。

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

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

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

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

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

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

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

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

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

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

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



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

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

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

这些东西学会了也确实不能提高你的专业技能，但学会了这些，大多数情况下你能更有效率更专心的来在工作中提高你的专业技能，还是不亏的，值得一试。

@lxrmido zune 的造型真是好啊。。。

@ourzhang 设计稿类似 PSD 这种二进制文件也可以很好的处理么？ 毕竟这也是有版本需求的……

@nullen 又想笑又心疼的感觉

@chimingphang 是的，如果是 electron 的话，编译时候多打个包也就差不多了。没什么难度。

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

这么个没难度的事，还有那么多大神云集的公司不愿意做呢。

求求你们那产品经理，别再搞什么 JB 钉钉运动，没事还红包刷存在感了，乌烟瘴气。

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

可能主要是产品本身太不讨喜，毕竟阿里系本来就有人不喜欢，然后钉钉这种工具又有人不喜欢，然后还有运营部门没事瞎上活动虾捣蛋。。。

@jy02201949 ……看个书有啥 low 不 low 的……

在这里跑个题，讲性能这件事，虽然也是老生常谈。

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

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

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

but

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

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

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

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

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

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

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

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

真的。踩坑一年的过来人告诉你，放心踩，再来一次，我还会选择 Laravel。

@harry890829 连用持久化方式跑的 php 都不服气，表示跃跃欲试。

确实是比较弱，毕竟看楼主描述才是一台单机，这配置也就开开记事本了吧

@doublleft 是的，活动页本身是几乎不会再用了。

但是我们公司就是以做活动页为主，我想引入版本系统还有个原因其实是想做到一个比较好的归档。

公共资源倒是比较早做了。

一个是确实没什么特殊之处，一般基本功合格的前端转过来并没什么难处，除了一些局部的坑，大多数内容确实不那么值得讨论。 二个是，在 V2EX，小程序其实是不太招待件的…

学好前端基本功，小程序不在话下。

@yangwudong 我们是 T+7 的广告行业……