软工+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
    • 所谓“固执己见”。怎样才能避免这样的效应？
  • regression toward to 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

估计与耗时：

教师／助教

项目设计

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

开发与实现

遗留项目：

  • 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."
      • 在我经历过的项目里，遗留项目多多少少都有价值，甚至新系统很多时候都是在重复做遗留项目做过的事情，遗留项目甚至有些是先进的，然而因为各种原因被丢弃了。从遗留项目里，实际上是可以学到很多宝贵的东西。

人、绩效与职业道德

posted @ 2017-03-07 12:35  ffl  阅读(484)  评论(6)  编辑  收藏  举报