肯定不会没人要。

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

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 的广告行业……

这个靠搜索引擎答题的思路才是最 6 的

“然后我朋友不服顶了两句就被炒了。”

我个人觉得吵架这才是原因。

老板可能听别人这么一说，顺嘴提起来，这位楼主的朋友估计也是个死心眼，非要顶着说。

万一老板那边可能还正好有火气，炒了也是自然。

反正就算楼主你标题里说因为 Ubuntu Server 被炒，我也不相信真的是因为用什么发行版被炒。一定还是别的原因。

而且楼主自己都说了，也是个听说，当事人自己可能就没说真正原因，只是含混带过。

但是……

居然楼上有一堆人都在纠结于这个发行版的事。好像大家都认为本质原因真的就是因为发行版不符合老板的心意才炒的。都在说这样的傻逼公司不呆也罢。

嘿嘿嘿嘿，楼主这个节奏带的真不错。有意无意不重要了，我也不是说楼主故意这么带，其实也就这么随便一提，但大家楼上楼下已经一起配合已经构建出了一个“因为选用的发行版问题就炒了员工的傻逼老板”的形象，并且又开始了发行版的讨论。至于真正的原因，大家也不关心了，反正老板的恶人形象已经固定了，我也不洗了。