架构
技术决策是否合理、瓶颈在哪里、能否承受业务增长。
我们按标准评估,而不是凭喜好:可扩展性、可维护性、安全性,以及对特定人员的依赖程度。
技术决策是否合理、瓶颈在哪里、能否承受业务增长。
可读性、测试覆盖率、重复代码,以及是否有文档。
过时与已停止维护的库,以及存在已知漏洞的组件。
已经积累了多少,修复要花多少钱。
换一支团队能否接手,还是知识只存在于某一位开发者的脑子里。
风险评估与改进建议,用非技术人员也能读懂的语言写成。
中等规模项目的审计,含访谈与报告编制,需要两到三周。
为什么要做审计:并购、换承包商还是评估风险。重点由此确定。
获取代码、文档与基础设施权限,并访谈团队成员。
按既定标准逐项核查,记录发现及其后果。
含风险、优先级与整改成本估算的报告。
我们发现的最大风险不是代码写得差,而是对某一个人的依赖。系统写得中规中矩没关系,但如果只有一位开发者看得懂、又没有文档,公司就被绑架了。这一项我们会与技术质量分开评估。
有,这正是最常见的委托原因之一。审计给出独立结论:做了什么、处于什么状态、接手要花多少钱。有了这份文件,与原承包商和新承包商的谈判都能落到实处。
审计不是追责。我们描述的是系统状态与风险,而不是评价个人。结论往往还能帮到团队:开发者早就提过的问题,终于得到了独立确认。
我们会直说,并给出依据以及两种方案的评估:继续改造还是推倒重写。决定权在贵司,但最好基于数据而不是感觉。
申请已受理
我们已经收到。我们会在一个工作日内回复,紧急问题将立即安排值班工程师处理。
未找到该城市,请检查拼写。