I'm not technical. Can I work with iDev?

Absolutely. Most of our clients are non-technical. Just tell us what you want the end result to look like — we handle all the technical details.

How much does it cost to hire iDev?

We quote individually based on project scope and complexity. Initial consultation is completely free — we give you a clear quote after understanding your needs. No fit, no charge.

How big is the iDev team?

A few core members, each capable of delivering full-stack independently. We flexibly assign people based on project scale and can run multiple projects simultaneously.

What happens after project delivery?

We provide complete code and documentation at handover. For ongoing feature development or maintenance, we offer monthly or per-project arrangements. Most clients choose long-term collaboration.

What if I'm not satisfied with the project midway?

We confirm with you at every stage before moving forward. If the direction is off, we adjust immediately. If it truly can't continue, completed work is settled normally and all code is yours.

我完全不懂技术，能合作吗？

当然可以。我们的大部分客户都不是技术背景。你只需要告诉我们你想要什么效果，技术实现的事情完全由我们来处理。

费用大概是多少？

根据项目复杂度和功能范围单独报价。初次沟通完全免费，我们会在了解需求后给出明确报价，合适再开始，不合适不收费。

团队有几个人？

核心团队几个人，都是能独立交付的全栈开发者。根据项目规模灵活安排人手，可以同时推进多个项目，不用等排期。

项目做完以后怎么维护？

交付时会提供完整的代码和文档。后续如果需要功能迭代或维护，可以按月或按次合作。大部分客户选择了长期合作。

做到一半不满意怎么办？

每个阶段交付前都会和你确认。如果方向不对，我们及时调整。如果实在无法继续，已完成的部分正常结算，代码归你。

代码审查清单：我们团队 Code Review 都看什么

Code Review Checklist: What Our Team Actually Looks For

| Alex | 2026-09-01T20:38:14

Code Review 是提升代码质量最有效的手段，但如果没有明确的标准就容易变成走过场。分享一下我们团队的 Code Review 清单。

Code review is the most effective quality gate, but without clear standards it becomes a rubber stamp. Sharing our team's review checklist.

我们团队推行 Code Review 有两年了，一开始大家不知道该看什么，经常就是点个 Approve 就过了。后来整理了一份检查清单，Review 的质量才慢慢提上来。必查项 1. 安全性 SQL 拼接有没有注入风险？是否使用了参数化查询？用户输入有没有做过滤和转义？敏感信息有没有出现在日志、注释或前端返回值里？接口权限控制对不对？ 2. 正确性边界条件处理了吗？空值、空列表、最大值？并发场景考虑了吗？多线程安全？异常处理合理吗？有没有吞异常？事务边界正确吗？ 3. 性能有没有循环里查数据库的 N+1 问题？大数据量场景考虑了吗？分页、限流？缓存用合理吗？会不会有缓存穿透/击穿？建议项 4. 可读性变量命名是否清晰表达了含义？方法是否过长？（超过 50 行建议拆分）逻辑是否过于复杂？（嵌套超过 3 层考虑重构） 5. 可维护性有没有硬编码的魔法数字？配置是否外部化了？新加的代码是否和已有代码风格一致？ Review 的态度最重要的一条：Review 不是找茬，是一起学习。评论要具体、建设性，比如： ❌ "这段代码写得不好" ✅ "这里用 Stream API 可以简化，而且避免了中间变量" 对于风格偏好类的分歧（比如用不用 var、方法链式调用拆不拆行），统一用 linter 规则解决，不要在 Review 里争论。

After two years of code review practice, sharing our team's evolved checklist. Must-Check Security: SQL injection, input sanitization, sensitive data exposure, authorization Correctness: boundary conditions, concurrency, exception handling, transactions Performance: N+1 queries, pagination for large datasets, cache usage Recommended Readability (naming, method length, nesting depth) and maintainability (magic numbers, externalized config, code style consistency). Key principle: Reviews are collaborative learning, not fault-finding. Use specific, constructive comments. Style debates belong in linter rules.

← Back to News