@evilStart #19

确实是反面案例，用以佐证我的观点：
自动化检测工具需要支持本地化运行，最好有 IDE 插件实时检测；如果只支持云端检查非常影响开发效率和体验。

@wu67 #13

你举的「逻辑写法」内容应该也能工具化规范化解决。

> 遍历数组都能写出 7 8 种写法
eslint-plugin-github 有 "Prefer for...of statement instead of Array.forEach" 规则。
https://github.com/github/eslint-plugin-github/blob/main/docs/rules/array-foreach.md

> 还有在非变异方法里面通过引用改变原数组值的
似乎 eslint 的 no-param-reassign 搞不定这种情况，要上 typescript 的 readonly T[]
https://eslint.org/docs/2.0.0/rules/no-param-reassign
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#improvements-for-readonlyarray-and-readonly-tuples

---

有些代码规范的工具化，需要引入新工具甚至新语言（ javascript → typescript ），成本不菲。
这就引申出进一步的问题：如何平衡代码规范和开发体验？

引入代码规范最好能循序渐进持续增强，切忌大破大立，很考验领导者的平衡艺术。

@ChefIsAwesome #11

> 可实际上，你问他们，怎么写出来不像屎一样的代码，他们根本不知道。
是的，这对很多团队来说属于 "unknown unknowns"。
即使感觉到了痛点，也总想走捷径，不愿意花精力去学习了解（就像我的巨子同学）。

> 只可惜“如何写好代码”，学校不教，面试不问，工作不查。
哈哈，我面试的最后一个问题都是「对于提高团队的整体代码质量，你有什么经验和心得？」。
进而引出对源代码检测、单元测试、code review 的讨论，判断他的技术追求和团队适性。

@l00t #7

你是说直接复制粘贴第三方源代码进项目的情况吧？

两种处理方式：
1. 所有第三方源代码文件置于一个特定目录，在工具里配置不检测这个目录的内容。

2. 粘贴复制后修改使其符合规范
2.1 粘贴复制 git commit -m 'Add a class for xxx, copied from https://xxx'
2.2 修改使符合规范 git commit -m 'refactor it to follow our code style'

@FrankHB #3

你的关注点已经是「规范的合理性」了，这通常是精英级团队才会考虑的问题。
精英团队完全可以自行裁剪组合甚至新建能符合自己团队项目情况的规范。

对于平均水平团队，初次引入「代码规范」的情况来说，有规范总比没有规范好。
不喜欢 google style 可以找找别的。

@jorneyr #4

> 规范定制容易，怎么执行才是核心。

非常同意。这也是我再三强调自动化工具及持续集成的原因。

员工可以就使用过程中的不便提意见，需要带明确的反对理由、业界实践、修改建议。
未被采纳前就要按现在规范严格执行。

@fengzl #1

已修正，谢谢提醒。

赞美 OP ！

建议：增加「 N 日最多感谢回复贴」的筛选功能
https://github.com/v2hot/v2hot.github.io/issues/5
---

很多时候回复贴比主贴价值更高，特别是感谢数很多的回帖。
但是现在 V2EX 原生的内容组织形式似乎没有办法挑选出来。

如果 v2hot 能实现这个功能就太好了。
或者简单一点，在 top 热帖里增加显示合计感谢数？

@ccc825 #35

> 主管迫于 kpi 对功能都是「先做出来能用」的态度
> 两个后端同事比较佛系坚决不加班，然后老板可能对进度不满意
现团队在组织管理（目标对齐、计划分解、进度管理、质量管理、团队凝聚力）上有严重缺陷且无法解决，难怪老板要空降大拿

> 感觉下边干活的觉得自己已经要被榨干了，老板认为产出不足
如果是我，会把这作为主要关注点，在和新 CTO 的 1on1 上具体细致地交流，判断自己是否能与他合拍，能否从中学到新技能。

我当初和空降领导面谈前准备的问题，供参考：
1 、x 总，您觉得我们部门存在的最严重的三个问题是什么？您的解决思路是什么？（了解对方施政纲要和工作方式）
2 、x 总，现阶段 a 、b 、c 几个问题比较严重，正好我去年做了 e 、f 、g 工作，希望在那基础上把这些问题也解决掉。（判断对方是否认可自己的成绩和努力方向）
3 、x 总，我最近在学习 xxx 技术，总感觉理解不够深入，您有什么建议吗？（评估对方技术水平和引领能力）

几乎清一色劝楼主提桶跑路，实在理解不了现在年轻人的思路……

建议：观察学习新 CTO 新团队的新思路新方法，对照着补强自己，自己强大才是王道。原因如下
1 、空降 CTO 还带团队，说明现团队肯定有（老板认为的）无法解决的严重缺陷，深度参与这一修正过程能大幅提高自己的阅历和能力；
2 、CTO 带团队过来说明领导力不错，说不定是个赏罚分明有口皆碑的人呢？
3 、CTO 的老团队也不过和他多共事几年，如果你们工作节奏很合拍，你也能加入他的圈子。
4 、即使立即跳槽去新公司，也免不了碰到资深同事是领导嫡系的情况，你又继续跳？

PS. 楼主给的信息不太充分，如果存在下列情况之一，当我没说。
1 、楼主本来就对公司（老板）严重不满，上班如上坟。
2 、CTO 整人立威，原团队苦不堪言。
3 、CTO 只会吹牛推诿，技术能力堪忧。
4 、楼主安于现状，拒绝变化。
5 、楼主本来对 CTO 角色虎视眈眈，现在严重挫败和失落，拒绝合作。

利益相关：曾经空降过，也曾经被空降过，我都持开放心态希望这一变化能把蛋糕做得更大。

对接的平台有成熟解决方案就直接用。
特别是抢券模块，预估好并发量，准备好机器，提前做好压力测试。

上个月合肥市发消费券，微信通道一上线连崩两天，第三天刷新页面上百次才抢到（美团通道倒是一切正常）。
怀疑又是层层转包给某个野鸡团队随便糊弄的。

同是不怎么会聊天（吹牛）的技术型 leader ，分享一下之前空降到新公司负责技术部门的经验。

部门内部相当简单，用你的技术实力征服他们：
1 、适当场合顺带提提自己的成功经验，给他们“这些场面老大都搞定过”的感觉，有人兜底心里不慌；
2 、结合公司、团队、个人情况，与每一个团队成员坦诚沟通，量身定制职业发展规划并在日常工作中落实（“我之前有个同事跟你很像，他做了 xxx 、xxx 、xxx ，现在 xxx 混的风生水起”）；
3 、不思进取摆烂混日子的人，果断 n+1 ，用事实和数据告诉老板和团队此人负贡献。

部门间勾心斗角互相甩锅的情况没办法避免，弯弯绕绕的办公室政治不是我们的专长。
我的策略是紧密跟随引荐我到这家公司的伯乐。
在任何组织里，站队是免不了的，选择一个相当知根知底的人，风险小一些。
外事不决就找他，他也通常能从更高的维度和更广的视角提供信息和建议。
当然这也带来一个风险，伯乐一旦靠边站，我也会很快凉凉。

“我就截取了一个 json 里面的几个参数，表示是相加得出来的” -> 没有接口文档或 swagger
“我维护了几百个微服务” -> 运维小伙出身？还是一个接口部署一个微服务？没读出来有啥技术含量的

“经常对他的方案表示质疑，对外处理问题也还是以前的路子，习惯了” -> 有人能忍你不表示所有人都会忍你
“然后他就说会议室聊会，我就去了，然后他就一直说了很多很难听的话” -> 在没找好替补前就说这么直白，这个 leader 也够憨直的

从技术能力和协作沟通两方面看，当事双方都是半斤八两，正好针尖对麦芒了。

感觉楼主的团队很有一些故步自封的腐烂气息，不妨趁这次机会跳出舒适区看看外面的世界。
在技术圈里，“能力越强的人越谦逊”大概率是对的。

分享一篇关于站立会议的的文章，非常全面的分析了站立会议的形式、意义、最佳实践和常见问题。
楼主有兴趣可以研究学习一下，不过是英文版。
https://www.martinfowler.com/articles/itsNotJustStandingUp.html

如果发现站立会议流于形式，没发生正面作用，可能有两方面原因：
1. 团队荣誉感 /自治性不足，主观上不愿意作为团队的一部分去共同实现一个有意义的目标；
2. 团队成员职业能力有短板，客观上无法理解团队目标，达成团队协作，阐述团队及个人的工作内容和价值。

两者都是站立会议可以轻松暴露的问题，但需要在站立会议之外解决。

不管是给自己部门招人面试还是帮其它部门交叉面试，我都会先看过《应聘登记表》上的期望薪资再接触候选人。

因为期望薪资体现了候选人对自己工作能力的认知；
我也要根据这一价位选取合适的交流主题，判断其能力是否符合公司对该 level 员工的期望。

只有双方对能力及薪资的认知大体一致，后面才能有合作的可能。

> 1.收到您的简历后，如果符合要求，我们会通过邮件与您联系第一轮 coding test 。
> 2.您有两天时间完成 coding test 。通过之后 HR 会邀请您进行一次非技术面试，以了解您的更多信息，如薪资期待等 。

本来想要试试的，被这面试流程劝退了……
公司情况、团队情况、发展规划、工作要求都不先聊聊，候选人怎么知道和企业的匹配度如何，是否值得花几天时间去做 coding test ？

> 由于每日收到邮件较多，无法一一回复，希望大家见谅

据信标准模板都懒得抄一下，太过于傲慢了。
接触过的北美本土 startups 都会「礼貌婉拒」。如果再去信想要了解不匹配的地方，大多也会简单说几点。

1 、靠谱的产品策划 /行业布局
2 、兼容互补、互相欣赏、逐渐信赖的合作伙伴
3 、突破当前职业天花板的机会 + 合适的股权期权
4 、能让团队存活一年以上的现金
5 、能保持体面生活的月薪

「政务类项目+销售型老板」的通病……

在我看来这不应该是「工作优先级」的问题，而是「项目管理如何平衡“功能范围 & 时间 & 质量”」的问题。

如果老板逻辑还算清晰，能尊重技术的话，建议准备好充分的素材后与其做一次坦诚深入的沟通，从你的视角提供几个解决方案让老板选。举个例子：
技术团队上一个月同时维护 x 个项目，共发布 y 个版本，总计 z 个用户故事；
以同行业同地域平均水平而论，需要 xx 个团队成员 yy 人日完成；
但由于现在仅有 4 人，导致加班严重，交付质量严重下降，共出现 xxx 个缺陷，其中 yyy 个是生产环境严重级 bug ；
目前团队修 bug 和开发新功能的时间比大概在 x:y，参照前几个月工作产出估算，接下来四周最多能完成 z 个用户故事；
解决方案 1: 缩减功能范围，专注开发 a 、b 、c 几个核心功能，其余低优先级项目 /功能由商务挡住；
解决方案 2: 延长开发周期，下两周开发 a 、b 功能，再下两周开发 c 、d 功能，……总计开发周期预估为 x 个月；
解决方案 3: 降低产品质量，所有功能均做最小化开发与测试，商务验收后再长期救火不足部分与线上 bug ；
长期解决方案：补充团队成员至与项目规模匹配的数目，但要说明新人上手需要一个月，稳定输出需要两三个月，对近期项目没有帮助，甚至帮助新人融入还会降低老员工的工作效率（没有银弹！）。

如果老板不讲理的话，那就真的只能六字真言了。

> 我们公司同个部门的好几个同事

多个成员存在这样的问题，说明这是团队（负责人）的问题，而不是孤立的某几个人的问题。

如果要从团队层面系统地解决这个问题，推荐两个实践：
1 ）引入压力测试 /性能优化，对于数据量千万级以下的传统应用，要求单机支持 1k+ tps 、100- ms latency，可以在设计 /开发 /测试环境快速识别性能瓶颈，避免低质量的设计和开发；
2 ）引入 Application Performance Monitoring 工具，数字化直观展现应用在生产环境的性能瓶颈，将慢操作视为高优先级技术债务，对应的产品有 SkyWalking 、New Relic 等等。

通过建立体系化的开发流程，即使新的工程师加入时没有相关的经验和意识，处理几次相关问题后也能逐渐适应和融入。
当然，这对团队负责人的技术能力和管理能力要求就比较高了。
如果楼主部门领导不具备这种能力，楼主描述的问题必然会反复出现。