shot 最近的时间轴更新
shot

shot

V2EX 第 91223 号会员,加入于 2015-01-11 21:06:11 +08:00
为团队引入「代码规范」的建议与心得
  •  3   
    程序员  •  shot  •  56 天前  •  最后回复来自 Jero
    31
    写一份让人眼前一亮的技术人简历
  •  3   
    职场话题  •  shot  •  291 天前  •  最后回复来自 mdyh
    36
    远程工作小贴士 No. 1: 请关注企业信息安全
    职场话题  •  shot  •  2020-02-08 11:00:35 AM  •  最后回复来自 shot
    6
    “在线工作平台”项目 - 诚邀投资人与联合创始人
  •  1   
    创业组队  •  shot  •  2017-09-08 22:47:12 PM  •  最后回复来自 shot
    8
    [自由职业者] 被 Upwork 坑了 30 刀,怒!
    分享发现  •  shot  •  2016-01-29 00:54:48 AM  •  最后回复来自 shot
    9
    [bug] 发帖时间在主题列表页面显示错误
    反馈  •  shot  •  2015-02-08 22:01:30 PM  •  最后回复来自 shot
    2
    shot 最近回复了
    @nnegier #218

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

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

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

    不过后来投身「自由职业者」后就不再有这方面的烦恼了,哈哈。
    56 天前
    回复了 shot 创建的主题 程序员 为团队引入「代码规范」的建议与心得
    @evilStart #19

    确实是反面案例,用以佐证我的观点:
    自动化检测工具需要支持本地化运行,最好有 IDE 插件实时检测;如果只支持云端检查非常影响开发效率和体验。
    56 天前
    回复了 shot 创建的主题 程序员 为团队引入「代码规范」的建议与心得
    @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 ),成本不菲。
    这就引申出进一步的问题:如何平衡代码规范和开发体验?

    引入代码规范最好能循序渐进持续增强,切忌大破大立,很考验领导者的平衡艺术。
    56 天前
    回复了 shot 创建的主题 程序员 为团队引入「代码规范」的建议与心得
    @ChefIsAwesome #11

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

    > 只可惜“如何写好代码”,学校不教,面试不问,工作不查。
    哈哈,我面试的最后一个问题都是「对于提高团队的整体代码质量,你有什么经验和心得?」。
    进而引出对源代码检测、单元测试、code review 的讨论,判断他的技术追求和团队适性。
    56 天前
    回复了 shot 创建的主题 程序员 为团队引入「代码规范」的建议与心得
    @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'
    56 天前
    回复了 shot 创建的主题 程序员 为团队引入「代码规范」的建议与心得
    @FrankHB #3

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

    对于平均水平团队,初次引入「代码规范」的情况来说,有规范总比没有规范好。
    不喜欢 google style 可以找找别的。
    56 天前
    回复了 shot 创建的主题 程序员 为团队引入「代码规范」的建议与心得
    @jorneyr #4

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

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

    员工可以就使用过程中的不便提意见,需要带明确的反对理由、业界实践、修改建议。
    未被采纳前就要按现在规范严格执行。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2347 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 00:39 · PVG 08:39 · LAX 17:39 · JFK 20:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.