The Pragmatic Programmer的笔记(3)

按有用程度 按页码先后 最新笔记

• 

  第5页

  乱姬 (实用主义)

  破窗理论：在写程序的过程中，非常容易出现由于心情浮躁而导致的垃圾代码。这点在多人协作时尤其常见。如果有完美主义情节但却不能控制事情的发展时，往往变成恶意地交差应付。在实际工作中，我就碰到过很多这样的情形：当自己的原本设计流程被人推翻并提出需要修改，而这种修改明显不是最优解决方案，但自己又无力去争论。此时方案就会变成：去你妈的，就这样吧。于是，项目中就会从充斥垃圾代码开始，最终变成没人愿意维护修改的... (更多)

  破窗理论：在写程序的过程中，非常容易出现由于心情浮躁而导致的垃圾代码。这点在多人协作时尤其常见。如果有完美主义情节但却不能控制事情的发展时，往往变成恶意地交差应付。在实际工作中，我就碰到过很多这样的情形：当自己的原本设计流程被人推翻并提出需要修改，而这种修改明显不是最优解决方案，但自己又无力去争论。此时方案就会变成：去你妈的，就这样吧。于是，项目中就会从充斥垃圾代码开始，最终变成没人愿意维护修改的劣质项目。从此，项目变成内心的恐惧，由此影响工作心情，从而恶性循环。。。

  保持整洁的方法在于保持细节上的整洁，破窗理论或许源自人的惰性：维护细节的整洁是很繁琐并且成效甚微的，所以常常被忽视。

  卓越来自于细节，或是，细节决定成败。 (收起)

  2012-03-26 12:29:23   1人收藏   回应

  收藏

  推荐
• 

  1.1 Prototypes

  Ovilia (静观己心，厚积薄发)

  The distinction is important enough to warrant repeating. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired. 主要在说Prototypes和Tracer code的区别，我的理解是，前者是为了给客户和开发者看最终效果从而... (更多)

  The distinction is important enough to warrant repeating. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.

  主要在说Prototypes和Tracer code的区别，我的理解是，前者是为了给客户和开发者看最终效果从而统一对需求的理解，做一个比较完整的东西出来看效果，其实现可能是虚拟的（比如一个算法没有实现，直接输出一个假的结果），展示完以后完全抛弃；后者是为了打通技术关键，确定可行性，实现可能不是很高效，但是能用的，展示完以后等于制定好了框架，在这个基础上进行开发，而不是完全抛弃。

  What sorts of things might you choose to investigate with a prototype? Anything that carries risk. Anything that hasn't been tried before, or that is absolutely critical to the final system. Anything unproven, experimental, or doubtful. Anything you aren't comfortable with.

  (收起)

  2011-08-28 19:46:19   回应

  收藏

  推荐
• 

  2.8 Orthogonality

  Ovilia (静观己心，厚积薄发)

  When you bring in a toolkit (or even a library from other members of your team), ask yourself whether it imposes changes on your code that shouldn't be there. If an object persistence scheme is transparent, then it's orthogonal. If it requires you to create or access objects in a special way, then it's not. Keeping such details isolated from your code has the added benefit of making it easier to c... (更多)

  When you bring in a toolkit (or even a library from other members of your team), ask yourself whether it imposes changes on your code that shouldn't be there. If an object persistence scheme is transparent, then it's orthogonal. If it requires you to create or access objects in a special way, then it's not. Keeping such details isolated from your code has the added benefit of making it easier to change vendors in the future.

  (收起)

  2011-08-25 18:39:49   回应

  收藏

  推荐