软件开发常见问题分析

长河马俊强

　　随着互联网的不断发展，越来越多的人都在通过自学或者参加达内IT培训课程来学习软件开发技术或者是UI设计技术，今天我们就通过案例分析来了解一下，软件开发常见问题分析。
　　1、设计
　　如果你在绕开系统弱点上面用的代码量多过利用其优点的代码量的话，就是坏设计
　　有人有一个很棒的新设计，他们想实现这个设计，因为它比原来的那个好多了，原来的设计太糟糕。只是这么做会需要到处修补一下，但这完全是可以接受的，因为整体上新设计更好。直到后来才发现需要的修补的地方太多了，但是你已经全力以赴，没法走回头路了。
　　解决方案：重新开始。沉没成本谬论是真的。你已经犯了一个错误，没关系，你可以吸取教训然后做出更好的。不要无奈地接受混乱。
　　如果致力于这一代码库的大多数人都遇到了同样的问题，并且这些问题采用不同的架构时可以避免的话，就属于糟糕设计
　　你会注意到同一段代码被拷贝粘贴到系统的每一个被牵涉到的地方。你问某人为什么，他们解释说“哦，那是因为这个系统因为某个原因预计要做这个，其实这不是真的，但听起来不错，所以大家只好跟着做。”你不知道为什么他们要这么做，但你很忙，所以就把这段代码粘贴进去然后继续自己的事情了。
　　解决方案：我说的话听起来会很痛苦，但是，还是重构吧。重构整个东西，把那些拷贝粘贴都去掉。付出会有回报的。
　　2、编码
　　随意编码。没有测试，或者测试糟糕。没有处理极端情况，而主要是编写基本逻辑(happy-path)代码
　　“这里是初创企业，我们没有时间做这个，晚点再处理。这是可以接受的，”这些年来很多开发者都这么说，每个人都为后的混乱局面贡献了自己的力量。未经测试就上线代码，产品出问题晚点再修复，哪怕写测试也只是测基本逻辑，或者甚至连这个都不做。
　　解决方案：管理层可以强制要求测试的覆盖面，不过其实这并不是代码库测试是否到位的好的衡量手段。有效的办法是让周密的人对这些代码进行评审，让那些代码评审只是做表面文章的走人。不幸的是，不幸的是，当你招进来的工程师缺乏经验或者不够尽责的时候就会出现这种情况，所以招人的时候要擦亮眼睛。
　　3、会议
　　没有日程，或者日程不明确，没有可衡量的输出
　　你查看日程发现自己有个叫做“系统讨论会”要参加，但是要干什么并没有描述，只知道邀请了10个人，要进行1个小时。身为好员工的你出席了，但是绝大部分时间内都是默不作声，只有其中的2个人在那里漫谈，到会议后的时候，组织者拍拍那两个人的后背中断了同名的谈话，并且威胁着要再举行一次会议。大家的时间被白白浪费掉了，一点收获都没有。
　　解决方案：在全公司范围强制执行一项政策，要求所有会议都要有日程，有可衡量的输出，只让必须参加的人出席，而且要有备忘录，看看会议的结果是否达到预期。一旦目标达成或者时间到马上结束会议。任何违背这些原则的会议，要么允许大家走人，要么允许将来不再出席。这样就会迫使大家做出改变。