标签：可维护性 天都 成本 原创 pen 例子 理解 inf 作者
在家办公的我，砍需求砍得更狠了收录于话题
#程序人生
13个
△Hollis, 一个对Coding有着独特追求的人△
这是Hollis的第 251篇原创分享
作者 l Hollis
来源 l Hollis（ID：hollischuang）
最近全民开始了在家办公模式，目前看来这种模式还要持续很长的一段时间，至少要到3月份才能有可能回到公司办公了。
其实，在哪办公对于程序员来说其实差别并不是很大，无非就是在哪敲代码而已。
时间很快，从在家办公开始，一直想说点什么，但是一直都没落笔，现在已经两周多了，是时候写点什么了，这两周给我最大的感受有两点。
在家办公之后，每天都是各种电话会议、视频会议、语音会议等等。
在公司办公的时候，只有有一些大事，如需求评审、设计评审之类的才需要开会，还有就是项目晨会或者团队周会之类的。
但是在家办公之后，每天会被拉着参加各种会议，以下是我某一天的会议日程：
-w877
?从早上9点，到晚上8点，一直都有会议，甚至有时候还有很多会议时间是重合的。
这时候就体现出在家办公的好处了，我就可以同时参加多个会议。钉钉视频会议开一个，手机电话会议开一个。不需要我的时候我就把我的麦禁掉。
比如有些会议，我只是负责把相关人员拉在一起，大家讨论下，最终得到一个结果，我发个邮件出来就好了。这种我就不需要发言，只需要听着就行了。
还有的一些会议，如技术方案评审之类的，可能会议中只有一小部分是和我相关的，那么我只需要再讨论这部分的时候开麦发言就好了。
如果是在公司开会，是不可能同时进行的，这反而大大提升了开会的效率。
我万万没想到在家办公带来的一个变化，也不知道是好是坏，那就是：我砍需求砍得更狠了！
相信很多一线开发人员都和我一样，每天都会接到各种各样的需求，而给我们提需求的人也是形形色色。
而各种奇葩需求更是让我们哭笑不得，但是大多数程序员在做过一些心理斗争之后都会想办法解决这个需求。
其实，所有需求都需要解决的，这没错，但是我还是给大家提一个建议：先用嘴解决需求，不行的话再用代码解决。
在家办公之后的这两周，我负责的一个项目目前正处于联调阶段，但是这个阶段还是会接到一些需求，这其中有些是产品经理提出来的需求变更、新增需求等，还有些是合作方技术提出来的有些技术需求，如要求接口同步、要求多一次系统交互、甚至要求ERROR_CODE的格式等等。
因为我负责的这个项目是个新产品上线，完全初期，要尽快上线接收用户检验，没必要一开始就搞的特别复杂。所以对于这些需求，目前的状态是能砍则砍，不能砍的先用最简单的方式先上去。
所以这两周来，我越发的发现我砍需求砍的原来越狠了，甚至有一次，我团队的另外一个同学问我一个单据的状态问题，我随口问了下问这个干什么，他说产品经理让他实现个小需求。
我了解下来之后，就拉他和产品经理一起开了个电话会议，然后动之以情，晓之以理，把"不合理"的地方都砍了，把"能优化"的也都优化了。
本来需要2-3个系统合作才能实现的一个查询功能，经过调整之后，变成只需要查询一个系统就可以实现。这既减少了系统交互、降低了风险，又减少了用户的理解成本。何乐而不为呢？
我始终认为，啥需求都接的程序员，一定不是个好程序员！但有些需求，总要有人先站出来砍！就算最后没砍掉，我认为也是有好处的：
1、可以让我们理解这个需求背后的东西。之所以最终没砍掉，肯定是有很多原因在的，只有在讨论的过程中我们才能更多的理解这些背后的原因。否则最后可能只是你毫不情愿的实现了一个你认为"垃圾"的功能，但是实际上可能这个需求背后有一些你不理解的原因。如合规风险、法务风险等等。
2、表达一个我们的态度。我觉得，作为一个程序员，态度还是很重要的。比如有些恶心的或者需求，我们可以"迫于压力"去实现，但是我们还是有权利表达我们"不认可"的态度。而且这个表达的过程，也是你树立话语权的一个过程。
我砍需求有很多考虑，但是减少工作量绝对不是最重要的。最近几天砍需求，我大概总结了一下，用到的很简单的几个架构设计原则：
1、Keep It Simple ， Stupid
2、Open/Closed Principle
3、Single Responsibility Principle
4、Minimize Coupling
5、Avoid Premature Optimization简单点，无论是系统功能，还是系统代码，最怕的就是复杂。越复杂的功能用户越不喜欢，所以，如果一个功能很复杂，那大概率是个垃圾功能。
系统实现上面也是，如果一个功能，实现起来很复杂，那大概率会存在很多问题。而解决这些问题最好的办法就是提前减少复杂度。
除此之外，要明确知道系统边界以及系统关系，实现一个功能可能有100种方式，但是到底由谁来实现比较合适？如何才能降低系统间的耦合度？如何实现才有更强的可扩展性和可维护性？这些都是要考量的。
还有比较重要的一点，在初期，不要过早的做所谓的优化。记住：Done is Better than Perfect，
我们日常要接的需求中，有一些是业务需求，还有一些是技术需求。那么，有什么好的原则或者办法可以参考呢？到底哪些能砍，哪些不能砍？到底应该怎么砍呢？
关于这些问题，我后面会写一篇详细的方法论，结合我工作中的例子，论如何砍需求。大家如果有更好的建议，或者对这个话题感兴趣，可以给我留言，欢迎探讨！
愿这个世界没有需求变更！~
关于作者：Hollis，一个对Coding有着独特追求的人，现任阿里巴巴技术专家，个人技术博主，技术文章全网阅读量数千万，《程序员的三门课》联合作者。
如果你喜欢本文,
请长按二维码，关注 Hollis.
转发至朋友圈，是对我最大的支持。
好文章，我在看??
标签：可维护性 天都 成本 原创 pen 例子 理解 inf 作者
原文地址：https://blog.51cto.com/13626762/2544197
