基本要求

地铁上，一个妈妈用手遮着孩子的鞋子，为了不弄脏旁边乘客的衣服。评论者说：“这不是很基本要求的吗？”

是的，这位同学说得没错。但是，究竟做这个的是多数还是少数呢？

很多时候，我们想当然地以为，一些基本的东西，实际上我们都没有做到：

• 譬如不随地吐痰扔垃圾
• 譬如给老幼病残孕妇让座
• 不在公共场合大声喧哗
• 不要在社交媒体做没脑的喷子
• 不要为了蝇头小利出卖自己的人性，譬如做5毛

素质与底线

很多时候，我们可以简单粗暴地归纳，上述那些人没素质。同理，很多开发人员并没有基本的素质：

• 不管代码质量，填满工作时间便可，善于挖坑，“我离职后，哪管洪水滔天！”
• 懒散，故意拖进度
• 老油条，得过且过
• 拿网上有版权等代码据为己有

更有甚者，在犯罪：

• 大学毕业后第一份工作，一个离职员工，把硬盘格式化，还破坏分区
• 还是第一份工作，部门经理偷公司的源代码去卖

不奢求每个开发人员都写高质量代码，但是起码的是，代码能被维护，程序跑起来不会随意崩溃，用户体验不会顿卡，等等。

父母从小教导我们，不属于自己的东西不要去贪图，这个包括各种手段，譬如偷、抢等。邀功、推塞责任等都是罪恶。

八荣八耻

• 以踏实编码为荣 以心浮气躁为耻
• 以详细注释为荣 以注释残缺为耻
• 以勤于测试为荣 以懒于测试为耻
• 以简明文档为荣 以冗余文档为耻
• 以注重团队为荣 以孤傲自大为耻
• 以刻苦钻研为荣 以敷衍了事为耻
• 以善于总结为荣 以不思进取为耻
• 以质效并进为荣 以单取其一为耻

来自这里

 

• 以动手实践为荣，以只看不练为耻。
• 以打印日志为荣，以出错不报为耻。
• 以局部变量为荣，以全局变量为耻。
• 以单元测试为荣，以手工测试为耻。
• 以代码重用为荣，以复制粘贴为耻。
• 以多态应用为荣，以分支判断为耻。
• 以定义常量为荣，以魔法数字为耻。
• 以总结思考为荣，以不求甚解为耻

来自这里

欲望与追求

合格的开发人员，应该有自我提升的想法并且付诸行动，譬如下班后去学习一下新技术，在工作中，遇到不满的代码会尝试改进。人如果没有梦想，那和咸鱼有什么区别？

懂的交流

码农不应该是那种刻板的书呆子不善于交流的形象。技能分两种，软技能和硬技能，前者如人际交流、情感控制等，后者如对某种特定技术的掌握等。

人是群体动物，软件开发是团队协作，一个人难以完成一个系统，所以基本交流技巧必须掌握。

不管产品经理如何虐你千百遍，你还是得待他们如初恋，尽管一般都有比较苦涩的结局。

 

 

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

在《爆栈之旅》，我根据大家都实际情况、水平、方向等规划职业路径，手把手带你做实战的项目，用最高效的办法达到你想要的高度。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

前言

之前在文章《学员问答精选 – 1 – 数据库表拆分》中提及过一个数据库的设计问题。今天，微博上的@火丁日记 说：

表里有一个 status 字段，用来表示数据的状态，比如订单的已付款，已关闭等。以前我习惯把它定义为 INT 类型，但是慢慢的，我就记不清楚 1，2，3 到底指的是什么意思了，也想过用 ENUM 类型，但是不方便扩展，最后，我觉得直接用 VARCHAR 类型算了，去它的三范式。

百家争鸣

• 一些网友赞同使用varchar
• 一些还是觉得应该enum
• 一些觉得最原始的int是最好的
• 一些觉得要用字典表

各种考量

其实，一个字段类型的考量，主要包括：

• 准确性/精确性：必须能满足业务需求，不能丢数据，溢出等
• 性能：一般来说，int的运算比varchar要快
• 空间：尽可能占用最少的空间，一条记录浪费1字节，10亿记录就浪费1GB空间了
• 辅助性：譬如方便功能上的排序、方便开发人员记忆等

如果要为开发人员着想：

• 数据库里，表的字段可以添加描述，譬如0: Pending, 1. Paid, 2: Processing, 3: Delivered, 4: Cancelled
• 如果不满足，那可以用char(1)，26个字符足够表达各种状态了吧？不够就char(2)，再不行就char(3)，主要是省空间。为什么不用varchar(n)而用char(固定数值)？因为varchar(n)要运算做各种trimming，起码在SQL Server里，譬如len()就是后面空格去掉后的长度，和datalength()不一样。这个一般是单词的首字母，记起来比int舒服些。我发现一些公司就是这样做的。

如果要追求节省空间，完全可以用tinyint甚至varbinary，毕竟1个字节有8位，一般订单也就那么几个状态吧？

首先，如果用varchar，那么要考虑：

• 你这个状态的值，是放英文还是中文？你的产品是否全球化的？
• 如果是放英文，那你还是需要本地化。
• 而且，既然要本地化，就没必要放完整的单词，char(1)便可，原因参考上面。

如果使用int，那么要考虑：界面文本显示，开发人员友好。

如果要考虑界面显示如排序等，一般来说，界面需要先根据条件过滤出来某种状态，但是，如果你的业务逻辑就是要同时显示多种状态的数据，这要考虑目标数据只是已经在界面的，还是在数据库的：

• 界面：那数据库的类型还是最精简的varbinary(1)，在界面对值进行解释然后根据解释出来的规则进行排序

当然，有些业务系统会使用字典表，相当于外键，如果返回结果的时候就join，这里会比case xx when 1 then ‘某状态’ 的效率要差些，而且字典表还是需要做语言本地化的。

总结

其实，不管用哪种方案，都没有完美的，还是应该具体业务需求来。

 

爆栈之旅

是否想技术水平快速提升？是否希望快速成为公司的技术骨干？

• 把我这10多年来所学到的知识、总结的经验、吸取的教训分享出来
• 针对不同的学生量身定制规划学习成长路线、1对1个人指导、代码审阅等
• 解答各种技术问题
• 为公司提供技术解决方案

请查看本站右边的信息联系我。

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

苦恼

我的一个学员问我：“我已经入职了，有点苦恼，感觉现在一天没什么时间是自己的，不过公司这边就有安排导师就是带着我，现在在慢慢地熟悉一些东西。我现在还好，没负责什么项目，所以一天还有一些时间可以自己学习一下，可是看周围的人都感觉好忙，可能就没剩什么时间了，老师，您是怎么解决这个问题的？”

存在即合理

周围的人很忙没有时间剩下来？这不是正常吗？老板给钱你来上班就是努力干活啊，哪里有所谓的”me time”。

所以一般人想学新的东西，除非公司上新项目/改造系统，否则只能自己回家慢慢学，譬如跟我学 😉

专注

工作中，多样事情同时发生，譬如你写代码的时候，刚来公司的新人张三来请教你，可能还没有回答完，隔壁老王又来找你讨论产品的修改。

我们做个小游戏：你同时把左手放胸口搓圆型，和右手拍打脑袋，有点别扭，是吧？

同理，很可惜，很少人能同时应付多个任务，毕竟，你不是多核CPU可以并行计算，你顶多可以并发处理，就是跟CPU那样不断做context switch，在不同的项目中来回切换。

但是，这个的效果其实并不好，因为思路很容易打断，而且继续做的时候要思考一下之前做到哪里，接下来怎么做。

如果是你想合理控制时间，你需要把时间集中起来，某个时间段内任何其它东西都不做，只专注一样东西，这样更容易有实际的产出，譬如每天安排：

• 上班中，多个30分钟，都只做一样事情
• 下班后，30分钟看看新闻
• 下班后，30分钟研究你的领域里的新技术
• 下班后，30分钟做一下你的个人爱好
• 下班后，30分钟刷一下社交媒体跟进一下好友动态

站在巨人的肩膀上

经过研究后还是不懂就马上问，别浪费时间，合理搜索正确答案和利用第三方解决方案。不要钻牛角尖，掉坑里爬出来可能是几天甚至几周之后的事情。

 

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

在《爆栈之旅》，我根据大家都实际情况、水平、方向等规划职业路径，手把手带你做实战的项目，用最高效的办法达到你想要的高度。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

前言

数据库是大中小型系统的基石，所有操作，最终都需要和数据打交道，一切来源自数据，一切回归数据。

传统的非关系型数据存储

XML、JSON、CSV等文件，没有关系约束。

关系型数据库系统RDBMS

传统关系型数据库系统很难横向扩展(scale-out)，很多时候我们都是仔细设计怎么对数据进行分库分片，可能垂直拆分（业务给表分块），也可能是水平拆分（表按时间、地区、自增ID等切分），还可能混合拆分。

传统关系型数据库因为追求强一致性，所以一般高可用性是通过各种形式的日志备份(log backup/log shipping等)。

分布式

当单机无法支撑业务的时候，我们可能会优先考虑升级硬件(scale-up)，但单机迟早有物理限制（譬如有些机器最多支持1TB的内存），这种情况下，我们会实现分布式，所谓的scale-out。

但是，根据CAP理论，一般分布式系统做不到C（强一致性），所以他们会实现2PC（Two Phase Commit，二阶段提交）。

NoSQL

NoSQL天生支持分布式、多节点、高可用性，高性能是他们的卖点，但他们一般只强调A（高可用性）和P（分区容错），而做不到或者很基础的支持C。

MongoDB

MongoDB是NoSQL界的旗帜，他们无孔不入的宣传手段让这个问题诸多的解决方案成为很多公司的首选。

坑这么多的 MongoDB 到底是怎么做起来的？其背后的公司运作得不错：在各地区搞了用户组，给组长资金支持，组长办线下活动、找“专家”开讲座/写博客违心地夸奖 MongoDB，文章在这里《MongoDB 背后的营销策略》。

NewSQL

而如MongoDB之类的NoSQL虽然天生支持scale-out，但无法解决CAP定理指出的问题： 一致性、可用性、分区容错三者不可兼得

所以NewSQL的出现尝试解决这个问题，他们的目标是拥有NoSQL的高可用性和分区容错，还拥有传统关系型数据库系统的强一致性。

CockcroachDB

CockcroachDB是相对成熟的新型分布式数据库系统，底层基于PostgreSQL，所以支持传统的SQL查询，做得相当智能，可以自动根据数据的访问频率来把热点数据推送到最近的节点。

特点：是CP非A（强一致性和分区容错），兼容PostgreSQL。

官网在这里，开源。

Fauna

Twitter一些工程师离职后搞的数据库系统，高可用性、高性能、分布式、支持最严格的ACID。这篇文章拿MongoDB 4.x支持ACID来比较，实际上MongoDB并不支持强ACID，而且只有他们收购的WiredTiger引擎才支持，而且只支持本地节点而已。

官网在这里。

ActorDB

分布式数据库，特别适合作为手机App的服务器端存储，开源项目。

比较

其实，大部分的观点是，NoSQL比传统关系型数据库快，这个定义必须明确一下：

• NoSQL的存取是读写一个文本（主要是JSON/B SON格式)，一般没有外键约束等检查，没有关联查询，所以简单粗暴的操作是来得快
• 关系型数据库系统，一般的读写要做以下操作
  • 写
    • 规范化：一条记录根据业务关系拆分别存储到不同的表
    • 锁
    • 外键约束
    • 更新索引
  • 读
    • 关联表

所以你看见，关系型数据库系统，需要额外的操作，自然会“慢”。但是，说传统关系型数据库就是慢的同学，估计没有用Bulk Copy。

应用场景

你要去探望在小溪的对面的邻居，你会走桥、坐船、开汽车、坐飞机还是乘宇宙飞船过去呢？

同理，不同的场景用不同的数据库系统。

 

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

在《爆栈之旅》，我根据大家都实际情况、水平、方向等规划职业路径，手把手带你做实战的项目，用最高效的办法达到你想要的高度。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。

入乡随俗？

泰国要搞一个大型基础设施，找了中国的工程队去，当地的协会要求该工程队先考一个资格证，国王知道后，说：“你们就是自己做不了才找的中国的工程队过来，这说明人家水平比你们高，你还需要别人考取你们的资格证？这不像话。不需要他们考证。”

一些时候，新人进入公司，不管该新人背景如何，水平多高，就是把你当初级程序员那样用，即便过了一段时间该新人对业务系统已经有一定的认识，仍然得不到应有的重用，反观一些水平差不少、态度很差的老油条却不断升迁、加薪。

改进和重写

英文里，我们有evolution 进化和revolution 革命，一个字母之差，如中国古语说：差之毫厘，谬之千里。

一些老系统，如果要改造，主要考虑项目的大小和公司的资源，如果系统较小、资源充足、权衡利弊后回报合理，那可能选择重写。否则，应该采用进化的方式逐步改进。

我之前说过，开发人员有英雄主义情结，有些开发人员做得比较极端的是，看着系统不爽就说要推倒重来，主要心态是：

• 我想学新东西，平时没机会，现在找这个做借口，练手
• 老子自认天下第一，别人的代码都是垃圾，都得扔掉

当然，也有可能是客观的情况：系统不行

• 系统设计一团糟 (big ball of mud)，无法维护和改进
• 要么性能低下
• 要么问题百出
• 要么用户体验糟糕
• 要么跟不上时代，如不支持各种移动设备，或者用户量上来了现有架构无法应付

其实，即便全面改造现有系统，也可以有序地进行，譬如垂直按模块来，分而治之。又或者采用所谓的lift & shift，改造底层架构，譬如本地服务器改成用云的分布式。

曾经有这样的系统，采用新技术重写，花了8年，仍然还是半成品。所以还没有交付，技术又落后了。

 

想知道为什么我这么多年来能掌握那么多种技术，不仅仅是广度，还有深度，达到我所说的“爆栈”吗？

在《爆栈之旅》，我根据大家都实际情况、水平、方向等规划职业路径，手把手带你做实战的项目，用最高效的办法达到你想要的高度。

爆栈之旅

版权所有

所有文章内容版权所有，任何形式的转发/使用都必须先征得本站书面同意。本站保留一切追究的权利。