误区:认为编好程序,完成任务,即是好的程序员,无须文档;
缺乏文档,对软件开发是致命的,一方面是软件无追溯能力,无法找到软件开发的起源,思想;另一方面,则是为后续软件查错,软件升级带来麻烦。作为早期的程序员,技术文档占用的工作时间应该为30%,而高级程序员、系统架构师等则需更多的时间。一般的软件文档要求,本篇不多说,可以回顾入职前手头上的软件文档要求和样式。
作为一些国外知名软件公司,如微软、IBM、甲骨文等,都会对程序员开发的程序进行代码要求,代码的变量名要规范,关键代码段需要注释,注释格式统一,甚至嵌套中行缩进的长度和函数间的空行数字有明确的要求。
中国程序员,一般常会出现,全局变量滥用,注释语言表达不到位,变量名采用拼音等,虽不影响开发,但却影响了后续代码交接和分享工资。
误区:入门的程序员一般不会对项目的需求进行刨根问底的分析和询问需求人员,拿到文档,即开始进行开发;在B/S架构中,更经常出现前台需求与后台衔接的问题;
因此,在做需求的时候,我们应该做到,了解需求的详细要求,力争到位;加强沟通,了解需求深层次内容,特别是功能点要达到什么要求,怎么使用系统才觉得舒服。对需求的把握不能从感性角度理解,必须多和工作伙伴进行碰撞,才算是真正把握需求——经验。真正的需求把握得恰到好处,所需的是2-3年的时间。
每个程序员在开发一个功能模块或函数的时候,应该多思考,不要局限在完成当前任务的简单思路上,思考一下,该设计的模块能否脱离这个系统存在,是否能够通过最简单的修改方式在其他系统或应用环境直接引用。
通过这两年中的实践与观察,发现我们团队一些同事在起步阶段,经常经历代码重写的事情,是很没有必要的,一方面自己思想需重新确立,另一方面是浪费了提升代码质量的时间去做重构的事情。
软件研发一直以来有个好传统,软件开发过程中问题发现的越早,解决的代价就越低。测试工作实际上也不麻烦,一是做正常调用的测试,看软件的基本功能能否实现,这也是许多公司常见的,也是唯一的测试,但强调,这是错误的!二是异常调用的测试,例如在B/S体系下常用的压力测试、破坏性测试、频发异常请求处理测试等,只有全方位的掌握好测试办法,才能提高软件开发的质量。
日本经营之神松下幸之助曾说过:“工作就是不断发现问题、分析问题、最终解决问题的过程,晋升之门将永远为那些随时解决问题的人敞开着。”可见,工作过程中有问题是正常,没有问题才是真正的问题。在发生问题时,能勇于面对问题、解决问题的人,才是公司真正的骨干。
现实中,很多人总是千方百计回避问题。当上司安排一项艰巨的任务时,也想尽办法推托。殊不知,对于个人而言,问题其实是最好的学习机会。往往那些愿意接受困难工作的人,能力会越来越强,那就是因为他们在克服困难的过程中取得了巨大的进步。