程序员如何避免996、icu?欢迎来讨论一下。

最近*火了,我以前就被996害了。现在还没缓过来,可能是自己体质比较弱吧。

以前的事就不说了,说说现在的想法吧。那么程序员如何才能避免*呢?

有两个基本因素:

1、 实现一个功能,只需要更少的代码,甚至不需要写代码就可以实现。

2、 客户的需求变化了,只需要修改很少的代码,甚至不需要修改代码,就可以满足客户的变更需求。

3、 有空多健身,加强自身的身体素质。

先看看为啥要996?客户说了下个月必须上线,不上线不行。然后我们来看看还有多少事情要做?结果是——很多很多很多很多!怎么办?只好996了。

那么怎么避免这种情况发生呢?有很多种方案,比如:

1、  和客户协商,上线时间能不能推迟一下;

2、  能不能把一些功能放在二期项目里?

3、  一些功能能不能简化一下,

4、  能不能增加人手,

5、 其他

等等。

但是这些有一个共同的前提和基础,到底需要写多少代码?能不能写更少的代码就能实现功能?

1、  实现一个功能需要多少代码?

2、  修改一个功能需要改多少代码?

3、  测试需要写多少测试用例?

4、  发现bug后需要多长时间能够找到原因(出错的地方),又需要多少时间才能改掉bug,重点是如何避免引发其他bug?

好了,重点来了 —— 在实现相同功能的前提下,需要写的代码越少,需要的时间也就越少。

那么少写代码,甚至不写代码,是不是很重要呢?

这么多年,我是一直想要达到,写更少的代码实现更多的功能,最后做到不写代码就可以实现各种功能!

只是似乎没有找到同路人。

感觉是一个人在孤独的在一条漆黑的道路上默默的前行。

现在想借助*的热点,看看有没有同路人。

上一篇:(转)Monte Carlo method 蒙特卡洛方法


下一篇:Summary: How to calculate PI? Based on Monte Carlo method