[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-lightweight-code-review-en":3,"blog-adjacent-lightweight-code-review-en":27,"blog-related-lightweight-code-review-en":64},{"id":4,"slug":5,"title":6,"excerpt":7,"content":8,"cover":9,"tone":10,"author":11,"publishedAt":12,"updatedAt":12,"readingMinutes":13,"featured":14,"tags":15,"category":19,"seoSettings":26},41,"lightweight-code-review","Making Code Review Work in a Small Team","Review is not fault-finding. It is making sure a second person understands a change before it merges.","\u003Cp>For years only a handful of us wrote code and almost nothing was reviewed; whoever finished merged. Then one database field change broke three modules and a client found it first.\u003C\u002Fp>\n\u003Ch2>A lightweight process\u003C\u002Fh2>\n\u003Cp>All changes go through a branch and need one colleague's approval before merging. Even ten minutes counts.\u003C\u002Fp>\n\u003Cp>Focus on three things: edge cases, error handling and impact on existing features. Formatting belongs to tooling.\u003C\u002Fp>\n\u003Cp>Split any change above four hundred lines. Review quality drops sharply with size.\u003C\u002Fp>\n\u003Ch2>Two habits\u003C\u002Fh2>\n\u003Cp>Write why the change exists, not just what changed. Three months later the motivation matters more than the diff.\u003C\u002Fp>\n\u003Cp>Phrase comments as questions, such as 'what happens under concurrency here'. It lands better than a verdict.\u003C\u002Fp>\n\u003Cp>Review costs twenty minutes a day and saves a late-night rollback. That trade works in any team.\u003C\u002Fp>","","blue","佳益方圆团队","2026-06-07T12:23:00+08:00",1,false,[16,17,18],"Code Review","Team","Engineering",{"id":13,"parentId":20,"slug":21,"name":18,"description":22,"icon":23,"cover":9,"tone":10,"kind":24,"sortOrder":25,"count":20},0,"engineering","Hands-on engineering practices in architecture, performance optimization, AI integration and cross-platform delivery from our R and D team.","cpu","article",60,{},{"previous":28,"next":46},{"id":29,"slug":30,"title":31,"excerpt":32,"content":9,"cover":9,"tone":33,"author":11,"publishedAt":34,"updatedAt":34,"readingMinutes":13,"featured":14,"tags":35,"category":39},20,"after-learning-to-say-no","After We Learned to Say No","Declining the wrong work looks like a loss now and returns time to what matters later.","teal","2026-06-09T11:10:00+08:00",[36,37,38],"Startup","Decisions","Boundaries",{"id":40,"parentId":20,"slug":41,"name":42,"description":43,"icon":44,"cover":9,"tone":10,"kind":24,"sortOrder":45,"count":20},6,"founder-notes","Founder Notes","Reflections from the founding team on business, management and product, documenting the growth of a software company.","pen-tool",10,{"id":47,"slug":48,"title":49,"excerpt":50,"content":9,"cover":9,"tone":51,"author":11,"publishedAt":52,"updatedAt":52,"readingMinutes":13,"featured":14,"tags":53,"category":57},61,"requirement-priority","Prioritisation: The Loudest Voice Is Not the Most Important","Priority should follow reach and criticality, not the seniority of whoever asks.","indigo","2026-06-05T12:23:00+08:00",[54,55,56],"Requirements","Prioritisation","Delivery",{"id":58,"parentId":20,"slug":59,"name":60,"description":61,"icon":62,"cover":9,"tone":10,"kind":24,"sortOrder":63,"count":20},2,"product-thinking","Product Thinking","Requirement analysis, user experience and product design methods, plus the thinking from business problems to product solutions.","lightbulb",50,[65,76,87],{"id":66,"slug":67,"title":68,"excerpt":69,"content":9,"cover":9,"tone":70,"author":11,"publishedAt":71,"updatedAt":71,"readingMinutes":13,"featured":14,"tags":72,"category":75},30,"integration-api-pitfalls","Five Traps in Enterprise System Integration","However complete the API documentation is, integration usually stalls on field semantics, timeouts and repeated pushes.","cyan","2026-10-17T09:00:00+08:00",[73,74,18],"Integration","APIs",{"id":13,"parentId":20,"slug":21,"name":18,"description":22,"icon":23,"cover":9,"tone":10,"kind":24,"sortOrder":25,"count":20},{"id":13,"slug":77,"title":78,"excerpt":79,"content":9,"cover":9,"tone":70,"author":11,"publishedAt":80,"updatedAt":81,"readingMinutes":58,"featured":82,"tags":83,"category":86},"why-enterprise-systems-age","Why Enterprise Systems Start to Age After Three Years","A system can pass acceptance with every feature checked, then feel awkward three years later. The problem is rarely the code — it is the changes that were never considered at delivery.","2026-10-16T09:30:00+08:00","2026-10-18T15:58:14.648+08:00",true,[84,85],"System Evolution","Architecture",{"id":13,"parentId":20,"slug":21,"name":18,"description":22,"icon":23,"cover":9,"tone":10,"kind":24,"sortOrder":25,"count":20},{"id":88,"slug":89,"title":90,"excerpt":91,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":92,"updatedAt":92,"readingMinutes":13,"featured":14,"tags":93,"category":97},31,"idempotent-design-basics","Idempotency: Duplicate Submissions Are Not Just Double Clicks","Retries, redelivery and impatient users all send the same request more than once. Idempotency belongs in the API design.","2026-10-05T10:13:00+08:00",[94,95,96],"API Design","Idempotency","Reliability",{"id":13,"parentId":20,"slug":21,"name":18,"description":22,"icon":23,"cover":9,"tone":10,"kind":24,"sortOrder":25,"count":20}]