@phinex
@xinbaqiu 对我奇怪的就是这点，辅导员说了这个需要回去，但是我当时大学毕业的二战室友却还在上海租了个房子继续二战，感觉不太对劲，就这点其实比较重要，一旦回去考的话觉得不太好。

955 按理说才是正常上下班时间吧。重点还是有没有严格的考勤制度，做的事情是不是水分较多（不是指含金量，是指时间可调配程度较高）。无薪 996 无外乎都是“弹性上下班”给搞的，有薪 996 可能就是卷了。

另外，还需要参考工作强度，假设工作时高强度，例如高铁司机、航空业，那基本上不到 8 小时一半可能就要必须强制休息了。但是写代码、做表格之类的工作，可以上厕所、打电话、刷 V2EX ，那就不管工作多久都肯定会摸鱼。

再比如像保险、外勤、出差等情况， 如果一直不是待在自己的工位上，反而摸鱼很难，虽然那样上下班时间很早，但工作时最好不做别的事情。

@hh4646908 关灯或者拉了遮光帘应该效果还好吧，那种情况下暗吗，要是黑暗环境还是很暗的话我可能接受不了。

@hh4646908 是因为亮度低的原因吗

两地三中心，我觉得如果是个人的话，这样的备份方案要至少有一处是自己可以物理控制的，例如自己的移动硬盘、可全部管理权限的电脑、U 盘、碟片等。

数据就算有 1 万种保存途径，软肋终究是人。只有自己都碰不到的地方才是最安全的备份（狗头）。
@qsmd42

@lucays 电视对于租房来说太折腾了，而且我自己是本来打算买个显示器来着的，但是考虑到现在有的显示器够用了，而又缺少一个大屏幕，所以就想考虑投影。

我个人建议使用 mac 时候如果把 mac 当成台式机来用，接一个好一点常插的扩展坞，然后鼠标接收器怼上面。

然后买个支持侧边按键或左右滚轮的鼠标代替手势。

有，但是无一例外都要备案或实名。（现在不清楚具体哪家还在运营了，可以自己搜一下？我记得 coding 之前我用过好像还不错）

看起来国内很多“国产化”操作系统都基于 CentOS 改的，比如 OpenEuler 、TencentOS （十处优化的 CentOS ，版本号都没删），服务器版 Kylin 还是啥来着，我觉得也可以考虑下。

B 站的还好，如今很多小公司开发的产品数据库里面的字段名称是这样的：YWDM,XTMC,SFZH,JTZZ,XH,ID,SJHM,XMBH,YX

而且没有文档，所有字段 VARCHAR

同求，不过我的看法是现在 Word 格式虽然是开放的但还是很复杂，复杂就有点私有那味了，也就是不能完全通过自己的代码来操控 DOCX 文件内的每一个细节。

我之前是尝试使用各种语言的各种库生成 DOCX ，但反过来就很难。（因为有时候你永远也不能确定这份 Word 文档的一段简单的文字格式有多复杂）

感谢提醒，你知道我第一个想到的网站是什么吗？

CSDN 表示很淦（ doge ），它的登录后复制功能这样完全被 Edge 秒杀了，刚才试了一下，直接可以把代码块拷贝出来。

@libook 你说的在理，我一开始是打算把路由器放到书房的，但是又有个新的问题我忘记提到了，是书房很挤，光猫的弱点箱里面也只能塞一个光猫进去了，路由器完全放不进去，如果把路由器放在光猫旁边，那么也会导致书房门无法完全打开（箱正好在门后面）。

如果把路由器放在书房外面，通过墙内线连接光猫，路由器放在书房桌子上，那样就路由器只能是无线 AP 了（我现在已经是路由器拨号，不打算光猫拨号）。

卧室到书房的弱点箱内有两条线是通的，弱点箱和书房书桌旁边也是有一条墙内线是通的。书房主机也可以选择使用 WiFi 进行连接。

@9544 有没有那种体积很小的交换机，就几个口比路由器还小的

@acbot 打印机是 2.4G WiFi ，而且对速度要求没那么高，所以就有了如图的配置，究其原因还是书房太小了点，那个墙里面的光猫放进去网络墙门里就啥也放不下了。不过我还是打算尝试一下你说的把路由器放过去是啥效果，感谢。

@acbot 有道理，但是卧室的 WiFi 信号就不好了。

就是类似交换机那样有一排网口的一个东西（但不是交换机，没电源），我的理解就是类似那种网线一分二的东西，但我也不知道这样会不会影响速度。这样接的话路由器和 NAS 是可以通的，所以只有速度问题了。
@fastcache

我感觉这个应该不是吐槽的问题，而是开源本身的定义问题。

现在大多数开源项目其实只是开源协议+代码部分开源，好一些的开源项目带 Issue 光速处理的。但是开源项目本身不是一个产品化或标准化的流程，写设计文档这件事就相当于招标投标那些流程然后开发时候做的穿插的一件事情了。如果将设计文档写好，那么开发者完全可以将这个当做一份完整的产品售卖，不开源的效益会更好。

而且设计文档本身可能写起来比代码更费力，就好比大学毕业设计写一个系统，自己写的代码是什么样心里很清楚也许没那么复杂，但就是难以在短时间内写出优美的设计方案来。

举一个简单的例子：编写一个 Web 框架，有一个路由解析函数，代码层面也许就是几个方法组合起来带过，自己心里很清楚，但是转换成详细设计文档，你就需要用额外的精力去画这个解析过程的流程图、思维导图、数据结构相关的表等，而有这些时间，我相信开发者更乐意先把 TODO 搞完。虽然一边写代码一边画流程也不是不行，但是代码可能好改，流程图也必须跟着反映变化，而这时你的思路就必须以设计文档为准了，这里你写的可能不是项目，更像是软件工程。

我觉得改善这种设计文档缺失的局面有几种解决办法：

- 首先就是让自己的项目变得成为类似标准一样的东西，自然有人会请求读源代码、看看“教科书”式的项目是怎么样炼成的。
- 其次就是不要单人开发，最好有一个不超过 5 人的小开发团队，提前对项目做好规划，但是团队内每个人都要非常清楚自己在做的事（人数少就是为了防止有人浑水摸鱼啥也不知道）。
- 开源项目模块化，尽量将自己的一个超大型项目拆分成可独立的小项目，比如会话模块、路由模块、连接保持模块等。
- 如果是小项目，可以在写 README 时，让 README 本身不仅做简介，还做一下对程序工作流程的简介（这个很重要，有时虽然可能缺失文档，但是非常有助于包括自己在内的他人可以更方便地读源代码）。