程序员真正日常的工作:任务拆解 + 代码实现 1

  • 大块的任务需求拆分成小块的任务

  • 小块的任务实现成代码

    1. 接到需求前第一步

  • 为什么要做这个特性，它会给用户带来怎样的价值？

  • 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
  • 达成这个目的是否有其它手段？是不是一定要开发一个系统？
  • 这个特性上线之后，怎么衡量它的有效性？

可能你会质疑,我就是开发,我管这么多干什么,这不是产品的事儿么?但是这样的思维非常的外包化,把自己当成了一个机器,接受固定的需求,翻译成代码,然后交付给测试.日复一日日复一日日复一日.
当然对于初级程序员来说优先掌握好手里的”锤子”是很重要的,然后才能去用手里的锤子去解决问题.技术本身是不产生出价值的,就像纯粹的数学理论是不产生价值的一样.只有与具体的实践场景相结合,才能发挥出价值,比如阿里经常说的:技术赋能业务.
同样的if else写在不同的地方,解决不同的问题,给公司带来的收益和给程序员的回报都是不一样的,当你有丰富的”工具箱”,并且能够利用它去解决只有我们程序员才能搞定的问题,就能不断的变被动为主动,这样市场也一定不会亏待你的.

2. 怎么去分析需求:以终为始

有一段时间，网上流传着一个帖子，亚马逊 CTO 介绍亚马逊是如何开发一项产品的，简单来说，他们采用向后工作的方法，开发一项产品的顺序为：

  • 写新闻稿；
  • 写 FAQ（常见问题解答）；
  • 写用户文档；
  • 写代码

践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情.
小技巧:
1.事前推演,在脑海中演习,并记录下来
2.把自己想象成用户,模拟使用
3.BDD 式的开发,先设想针对每一个场景的验收标准(自己脑海中自己精分成一个测试人员),对每一个功能点设定自己开发的验收标准,这个标准技术上可以实现为单元继承或者端到端测试.但是如果没有掌握这些技术,也可以写简单的 BDD 的拆分场景.
一般的BDD 测试用例是give-when-then的模式
give-给定一个环境或者场景
when-当特定的某件事情触发或条件达成
then-则执行什么样的功能
BDD 与 TDD 的区别是什么;
从需求到代码产出,BDD 更接近需求侧,TDD 更接近代码侧.
很多敏捷开发都是,将用户的需求拆分成一个个的用户故事,用户故事是很容易用 BDD 来描绘的,而单个的用户故事是很方便的拆分成具体的开发目标的,而我们基于拆分下来的开发目标进一步写 TDD,最终完成我们的代码.
对内我们交付的是有单元测试的代码,对外,我们交付的是一个个的 BDD 的测试用例.
当然现实开发中是很难做到的,但是不是说我们的方法不对,而是开发人员的不熟练导致实施上述的步骤成本过高,又为了赶进度,又没有对开发做训练,所以导致了国外的开发和国内的开发很不一样.

3. Code Review与人探讨-精益求精

我理解的 Code Review 应该是 reviewer(评审者) 和reviewee(被评人)一个交流的过程,目的是找到更好的实现方式,或者提高代码质量.
第一步:提升可读性,通过变量命名、函数封装、注释等方式很容易实现.但是这里有一个分水岭,就是代码的表达力,表达力强的代码是面向人的,而不是面对冯诺依曼体系下的指令机的.作为程序员应该是去抽象具体的过程,而不是在产出一个打孔纸带输入给机器.所以我一直在强调不要用命令式的方式来写代码,而是脑袋里面有

  • 输入是什么?
  • 输出是什么?
  • 输出到输出需要做哪几步的处理?

如果你用这样的思维,那么你可能就很少从头到尾的写一个函数了,而是先开始写伪代码,第一步接受初始输入,然后假设我们的中间处理函数都已经有了,然后自己设计中间函数的接口,然后当我们完成了所有的中间处理函数之后,将这些函数拼接起来,最后功能就实现了.并且实现单一函数的过程中,比较聚焦,质量也更高,并且将代码按抽象层次提前弄好了,当你发现抽象层级比较高,可以继续往下,这样也就达到了隐藏细节的目的,这样比你一开始就写非常底层的代码,然后不停的往上抽象来重构效果更好,也是我一直比较推崇 TDD 的原因之一.