软工+C(3): 超链接

// 上一篇：分数和checklist
// 下一篇：Alpha/Beta换人

---

注：平常看文章，总有能和构建之法，软件工程相关的链接，增量记录，也可以通过在其他人博客的交流中使用相关的超链接，在使用中review这些超链接背后文章的知识、方法或者观点。链接内容有好有坏，有完备的也有简单的，链接的内容可以深入去阅读，也可以做为一个交叉引用的关键字，引开关注主题的讨论和思考。对链接做归类也是一个必要的方式。每个人都可以建立自己的链接库，所以，也许不在乎是否要全部把链接都点过去看，而在乎的是自己去建立、索引、交叉联想的过程，建构式做知识和方法积累。此外，通过在开放式的博客里持续修订和记录，可以看到修订和迭代的过程。

构建之法：

• 参考书链接
  书本里虽然列出了这么多参考链接，但是读者是很难一下子全部去看，大部分情况下是一个都没点击过去看。如何有效利用这些参考链接？助教们在点评过程中可以随时按需使用这些链接，通过增量的点评附带相关链接的方式让学生们真正在需求中阅读和理解链接相关内容。
• http://www.cnblogs.com/lwr-/p/5199030.html?winzoom=1
  • 这个学生利用寒假通读并写了大量笔记。关于知识和方法，我们在大脑里思考的越丰富，写下越多的记录，在实践中印证和理解概念就越清晰和有章法。
• https://zhuanlan.zhihu.com/p/19970642?winzoom=1
  • 驱动
  • 责任
    • 猪、鸡、鹦鹉
    • 南郭先生
  • 交流
    • 外部交流成本
    • 内部交流成本
  • 远虑和近忧
    • 【一群牛人在 “没有近忧，只有远虑” 的条件下讨论问题，最后只能议而不决。 在一次次延续到深夜的讨论中，有人感慨 – "How is this night different from all other nights?" 】
  • 项目收敛的条件是什么
    • 怎样做

隐喻，定律：

• make it work, right, fast
  • work了未必right
    • right了需要fast
      • 也只有right的才能fast
  • 做到这三点并不容易，当一个可以work的软件一直出未知的错误，我们就要去深入剖析下哪些没做对的事情。
  • right,事实上需要应用我们的逻辑能力：证明与反驳。
    • mcs-page-19:【The analogy between good proofs and good programs extends beyond structure. The same rigorous thinking needed for proofs is essential in the design of critical computer systems.】
• Basics of the Unix Philosophy
  • 影响深远的Unix哲学
    • 管道思想，所有链式设计的原型
    • 一个程序只做一件事，并且把这件事做好、做对、做快
    • 使用和创造工具解决问题
    • 通过做Profile探测瓶颈
    • 围绕数据结构编程而不是算法
    • 关于模块、分类、组合、分离...
• Backfire effect
  • 所谓“固执己见”。怎样才能避免这样的效应？
    • 需要深刻理解：行为和表现、习惯和动机、本质和固有属性 之间的界限。
      • WHY FACTS DON’T CHANGE OUR MINDS
• regression toward to mean
  • http://www.socialresearchmethods.net/kb/regrmean.php
  • http://rationalwiki.org/wiki/Regression_to_the_mean
    • 当一个公司找的人越来越多的时候， 它不可能总找到优秀人才， 总是要回归到平均值。
• 破窗效应(Broken windows theory)
  • 为什么要有编码规范？看你在一堆糟糕的代码里添加代码，你是否也会添加的更随意？
  • 为什么要合适的命名？当你看到一堆随意的命名时，你是否也会增加另一个随意的命名？
  • 为什么要选择优秀的人，淘汰混日子的人？当你看到一堆人在混日子，你是否也会觉得自己混日子是自然的。
  • 为什么要创新？当大家都在使用落后的技术的时候，你是否也会觉的好像新技术也没什么用？

书籍：

• 更多软件工程书籍
  • 这么多，我可以只取一本来看么？

个人：

• 软件开发只需要写代码就可以么？
  • 但是不擅长其他各方面的所谓书呆子，可以从写代码这个相对聚焦的地方开始入手，书呆子们的智力，可以从写代码开始发挥，慢慢再展开到其他方面。
  • 然后通过结构化的方式把代码之外工程上的其他环节训练到位。怎样算结构化，例如手绘流程图虽然不错，但是使用思维导图工具可以增加对结构的约束和规范。
• 有哪些老鸟程序员知道而新手不知道的小技巧？
  • 所谓小技巧是在破除了种种迷思之后，逻辑上正确的解法，或者最佳实践。
• 深度程序员-机器取代程序员？
  • 编译器和连接器事实上让我们不必再写汇编语言，所以我认为即使有更高级的机器编写程序的事情出现，也不会替代程序员这个行业，到时候程序员只是做越来越高阶的程序工作而已，只是由于抽象泄漏法则，写低阶代码的程序员也会一直存在。
• 编程的智慧
  • DRY（Do Not Repeat YourSelf）容易引起误解的地方之一就在于好像重复一定是坏事，这篇文章里展现了许多必要的重复。
    • “写无懈可击的代码”，这是重要的地方，我记得早期在学校里一个大一的学生在还没学会循环结构，仅仅使用if else就把复杂的逻辑写的清清楚楚的作业，我的计算机启蒙老师说这个学生的思维很严密。
• 开发者大多靠自学，还需要大学学位吗？
  • 自学可以算野蛮生长（放羊学习），需要避免陷入原生态思维
    • 学生的头脑是容器还是火把？
• Three Attitudes that Lead to Maintainable Code
  • Change Your Perspective, => 结对编程的一种效果，【At Atomic Object, we often do pair programming, which is a great way to immediately get answers to these questions from someone who is not you.】
  • Neatness Matters，=> 编码规范，自说明
  • Avoid Special Cases，=> 从根上解决问题

结对：

• 联合创始人之间的冲突
  • 联合创始人之间的沟通合作，也符合结对编程中两个程序员之间会遇到的问题。行为/表现，习惯/动机，本质/固有。

CodeReview

• 编码规范
  • Recommended C Style and Coding Standards
    • 中文：C语言编码风格和标准
  • 程序员的工作里有很多时候都要写脚本，见过很多脚本写的时候比较随意，工程师在写高级语言的时候，会有编码规范，写脚本的时候可能就随意很多，实际上脚本也是程序，也需要有好的编码规范，例如这里就有shell的编码规范：Google Shell Style Guide
• 代码复审的缺点
  • 做任何事情都有成本，代码复审当然也有成本，在知道它的成本之后，为什么还要去做，怎样做才更有效率。
• 怎样阅读代码
  • 对怎样阅读书籍似乎也有用
• 编程卡片
  • 卡片／伸缩，每个卡片都是问题解决的一个侧面
  • https://en.wikipedia.org/wiki/Oblique_Strategies
• 两个简单规则
  • 发现问题
  • 提出解决办法
  • 别提交第一个草稿? 但有时候提交比不提交强，这文章里的意思是提交前要自己做足工作。

估计与耗时：

• 怎样算有效率的工作？ Beware of Developers Who Do Negative Work
  • 之所以说软件开发不是劳动密集型行业，这个帖子可以做一个注脚。工程师需要成长，成长需要代价，也包括这种干了一堆活实际上是负面的活的代价。但是如果经过扎实的基础学习、系统的专业训练，我们应该可以适当规避这种帮倒忙的情况，实际上这也是需要规避的一种风险。
• 如何验证产品需求？How to Validate Demand for Your Product
  • 用使用互联网的工具收集数据和分析是一种办法

教师／助教

• Learning How to Teach a Class
  • 这个工程师做了大量的分析、咨询、准备、计划和预演，成功实施了他/她在学校的教学工作
  • also to NABCD
• 如何提出好的问题
  • 以前也有一篇叫“提问的智慧”的文章。提问就是分析和定位问题的过程。
• 看看皮克斯的动画短片《鹬》
  • 教学中的师生关系是怎样的？也可以看这个短片直观的感受。
    • 当然，这里有其他的师生关系的描述：http://www.cnblogs.com/xinz/archive/2011/05/16/2048044.html

项目设计

• 算法-类库-编程既服务
  • 如何从算法进阶到类库，从类库进阶到服务、从服务进阶到PaaS平台？
  • 程序=算法+数据结构有长久的生命力。当然软件=程序+软件工程，在这个过程中有大量的活要做。设计练习项目的时候，可以采用这种思路。

开发与实现

• 2000-2017，重复出现的GCC BUG
  • 一个BUG的生命周期

遗留项目：

• http://fabiensanglard.net/Compile_Like_Its_1992/
  • https://en.wikipedia.org/wiki/Legacy_system
    • "In computing, a legacy system is an old method, technology, computer system, or application program, "of, relating to, or being a previous or outdated computer system."[1] Often a pejorative term, referencing a system as "legacy" means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement."
    • 在我经历过的项目里，遗留项目多多少少都有价值，甚至新系统很多时候都是在重复做遗留项目做过的事情，遗留项目甚至有些是先进的，然而因为各种原因被丢弃了。从遗留项目里，实际上是可以学到很多宝贵的东西。

人、绩效与职业道德

• 如何评价华为开始「清理」34 岁以上的职员？
  • http://www.cnblogs.com/xinz/p/6262253.html 但是我们可以看看这篇文章末尾的故事，30/35是一种迷思，也既“坊间的说法”。
• OKR为什么到今天突然才火
  • 很迟才认识到彼得·德鲁克这个人，《管理学的实践》是需要认真阅读的，感觉大学生都应该学这个通识课程