程序员修炼之道github

Permalink

目錄 Show

Name already in use
第一章注重实效的科学
我的源码让猫给吃了
软件的熵
程序员修炼之道--从小工到专家
1. 注重实效的哲学
1.3 石头汤和煮青蛙
1.4 足够好的软件
了解你的听众
2. 注重实效的途径
2.11 原型与便签
3. 基本工具
4. 注重实效的偏执
5. 弯曲, 或折断
6. 当你编码时
7. 在项目开始之前
8. 注重实效的项目

master

Switch branches/tags

Could not load branches

Nothing to show

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Go to file

Go to file
Copy path
Copy permalink

Cannot retrieve contributors at this time

25 MB

Download

Open with Desktop
Download
Delete file

Sorry, something went wrong. Reload?

Sorry, we cannot display this file.

Sorry, this file is invalid so it cannot be displayed.

Permalink

Cannot retrieve contributors at this time

第一章注重实效的科学

注重实效的程序员对他们所做的每件事负责
注重实效的编程源于注重实效的思考和哲学

我的源码让猫给吃了

在所有的弱点中，最大的弱点就是害怕暴露弱点

软件的熵

不要留着“破窗户”，低劣的设计、错误的决策、或者是糟糕的代码要及时修复。方法：

把出问题的代码放入注释
显示为“未实现”
用虚拟的数据代替

定期为你的知识资产投资目标：

每年至少学习一种新语言
每季度阅读一本技术书籍
也要阅读非技术书籍
上课
参加本地用户组织
试验不同的环境：windows， linux
跟上潮流
上网

程序员修炼之道--从小工到专家

总结

这本书介绍了挺多的方法,学习交流如何做项目

但是我赶紧对自己不算太适用

评分(3),总页数 378

1. 注重实效的哲学

1.3 石头汤和煮青蛙

设计出你可以合理要求的东西,好好开发它,一旦完成,就拿成果给大家看

提示5--做变化的催化剂

1.4 足够好的软件

今天了不起的软件常常比明天的完美软件更可取

提示7--使质量成为需求问题

1.6 交流

知道你想要说什么

了解你的听众

你想让他们学到什么
他们对你讲的什么感兴趣
他们有多富有的经验
他们想要多少细节
你想要让谁拥有这些信息
你如何促进他们听你讲话

2. 注重实效的途径

2.11 原型与便签

构建原型可以忽略

正确性
完整性
健壮性
风格

提示16--为了学习而制作原型

3. 基本工具

提示21--利用命令shell的力量

建议用emacs vim等

提示22-用好一种编辑器

4. 注重实效的偏执

提示31 通过合约进行设计

子类必须能够通过基因的接口使用,而使用者无需知道其区别

提示33 如果它不可能发生,用断言确保它不会发生

5. 弯曲, 或折断

提示40 用服务进行设计

6. 当你编码时

发现

重复
非正交设计
过时的知识
性能

就进行重构

提示47: 早重构, 常重构

不要试图在重构的同时增加功能
在开始重构之前,确保你拥有良好的测试.尽可能经常运行这些测试.这样,如果你的改动破坏了任何东西.你就能很快知道

7. 在项目开始之前

提示51: 不要搜集需求--挖掘他们

提示52: 与用户一同工作,以像用户一样思考

8. 注重实效的项目

提示62: 早测试,常测试,自动测试

提示63: 要到通过全部测试,编码才算完成

提示66: 一个bug只抓一次

出现一次bug 就应该增加一个测试用例

提示70 在你的作品上千名

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

	# chinese page(english page)

	1.1 我的源码让猫给吃了 2
	1.2 软件的熵 4
	破窗理论，整个过程的心态变化，”随便“，“无所谓” 开始。。。
	1.3 石头汤与煮青蛙 7
	跨部门合作，要让其他部门出人，得先出一个demo，眼见为实了才能调动他们的积极性。
	==人们发现参与正在发生的成功要更容易，让他们瞥见未来，你就能让他们聚集在你周围。==
	1.4 足够好的软件 9
	1.5 你的知识资产 12
	知识是无形的资产，具有时效性，需要不管更新迭代。
	增加对知识读书的投入
	充电增长见识，同时批判地思考，对所看到的、听到的进行二次过滤。
	1.6 交流 18
	I believe that it is better to be looked over than it is to be overlooked.被打量比被忽略重要。
	Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication.
	除非你能够与他人交流，否则就算你拥有最好的主意，最漂亮的代码，或是最注重实效的想法，最终也会毫无结果，没有有效的交流一个好想法就只是一个无人关心的孤儿。

	·知道想要说什么：写大纲，熟练掌握
	·掌握听众的需求
	·选择时机
	·选择风格，面谈、QQ、Email。。。
	·让文档美观，不能只注重内容。
	·让听众参与，互动~
	·做倾听者：让大家听你说话，必须使用一种方法：听别人说话。
	·回复他人：任何形式的讨论，回复他人。。
	It is both what you say and the way you say it.

	2.1 重复的危害性 26
	需求不断在变化，代码、模块的复制十分容易，梦魇地开始。
	DRY Don't repeat yourself. 最重要的工具！
	DRY替代方案是多个地方有相同的内容，
	It isn't a question of whether you'll remember: it's a question of when you'll forget
	不是你能否记住的问题，而是你何时忘记的问题。

	·强加的重复
	信息多重表示：客户端、服务器可能基于不同语言开发，某些数据结构不可避免重复，方案：开发代码生成工具。
	代码注释。
	Bad code requires lots of comments.
	代码和注释某种意义下也是重复，每个修改都要同时修改code和comment，注释会不可避免地过时。有注释还不如没有。
	代码和文档
	写代码，同步文档。但是当最后期限逼近，客户抱怨，We trend to defer the updating of documentation.(我们一般倾向于延迟更新文档）。
	语言问题
	C/C++ .h,.cpp文件中函数申明等重复，没办法克服！避免在头文件和源文件中重复注释。
	·无意的重复，有时候重复是错误设计的结果。
	C++, Java, Always use a accessor functions to read and write the attributes of objects. It will make it easier to add functionality, such as caching in the future. The trick is to localize the impact(影响局部化).
	·不耐烦的重复
	项目紧任务重，怎么快怎么着。。
	欲速则不达，shortcuts make for long delays.前期的不耐烦后期可能付出代价。
	·开发者之间的重复
	这种重复最难检测。
	相互之间多交流，论坛、svn，codereview，相互学习！

	2.2 正交性 34
	STL是正交性设计的典范！正交性：模块之间耦合度为0，两个向量正交：一个在另一个上面投影为0。 Eliminate effects between unrelated things.

	·提高生产率 35
	改动局部化，开发、测试时间最低。
	正交能够促进复用
	正交组件组合，M*N结果
	·设计 37(56)
	Orthogonal systems: modular, component-based, layered，模块化、组件化、分层！
	组件按层次组织，每层提供一级抽象，每层只使用其下面的层次提供的抽象，改动底层实现，不影响其他代码方面，有极大的灵活性。参见Android层次化组件。
	·工具箱与库 39(57)
	ME：stl中容器和迭代器，适配器正交性，更换数据结构只需要修改数据结构类型，代码基本上不需要修改。
	·编码 40(59)
	Keep your code decoupled.
	Avoid全局变量：依赖于全局变量，升级到多线程可能会潜在风险，OO做法是：一般context通过构造函数参数传入模块。单例设计模式。
	避免编写想相似的函数：Strategy策略模式
	Refactor: Get into the habit of being constantly critical of your code. Look for any opportunities to reorganize it to improve its structure and orthogonality.
	养成批判对待自己代码的习惯，寻找任何机会，重新进行组织优化数据结构和正交性。
	·测试 41(60)
	为每个模块写内在的单元测试。
	·文档 42(60)
	正交性也应该应用到文档中，两个维度坐标轴是内容和形式。显著改变形式并不会影响到内容。
	·认同正交性
	正交性跟DRY很类似，DRY降低系统内重复度，正交性是降低系统模块之间的依赖性。

	系统不正交，每处改动都会造成其他地方出错，噩梦开始，It is time to refactor！

	2.3 可撤销性 44(62)
	·可撤销性 45(63)
	要把决策视为写在沙滩山的，而不要把他们刻在石头上。大浪随时可能到来把他们抹去。
	There are no final decisions.
	·灵活的架构 46(64)
	不同语言（java、C++、）不同平台（win32、unix、linux、android等），随时可能要支持，把第三方产品隐藏在定义良好的抽象接口或者使用元数据。
	可撤销性：如果某些东西是自动添加的，它也可以自动撤销。
	没人知道将来会怎样，尤其是我们，要让代码学会“摇滚”：可以摇就摇，必须滚就滚。

	2.4 曳光弹 48(66)
	曳光弹与常规子弹交错在一起，运行环境和约束与真实子弹完全一致（这点区别于原型），并且反馈是及时的。
	·在黑暗中发光的代码 49
	用户能够及早看到能工作的东西
	开发者构建了一个能在其中工作的结构
	你有了一个集成平台
	你有了可用于演示的东西
	你将更能够感觉到工作进展
	·曳光弹并非总能击中目标 51(69)
	·曳光代码 vs 原型开发 / Tracer Code versus Prototyping 51(69)
	原型开发为了试验，结束后丢掉所有所有东西，使用已经获得的经验进行重新编码。例如使用高级语言实现xx功能，结果理想的话，然后用C/C++实现算法细节。
	原型制造生成用过就扔的代码，曳光弹代码虽然简约，但却是完整的，并且构成了最终系统的骨架的一部分。原型制造可以视为在第一发曳光弹发射之前进行的侦查和情报搜集工作。

	2.5 原型与便签 53(70)
	·应制作原型的事物
	架构、已有系统中新功能、外部数据结构内容、第三方工具组件、性能问题、用户界面设计
	Prototype to Learn
	·怎么样使用原型 54(72)
	可以忽略正确性、完整性、健壮性、风格。使用高级脚本语言快速构建原型，获取经验以后使用低级语言重写！
	·制作架构原型 55(73)
	追求架构整体性，延迟考虑细节。
	·怎么样不使用原型 56(73)
	别人很容易被原型的完整性所误导。如果所在的环境或文化不允许，则最好还是采用曳光弹方法，你最后将得到一个坚实的框架，为将来开发奠定基础。

	2.6 领域语言
	·p77 - p84
	2.7 估算 84(81)
	实际开发中算法复杂度，
	整个北京市的陆网数据量?
	路况信息数据量?
	实时路况分布情况多少米一个交通点?

	。。。估算。。。模糊数学。。。

	·多准确才足够精确 84（82）
	考虑语境；回答数据的单位天周月。

	·估算来自哪里
	估算都是以问题的模型为基础，你能够成功地借鉴他人地经验。
	·理解提问内容
	沟通技巧啦，需要把握问题领域地范围。。。
	·建立系统模型？？
	·模型分解成组件
	每个组件有一些参数，影响它们在系统中的作用
	·每个参数设定指
	·计算答案
	·追踪你的估算能力
	尤其对于错误的估算，总结原因

	3 基本工具 91(88)
	强悍的find工具 find . -name '*.c' -print \| xargs grep 'printf' 输出包含printf的c源码文件。
	The Unix Philosophy: Unix is famous for being designed around the philosophy of small, sharp tools, each intended to do one thing well.
	·编辑器特性 103(99)
	可配置性，字体大小颜色；
	可扩展性，支持各种类型文件
	可编程性，提升开发效率
	代码局部排序，vi中一个命令即可，强大的vi。npd++，IDE都是鼠标配合。
	===> 钻研下vi