programming►python

用Python实现编程练习Kata-FizzBuzzWhizz

Functional programming leads to deep insights into the nature of computation. – Martin Odersky

近日软件匠艺小组的朋友用函数式编程的方式重新实现了一个古老的Kata练习题:FizzBuzzWhizz，用了很多种语言及其特性，非常精妙。这是一个软件匠艺的文艺复兴时代。
原帖见https://codingstyle.cn/topics/100

题目

FizzBuzzWhizz详细描述请自行查阅相关资料。此处以3, 5, 7为例，形式化地描述一下问题。

r1
+ times(3) -> Fizz
+ times(5) -> Buzz
+ times(7) -> Whizz
r2
+ times(3) && times(5) && times(7) -> FizzBuzzWhizz
+ times(3) && times(5) -> FizzBuzz
+ times(3) && times(7) -> FizzWhizz
+ times(5) && times(7) -> BuzzWhizz
r3
+ contains(3) -> Fizz
+ the priority of contains(3) is highest
rd
+ others -> others

Python实现

借助原帖的测试用例，我用python语言也练习了一把。本来想引入Pipe库用管道式的方式写，可能会取得一些方便，但想想还是用原生的语法来做吧。

Read More

agile►engineering

写出angularjs风格的源代码提交历史

你的项目中是怎么写提交历史的？

不论你是用SVN、GIT或是其他源代码仓库，去看看实际项目中的提交历史吧，你是否能很快地从中找到之前某次改动吗？

看看这张图中的提交历史，眼熟吗？

这还算是不错的呢，还有很多项目的提交历史根本就是大段空白！很多程序员其实并不清楚为什么要写 **提交历史(commit messge)**。

Read More

agile►engineering

结对编程与结对工作

结对编程最早源于极限编程XP中。
每一行代码的编写都是由两个人在同一台电脑前完成的。结对编程提高了软件质量，却并不会影响交付时间。这是反直觉的，但是2个人在同一台电脑前工作，可以产出与2个人单独工作时同样多的功能，同时质量更高。而更好的代码质量和可读性可以节省项目后期的时间。

结对编程的最好方式是在电脑屏幕前并排就坐。不断地滑动键盘和鼠标。一个人敲键盘并从战术层面来思考当前编写的函数，同时另一个人从战略层面思考该函数如何适应到类中。这种做法需要一些时间来习惯，所以不用一开始感觉到的不适应。
除了编码，其他工作也可以结对完成，比如测试、分析、研究等等。

结对的好处在于可以自动地完成代码评审，从其他人那里学习技巧、技术、领域知识，甚至是良好的习惯。两个人在共同工作时可以碰撞出更好的想法，更迅速的解决掉问题。
还有一点，通过结对编程一种很好的传播知识的方式，降低团队核心人员的压力，降低项目的整体风险。

Reference:

agile►engineering

用户故事图谱和用户画像

产品愿景

产品愿景（Product Vision）是对未来产品切实可行的构想，建议用一句宣传语来简明地向所有人传递产品愿景。
例如：“针对中型公司的市场和销售部门，CRM-Innovator是一款基于网页服务的产品，提供销售跟踪、商机发现、销售支持等功能以改善客户关系，不同于其他产品，我们产品具有巨大的成本优势。”

用户画像

用户画像（Persona）是真实用户的虚拟代表，建立在一系列真实的市场数据和用户调用数据之上的目标用户模型。建立persona的目的是为了让PO与团队成员在产品设计的过程中能够抛开个人喜好，将焦点关注在目标用户的动机和行为上进行产品设计。PO为具体和特定的人物做产品设计要远远优于为脑中虚构的东西做设计，也更来得容易。有了共同的认知基础，PO和团队在实现产品的时候也更容易对优先级和实现手段达成一致。可以参考书籍《创建定性用户画像》。

Read More

agile►engineering

深入理解代码评审

代码评审（Code Review，以下简称CR）是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。其目的是帮助提高代码质量，尽早发现由于编码习惯而造成的缺陷，重新梳理思路，最重要的是促进团队沟通共享，共同识别优秀的习惯和模式，把代码评审活动看做一种 学习活动而非批判活动。

内容

  • 编码风格、文档与注释
  • 代码结构
  • 工具框架的使用
  • 功能和业务逻辑、异常处理
  • 安全性、性能
  • 可测性
  • 工具扫描出的违规项和编译器警告

形式

Read More

agile►engineering

TDD测试驱动开发

定义

在编写任何产品代码之前，先写一个测试来表达期望的行为，此时测试应当会失败，因为功能还没有实现。然后编写实现来使测试通过。换句话说，__”只为修复失败的测试而编写代码！”__
TDD要求测试可以完全地自动化运行，通常会借助单元测试作为基础。

Read More

agile►engineering

单元测试

单元测试（Unit Testing简称UT）是最微小规模的测试；测试粒度在某个类、函数或代码块。典型地由程序员而非测试员来做。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

在Java语言环境下，推荐采用JUnit，也可以和Eclipse集成或单独运行。

语言环境 推荐工具
Java/Android JUnit
C# NUnit
iOS XCTest
Javascript Jasmine

下文以Java的单元测试框架JUnit4和Eclipse为例。

Read More

agile►engineering

重构

为什么要重构？

好的软件除了满足功能需求之外，还应从长期维护的角度来考虑可读性、可扩展性等。没有明显问题，不代表明显没有问题。
然而，随着时间的推移，任何原本设计良好的代码都必然会逐渐腐坏，产生各种代码坏味道，变得难以理解，难以维护，缺陷频出。
随着代码质量下降，问题越来越多，程序员压力也越来越大，而士气也会受到影响，甚至原本的设计队伍都不在了。因而当需要修改bug或添加新需求时，人们更倾向于采用快速的打补丁方式来维护本已不堪的代码，致使代码质量进一步下降，从而造成更多的代码坏味道(Code Smell)，形成恶性循环。
采用重构以后，可以有助于改善软件设计，使软件更加容易理解，发现潜在缺陷，从而使未来的编码更加快速。

什么是重构?

重构是指在保持程序的全部功能的基础上重新组织代码结构，以更好地适应将来的变化。重构的类型有很多，如更改类名，改变方法名，或者提取代码到方法中。每一次重构，都要执行一系列的步骤，这些步骤要保证代码和原代码相一致。

Read More