Web开发者需具备的8个好习惯

 

 

 

想要做好软件开发并非易事，这里面还包含大量的功能需求、Bug报告以及用户反馈的内容都值得我们好好去摸索。也许有的时候你会收到有关需求的要点列表邮件（如果幸运的话），再好不过了，因为用户愿意花时间来给你写邮件反馈信息，尽管这些邮件有的并不是真的有用。

 

使用Bug追踪/项目管理解决方案，比如Basecamp（提供消息板，待办事宜，简单调度，协同写作，文件共享）或Trac，让你记录ticket（问题）或者不会遗漏重要事项。由用户（可以是同一个公司的使用人员）反映错误在哪，因为每一个订单，每一个提交的表单都有不同地方，当业务人员或者说最终用户给你说某个地方出现问题，你要追踪这个问题发生的位置。为什么出现这种情况，这次提交的ticket（问题）到底是因为哪里出现的，然后解决它。

 

你可以通过添加关键词（方便同事轻松找到），并添加一个优先级，前提是确保负责人能够“修复它”。在描述过程中，试图提供一个user story（用户故事）添加摘要，你还可以采用幽默的方式提交建议，但请确保ticket（问题）信息要清晰、明了。

 

 

要有精确性和针对性。你应该知道谁可以做什么，谁不可以做，也就是说分工要明确。当发生问题，直接找到该项目负责人，而不是一竿子打死一片人。

 

 

当问题修复后，应该把这问题的原因、处理结果记录下来，并且反馈给最终用户，告诉他们为什么出现这个问题，然后技术团队是怎么解决的。

 

 

 

与团队成员一起制定计划（通常称其为Scrum，敏捷），并在下次迭代中注明哪些是重要的，哪些不是。记住不要让开发者采用自己的个人战略。

 

 

很多个人或者团队会采用单独的实例，我的建议是请停止发布每个版本。

 

弄清楚这个实例是否在编写代码后才发布，（如果是个小团队）那么经常改变这个角色。为什么呢？这是因为每个人都能改变系统。即使你已经连续测试，最终还会有一些测试代码或填充内容被更改了。

 

 

 

  

创建特性团队，是指整个团队的工作特性，而不是“前端”或者“后端”。我第一次听到这个想法是从Budapest一名开发者获悉的。意思是：修复Bug，是每个团队成员的责任，而不是仅仅是为了修复自身负责的模块在那不停的返工。每个人都要准备好去修复别人的Bug，但是，显而易见，并非他们自己。拥有伟大的想法是构建伟大的软件前提。

 

 

  

有时，快速发布版本真的很重要，但是花时间来做功能测试是很有必要的。在电子商务平台不会因为有Bug而阻止你去测试，就像没有什么能够阻止愉快的周末来临一样。

 

底线：如果你在未经测试代码的情况下进行发布，那么你的计划是糟糕的，你会为此而感到头疼。

 

请记住：任务需求分析（（与客户交谈、部署、质量保证等））所占用的项目开发整体时间，只有三分之一。

 

 

永远思考如何优化你的应用程序，这一点很重要。总结起来主要有三点：

 

程序保持正常运作；

确保结果正确性/优美的；

运行效率更高。

遵循整个列表顺序，那么你将得到可持续的发展结果。记住，确保在正常运作且代码正确的情况下进行优化，而不是在代码进程堆中进行工作。