Web 项目经验总结
开发流程
一个产品团队里面主要有如下几种角色。
1.产品经理(PM):规划要做的功能,整理需求,跟进设计和开发的进度,最后验收。
2.设计师:根据需求设计 Web 交互效果,与 PM 和工程师讨论并修改设计。
3.工程师(Web 开发):设计未完成前可以做一些前提准备,等设计图出来之后,工程师按照敲定的设计实现对应的页面效果和后端逻辑。
4.测试:在开发基本结束的时候介入,验证功能。但并不是所有团队都有测试这个角色。
5.运营:负责日常网站的维护,反馈问题,也会提需求。
以下是笔者在开发中总结的一些经验,这里分享给大家。
确定需求后再做。 很多人一拿到需求,就开始先入为主地按自己的理解去做,最后的结果往往比较尴尬。笔者建议拿到需求后不要马上开始写代码,而是不断地找需求方确认,以确保对需求充分理解。
先验证那些可能实现不了的想法。 拿到需求应该先做整体规划,先验证那些可能实现不了的想法,然后再去做那些只要花时间就能完成的开发工作。
优先级管理。 工程师大多有完美主义情结,但是往往任务紧事情多,一定要分清优先级,对于手头的事情有整体的把控。尤其是上升期的产品,往往新增任务的速度大于处理速度,这时候就要缓一缓,如果一件事很急,需求方会不断向你询问进度。一定要明确事情的优先级,否则就把优先级不明确的事情放一放。笔者的经验是有相当一部分需求其实是需求方临时想起来的,很快在后来在考虑中发现漏洞而自己主动放弃了。
及时反馈。 不要等到事情做完的时候才反馈。整个开发过程都应该是交互的、不断迭代的工程,及时获得反馈让自己不会走得太偏,也能让需求方不断了解进展情况,甚至能给开发者提供一些额外的帮助。假如由于未预期的问题或者其他外因造成不能按期完成,最好在离约定的时间半程之前反馈。
合理的项目人员配比。 一般而言,实现一个小功能,一个设计师加一个工程师足矣,甚至不需要设计师;而对于比较大的项目,则需要一到两个设计师加两三个工程师。
尽量不要发太大的 PR。 把安排的任务分解为功能逐个提交 PR,通常同时进行多个功能的开发,不推荐一次性提交大量代码。这会给做代码评审的同事带来负担,代码评审持续时间更长且效果会受到影响。和其他同事一起合作完成项目,非常容易出现代码冲突,以致后期需要花费大量时间和精力处理冲突。
使用合理的项目结构
无论是从零开始做一个新的项目还是对现有的架构进行优化,都是有一定的原则可遵循的。首先是项目的结构应该保持简单,有以下原则:
1.层次不可太深,否则会造成代码分散,业务代码维护不方便。建议目录深度不超过 4 级。
2.层次也不能太平,否则造成模块/目录数量太多、太臃肿。尽量使用目录代替模块文件的方式。
3.善用蓝图(Blueprint)。把应用分解为一个蓝图的集合,可以方便地对这个蓝图注册或者注释,达到良好的可扩展性。
4.大型网站不是一天设计出来,项目结构也不是一蹴而就的,在业务发展的进程中需要不间断地进行代码结构的重构工作。
关注代码复杂度
mccabe 内置于 Flake8 中,旨在检查代码复杂度。它是循环复杂度(https://en.wikipedia.org/wiki/Cyclomatic_complexity )的 Python 实现,它认为若一个模块的循环复杂度超过 10,就需要对其进行拆分。可以对项目的代码复杂度指标进行考核。
Flake8 中默认设置的复杂度检查阈值是-1,需要设置成大于 0 的值才可以启用复杂度检查:
> flake8 --max-complexity 3 chapter3/section7/app.py chapter3/section7/app.py: 262:1:C901 'index' is too complex (4) chapter3/section7/app.py: 321:1:C901 'preview' is too complex (4) > flake8 --max-complexity 10 chapter3/section7/app.py
阈值的大小和业务复杂度、代码质量、历史遗留等因素有关,不同项目可以使用不同的阈值,但是复杂度越高、开发和维护的成本也就越高,所以阈值不宜太大。
一个函数或者一个类代码不应该过长,建议不超过显示器一屏。如果太长就应该拆分。
一个代码文件的总行数(包含空行,注释行等)也不应该过长,尤其用堆代码的方式会使代码文件越来越长。建议单文件不超过 2000 行,否则也应该做拆分。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论