你今年 35 岁，正坐在人事部忐忑不安。

现在国企改革，需要全面优质年轻化，你这几年的工作大家有目共睹...老同事很多，这种硬指标也算把人才损失降到最低了...
对方的嘴巴在不断张着合着，但你一个字也没听进去。刚刚自己因为是公司中寥寥几个大专学历的员工被强制遣散了。
回到进出了近十年的办公室，你强忍着不甘的泪水在桌子上收拾东西，往日的同事都很惊讶，问你离开的原因但你说不出口。

网上海量的招聘条目，你只能满含遗憾一拉到底。
面对“学历要求：本科或以上”的大多数工作，你不敢投。面对“学历不限”的职业，你也没信心竞争得过年轻人。
你只会代码相关的东西，最终投了薪水是之前五分之一的“中级 Java 开发”。

面试官是曾经的小徒弟，碍于颜面，他勉为其难地录取了你。
你虽然看不起这个徒弟的不学无术，但家庭相册告诉你大丈夫能屈能伸...
某次任务中由于小徒弟上司的骚操作，导致项目延期。然而他把锅甩给了“头昏眼花的大专临时工”，官大一级压死人，你只得加班加点地弥补上司的错误。

日子久了你感觉身体熬不住，去医院查出了印象中仅存在于无良广告中的三高、心衰、肝肾损伤。
你知道病情的严重性，但不敢告诉家人，只得每个月自己去医院做治疗，服用昂贵的药。

某天在回家的地铁上你收到媳妇催你替孩子交学费的信息。
打开银行 app ，翻了翻几张卡的余额，多年以来攒的几十万已经见底。不过手依然控制不住地输入“我知道了”。
你没有到站下车，如同行尸走肉一般从起始站坐到终点站，又从终点站坐回起始站。

恍惚间你好像看见了一个拿文件袋考试归来的年轻人坐你对面，你像他那样已经是很久以前的事了。

---------------------------------分割线---------------------------------

“大专文凭够了”

“都那么卷了，读个二本没用”

“还不如多写两年代码”

这些论调都是认真的吗？我真的服了某些 V2er 。

LZ 在想什么？你的眼界就这么狭隘？十万二十万哪能比得上本科文凭？

本想多说一些的，看了帖子的回复，还是算了。

套皮嘛...

还得先问你你要做的项目是什么？

直说了吧，LZ 的方向走错了。

无论是你以学习的目的写一个 Demo 还是真正做一个可运营的站点。都应该以“抄”开始，而不是按自己想的先随性地做一个然后拿出来给大家改。

一个好的画师在磨练出自己独有的画技之前，他必须要有足够的对美的鉴赏力。有了对美丑的感觉，才有对画法好坏的定义，才有一个明确的努力方向。

我以前也曾用 JQ 手撸论坛系统，然后根据用户的体验一点点改，事后发现这完全是愚蠢的，或者说是很低效的。
像登录模块这种有“定式”的部分，我本可以借鉴外界的最佳实践，但却浪费了大量时间在改样式、文本上；
像帖子界面那样本该简洁的布局，应该把思考重心放在内容呈现上，控件的摆放细节却让我耗尽心神；
像权限分配一般重中之重的功能，我对其中的内涵一无所知，设计的时候各种“想当然”；

这一切都是因为我根本不知道这种内容系统该怎么做：
我接触的论坛类型少；
我从未在设计的角度思考我用过的这些网站；
我不知道这类站点会有哪些“潜规则”；
我只知道扣 Margin 、padding 的数值！

回到 LZ ，你的问题大体是类似的。
其实用过时的 JQ 做项目根本不是重点，重点是你现在连一些模块怎么做，一些最基本的“定式”“常识”都没有掌握。用几个 input ？用什么过渡效果？这些主观的东西不应该是 V2er 你一言我一语地教出来的。

你现在最好的学习方式就是抄，大量地抄。从方案到具体技术，一步步来，让自己形成一种知觉，在实现框架中形成自己擅长的模式。

自己的人生，自己做决定，自己负责。

其实这事没什么好辩论的。开源协议不是什么严丝合缝的法律条文，选择它时也没有什么特定的法律程序，双方都说得有理有据，要真拉扯双方都有拉扯的空间。天猪也说了本来就是很简单的事，说一声双方都知道就得了。

现在主要矛盾是天猪觉得 LZ 把他挂到 V2 上来害他被骂了，他要采取措施。建议 LZ 私下与天猪协商，事后让坛主把帖子删了得了。

我看了 Mix Space ，也看了保罗的小窝，有一些结合了个人经验的看法。

我没做过完整的前端 UI 方案，但做过 Discuz 的插件跟局部 UI 修改，恰好 Mix Space 这种板块布局风格非常像以前的 Discuz 二次元主题，我想可以说些什么。

由于主题叫 Kami ，加上 demo 标题，这应当是一套偏日式风格的 UI ，但我感觉到一些违和：

1. Helvetica 极其平淡，使用日式风格字体更好，比如一些黑体、细长体与细圆体。

2. 白天模式下的背景白对比过于强烈，造成阅读不适，可以换成温和的大色块。夜晚模式要好一些，但背景的横线仍让我不禁想起 QQ 空间中的“信纸”，有一种廉价感。

3. 透明底的控件不好。博客要设计得有层次感，一是突出内容的类属，比如正文、回复框与评论，降低读者的“负担”，二是反衬出背景，不致于文字与图像无序杂糅。

4. 减少色彩的使用。这个就不多说了。

5. 论坛式的板块布局不适合直接用于文章陈列。弊端很多：
- 无法从有限的板块宽度中提取完整的文章标题；
- 文章配图局限大；
- 横向空间利用率低；
- 整体有效信息密度低

就信息密度低多展开一下。无论是博客系统还是论坛系统，重要的还是有效信息，风格再强烈，该传达给读者的还是要传达的。所以除了纯炫技的飞机稿，非主要的图片元素喧宾夺主是打造主题时很忌讳的一件事。

希望 LZ 的项目能越做越好。

看了 Pixcall 的官网，有些东西可以说一说。

我建议你先对 Pixcall 和 Eagle 的官网做一做各级标题的词云分析。
Pixcall：“云端同步”、“本地客户端”“图片优化”、“浏览器扩展”、“客户端插件生态”、“免费”。
Eagle：“素材整理”、“激发灵感”、“快速找到收集”、“轻松整理”、“流水般浏览”、“用户喜爱”、“媒体好评”。
Pixcall 的主流服务群体是谁？是设计师等一众呈现视觉效果的群体，TA 们感性度更高，更受用表达情感的抽象名词而非技术名词。
你希望它是一个“硬邦邦”的工具，还是“柔软灵活”的助手？

同样的角度，动效的表达大于静图，内聚的表达大于宽放。就不展开说了，个人觉得 Pixcall 官网的内容及排版需要更加专业、有倾向性的设计。

然后我想讲几点关于竞品的理解。
（这里只是针对策划已知市面上已经存在同类产品的情况）

“凭什么抛弃惯用的 B 来选择你的竞品 A”是在产品立项的时候就要作出的思考。未雨绸缪利于在关键点上对症下药，如：
用户觉得缺少平台支持--使用跨平台、移植性好的技术。
用户觉得软件不够灵活--模块化、增加插件机制，甚至（部分）开源。
用户有路径依赖--复制竞品的逻辑与流程，大到布局、小到快捷键。

在运营端，先争取大牛背书，讲得一手好故事，有了基本立足点后借助各路大众媒体广撒网。推广与技术配合好，在宣传期降低活动准入门槛（别一上来就搞手机邀请码注册），筛选种子用户，做好反馈收集。接下来就是赶紧迭代，实在没辙了就修正赛道，在小众需求上实现弯道超车。

对于竞品开发，小团体对抗大公司可能只有一个有利条件：关键的运营人员、技术人员离实际用户“更近”，在快速反馈上有人员组织架构的优势。

确实跟 Twitter 风格很像，不过并不重要，如同 @yazoox 所说，怎么运营、怎么进行内容管理才是建设这类站点核心的地方。

Append 2

0X 年的时候写过游戏逻辑，技术可能过时了，就简单说说吧。

1. 不知道，这得问 LOL 的开发人员，不同游戏的 ping 代表的含义可能会不一样。
游戏内显示的 ping 值不一定是 TCP/UDP 的时延，也可能是专门为游戏设计的心跳机制中的网络参数。

2. 网络状况迥异的环境下，没有任何技术手段能确保双方都在某个 ping 范围内。
比起锁定延迟，我们更常的做法是在帧同步上下功夫，比如优先让网快的正常游戏，网慢的客户端对短时间内过来的更新指令作类似于快进的处理。

3. 不同架构、不同类别的游戏控制同步的方法不一样。
比如一款中心化的 RTS 游戏，采用的是服务器广播-客户端收发的方式交互，想要增加延迟可以设置广播队列的发送时间。对一款允许局域网内的 RPG ，纯粹的 P2P 通信，只需要交互前约定共同参数即可。

@littleylv 见 append

频繁地改需求，不外乎是以下几个原因：

1. 甲方对自己的需求不明确 或 乙方对需求理解有偏差。
这种还是挺有说法的，对口定制化跟不对口定制化情况略有不同。
对口定制化中，乙方在开需求会议的时候有义务引导甲方把需求漏洞补全；
非对口定制化中，需要甲方有人全程跟进，双方频繁沟通保持意见统一；

如果已经进入了开发期，有必要重新开展需求研讨会。

2. 甲方追加额外需求
甲乙双方在协商开发周期以及开发成本的时候就要明确额外需求的处理方式--优先级、费用、后续维护事项等。
一旦写进合同，照章办事。甲方来新的需求，乙方负责人会议评估，一致通过的话可以进行排期。如果不通过，对甲方反馈再作协商。

这里面有一个非常重要的点：甲方的需求不能直接到具体的编码人员，中间必须要有项目经理跟技术经理作评估。乙方需要有立场的独立性。


甲方是不会有直接的感同身受的，乙方需要维护自己工程师的利益。如果乙方只会两头吸血，那么 run 就对了。

对于已经语义化了的变量，我有一种评判代码逻辑组织是否合理的方式，即

用自然语言去试读代码是否会让人感到冗余。

从这个角度来看，我是同意 LZ 的说法，比如 if isOpened == true (假如 已打开 为真）就不如 if isOpened （假如已打开）。

之前好像回答过类似的问题。

一言蔽之，在体制内工作容易缺乏职业自信。原因懂的都懂，不赘述。

裸辞跟骑驴找马哪个好，这无法判断，很多事确实只能等到“盖棺”才能定论。但有一个事情是没错的，无论作了哪种选择，都要付诸相应的努力走下去，瞻前顾后、反复横跳是大忌。

既然是挂在网站上作个人展示，就不要拘泥于纯文字描述，可以发挥网络媒体的优势，增强一下读者的视听感官体验。

因为你也是 Web 工程师，前后端都做过。不妨：
- 做个个人经历的 timeline ，突出从学生时期到职人时期的里程碑节点。
- 对项目介绍作可视化处理，比如小程序的动图+动效展示。

个人网站一般是第二入口，即大部分点进去的人是“对你有点感兴趣”的对象，他们可能从别的地方（投递的简历 /论坛的贴子 /Github 的项目代码）知道了你，然后想进一步了解你。因此我觉得在里面感性的建设是必要。

最后是个个人看法：开源出来的东西尽量把 README 写好。
我注意到“喜欢编写健壮的代码，编写会以牺牲性能来提高可读性的代码，因为代码是给人看的”，从工程的角度看，纯叙述性的项目描述也是可以提高项目可读性的。

...给后来的人总结一下：

LZ 面试了一个图形工程师，感到不快，原因如下：

对方背景似乎很牛，但对于 LZ 的核心问题没回答到点子上。
从对方的话语中得知他只想“找大牛抱大腿”（可能还有点不愿意做一线实施的意思，仅个人猜测）。