Group items tagged

运维又会分成基础运维和应用运维，开发则会分成基础核心开发和业务开发。

基础运维和开发的同学更多的只是关注资源的利用率和性能，而应用运维和业务开发则更多关注的是应用和服务上的东西。

试想一下城市交通的优化，当城市规模到一定程度的时候，整体的性能你是无法通过优化几条路或是几条街区来完成的，你需要对整个城市做整体的功能体的规划才可能达到整体效率的提升

当系统越来越复杂的时候，用户把他们的  PHP，Python, .NET，或 Node.js 的架构完全都迁移到 Java + Go 的架构上来的案例不断的发生。

更为工业化的技术

使用更为成熟更为工业化的技术栈，而不是自己熟悉的技术栈

不要自己发明轮子，更不要魔改

完全没有必要。不重新发明轮子，不魔改，不是因为自己技术不能，而是因为，这个世界早已不是自己干所有事的年代了

好些公司的架构都被技术负责人个人的喜好、擅长和个人经验给绑架了，完全不是从一个客观的角度来进行技术选型

全中国所有的电商平台，几百家银行，三大电信运营商，所有的保险公司，劵商的系统，医院里的系统，电子政府系统，等等，基本都是用 Java 开发的，包括 AWS 的主流语言也是 Java

NoSQL 的数据库在 Join 上都表现的太差

永远使用完备支持 ACID 的关系型数据库

性能上的事，总是有解的，手段也是最多的，这个比起架构的完备性和扩展性来说真的不必太过担心。

很多公司的系统既没有服从业界标准，也没有形成自己公司的标准，感觉就像一群乌合之众一样。

Restful API 的规范。我觉得是非常重要的，这里给两个我觉得写得最好的参考：Paypal 和 Microsoft 。

监控系统宁可自己死了也不能干扰实际应用。

一个公司至少一年要有一次软件版本升级的review，然后形成软件版本的统一和一致

架构和软件不是写好就完的，是需要不断修改不断维护的，80%的软件成本都是在维护上。

通过服务发现或服务网关来降低服务依赖所带来的运维复杂度

一定要使用各种软件设计的原则。比如：像SOLID这样的原则（参看《一些软件设计的原则》），IoC/DIP，SOA 或 Spring Cloud 等 架构的最佳实践（参看《SteveY对Amazon和Google平台的吐槽》中的 Service Interface 的那几条军规），分布式系统架构的相关实践（参看：《分布式系统的事务处理》，或微软件的 《Cloud Design Patterns》）……等等

没有自动化测试，没有好的软件文档，没有质量好的代码，没有标准和规范

以前欠下的技术债，都得要还，没打好的地基要重新打，没建配套设施都要建。这些基础设施如果不按照正确科学的方式建立的话，你是不可能有一个好的的系统

与其花大力气迁就技术债务，不如直接还技术债

建设没有技术债的“新城区”，并通过“防腐层 ”的架构模型，不要让技术债侵入“新城区”。

如果有一天你在做技术决定的时候，开始凭自己以往的经验，那么你就已经不可能再成长了。

做任何决定之前，最好花上一点时间，上网查一下相关的资料，技术博客，文章，论文等 ，同时，也看看各个公司，或是各个开源软件他们是怎么做的？然后，比较多种方案的 Pros/Cons，最终形成自己的决定

我很喜欢追问为什么 ，这种追问，会让客户也跟着来一起重新思考。

激进并不是瞎搞，也不是见新技术就上，而是积极拥抱会改变未来的新技术

不是不喜欢的就不学了，我对区块链和 Rust 我一样学习，我也知道这些技术的优势，但我不会大规模使用它们。

进步永远来自于探索，探索是要付出代价的，但是收益更大。

不敢冒险才是最大的冒险，不敢犯错才是最大的错误，害怕失去会让你失去的更多