shot

@nnegier #218

县城高中老师的利：
1. 出身教师家庭，熟悉和喜欢校园环境
2. 能传播知识和见解，满足自己好为人师的习惯倾向
3. 生活安逸，可能有充分业余时间继续发展爱好
4. 在当地能形成一点人脉，也许能照顾大家庭

县城高中老师的弊：
1. 年复一年作固定知识的简单重复，无法满足求知欲和事业心
2. 八线县城，交际面很难获得思想共鸣和新事物的冲击
3. 体制僵化，外行领导内行，大学里都不能教授治校，何况高中
4. 天花板低，要获得职业突破免不了挤去一线城市或者省会城市，但是回去了再想出来更难

我应该会尝试做一个高中老师。

10 年前在国企煎熬的很多个不眠夜里，我就非常严肃地思考了回高中母校教书的可行性和利弊。

不过后来投身「自由职业者」后就不再有这方面的烦恼了，哈哈。

@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 可以找找别的。