程序员的自我修养- 谈实践与认知

第二章 谈实践与认知

一、突破程序员思维

1．什么是程序员思维
  长期不间断地编程实践。
  持续地学习与借鉴（参考）。
  学会反思，并像专家一样思考
2．为什么要突破程序员思维
  既然程序员思维对程序员来说如此重要，那么我们又为什么要突破、它呢？在我看来，主要有以下一些原因
    不仅需要具备很强的编程能力，同时还需要具备从设计、运营、测试等各种不同角度去进行分析和判断的能力
    需要你突破程序员思维，从更人性化的角度去识别和解决问题
    突破程序员思维对你的生活也会有所帮助。有很多过于技术的程序员，随着编程时间的增加，他们会越来越不善与人沟通，甚至排斥与人交流。他们也往往无法扮演好自己在生活中的角色
    
3．如何突破程序员思维
  （1）透过技术发现问题的本质
    解决问题的关键，往往不是如何通过技术手段禁止用户这样做，而是理解用户这样操作的原因，从而从根本上找出解决的办法
    
    真正优秀的程序员一定善于透过技术发现问题的本质
    
  （2）像专家一样给出意见
    真正优秀的程序员在与用户进行沟通时，总是试图去理解用户所提出需求背后的真正原因，因为他们知道用户往往会按照自己对问题的理解去给出他们认为正确的方案,而很多情况下，他们所给出的并不是正确或是最优的。那些优秀的程序员会站在用户的角度，认清问题，并像专家一样给出他们认为最优的方案
    
    如果你对一个问题有充分的理解，并具有足够的信心，那么你就应该站出来像专家一样给出自己的意见，这会让你显得与众不同。如果你每次提出的意见都被证明是正确的，那么不需要多久，你也会被大家认同为是一位真正的专家了
    
  （3）杂学并从中获得不同的视角
      看清问题的本质并像专家一样给出意见，其实并不简单，这不仅需要你具备极强的技术功底，更需要你对问题所涉及的相关领域有足够的认识
      
      程序员无法跳出程序员思维，站在用户、设计师、产品经理的角度看待问题，也是一个重要的原因
      
      你也可以学习某个行业的知识，即使你无法成为这个领域的业务专家，但这些知识能够帮助你更好地理解用户的需求，从而得到更优秀的技术解决方案
      
  （4）找回创造力
      创造性地解决问题是优秀程序员所需要具备的能力
      突破程序员思维并不是要摒弃它，恰恰相反，突破正是建立在成熟的程序员思维之上的，这将帮助程序员以更全面的视角去思考和解决问题，同时也能为程序员这个职业创造出更多可能

二、全栈工程师如何快速构建一个Web应用

1．网站定位与功能设定

2．信息架构
  不同的团队或项目中会有很多不同的名字 ，比如，概要设计、业务建模
  
  先定义出合适的业务领域和实体模型
  再定义出服务，并为它们增加相应的方法
3．UI设计
4．应用架构
  没有最好的架构，只有最合适的架构。
5．开发
  在整个开发过程中，需要去解决一些问题

6．部署
  （1）选择云服务
  （2）应用部署
  （3）安全
7．性能调优  
8．网站数据统计  
9．开发与设计工具

三、如何成为一名优秀的全栈工程师

1．什么是全栈工程师
  百度百科对全栈工程师的定义是这样的："掌握多种技能，并能利用多种技能独立完成产品的人"。
  全栈工程师应该同时是一位资深开发工程师、架构师，以及具有敏捷开发技能的程序员
  全栈工程师往往是某一方面的专家，同时通晓并善于在正确的场合运用其他语言、工具和技术
2．全栈工程师的价值
  个人价值及自由度的极大提升
  全局思维与技术前瞻性
  降低沟通成本
  初创公司
3．全栈工程师的技能栈
  要掌握所有技术是根本不可能的，而成为全栈工程师也并不需要你真得掌握所有的技术，你应该将自己的精力聚焦在关键开发技能，以及一些必须掌握的附加技能上
  
  （1）关键开发技能（硬实力）
    Git/GitHub
    至少一门编程语言
    运用开发框架和第三方库
    前端技术 之所以将前端技术独立出来，作为一项关键技术，是因为它在今天的项目和产品的研发过程中正变得越来越重要。一个产品除了实现所需的功能之外，是否好用（用户体验）也正在成为评判一个产品是否成功的重要标准
    数据库与缓存
    基本设计能力
  （2）附加技能（软实力）
    沟通
    问题解决能力
    时间管理
    好奇心 
      对任何工作都抱有好奇心，并愿意不断学习和改善是那些优秀工程师的共同特性
    领导力 
      成为管理者并不是让你去支配其他人，或让其他人替你做事。
  
4．优秀的全栈工程师需要走出去  
  优秀的全栈工程师不应局限于自己的工作，他更应该走出去，接触不同的技术，分享自己的经验和心得，认识更多的朋友
  参加技术大会
    不仅能够听到技术大咖们带来的各自领域最佳技术实践，而且能认识很多行业内的朋友
  做公开演讲
    一定需要在团队内部做技术、管理等方面的演讲
  个人博客  
  参加线下活动  

四、为什么每个程序员都应该学习使用命令行

  早上来到公司→打开电脑（启动Windows）→打开Eclipse（我是一名Java程序员） →打开浏览器 → 打开记事本 → 打开navicat → 写一天代码→下班前通过Eclispe的插件把修改过的代码提交到git代码仓库中→下班回家

  用户通过命令行直接进行操作
1．有效控制你的操作系统  
2．用Git来做版本控制
3．前端开发依赖于命令行工具
4．既然学习命令行对于程序员来说那么重要，我们又应该如何学习呢？
  最常用的基本命令开始,然后就可以更进一步，去写一些自动化脚本来帮助你完成一些工作

五、重构——系统改善之道

1．从构建工具开始
  自动化程度低下
  缺少有效的包依赖与版本管控
  缺少自动化测试覆盖
  不利于团队构建
  系统重构的第一步便是引入构建工具或重写构建脚本
  引入构建工具
  第三方包依赖与版本管理
  实现自动化  
  写入开发手册
2．让自动化测试成为重构的保障    
  我们重构的目的往往是去解决系统的某些痛点，这些痛点也往往是系统的核心功能，因此，在你改动代码之前，需要详细分析修改可能造成的关联影响  
  
  详细Review该功能的需求。
  针对需求，完善自动化单元测试案例。
  将这部分单元测试的执行引入到每次自动化构建中
  
3．代码级的持续重构  
  代码会随着时间的推移变得越来越糟
    重复的代码（它们可能存在于同一个类或不同类中）。
    不一致或没有标识性的对象、变量或方法命名。
    过长的代码段。
    让人费解的布尔表达式。
    过于复杂的逻辑判断。
    对象错误地暴露其内部状态。
    遭废弃但没有删除的类或方法
    
4．基于微服务的重构  

六、程序员也该懂得“这样就好”

是不是这样做就好了呢？如果没有必要，我们就不需要增加这个附加功能了  
优秀的系统绝不可能凭空产生，也没有一个统一的标准，而“这样就好”却能指导我们这些系统设计者，在众多选择中做出平衡与取舍

不盲目使用新技术  
避免过度设计  
  过度设计源于系统设计者没有理解用户的真正需求，而将自认为有必要的功能附加于系统之上。前面提到的可配置、个性化等就是那些最典型的例子。要避免过度设计其实也很简单，要做到多看（看那些优秀的系统是如何设计类似功能的），多想（站在用户的角度去想他们所提需求背后真正的痛点和问题是什么），多做（不要只停留在需求文档上，应做出能够验证需求的功能原型然后不断确认和改进），多说（在每一个阶段都与用户保持有效的沟通）
  
不在项目中技术镀金
  技术镀金指的是开发人员在项目开发中过于追求技术的完美性，试图在技术上镀一层完美的金壳，导致软件开发工作量加大，项目时间拉长，最终有可能导致整个项目的失败

七、走出软件开发法则

1．面向对象
  今天的开发与以往相比已经大大简化了，那些底层需要复杂抽象的设计都有了可以直接拿来使用的框架，程序员要做的更多是基于这些框架去写业务实现逻辑。虽然开发变得更简单了，但这却在一定程度上减弱了我们的编程能力
  
2．测试非常重要
  TDD（测试驱动开发）
  会通过测试覆盖率等指标
  
  测试不是为了证明那些必然正确的东西
  测试无法提高代码的质量也不会让代码更易于维护
  测试的方法很多
  集成测试越早越好
  
3．那些层出不穷的方法论  
  在开发流程与团队协作领域，我们又经历了从瀑布式和工程化的开发方法到敏捷、XP、Scrum开发，以及今天我们经常挂在嘴边的DevOps
  这些所谓方法论都出现在不同的时代大背景之下，又与当时的技术环境紧密相关
  程序开发的美妙之处也正在于它充满着令人兴奋的变化和各种抽象思维。不要被任何思想、教条、方法论束缚住你的思维，只有这样，你才能真正体会到程序开发所带来的乐趣

八、我无法写出易读的代码

1．代码本来就是难以阅读的
  这是程序员的问题吗？不，至少我认为不是这样的。因为代码并不是自然语言，它本来就是难以阅读的，况且代码是否易读不仅与代码本身有关，还与阅读代码的人对系统的理解程度，以及他们自身的技术水平有关。更何况，我们写代码的目的本身也不是为了让它更容易阅读

2．如何让你的代码更易阅读
  （1）推行模式（Patterns）而非建立规范
    虽然表面看来，每个人都在遵守着那些代码规范，但其实他们的思维却没有得到很好的统一。想象一下，在一个阅兵式上，一队身着统一制服的士兵，他们每个人的动作都非常标准，但他们都在按照自己的节奏和步点做动作
      使用什么结构来表示数据本身。
      采用哪种机制来进行数据加工。
      如何进行统一的错误处理。
      会话的管理及使用策略。
      哪些地方需要记录日志。
      包与方法的命名Name Convention。
  （2）深入理解并尊重你所使用的应用框架  
    构建应用框架的目的并不是为了给开发者提供一个比Spring更强大的框架，恰恰相反，它们在大多数时候，是为了限制框架的使用，而使整个系统变得更加标准且易于维护
    
    在开发时尽可能使用应用框架所提供的标准方法
    
    通过阅读源码，以及大量的实践去深入地理解它们，并训练出最有效使用它们的感觉
    
  （3）不要使用过多的所谓技巧
  
  （4）Design Review与Code Reivew都很重要
  
    Design Review能够帮助我们在较早的阶段就发现那些潜在的设计问题，并加以纠正，这往往能发挥事半功倍的效果
    建议采用最简单的设计文档模板 并让开发人员写下真正体现他们所做程序设计的内容
  
  （5）让你的架构师忙起来
    架构师应该承担起应用架构、代码规范制定、系统接口定义、技术风险识别、指导团队开发等很多工作
  （6）小比大好
    大类小方法

九、一名全栈工程师的Mac工具箱（设计、开发、效率

简明和现代
有一定知名度和影响力，并且有良好的社区支持
足够轻便
买得起，或者你能找到合适的工具
1．设计类工具
  （1）Sketch 3（http://www.sketchapp.com/）
  （2）Affinity Designer（https://affinity.serif.com/zh-cn/designer/）
  （3）Framer（http://framerjs.com/）
  （4）PaintCode（http://www.paintcodeapp.com/）
  （5）Hype 3 Professional（http://tumult.com/hype/pro/）
  （6）Pixave 2（http://www.littlehj.com/）
  （7）Iconjar（http://geticonjar.com/）
  （8）Sip for Mac and iPhone（http://theolabrothers.com/）
2．开发类工具
3．效率类工具

十、我似乎理解了编程的意义

1．编程是一项技能
2．编程是去解决问题
3．编程是在表达，也是在创作
4．编程是为了留下痕迹