摘要：
依赖倒置原则: 一般来说我们认为作为底层基础框架的逻辑是不应该依赖于上层逻辑的, 所以我们设计软件时也经常是: 需求 - 上层逻辑(直接实现需求) - 发现需要固化的逻辑 - 开发底层模块 - 然后上层调用底层逻辑. 但是这样做一开始是没问题的, 但是当上层剧烈变化时, 会不断的侵染底层逻辑, 底层 阅读全文
摘要：
有时候一个地方暂时看不清怎么写比较好, 往大了说是框架, 层次, 往小了说, 不知道起啥名字, 一个总是让你内心凸起一个小疙瘩的 框架, 类, 函数, 命名 都会让你每次路过时 被 咯一下. 有时候会想着, 我忍了 慢慢的,你会发现, 因为这个小疙瘩, 又不得不引入另外一个疙瘩. 慢慢的 坑坑洼洼的 阅读全文
摘要：
在一般的技术开发团队里,大家各自负责各自的模块, 但是随着需求的不断扩展, 各个模块开始不可避免的产生交集, 还有大量的底层逻辑,说不清谁来负责 当出现其他需求进入自己模块的时候,需要对接口, 对设计提出新的要求, 需要迭代升级时, 难免出现阻力, 如果让本来负责这个功能的同事来负责升级,会占用他当 阅读全文
摘要：
最美好的情况是, 写A的时候不用管B. 写B的时候不用管A. A把直接的工作做好, B把自己的工作做好, 需要结合的时候,左手一个,右手一个,恰到好处 从上中学的时候, 在螺丝钉和螺丝帽上领悟到的规范性,接口一致性的重要性, 那种给使用者带来的快感, 才是最适合创世者的环境 阅读全文
摘要：
定义流程的代码绝对不应该也不可能复用. 除非是有继承/替代关系的类,可以共享/继承流程 定义流程的代码在一定时期可能是具有复用价值的, 但是在迭代过程中,各个不同分支对流程的差异需求会导致之前复用的流程千疮百孔, 最终导致各个分支的流程都不清晰. 绞缠不清, 难以维护, 牵一发而动全身 涉及多条逻辑 阅读全文
摘要：
1. HeadFirst 设计模式 - 写除了HelloWorld之外的代码 2. 重构-改善既有代码的设计 - 少写代码少出bug 3. 敏捷软件开发 原则模式与实践 - 摆脱包袱撒腿跑 4. UNIX 编程艺术 - Let Me K.I.S.S 阅读全文
摘要：
面向接口=还有解药 数据驱动->消除硬编码->消除switch->消除if-else->表驱动->拥抱变化 https://blog.csdn.net/chgaowei/article/details/6658260 做一个有产品意识的技术,代码本身何尝不也是一个产品. 阅读全文
摘要：
与同事的聊天记录: 嗯.我也是习惯的看代码时发现不合理的就顺手改掉我自己有时候也是写的时候头昏,后面发现自己也看不懂,作为代码的阅读者去理解自己的代码如果理解不了,那就按照理解的方式去改成合理的,一般来说可能会引入bug,但是会提高代码可读性一段时间后,代码出现bug的可能性就很低了,因为可读性高, 阅读全文
摘要：
https://coolshell.cn/articles/5201.html/comment-page-2#comment-1932554 过去半年基本上完整经历了这个文章的各个阶段,看完文章结合自己的经历,发现的确有些值得反思,但是哪怕过程太痛苦,但如果是一个自己要长期维护的模块,”至少亲生的b 阅读全文
摘要：
主要内容来源 https://blogs.unity3d.com/cn/2014/05/16/custom-operator-should-we-keep-it/ 在我们代码里,如果有这样的代码: 那Unity底层做了什么? (事实上,除了GameObject,继承自UnityEngine.Obje 阅读全文