【论术】xx项目总结

为了进攻而防御，为了前进而后退，为了向正面而向侧面，为了走直路而走弯路，是许多事物在发展过程中所不可避免的现象。——《x国xxxx的战略问题》二十八画生

项目接近尾声，目前来看已无太大变动，索性做个总结，以此作为自己未来做事准绳。

日期：2025.5-至今

沟通方面：

开发工作以用户需求为先，但也须考虑实际情况

假设客户厌恶弹窗，则使用子页或者抽屉方式呈现，并且封装通用组件以便通用。

假设客户拒绝某种最佳实现，则可以考虑曲线救国的方式来实现，比如a方案实现不了，但使用b方案可以实现，

换方案不是目的，理解客户的本质需求并实现它才是应对之道，要让客户理解 虽然换了一种方式，但本质上依然是为了实现其核心目的，即目标不容置疑，但过程可以商榷

尽量贴近客户需求，但无理或者不可实现的需求也应明确提出，问题发现的越早越好

明确排期及规划，避免未来不必要的误解，并且明确告知客户以达成共识。人类往往厌恶未知，明确的排期及预计产出会显著缓解客户的焦虑情绪。

开发方面：

尽量避免直接使用原生ui组件或者第三方组件，如果时间充裕或多处使用，则应封装一层。

一来避免开发中期客户针对全局性的ui或组件进行修改时进行多处改动

二来可在组件基础上添加更多基于本项目的定制功能

三来封装完毕后，可在开发别的项目时复用，不用修改或者少量更改即可完成未来许多繁琐的功能(没想到前端也有一次开发多处运行的能力)

当前的业务场景大概就这么几种，如果封装够多，那留给未来针对陌生需求场景开发的时间也就更多，无形中会节省许多时间。

慎审AI的回答

多人协作时，务必写好自己的注释，过期的注释注意剔除，需要进行的修改要注意注释格式：年-月-日 ： 谁提出了哪些需求，须改动哪些数据

如不是在一个整体的组件模块内，在其他任何场景内杜绝使用inject/provide ，尤其是业务数据，避免开发一时爽，后期维护火葬场的惨剧(写下这一句时，昨天花两小时才重构完的笔者嘤了一下)

精密计算时须引入第三方库，js现有原生能力依然无法精确计算浮点数值，如有可能，尽量将计算逻辑封装在公共计算方法中。

封装组件时，注意避免强耦合问题，这里最大的感触是为了贪效率而在一个组件多处复用，最后举步维艰，苦是早晚要吃的，但是晚吃不如早吃

在需要对老组件进行增补参数时，注意要对之前的参数设置默认值以适配之前引用此组件的业务模块

业务组件与需求组件要尽量分离

明确每日要做的事情，如有紧急事项须向上反馈

开发之前要想一遍，开发完毕要注意总结复盘

注意防御性编程，确保问题不是出现在自己身上。

在开发大项目时尤其注意：不管是使用什么样的规范，整齐划一远远比优雅重要，一个项目的整体的规范比个体的独美更有战斗力

想说的都在没说的话里，愿能领会。

以上。