在我的印象中这本书应该很老了，大概是在我读大学的时候（十年前）就听过了吧。但是，我看了书的出版日期“2017-05”！！！这是怎么回事儿？难道是++曼德拉效应++？我再三确认后我的记忆没出问题，确实有一本同名的书在2009年就出版了。
曼德拉效应（英文名：The Mandela Effect）是一个心理学效应，指大众对历史的集体记忆与史实不符。主流科学界没有科学研究证明这一“效应”的真实性。
这本书早在2009年4月份就出版了，不过尴尬的是这本书我没读过，就听过名字。这让我想起了那个爱学习的小师弟，就是从他那儿了解到这本书的。
而我读的是这一本，读的时候没注意出版年月，还以为是那一本小黑书呢。满心欢喜的想着终于将欠了多年的债还了，知道真相后还是有一点失落——就是那种以为完成了结果根本就没动的感觉。这种感觉也仅仅是出现了一瞬间，然后还是满怀感恩的心写了这篇读后感。
这本书整体来说很浅显，也可以说是接地气。跟前些年读的那本《走出软件作坊》有的一拼，都是在解决（或阐述）职业工作中的实际问题。这本书重点在于“人”——也就是程序员。
职场生涯
说实话，我在这个行业即便算不上老兵，也可以算是中年兵了，就是老油子一枚。这一张的内容给我的感触确实不是太深，我就挑几点还记得住的和作者有共鸣的阐述一下自己的想法吧。
沟通
“沟通”是发生在团队中的活动，这里面就有一个重点“团队”。现在的软件行业，几乎已经找不到单打独斗出来的产品了，几乎都是团队协作出来，这个时候就有一个1+1<2的问题了。我看到很多项目在报价和评估工时的时候，都是以“人天”为单位，但是这种评估真的准确吗？其实不见得，而且在我经历的团队中使用这种方式评估出来的研发计划往往到最后都无法准时完成。这里面就是因为忽略了一个“团队沟通”的成本，关于这个问题的详细分析可以看看《人月神话》这本书，这也是一本老书了，还是当年读大学的时候学院副院长推荐的，另外再多提一句，当年那个爱学习的小师弟在大二的时候就看完了这本书，我不知道他能理解多少，但在后面工作中肯定能给他很多启发，学习就是这样，书到用时方恨少。
我在工作中经常使用的沟通方式：邮件、内部即时通讯软件、会议、面对面（Face to face）。
邮箱这种沟通方式主要用于向领导（团队）定时汇报工作、跨团队协作以及各种评审等需要留痕的沟通活动。有些项目涉及到人员巨多，比如我司现在的拳头产品——第三代审判系统（T3C），开发周期三年，涉及人员1000+，这期间用了很多方式来保留沟通痕迹，其中一个重要的手段就是邮件。还有就是各种评审，研发计划评审、需求评审、详细设计评审、测试用例评审，会议纪要等等，都需要通过邮件的方式发送所有参与人员。在实际工作中，跨团队协作时有发生，比如说需求团队和研发团队，再比如A项目与B项目对接等。有时候会因为某一个点互相推诿——俗称“甩锅”，这个时候邮件的作用就体现出来了，谁提出的问题、谁评审的、谁执行的都一清二楚。还有一种情况就是跨地域协作也需要邮件来保障沟通的有效性。邮件沟通有个很突出的弊端——时效性差，往往反馈一个问题一来一回，一天算少的，有时候好几天都搞不定，这也是我不喜欢邮件的原因。
内部通讯软件是我用的最多的沟通方式，不管从保密性、实时性、有效性来说都很不错。公司由于开发法院审判系统，很多时候都存在SM问题，一个安全可靠的沟通软件是非常有必要的，咱们在实际工作中几乎是不被允许使用微信等互联网社交软件的，毕竟信息没有掌握在自己手中。使用即时通讯软件，能够很容易的将公司内部成员（拥有所有员工的联系方式）拉倒小群里面针对某个问题进行沟通，而且有聊天记录，也相当于有痕迹证明了这一点，有时候各种评审活动也是通过即时讯通软件来完成的。
会议一般都用于较大较正式的沟通活动，比如重构某个模块，一个较复杂的需求设计等。要完成一次高效的会议，议程是必不可少的，需要主持会议的人提前准备好，减少会议上无谓的讨论和发散。刚到公司的时候，会议特别多，占用大量的工作时间，以至于经常是白天开会，晚上加班写代码。这种情况到很多同事怨声载道，甚至离职。后来公司也针对这种情况进行了整改，提出高效会议的口号，通过即时通讯软件减少会议次数，通过建立议程等方式减少会议时长。
其实在工作中，我更加赞同面对面的沟通方式，一对一，高效快捷。这也是公司敏捷实践的一种方式。而且面对面的沟通也能加深彼此的了解，对后续工作展开有着很大的作用。
其实还有一种沟通：团建。这个东西可以说是沟通，也可以说是文化建设。其根本目的就是加深团队成员之间的羁绊，但是往往也会起到反作用，就是占用周末、下班等时间，这一部分时间，严格上说属于员工个人的，但是某些领导总喜欢在这些时间来进行团建，以各种手段强迫员工参与，这种团建往往只会适得其反。
早睡
早睡这个词语对于我来说有些奢侈，就像现在写这篇文章，已经是凌晨了，还有一大部分都没有完成。在国内软件行业里面加班是常态，比如当年马爸爸的“福报”，刘脸盲的“兄弟”。这无不是劣币驱逐良币的行为。这是国内软件行业野蛮生长的产物，需要广大劳动人民反抗和争取才能改善的，当然资本家往往更愿意猿们住在公司，但是不提供住处，也不给饲料那种。我从上高中开始几乎没有12点之前睡过觉，到现在已经快15年了，这种习惯让我脱发，秃顶。但是我又无力改善，即便不忙了，我也很难12点之前睡着。这里面有外部原因，也有个人原因，俗称报复性熬夜。
我也尝试过早睡，把手机电脑关掉，躺在床上念道德经，念着念着也能睡着，第二天醒来也确实会感到非常的精神。之前备孕那段时间就是这么干的，整个人的精神状态非常的好，但是后来有了小孩儿有开始放肆了。
在这里，我只想说：早睡好，早睡真好！
薪资
书中提到“工作量和薪资不匹配”的问题，针对这个观点，我想补充一下就是：工作量不单单指写代码多少，责任、技术管理、项目进度跟踪等都是工作量，很多程序员在成为高级工程师、资深工程师、架构师或者更高岗位后，他们实际的代码确实少了，但是另一方面，在处理突发情况、项目管理、研发管理、技术文化建设、项目基础架构设计等工作上并不少，而且这些事儿往往更加消耗精力，其实也是在付出，而且付出的更多。这么一想，在大多数情况下工作量和薪资是匹配的，不过有少量拥有核心技术（专利）的程序员身上，这个不是很适用，但是他们几乎是提前付出了，现在不过是在收获劳动果实罢了。
这一点我其实想要阐述的是：不要紧盯着薪资，作为程序员应该是以技术为核心，增加自身的核心竞争力，以提高自身的价值，在这个过程中，薪资也自然而然的涨上去了。另外还有一个因素，就是目前来说软件行业还处于红利期，也就是野蛮生长的时期，大量资本的流入产生泡沫。互联网行业就是泡沫的集聚地，也是软件行业薪资最高的方向。如果真想要赚点快钱，还是可以在这个方向混些日子，不过想要长久高收入，终究还是逃不出“核心竞争力”这里几个字眼。
招聘
我在工作的第三年开始以面试官的身份开始协助公司招聘程序员，其实主要是公司没人了，我就是矮个子中挑高个儿。刚开始的时候，说实话我也不知道怎么去面试别人，然后在网上找了一堆面试题，然后又根据公司这边招聘的要求写了提纲，每次面试别人的时候问几个面试题，然后按照提纲一项一项的去了解。这种方式在某种程序上来说还有些用处，就是让我自身形成了更加系统的知识体系，每次面试别人的时候，我心中的都会默默地回答一次，然后比对面试者的答案。
说说面试中简历的作用吧，我比较喜欢看个人简介和项目经历。个人简介写的好的，往往在后面工作中写技术文档都会写的很好，而且这类人往往是非常有条理的。当然写个人简介也是有套路的，毕竟我的第一份简历就是去网上找的模板套着写的，这对我排除那些套路简历也有很大的帮助。另外就是项目经历，我关心他们在这个项目中充当什么角色，主要成绩有是什么，在项目又收获了些什么。这也是我写简历的方法，有个5w1h分析法的东西，可让我们把简历写的明明白白，之前某个网站上投了个简历，对方HR就建议我使用这个方法编写简历。
写文档
书中提到“文档要在它能产生价值的时候编写”，这个观点我比较认同。我现在所处团队中，每一个需求开发前都需要编写完整的设计思路，然后进行评审。很多时候，一个需求真实的编码时间可能也就是半天左右，但是编写文档的时间几乎都是2~3天才能完成，这里面涉及到画流程图、理清系统中原有逻辑、评审、整改等一系列活动。我不反对这些流程，用书中一句话说“程序员都应该尊敬流程”，但是我们不能僵化执行，需要灵活变通，比如整个工期评估超过3人天的需求编写设计文档的方式，来灵活应对文档。
另外，程序员必须要具备编写文档的能力，这是一种阐述设计思想的方式。也是走向技术更高层的必经之路，走管理路线的话，更加需要写文档的能力了。
大公司与小公司
关于大公司和小公司的问题，从我还没开始工作就在思考这个问题：
-
优点
大公司：规范制度完善，发展平台大，大牛多。
小公司：工作方式灵活、技术新、更多的实践机会、接触的技术面大。 -
缺点
大公司：僵化执行、历史包袱、技术往往老旧、绝大多数都是螺丝钉
小公司：工作范围不明确、没什么大佬可以交流学习、没什么晋升空间
我觉得在不同的工作时期，需要去不同规模的公司体验学习。刚毕业的时候可以去大公司学习一下完善的工作流程，跟行业大佬沟通学习，快速的进行学生到职业人的转变，接着就可以去小公司将这些年所学的东西进行实践，如果天时地利与人和，还能创业成功，成为一方大佬。小公司历练结束，就可以再找大公司大平台，不断提升软实力、晋升职位，参与（领导）大项目等增加行业影响力，成就一方大佬。不管怎么，咱们最终目标就是赚大钱，当大佬。您说是吧？
大城市与小城市
这个问题其实跟很多方面有关系，对我来说家庭成为了我抉择大城市和小城市的决定性因素。作为程序员，肯定是越大的城市越好，因为城市越大，以为着机会越多。就我们行业还说，国内比较牛的公司基本上都集中在北上广深，杭州因为有个阿里巴巴，也算是大牛集中地了。就我所在的成都市，几乎都是小公司，或者那些大公司的研发部门，因为成都的人力成本相对那几个城市来说低了很多，而且成都这边也有几所高效可以输送人才。像其他二三线城市，几乎很难找到专业对口的工作，就像我老家南充，我曾经了解过程序员的工作岗位，搜遍真个几个大型招聘网站，几乎就是那一两家企业招人，而且大多数都是销售、运维人员。而且薪资待遇距离成都市都还有一大截距离，跟不说北上广深了。但是，大城市和小城市的决定不是这么简单的，咱们还需要考虑生活成本、生活质量、家庭成员的意见等因素。起决定性作用的是你看重什么，然后这个城市有什么，就是一个匹配度问题。
思维认知
我记得大一的时候一个老师在课堂上提到过“编程思维”这个词，他说咱们学软件学的是一种思想，而不应该拘泥于某一种语言，某一个算法。最初的时候不能理解“编程思维”是什么，后来学了“面向对象”后懂了一点点“思想”，后来将这种思想运用到工作生活中，通过阅读、观察、讨论，明白了更多“思想”中的哲学。
最初我觉得“编程思维”就是绝对的理性，以计算机的方式思考问题，就是分治法、归纳法等。那个时候更是高喊“电脑是老婆，计算机是儿子”的口号，要将自己变成彻彻底底的“莫得感情的程序员”。
后来工作生活中的教训，让我明白程序员是人，写的程序是给人用的，编程不仅仅是do...while，还是一门艺术，每个程序员写的代码都有其特点，每个程序员面对相同问题时都有其独特的想法。写代码更像是在写诗，怎么能缺少感情呢？即便是真的把代码当儿子养，不也得付出感情么？
突破程序员思维
几乎所有程序员的思维都是偏理性的，说的不好听点就是认死理、犟拐拐。在写代码的时候这种思维没问题，但是团队和生活中沟通的时候就很容易引起不必要的争执，以至于外界对程序员这个群体有误解，我父亲就是这样的，认为我平时做事方式很怪，听不进去建议。
这么些年过来，我也认识到了这种思维的局限性，于是开始阅读一些杂书，比如道德经，诗经等国学经典，还有一些文学名著。通过这些阅读，我也渐渐地像一个“人”了，反过来在工作中，将更多“人”的思考放入程序设计中，起到了一个相互促进的作用。
平时我听音乐，看动漫等，我还是网易云音乐的黑胶会员呢！我听音乐喜欢看评论区的那些人才们的留言，什么跪着踩油门啥的，真的是脑洞大开啊，后来写代码的时候也会写一些比较俏皮的注释。有时候看到那些前人留下的那些注释也有一种笑翻的感觉，这或许求是突破了程序员思维的大佬们的快乐吧。
编程的意义
编程最开始是我的谋生手段，毕竟除了这个什么也不会。后来渐渐地编程了我快乐的源泉，我喜欢新技术，喜欢自己DIY一些小东西自娱自乐。而且每当解决一个问题都会有很大的成就感，这算是最没有门槛的获取快乐的方式了吧。
再后来，发现编程就是一门哲学，一门艺术，我想要将代码写的更加有美感，看起来赏心悦目。有大佬曾说过，代码刚开始是写给电脑看的，后来就是写给人看的了。观察计算机语言的发展就可以验证这个观点，最开始的打点计算机，然后是汇编，再然后是C语言，后来大量的高级语言出现。开始讲究代码的美观、易读性等，开始研究复用、接口，各种设计模式等，无不是为了让代码更加富有艺术感。编程更是一种内心的表达，对某个问题深思熟虑后的一种实现，通过不断的编程，能够能加清晰的认识这个世界，从这个方面来看，编程更像是一门哲学。
个人发展
任何行业最后都要谈到“个人发展”问题，毕竟人来到这个世界终究需要做些什么才行。那么程序员的“个人发展”是如何实现的呢？
所有“个人发展”问题到最后都是“生存”问题。国内有个很独特的现象：35岁的恐慌，其实形成这个想象的原因比较简单，就是公务员的年龄限制就是35岁，往往到了这个年龄，就必须有所抉择，也是最后进入体制内的机会了，过了就就只有一条路走到黑，而且很多企业都会裁掉高龄员工，因为这一部分人带着一些“暮气”，体力和精力都比不过那些小年轻。那么，咱们程序员们该怎么去面对这个“高龄”问题呢？
行业专家
在我看来“行业专家”的重点在“专”字上面，什么样的人能称为“专家”？就是一技之长，而且是特别的长。这需要花大量的精力在某一个点上进行突破，比如阅读JDK源码几十上百遍，对JDK的设计和思想十分的精通，这种人可以叫做专家。再比如我现在所在的法律行业，精通法院业务，各种诉讼法信手拈来，然后能将这些知识运用的系统设计和开发中，这也是专家。归根结底就是“一技之长”，比其他人都要厉害，有你必胜的这种人，就是专家。
这条路子走起来是非常孤独的，也是最厉害的，有点修真里面的“以力证道”的味道，是一种“逆天”之举。
个人品牌
个人品牌严格上讲不是一条路子，而是一种手段，不管是做行业专家，还是还是全栈工程师，都需要建立个人品牌。说白了就是要营销自己，让其他人知道自己。个人品牌建设是一个长期的过程，随着越来越多的人认可，事业和收入也会睡着增长。建立个人品牌的手段最简单的就是：个人博客。
博客是向其他人展示自己的最佳手段，也是其他人能全面了解你的窗口。那么我们如何创建个人博客？自行搭建还是使用社交平台？
自行租赁服务器搭建博客很简单，社区里面有很多开源程序，比如WordPress，其优点就是自由度比较大，。但是自行搭建博客有个很大的缺点，就是阅读量的问题。除非你知道怎么运营和推广你的博客，否则几乎没什么人知道你的博客。而且国内搭建个人博客还需要去备案，不同省份对于个人博客的要求不一样，这个限制还是挺大的，如果真要搭建个人博客，还是建议搭在香港服务器或者国外的服务器上。
使用社交平台的好处就是不需要关心系统搭建，让你将注意力集中到想要表达的内容上，创作出更加优秀的文章。而且平台也会专门的进行搜索引擎优化，平台内的置顶等提高文章阅读量，更快速的让其他人认识你。
我觉得如果技术比较好的，有精力可以自己开发一个博客，对接一些社交平台，在个人博客上编写内容，然后分发到各大社交平台上，然后引流到个人博客。这也是一种手段，而且能学到更到运营知识，开拓职业之路。
全栈工程师
全栈工程师就是什么都会干，不过呢，人的精力有限，如果什么都会干，那么就会造成一个结果，什么都不精。针对这个问题，咱们就需要使用秘密武器了——搜索引擎。所以全栈工程师还有一个名字：面向搜索引擎编程工程师。
在中小型企业里面，为了节约成本，往往全栈工程师会很吃香。毕竟什么都会干嘛，接到任务能根据自己具备的技能给出一整套解决方案。而且在接私活的时候也能一个人拿下整个项目。这位后面做自由职业者做好了铺垫。
针对成为全栈工程师我还是建议走T字型发展道路，一专多能。这样技能非常好的胜任某一项工作，也能顺带解决其他问题，在公司任职的时候，也有拿得出手的东西，否则当螺丝钉的时候就会被当成初中级对待，因为初中级工作方式大多数也是依赖搜索引擎ctrl+c+ctrl+v工作的，俗称胶水编程。
自有职业者
身边有几个自由自业者，其实就是个体户。自己找活儿干，然后时间自由。但是呢？
我高中同学做环境评估的，从第一家公司离职后，然后开始成为一名自由自业者。钱没少赚，时间也自由，刚开始还是蛮开心的。后来一次跟他聊天，他说时间看似自由，但是几乎每时每刻都在工作，没有周末，没有下班。工作时长和压力比在公司上班更大。后来他还是回到了公司去上班，这也算是他人生中的一次尝试吧。
在咱们软件行业里面，自由职业者还是非常多的，国外的更多，国内稍微少点，土壤不是很肥沃。自由职业者不一定就是靠去拉活自己干，还有一种方式就是做开源，找人赞助，或者自己做产品去买，或者做技术咨询。反正很多途径。但是自由职业一定有个前提，评估一下自己的自制力，在相对宽松的环境里面，人往往会忘乎所以，失去规范的约束，往往会走向歧途。
编程教学
咱们程序员没有天生就会的，都是通过学习获得知识和技能。这就离不开“教学”了。书中主要讲了三个方面：教他人如何学习编程，说自己该如何提升技能，最后讲了如何进行小朋友的思维训练。
自学编程
自学编程其实说的就是某些人因为各种原因想要学习编程，比如希望从事软件开发，希望自己动手做点东西等原因。那么在学习之前一定要想清楚为什么学习，针对不同的目的，其实学习方案是不一样的。
比如，想要从事软件开发，那么非科班的童鞋可以先学习一门最热门的语言，然后学习一些算法，计算机理论等。学习热门语言有个好处就是学习资料很容易找到。然后再报个培训班，系统的学习一下编程这个技术体系，跟着做几个真实的项目，也就能开始工作了。然后在工作中不断的加深学习，向大佬学习，最后其实很难分出是否科班生的。
如果是想自己做点东西，其实可能更需要全栈一点，可以学习js。这门语言恐怕是目前最全栈的语言了，后端服务器有nodejs, web端有vue等响应式框架，桌面端也可以使用Electron来开发。app端也有一大堆框架可以用。然后如果知识想做点数据分析，写个小爬虫啥的，python在合适不过了。
往往自学编程都是从学语言开始的，然后学习语言的思想，在使用中领悟语言的局限性和其优势等。计算机语言本身就是一个程序，就是一个编译器，将人类认识的语言翻译成机器认识的语言。仅此而已罢了。所以如果有耐性啃源码，也是进步的一种方法，而且还很扎实。比如java这种语言，其源码写的非常精辟，都是一群真正的大佬的杰作，看jdk源码会有一种跟大佬们交流的感觉，是一种非常棒的体验。
还有一点是很多学习编程的同学比较关心的问题：英语差能不能学习编程？
这个问题的答案是肯定的，可以！凡是都有个但是啊，如果英语确实太差，而且还排斥英语的话，却是很难将编程学好。不管承不承认，编程技术还是西方国家牛皮，几乎行业内影响和使用广的技术都来自西方国家，近两年国内也出现了一些有力量的技术，这是个好苗头，未来学习新技术的门槛就贬低了，也意味着咱们国家在计算机这一块不断的崛起。
编程书
说实话，我除了买了基本基础的技术书，如《core java》,《java编程思想》,《Effective Java》以外都是买的讲底层逻辑思想的书。而且这几本书也算是java语言里面最精髓的几本书了。我现在学习技术更多的是通过阅读官方文档，然后想一个应用场景，将该技术应用进去，结合文档学习和使用。
如果将学习编程比作练武功的话，这些语言、技术可以看成是外功招式，算法、编译原理、设计模式等就是内功心法了。需要内外兼修，那些外功招式在互联网上一搜一大堆，但是内功心法大多是独家秘方，还是得花钱买的。而且很多炒的很火的技术其本质就是很多年前提的一种思想或几种思想组合而成的，这些技术万变不离其中，终究是以图灵机模型建立的体系。如果有一天计算机模型彻底变了，恐怕咱们现在的编程就会变成玩魔方一样的东西，就剩下思维锻炼的作用了。
少儿编程
少儿编程这个事儿我也想了很久了，现在也是孩子的爸爸了，我也在思考什么时候开始教孩子编程，怎么教。这本书给我提供了一些思路，其中有一句话我记得很清楚：教手艺不教知识。我自己也知道学习计算机的理论知识是很枯燥的，当年大学的时候学习计算机原理和计算机网络几乎都在打瞌睡，还是这些年工作的时候感觉到这块的缺陷才补起来的。我刚开始学习编程的时候，我就只想着写代码，那些什么理论知识都去见鬼吧，太无聊了。所以当年的C语言还是高分通过的，哈哈现在想起来都觉得很牛逼。
那么怎么教手艺呢？爱玩是小孩子的天性，而编程恰好就是可玩性很好的一门手艺。我们可以通过编程来指挥机械运动，比如小车前进后退什么的，咱们可以自己写个程序让小车车送信什么的都可以。而且现在很多少儿编程的软件将游戏和编程结合起来，寓教于乐的让孩子学习编程，比如：playground。少儿编程刚开始的时候不宜直接教授一门语言，那实在是太无聊了，而且孩子还不一定能接受，还会适得其反。
最后在说说少儿编程的好处吧，编程是一项精力非常集中的、逻辑严密的活动。很多小孩儿学习不好的一个原因就是精力不集中，通过编程学习，让孩子学会思考，控制自己的思维，不管学习成绩是否好，但至少能有一个良好的学习习惯。其二严谨的逻辑思维让小孩子更加理智的面对突发情况，通过分析找出解决问题的方法，这是一种终身受用的思想。
设计与美
这本书的这一部分其实讲的很简单，但是也是贯穿真本书一直在阐述的事儿。UI设计是作者走出程序员思维的一种方式，咱么不一定非要学习设计才能走出程序员思维。比如摄影、厨艺、阅读经史都行。
但是我还是想从个人对设计的感受阐述一下，其实有一点我跟作者很像，就是觉得自己做的很丑，而且又缺乏设计师来设计，即便找到设计师，也很难将自己的想法表达给他。所以自学设计是最优解，自己知道要什么，跟着自己的思想去设计，就是最完美的作品。
设计师的位置
从工作到现在，我所经历的公司设计师都很少，专业的设计师更少。他们往往待在某个不起眼的角落，而且属于公共资源，每个团队每个项目他们都要参加。嗯，很累，而且很不受重视，甚至他们都没有自己的专属部门，就挂在前端组。还有他们要兼职公司的海报设计，活动照片修图等等。这是现实中的设计师。我还知道一种设计设，室内装修设计师，我认识的设计师们更像是商人，大部分的室内装修设计师对于计算价格的能力远远高于设计水平。我最开始对他们抱有很大的期待，我装修的时候就问了好几个设计师，但是最终还是选择了自己做，我发现我老婆的审美还是可以，至少比我好。总结一句话，真正的设计师很少，设计大师更少啊。
我想咱们还是需要重视设计师们，往往一个产品能否成功，设计师占很大一部分原因。我们想象中设计师可能就是做做图标，画几张图片，但是在我看来设计师更多是考虑交互问题，交互不进行是动作，颜色、声音、字体等都是交互，未来的计算机，触觉应该也要算在内。这就是设计，说实话编程很重要，但又不那么重要，编程决定的是能够尽可能快的干正确的事，但是设计师却是让用户能够快乐优雅的干正确的事。就我自己而言，如果一款软件设计的漂亮，即便慢一点我也是愿意使用的，爱美之心人皆有之啊。
在我们的教育中，就应该加入美学的教育。我计划中我女儿至少要学习三样：编程、美术、舞蹈，如果她有精力的话，还可以学一门乐器。但是还是不能勉强她，不然这些东西没学到，反而厌恶它们了。学习编程是让她拥有良好的逻辑思维，学习美术是让她拥有创造力，学习舞蹈是让她拥有一副健康的身体，乐器就是让他可以闲暇之余消磨时光的。哈哈，想象的很好哈，等她再大些让他尝试一下再说。
B端项目中的设计
我最初是在互联网公司工作的，做的产品几乎都是toC的，那时候咱们还是很讲究设计和交互的。但是现在我所在的公司，做的是B端产品, B端产品有个特点就是业务流程复杂，定制化更高，这种特性让需求功能变得更加复杂，业务线众多，能够在交互上下功夫的地方就少的可怜。而且一般来说需求工期都非常的紧张，能做出就已经用了吃奶的劲儿了，想要做好更难。还有一点就是B端产品一般研发周期都很长，就我司第二代产品已经有十几年了，这期间首批开发几乎都离职了，留下来的也已经是老总级别了，一代一代的人传下来传的面目全非，没有谁能理清楚里面的逻辑，这导致新进需求与原设计不匹配，操作不一致。这也是B端产品缺乏设计的一个原因。
本以为推翻重新开发一套会好很多，然后让我失望了。由于咱们公司的核心产品体量非常的大，公司在重新做了一套的时候采用了微服务架构，最开始还能专门的团队维护专门的服务，这个时候整体设计还是优良。前段设计也有总体规划组策划了规范。后来随着开发进度的展开，人员流失和补充，原来的团队打乱重组，不能专人专职的做某个服务，又开始了打游击，打补丁，哪里不会点哪里。现在这个产品才三年左右，已经没有人能说清楚咋回事儿了。
B端产品的开发一定要有一个人从头到尾的参与，这个人就是系统整体设计师，由于每个人的设计理念都不一样，换一个人基本上就是换一种思维，对于体量较大的产品，根本就掉不了头。如同改革开发是国企制度改革一般，船大了很难掉头的。要让一个设计师从头到尾的参与项目，那就得给他应有的位置，应用的重视和自主权，不然随便来个领导就可以指挥两句，那还干个啥？
结语
这篇读后感拢共写了3个晚上，思路断断续续的。从刚读完的时候感悟颇多，到后来感觉平平，也就那样。这是正常现象，就跟吃饭一样，刚吃完的时候好饱啊，过一会儿消化一些了，就觉得也就那样吧，再过会儿消化完了，又觉得好像再来一次啊。等我需要用的这书中内容的时候，就是我在想来一次的时候了。
这本书整体来说还是有深度，同时也很接地气。我和作者都是JAVA程序员，我也算是半个全栈工程师，除了不会设计，其他的都能干，比作者弱了一丢丢。所以我觉得很能跟作者达成某种共鸣。这本书的历程就像我这些年的经历一般，刚开始的时候想着职业发展，怎么写简历，怎么面试，怎么和同事相处等等，接下来想着如何发展自己，让自己变得值钱，再后来就开始读杂书，学习其他领域的思想，再后来结婚生子，考虑孩子教育问题。真的好像啊，除了我没有作者牛逼，感觉其他的我和他是一样的。这也是我为什么话这么多时间写这边文章的原因，我也算是回顾了一下这些年的经历吧。
Related Posts
