Python语言项目总结 第2页

                
                对于笔者这个项目客户说让我设计就行, 于是笔者使用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一样, 如果是这样的话, 这样项目带给你的只是一点经济上的收益, 对知识上收益却不大。
   
    遇到问题是好事, 起码说明利用这次项目又可以学习到新的知识。
   
    "没有解决不了的问题, 没有实现不了的功能。" 不管这句的真假, 但一定要抱着这种思想来解决问题, 官方的手册和搜索引擎是解决问题最好的帮手。 向别人提问那是次要的, 锻炼自己独立解决问题的能力才是真能力。
   
    遇到棘手的问题, 不要着急, 越急越没有头绪, 喝杯水躺下来休息会再思考, 很有可能在你躺下的那一会灵感就好了。 一定要事先准备好笔和纸, 灵感稍纵即逝, 打个哈欠的就很有可能导致把刚才的灵感给忘了。
    
   
五、做好优化、做好测试
    代码的优化是笔者经常忽略的一个问题, 并且常常找借口来忽略掉代码优化, 这类的借口通常是客户要的紧或者是优化不优化对效率的影响不大。 明知道可以优化的情况下不去优化这种行为称为什么好呢? 要想写出高质量的代码, 优化是个很重要的步骤, 希望读者引以为戒, 不要犯笔者这样的错误, 条件允许的情况下一定要回顾下代码看看哪里需要优化下。

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


   
六、项目结束后应该做的
    写篇博客, 把心得总结出来, 分享给更多的朋友。
   
引用《黑客防线》上的一句话作为本篇的结束语: 程序员是值得尊敬的,程序员的双手是魔术师的双手,他们把枯燥无味的代码变成了丰富多彩的软件。

上一页  [1] [2] 

  • 上一篇文章:
  • 下一篇文章:
  • Copyright © 2007-2012 www.chuibin.com 六维论文网 版权所有