两个项目, 一个总结 - 2012.12.18项目总结

两个项目, 一个总结 - 2012.12.18项目总结

博客连续13天没有更新了, 有种强烈的负罪感, 当一件事成为一个习惯后如果有一天你突然没有去做会觉得很不适应。这12天以来做了两个小项目, 一个是成功的, 一个是失败的。


一、这篇博客的适用对象
    1>. 没有实战经验的独立开发者 ;
    2>. 想在网上接私活的朋友 ;
    3>. 需要一篇项目总结模板应付检查的朋友(开玩笑的)。

   
博文背景:
    2012年12月13日夜, 在某任务发布网站接到一个小活, 这里对于任务网站以及其他信息全部省略, 避免软文嫌疑, 经过5天的努力后项目顺利通过验收。次日, 经朋友介绍又开始着手一个小项目, 此时是19号, 22号晚该项目宣布失败。两个项目的成员, 笔者自己。


这里不说项目内容, 只说项目的一些体会。


一、项目启动前的准备工作
    这两个小项目客户都没有对代码的所用的语言加以要求, 客户一要求要尽快完成并且软件运行要稳定, 客户二的项目有些棘手, 因为项目的成功和失败不掌握在我手里, 是有关广告推广的一个软件。
    
    1>. 确定所使用的语言
        对于这两个项目我使用的都是Python语言, 一是因为笔者对Python语言较为熟悉, 二是项目较小, 对数据处理的速度要求也并不高, 只是为了用软件替代重复的手动工作。
        
    2>. 工欲善其事, 必先利其器
        除了开发环境的准备外, 一个人的项目也要做好版本控制, 及时提交进行备份, 避免代码的意外发生, 选择并使用好一个顺手的版本控制管理工具是每个开发者都应该具备的能力, git、svn等任你选。 此外还有各种项目管理工具, 感觉需要就提前准备好。
        
    3>. 明确项目需求
        需求不明确就直接进行编码那是不明智的选择, 直接编码项目过程中不知道需求变动多少次, 可以以单位n进行计算, 因此在需求不明确的情况下就开发编码即使客户需求变动频繁开发者也有很大一部分责任。
       

        
二、如何避免项目过程中需求频繁变动
    在联系到客户时客户就已经将软件的需求和我说了一遍, 但是并不详细, 只是大致的描述了软件所需的功能, 用户中途需求频繁变动是个很常见的问题, 也是千万开发人员最不想面对的问题。 我听说过一个笑话, 说杀死一个程序员很简单, 把需求改三遍就行了。 当然, 这不是说开发人员怕需求变动, 而是感觉无谓的变动简单就是在浪费大家宝贵的生命, 为什么客户就不能提前把需求一次性描述清呢? 笔者认为, 可能有以下几点原因:

        ①. 客户不懂技术, 他只能将自己想要的功能描述清楚, 并且从决定找人开发这个软件到找到开发人员这个过程所考虑的时间一般不会太长, 在这个过程中很少有客户认真分析并把所需的功能全部考虑彻底再联系开发者, 甚至他不会想着去写一个需求文档交给你 ;
        
        ②. 客户会认为软件开发者是万能的, 他们会把软件开发的漂漂亮亮 ;
    
        ③. 把大致软件需求大致描述后客户不会把这件事抛到脑后, 因为这直接和他口袋里的RMB有关, 当他闲下来喝茶的时候他也会想着这个软件开发的怎么样了, 以后打算怎么使用这个软件之类的问题, 忽然, 客户一拍脑门, 对了, 这个功能不如改成这样, 这样我使用时肯定会更方便怎么怎么样, 然后... 就都知道然后了。
        
    笔者是如何处理需求频繁变动的问题的:
        对于需求变动, 我们一般不可能直接对用户说一旦需求确定, 不允许再变动需求, 这样是不科学的, 除非你确定以后坚决不会再和这个客户打交道, 也不指望下次他再找你开发软件。
        
        笔者的做法:
            ①. 从客户那得到需求后再自己整理遍需求并得到用户确认
                笔者的这两个客户都没有给笔者相应的需求文档, 只是通过电话或QQ聊天告诉我软件需求的功能, 当客户将需求说完后笔者将这些需求整理并写成一份软件功能需求设计文档交给用户看, 看看是否漏掉了某个功能或者哪个功能设计的不够合理。 一般来说, 对于一些用户描述模糊的需求, 或者在项目过程中可能变动的可能性最大的需求再这一步用户就会提出。
                
            ②. 给用户最大的DIY空间
                我们不知道客户对软件的使用习惯, 尤其是在UI这块, 有可能你设计的很满意的一个界面, 设计完成后客户看过会让你这里调整下, 那里调整下, 这个过程是个痛苦的过程, 就像你自己亲手设计的一件完美的艺术品现在就要被不懂艺术的人"践踏"一样, 心里一定很不舒服。 这里我觉得我们不应该埋怨用户不懂"艺术", 而是每个人的使用习惯不同, 这是实际情况, 就像我们喜欢使用快捷键, 不喜欢拿个鼠标一点点的点击, 而普通用户才不会去记这些快捷键, 他们觉得鼠标点更方便, 你能让用户放弃使用鼠标而全部改用快捷键或者更干脆点使用命令行?
                
                笔者首先询问了客户对于软件界面是否需求自己进行设计, 如果客户需要的话, 趁这个时候你可以去分析下项目了, 如果客户说你们设计就行, 我对界面没有要求。 那么这时也要注意, 是真没要求吗? 客户这样说可能是平时比较忙, 没有时间来自己个性化界面, 二是怕自己不懂设计, 如果自己设计, 设计出来后被人笑话, 以后想找我们再修改也不好意思。
                
                对于笔者这个项目客户说让我设计就行, 于是笔者使用PS设计了份软件四个不同界面的草图, 和大多数开发者一样, 本以为设计的自己已经很满意了, 谁知拿给用户看时看时还是进行了4处局部调整。
                
            ③. 模块化开发, 反复询问
                在确定软件的结构后, 每进行一个界面/模块的功能前向用户描述该界面/模块的功能, 并询问这样设计如何, 当用户感觉满意后再进行该界面/模块的功能的实现。
                
            ④. 过大的变动或不必要的变动放到最后进行实现
                对于需求变动很大的请求, 可以酌情考虑是否拒绝, 如果决定拒绝的话要尽量向用户解释清拒绝的原因, 要从用户角度进行拒绝, 不要说技术上难以实现之类的话, 如果你说技术上难以实现, 即使真的难以实现客户也会觉得你这人不厚道, 下次再也不和你合作了。 可以向用户这样解释: 如果要进行这个变动的话从技术上是没问题的, 但是如果确定要进行变动的话可能要增加项目开发的时间X天, 因为前面所进行的架构也要重新进行设计, 以及xxx原因。剩下的xxx原因就自己发挥想象吧, 笔者对文字游戏实在不擅长。就像这次中途的3次变动我也全部都答应了。
                
                如果你感觉这个变动可有可无, 即使不变动也不会对使用上有影响, 那么告诉客户说这样变动将再软件收尾时进行实现, 避免打乱了现在的脚步, 不过你应该把变动需求记下来, 如果忘了那就是你的责任了, 诚信很重要。
                    

        
三、如何提高开发效率
    1>. 先动脑、再动手
        不要先记着码代码, 不然写着写着你就会发现, 又写废了xxx行代码, 或者, 额... 好吧, 再Ctrl + C, Ctrl + V一段凑合上去, 如果你又copy paste了一段, 那么你应该庆幸, 还好, 是一个人的项目, 反正代码也馊了, 就让它更垃圾一些吧! 仔细而又认真分析需求才是硬道理, 做好功能上的分析, 从中分析出一些基本的通用方法, 调用的价值远大于copy paste。
        
        架构上就不多说了, 由于前文已说, 不讲项目内容, 没有实例也谈不上架构。
        
    2>. 合理注释和命名
        如果你觉得这个软件从此不再维护并且能够一气呵成, 恭喜你, 注释对你已成浮云。 "注释就是对代码的解释和说明。目的是为了让别人和自己很容易看懂。", 这是百科对编程代码注释的定义, 从接触编程开始就和注释打交道, 写注释是个习惯, 需要慢慢养成。 我有个朋友, 代码写的很棒, 就是不愿写注释, 他不写注释, 代码我就是不想看, 因此虽然我们在说话上很谈得来但从来没有合作过一个项目。如果在一个团队里, 不写注释的代码是令人无法忍受的。
        
        命名问题根据自己喜好, 作用也就不再啰嗦一遍了。
        
    3>. 模块化开发, 避免思维混乱
        不要同时打开多个模块的工作窗口, 把一个模块的功能彻底完善了再去实现另一个模块, 人类大脑即便可以"多线程", 但别忘了线程间的切换也是需要花费一定时间的。
        
    4>. 适当加班
        这一条可能要惹起争议, 不多说, 加班根据个人情况而定, 一个人的项目, 只能说加班是常事。
       

        
四、面对问题, 心态很重要
    如果一个项目, 在手里很顺利的就给解决掉了, 这个项目对你来说实际上又亏了一点, 因为他没有难度, 你只不过是在做你以前重复做的事情, 就像幼儿园时老师让我们写20遍 1 + 1 = 2, 到了五年级再让我们写1 + 1 = 2一样, 如果是这样的话, 这样项目带给你的只是一点经济上的收益, 对知识上收益却不大。
    
    遇到问题是好事, 起码说明利用这次项目又可以学习到新的知识。
    
    "没有解决不了的问题, 没有实现不了的功能。" 不管这句的真假, 但一定要抱着这种思想来解决问题, 官方的手册和搜索引擎是解决问题最好的帮手。 向别人提问那是次要的, 锻炼自己独立解决问题的能力才是真能力。
    
    遇到棘手的问题, 不要着急, 越急越没有头绪, 喝杯水躺下来休息会再思考, 很有可能在你躺下的那一会灵感就好了。 一定要事先准备好笔和纸, 灵感稍纵即逝, 打个哈欠的就很有可能导致把刚才的灵感给忘了。
    
   

五、做好优化、做好测试
    代码的优化是笔者经常忽略的一个问题, 并且常常找借口来忽略掉代码优化, 这类的借口通常是客户要的紧或者是优化不优化对效率的影响不大。 明知道可以优化的情况下不去优化这种行为称为什么好呢? 要想写出高质量的代码, 优化是个很重要的步骤, 希望读者引以为戒, 不要犯笔者这样的错误, 条件允许的情况下一定要回顾下代码看看哪里需要优化下。

    模块集成完毕后开始测试, 测试也是门很深的技术, 尤其是在软件较为复杂的情况下, 笔者没有深入研究过有关测试的内容, 所以不敢乱说, 怕一不小心就造成了误导, 那我就是罪人啊。
    
    测试最主要的是模拟用户的真实使用情况进行测试, 在第一个项目中由于对稳定性要求较高, 所以笔者就将软件随机导入好任务后让他自己跑了一天一夜, 结果还真出问题了, 白天一天运行正常, 夜里莫名抛出了个异常导致软件中止, 第二天笔者就感觉十分庆幸, 幸亏跑出问题了, 如果拿给用户后再出现这样的问题用户会怎么想? 软件挂掉的原因根据软件的日志也找到了, 是由于异常处理不到位导致的。
   

    
六、项目结束后应该做的
    写篇博客, 把心得总结出来, 分享给更多的朋友。
    


引用《黑客防线》上的一句话作为本篇的结束语: 程序员是值得尊敬的，程序员的双手是魔术师的双手，他们把枯燥无味的代码变成了丰富多彩的软件。

 

--------------------

wid, 2012.12.24