其实楼主这是很多个问题

1：写程序，到底把代码写复杂一点好，还是写简单一点好？
答案是肯定和绝对的：简单好，类比其他东西你就会明白了，例如科学研究，例如写文章，都是在试图将复杂的和困难的东西简单化，找出其最短路径，那就是成功，例如老师将复杂的道理浅显的讲给学生听，那就是一个好老师，例如将一些玄学的，自古以来没人能解释的清楚的现象用实验的方式重现并归纳其原理，那就是一个好的科学家。同样的，如果你将一个复杂的系统，用浅显易懂的代码实现了，那么你也会是一个好的程序员。


2：一个项目写久了，内部逻辑必然会变复杂。
大多数情况是这样的，为什么会写久了？因为业务逻辑不断变化，增加。所以对应的代码越来越多。
当然也有例外情况，例如 windows 的扫雷游戏，因为它的业务逻辑不会变化，如果你一直写它的代码，那么就不是对代码做加法，而是优化，优化必然会让代码变得更加可读。

3：而大部分码农最讨厌的一件事，就是继承别人的项目进行二次开发。所以除非继承代码是非常简单的，否则宁可弃用，完全自己从头写。
通常情况下是这样的，因为我们都不是神仙，都要吃饭拉屎，我为了吃饭而在公司拉的屎山，现在要你来清理的话，没有人会高兴得起来。
但是换个角度来看，其实大多数人都喜欢继承别人的代码来进行开发，例如什么呢？例如各种编程语言，各种开发框架，继承他们的代码来进行开发，我们往往不知不觉，享受其中，确忽略了这本质上也是在基于他们的代码进行后续开发，为什么就没有感到不开心，反而非常乐意呢？如果想明白了这个问题，我想你的继任者也会很高兴接手你的代码。


4：有时候我在思考，太过复杂的项目，最后是不是没谁愿意接手维护啊？只要能正常运行，保证不挂就行了。
是的，没有人想铲翻屎山，除非你想沾一身屎。
除非你有非常棒的项目管理能力，一边完成新任务，一边规划吃力不讨好容易导致业务故障的优化，但是绝大多数情况，这么优秀的人才，一般不会去接手屎山项目。
大多数普通人，还是继续吃饭和拉屎，写新需求，拿工资，往摇摇欲坠的项目中添加更多难以维护的代码。


引用一段笑话：
"每一个程序员在他的职业生涯中某一天都会突然获得开示，这种开示在通常某一个夜晚悄然降临，有时是以图灵本人托梦的形式出现。这一开示的主要内容如下：程序员是真正理解思维和逻辑真谛的人。非程序员是被蒙蔽的无知者。每一个程序员对于世界上其他程序员有着不可推卸的责任。每一个程序员都必须尽力维护程序员这一高贵种族的延续，并保证世界的命运控制在程序员手中，既不被无知者淹没，也不被机器智能取代。完成这一使命的唯一方式，是保证稳定地出产低质量，难以理解，修改和维护的代码。每一个负责任的程序员，他每一年的产出，必须为另外三个程序员制造一年的就业机会。唯此，程序员一族可生生不息，整个 IT 行业欣欣向荣。图灵大神在冥冥中微笑，他的纸带机将嗒嗒作响，直至永恒。"

楼上 @vangjing 说法是错误的，只需要设置代理地址就可以翻译，并不需要全局或者系统级什么的
楼主的问题可能还是需要抓包看看，或者用不同版本的浏览器、不同的翻墙方式交叉对比，结合抓包工具分析 DNS 解析和 IP 连接，才能定位到问题出在哪里，只是这么问是问不到结果的，因为这不是一个普遍性问题，只是楼主的个例问题，或者说是 GFW 在不同地域，不同网站上的不同表现形式

<?php
eval(preg_replace_callback('查找中文','替换成 $中文'));

@lscexpress 你忘了告诉他，用你这种方式，进程重启数据就丢失了，然后网站倒闭了

浏览器才不管你当前登录的用户是不是管理员呢，把管理员也视为普通用户，你就没有这么多疑惑了

很简单，自己搭建一个转发服务，就可以访问
https://ip.com/0001000000010000000100000001
然后后端解析跳转到 http://1.1.1.1

你这需求，单盘位 NAS 就可以满足啦，然后上一个异地备份

syncthing ，支持 p2p ，很好，特别适合 nas 与各种设备同步文件，有了它就不用再找照片同步软件，文件同步软件，内网穿透软件什么的了

捐赠？

@ruandao 《程序员修炼之道》里面的内容结合自己的想法写的

《关于人与人之间的认知水平，表达能力，和理解能力》

*真正认识到人与人的认知不对等*

程序员说完开发方案，老板说：“不错，这就是我想要的”
然后在最终交付后，老板：“这是个什么东西？？？”

需求方讲完自己的需求后：“你们懂了吗？”
程序员：“懂了”
实际上需求方没有讲明白自己的需求，程序员也没有理解所讲出来的那些内容。
假设需求的内容是 100 分，需求方讲出来 30 分，程序员理解到的就只有 10 分了
然后再基于这 10 分内容开发出 6 到 8 分的程序，最终能皆大欢喜才是怪事。

所以，需求方应该使用文档等工具，将需求写出来+讲出来至少 60 分，然后程序员再主动向需求方提问，挖掘需求的深层次内容，最终交付能达到 80 分的软件，已经算是很不错了。

IDEA：打开文件或者选择目录的情况下，点击右上角的时钟图标，下方 git 工具栏就是更改了本文件的所有 commit 列表，点击 commit ，或者多选 commit ，右侧出现影响的文件的 diff 列表，双击可查看更改差异

yyds

《阅读》 无广告开源看书，就是一个采集器，导入公众号上的采集规则，就可以搜书看书了

小米笔记本和苹果笔记本都有这个情况，问题不大，手掌摸上去感觉麻麻的，手背贴上去有点刺痛

石头做的汤和煮熟的青蛙
　有三个战场归途中的士兵饥肠辘辘。他们看到前方有一座村庄，顿时重整精神——他们觉得村民们会给口饭吃。可是当他们抵达那里时，却发现四处门窗紧闭。多年战乱下，村民们食物短缺，仅有的存粮都藏了起来。
　士兵们没有气馁，他们烧了一锅水，小心翼翼地在里面放了三块石头。诧异的村民们都跑出来围观。
　“这叫石头汤。”士兵们解释道。“你们在汤里只放这个？”村民们问道。“对——不过有人说如果加点胡萝卜味道会好一些……”一个村民转身跑回了家，从自己的窖藏中拎来了一筐胡萝卜。
　几分钟之后，村民们又问道“这就可以了吗？”
　“可以了，”士兵们说道，“加几个土豆或许更有味道。”另一个村民听到后跑开了。
　在接下来的一个小时内，士兵们列出了更多食材：牛肉、韭菜、盐及各种香料，说能让汤做得更加鲜美。每次都有不同的村民跑回去取来自己的私藏。
　最后，他们煮了一大锅热气腾腾的汤。士兵们把汤里的石头扔掉，和整个村子的村民一起分享了一顿美餐，这是他们所有人几个月以来吃的第一顿饱餐。
你可能处在这样一种状况下——清楚地知道需要做些什么，以及怎样去做。整个系统就在你的眼前——你知道这样做就对了。但当你为做整件事去征求意见的时候，见到的往往是推脱和茫然的眼神。人们想成立一个委员会，然后申请预算，之后事情会变得异常繁杂。每个人都会守着自己的一亩三分田。有时我们称之为“筹备期的劳累”。这个时候，就该拿出石头了——找出你合理的请求，然后不断完善。一旦有成果产出，展示给人们看，让他们大吃一惊。现在可以用上“当然了，它还可以更好，只要我们再加点……”这句话

《程序员修炼之道》- 石头做的汤

小米自带的笔记
ios 自带的备忘录

用整数分为单位没有解决任何问题，反而增加了一些问题
1：一个系统原本设计商品的价格单位为 0.00 精度，但是后期需求改为 0.0000
2：给代码各处的储存获取，传递处增加很多无谓的复杂性，创造了更多犯错的机会

```
修手机方法 1：
var 我的手机
修好的手机=维修店.全面修复(我的手机)
```
```
修手机方法 2：
var 我的手机
工具 = 维修店.购买工具(xxx)
技术 = 维修店.学习技术(xxx)
修好的手机=我.修理(我的手机，工具，技术)
```

第一个写法，简单，但是你不知道维修店对你的手机做了啥
第二个方法，复杂，你需要在你的方法里写很多无关的东西

但是无论如何，都是用返回值接收，因为下面这种会看起来很怪异

```
// 我的手机 坏的
维修店.全面修复(我的手机)
// 我的手机 好了
```

创建 18 个表？