<commit_before>---
layout: post
title: agile
category : ToRead
tagline: "personal notes for later use"
tags : [todo, "to read", agile, management]
---

[软件开发最佳实践](http://www.iteye.com/news/29020)

1.  为人编写程序，而不是为电脑 

一段程序不应该要求其阅读者能够比电脑内存记住更多的东西
变量名称要保持一致、独特、有意义
代码的风格要保持一致
2.  一些工作让计算机去做 

重复的工作交给计算机
将最近使用的命令保存在一个文件中，以便后期重复使用
使用一个构建工具来自动化工作流程
3.  增量式改进 

将工作分为若干个小步骤，快速反馈，及时修正
使用一个版本控制系统
将手动创建的所有东西都放入版本控制系统中
4.  不要重复自己（或他人） 

每一块数据必须在系统中有一个单一权威的表征
模块化代码，而不是复制和粘贴
重用代码，而不是重写代码
5.  对错误进行规划 

在程序中添加断言，以检查其操作
使用现成的单元测试库
将bug转化成测试用例
使用一个符号调试器
6.  软件正常工作后再进行优化 

使用分析器来确定程序的瓶颈
尽可能使用高级语言来编写代码
7.  记录项目的设计和目标，而不是记录技术细节 

记录接口和用途，而不是实现
重构代码优先于解释它是如何工作的
将文档作为软件的一部分
8.  协作 

对预合并的代码进行审查
在带新人和处理棘手的问题时使用结对编程
使用一个问题追踪工具


[代码不是文学作品](http://www.iteye.com/news/28976) 推荐

程序从一个初始计划或某种伪代码构建起来。书中的许多代码，是一些净化过的版本，不具备使程序运行起来的所有东西。

Seibel: 我想起了《计算机程序的构造和解释》的前言，里面写道“程序应该是为了供人读才写的，然后顺便让机器执行了一下。”然而正好你所描述的事实在实际中却是，大多数程序都是让机器来执行才写的，如果有的话，只顺便供人阅读。 

代码不是文学作品。我们不去阅读代码，而是解译、审查它。一段代码不是文学片段，而是样本。

更确切地说，有趣的代码片段是样本，我们是博物学家。所以我认为更好的方式是：我们其中的一位扮演着一个刚从异国回来的19世纪博物学家在国内科学界引发关于他们所发现的一只新型昆虫的议论：“看这怪物的触须！这些触须看起来非常笨拙，然而该物种的雄性可利用它们杀死小青蛙，然后雌性将卵产在其尸体中”，而不是像一群学比较文学的研究生那样挑出一段代码并去阅读、讨论它。 

这种演示的关键在于介绍者要选一段自己深刻理解的代码，并通过从进化碎屑层（亦为临时补救方案–指快速有效但丑陋的方案，译者注）中指出核心思想，有助于听众理解。一种合理的方式应该是展示真正的源码并剥离、重写关键部分，就像一个生物学家去染色样本，使不同特征更容易辨别一样。 

典型的演示应面向所有程序员，或男或女，或聪明或一般，但必须对与代码出处有关的任何特定知识不作要求。为了让组员理解代码，演示文档应该提供足够的上下文，解释对一般水平程序员而言比较晦涩的实现语言的任何细节。

由于我的顿悟，我们采用新模式，已成功举行了几次代码阅读小组会议，现在被称为Twitter的旨在提高编码知识的英国皇家学会。我们仍在摸索讲演代码的最佳方法，尽管目前方法感觉很不错。另外，我不再觉得我这种解剖式阅读代码的方式是糟糕的。 

至今最大的教训是，代码是非常稠密的。半小时的报告只够用来呈现大约十二行耐人寻味的代码和一个主要思想。几乎可以肯定的是：报告人必须真正深入某段代码，要比任何人有更深的理解。除此之外，一个优秀的演示至少可让组员接触到的核心思想，对于决定自己去阅读代码的人们来说，可能是一个好的开端。 

original : http://www.gigamonkeys.com/code-reading/

[敏捷开发的6个实战经验](http://www.iteye.com/news/28541-6-practical-agile-techniques)
1. 快速迭代 
2. 让测试人员和开发者参与需求讨论 
3. 编写可测试的需求文档
4. 多沟通，尽量减少文档 
5. 做好产品原型 
6. 及早考虑测试 


[自上而下做好安全代码审查](http://www.iteye.com/news/28477-application-security-code-review) Important

###### 安全代码审查：对安全知识要求高

常规的程序代码审查需要代码审查者具备业务、程序语言和相关技术知识的积累，安全代码审查则需要具备以下 3 个不同方面的安全知识：

* 常见威胁（可以前往 STRIDE 了解此类威胁）
* 安全漏洞（OWASP 描述了 10 种最常见的安全漏洞）
* 常见的程序修复技术

etc

[为什么项目估算偏差如此之大？](http://www.iteye.com/news/28299)

[无法衡量的软件开发生产效率](http://www.iteye.com/news/28274)























<commit_msg>add note<commit_after>---
layout: post
title: agile
category : ToRead
tagline: "personal notes for later use"
tags : [todo, "to read", agile, management]
---




[改变开发者工作方式的15种技术](http://www.iteye.com/news/29281)
1、持续集成（Continuous integration）
7、应用程序容器（Application containers）
现在，类似 Docker 这样的应用程序容器允许我们按一个按钮就找到正确的库。如果 这个代码库可以运行在我们的测试机上，它也可以运行在服务器上。所有的东西都捆绑在一起了，那些夹在我们桌面和服务之间不兼容的东西都不存在了。
10、二级市场（Secondary marketplaces）

如果你想构建一个游戏，你可以自己雇佣一些设计人员，创建一个非常棒的模型集。你甚至可以雇佣一些开发人员为你的游戏增加一些视觉效果，让游戏看起来更酷。或者你可以去类似统一资源市场的二级市场购买你需要的所有部分。当我写这些的时候，构建下水道的场景的工具箱正降价30%，可以用来构建小型的或大型的游戏场景。这个销售活动在你看见这则新闻的时候可能已经结束了，价钱可能已经升到45美元了。开发人员和设计人员怎么会有这么低的价钱！

现在有越来越多的提供插件，库和其它附加软件的市场。有这么多的库和框架，开发人员也越来越多的去购买所需要的部分，编码工作越来越少了。

12、社交媒体网站（Social media portals）

13、运维工具（Devops tools）

很久以前，我们仅仅需要在一个服务器上安装软件就能满足应用需要。但是现在，我们要租用大量的服务器，需要几十，成百，甚至上千台机器，其中很多机器都需要按照需求配置，已经不是一个能用手工完成的工作了。

进入运维模式，就会有一些类似 Chef 和 Puppet 这样的工具帮助你完成这些复杂的工作。将软件推送到云端，在这些工具的控制下，可以保证所有的机器上运行的是相同的代码。这些工具替自动完成了我们以前在一台机器上的工作。

有一些服务，例如谷歌应用程序引擎已经在内部处理了这些，你需要做的仅仅是将你的应用程序告知引擎，并授权它开始工作。你甚至不知道后台到底发上了什么，你能看见的仅仅是 CPU 的占用量。

14、GitHub，SourceForge和代码共享（GitHub, SourceForge, and social code sharing）

代码共享网站可能是开源世界的最大贡献。在 SourceForge 出现之前，软件仅仅是在你的机器上创建并且代码也只属于你。如果另一些人想获得源码，他们需要找你来获得源码，当然必须要得到你的统一。

现在代码共享已经变成了一种共识。类似 SourceForge 和 GitHub 这样的网站发布了所有的代码，供所有人阅读和更新。他们为代码的维护、共享、评论提供了一个易于访问的地方。你可以通过一个入口阅读这些代码，并提出修改意见。很多项目每个星期可能有几十甚至几百万的下载量，这在以前是不可能的。

这种模式非常有优势，很多自营项目都使用这种模式。GitHub and BitBucket 这些网站还在一定程度上支持他们售卖自己开发的代码库。

15、性能监控（Performance monitoring）


[软件开发最佳实践](http://www.iteye.com/news/29020)

1.  为人编写程序，而不是为电脑 

一段程序不应该要求其阅读者能够比电脑内存记住更多的东西
变量名称要保持一致、独特、有意义
代码的风格要保持一致
2.  一些工作让计算机去做 

重复的工作交给计算机
将最近使用的命令保存在一个文件中，以便后期重复使用
使用一个构建工具来自动化工作流程
3.  增量式改进 

将工作分为若干个小步骤，快速反馈，及时修正
使用一个版本控制系统
将手动创建的所有东西都放入版本控制系统中
4.  不要重复自己（或他人） 

每一块数据必须在系统中有一个单一权威的表征
模块化代码，而不是复制和粘贴
重用代码，而不是重写代码
5.  对错误进行规划 

在程序中添加断言，以检查其操作
使用现成的单元测试库
将bug转化成测试用例
使用一个符号调试器
6.  软件正常工作后再进行优化 

使用分析器来确定程序的瓶颈
尽可能使用高级语言来编写代码
7.  记录项目的设计和目标，而不是记录技术细节 

记录接口和用途，而不是实现
重构代码优先于解释它是如何工作的
将文档作为软件的一部分
8.  协作 

对预合并的代码进行审查
在带新人和处理棘手的问题时使用结对编程
使用一个问题追踪工具


[代码不是文学作品](http://www.iteye.com/news/28976) 推荐

程序从一个初始计划或某种伪代码构建起来。书中的许多代码，是一些净化过的版本，不具备使程序运行起来的所有东西。

Seibel: 我想起了《计算机程序的构造和解释》的前言，里面写道“程序应该是为了供人读才写的，然后顺便让机器执行了一下。”然而正好你所描述的事实在实际中却是，大多数程序都是让机器来执行才写的，如果有的话，只顺便供人阅读。 

代码不是文学作品。我们不去阅读代码，而是解译、审查它。一段代码不是文学片段，而是样本。

更确切地说，有趣的代码片段是样本，我们是博物学家。所以我认为更好的方式是：我们其中的一位扮演着一个刚从异国回来的19世纪博物学家在国内科学界引发关于他们所发现的一只新型昆虫的议论：“看这怪物的触须！这些触须看起来非常笨拙，然而该物种的雄性可利用它们杀死小青蛙，然后雌性将卵产在其尸体中”，而不是像一群学比较文学的研究生那样挑出一段代码并去阅读、讨论它。 

这种演示的关键在于介绍者要选一段自己深刻理解的代码，并通过从进化碎屑层（亦为临时补救方案–指快速有效但丑陋的方案，译者注）中指出核心思想，有助于听众理解。一种合理的方式应该是展示真正的源码并剥离、重写关键部分，就像一个生物学家去染色样本，使不同特征更容易辨别一样。 

典型的演示应面向所有程序员，或男或女，或聪明或一般，但必须对与代码出处有关的任何特定知识不作要求。为了让组员理解代码，演示文档应该提供足够的上下文，解释对一般水平程序员而言比较晦涩的实现语言的任何细节。

由于我的顿悟，我们采用新模式，已成功举行了几次代码阅读小组会议，现在被称为Twitter的旨在提高编码知识的英国皇家学会。我们仍在摸索讲演代码的最佳方法，尽管目前方法感觉很不错。另外，我不再觉得我这种解剖式阅读代码的方式是糟糕的。 

至今最大的教训是，代码是非常稠密的。半小时的报告只够用来呈现大约十二行耐人寻味的代码和一个主要思想。几乎可以肯定的是：报告人必须真正深入某段代码，要比任何人有更深的理解。除此之外，一个优秀的演示至少可让组员接触到的核心思想，对于决定自己去阅读代码的人们来说，可能是一个好的开端。 

original : http://www.gigamonkeys.com/code-reading/

[敏捷开发的6个实战经验](http://www.iteye.com/news/28541-6-practical-agile-techniques)
1. 快速迭代 
2. 让测试人员和开发者参与需求讨论 
3. 编写可测试的需求文档
4. 多沟通，尽量减少文档 
5. 做好产品原型 
6. 及早考虑测试 


[自上而下做好安全代码审查](http://www.iteye.com/news/28477-application-security-code-review) Important

###### 安全代码审查：对安全知识要求高

常规的程序代码审查需要代码审查者具备业务、程序语言和相关技术知识的积累，安全代码审查则需要具备以下 3 个不同方面的安全知识：

* 常见威胁（可以前往 STRIDE 了解此类威胁）
* 安全漏洞（OWASP 描述了 10 种最常见的安全漏洞）
* 常见的程序修复技术

etc

[为什么项目估算偏差如此之大？](http://www.iteye.com/news/28299)

[无法衡量的软件开发生产效率](http://www.iteye.com/news/28274)
























{'fraction_non_alphanumeric': 0.0934018851756641, 'fraction_numerical': 0.021422450728363324, 'mean_word_length': 8.824915824915825, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 15, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2877826', 'n_tokens_mistral': 5149, 'n_tokens_neox': 5880, 'n_words': 254}