这些讨论实在是太无聊了, 继续来开不同话题, 讨论点有内涵的东西不是比较有意思吗? 这篇来讲讲怎麽进入一个陌生专案,所谓的陌生专案有很多种形式, 但不管什麽形式, 这里的前提都是 source code 还在, source code 都不见的逆向模式特别复杂, 这里先不论. 以下我把专案形式概略分为四类: 1. 弃婴型: 所有以前的开发者已经不可考了, 目前无人主力维护 2. 孤岛型: 专案本身跟其他专案连结性不高, 本来就已经有1-2人在主力维护. 3. 协作型: 专案本身有跟其他专案连结, 且各专案(包括当前专案)都有人维护. 4. 跳岛型: 专案本身有跟其他专案连结, 但其他专案没有固定人员维护, 可能就3-4人维护多个专案, 要不断切换专案. 然後进入专案的身分我们先假设是一个工程师, (主管角度的有机会在写) ------------------------------- 一个工程师进入专案时, 有以下几件事情会建议要列表确认: (这里的确认不是筛选, 我们假设你就是要做这件事情) (反过来说如果你是 code manager , 这些也应该写成 getting start SOP) 1. 有哪些 repo / 使用的版本控制工具(虽然这年头应该都是 git) 2. 测试环境的 setup 跟准备, 了解测试环境共用的情况, 自己的行为会对别人产生什麽影响(反之亦然). 3. 有无特殊 commit log 要求或格式 4. 有无特殊的 coding guide , 命名规则/程式码惯例要求...etc 5. issue 使用什麽方式追踪纪录 (issue tracker) 6. 如果对任务有疑问时, 有谁可以解释需求问题. (requirement manager) 7. 如果对任务有进度时, 应该要跟谁回报/形式为何 (通常跟5有关,但有些地方会有特殊要求, 所以单列一项) 8. 如果对既有的程式逻辑有疑问时, 有谁可以讨论惯例 (coding mentor) 9. 团队习惯的沟通工具, 每个人习惯的沟通频率(重要). 进入一个专案, 越快越好的抓紧上面的这些事情, 能大幅的增加融入的情况, 这种时候不要怕烦别人, 新人是少数烦别人别人不会靠北你的时期. -------------------------- 底下几种类型的专案分别论述: 1. 弃婴型: 所有以前的开发者已经不可考了, 目前无人主力维护 这种类型的专案, 对你来说最重要的 key man 就是 requirement manager. 我们大部分的工作都是在把程式码跟需求提供者的描述对照, 并且能力范围内去确保他是有可读性的. 有时候会碰到出现需求提供者没讲到, 但程式码有的判断跟逻辑, 这时候要复述几次程式逻辑所想表达的意思, 跟需求提供者确认是否有任何一丁点可能是什麽东西. 如果真的找不到原因, 可以反过来确认如果修改他会发生什麽影响, 请需求提供者确认这样的影响是不是预期的. (损害控管) 如果两层确认後都非预期, 那就改吧. 一个专案越多不敢改的东西, 控制力就越低. 这种情况通常不用负责处理团队政治, 话语权也会比较高, 要作的就是谨慎的放手去做, 该大胆就大胆, 但就是确定自己有掌握状况. 这个状态时要特别留意文件的撰写, 因为不会有其他人帮你记得惯例跟程式码文化. 写文件是给自己看的. 2. 孤岛型: 专案本身跟其他专案连结性不高, 本来就已经有1-2人在主力维护. 这种时候要留意的是原本的主力对需求的掌握程度为何, 是能充分承接跟满足, 这种时候当然就先观望, 衔接他们的工作分配. 如果原本的主力就已经是火烧屁股的状态, 这种时候则应找他们讨论, 看是划定自己的责任区, 大家各自分工, 以利团队稳定, 还是他们还有余力带着自己衔接工作分配. 另外在这种情况, 除非你有划定自己的责任区, 不然要作程式码文化或惯例调整时, 必须找到原本的 keyman 说服. 总之, 留意团队默契, 这种时候其他 1-2 人的话语权相对高很多, 而你只是个新人, 除非真的有足够的实力, 让其他人让位听你说,不然没有必要硬坦. 这种时候可以不用太积极写文件, 因为你写出来的文件对团队贡献度也有限. 3. 协作型: 专案本身有跟其他专案连结, 且各专案(包括当前专案)都有人维护. 基本上是 2 的扩大版, 现实生活中正常软体公司都处於这个位置居多, 通常跨专案会有 1-2 个人会负责跨专案协调, 这些人是地下(或实质)架构师, 融入体系时要留意这些人跟专案资深成员的关系. 以国内的风土民情通常是关系不会好到哪去, 因为架构师的工作往往是比较惹人嫌的. (看到他们出面就表示有新的工作了) XD 而且圈内正常合格能作跨组协调的架构师没那麽多, 这是复杂一点的技术管理工作. 如果关系不好, 那就要把视线放在留意目前专案资深成员在意的点, 通常是当前专案的敏感点, 有些专案都有自己的[强假设], 再跟架构师关系不好的前提下, 这些强假设会特别敏感. 如果跟架构师关系很好的话, 那就把视线放在架构师的指示上. 这种团队的方针, 因为上面反正横竖都有人, 自己的工作是消化 task, 直到自己变成能主导够大责任区的 senior. 文件的处理在这个状态也相对不重要. 4. 跳岛型: 专案本身有跟其他专案连结, 但其他专案没有固定人员维护, 可能就3-4人维护多个专案, 要不断切换专案. 这种情况略为棘手一点, 正常这种情况 mentor 会帮你安排, 因为如果 mentor 不特别安排期待的话, 这种专案基本上是新人坟场. (新人最忌讳的就是没有稳定专案, 没有明确需求, 没有明确范围) 多数人在这种状态时, 会急着想找个专案开主堡开始生兵, 但如果是我的话, 我会各专案先理解彼此之间的关系, 看哪些专案是敏感(或不敏感的), 看自己的风险属性, 决定自己要对哪些专案特别热情, 慢慢的你就会发现自己往那个专案移动. 但如果这个过程中又出现砸下新的专案的情况, 这种时候请毫不犹豫的离职, 组织一定是出了大问题. 另外, 这种时候也要多 focus 在文件的撰写, again, 文件是写给自己看的. -------------------------- 基本上在专案融入的过程有几个常见的困难: 1. 听不懂团队内术语或行话, 最可怕的不是完全听不懂, 而是同样的话听在你耳里跟听在团队成员是不同意思. 2. 看不清楚权力分配, 导致对所有指令照单全收, 结果作错. (如果团队有人过度热心/白目时会发生这种惨案) 3. 没弄懂大家合作的方式跟默契, 导致把其他环境搞烂 4. 写出跟团队惯例或程式码文化不一致的东西或作法. (要你用 util 挖个碉堡, 自己用土锹挖了个地下城. 我在别人身上碰过这种情况, 我後来负责收尾......花了很多力气.) 5. 有时候团队本来跨 team 分工默契就烂等着在找战犯, 结果你一去就撞在大家的敏感点上, 变成别人攻击你团队的破口或代罪羔羊, 这就有点衰. ------------------------- 这篇写的东西算是入门时一些要留意的事情, 其实工作时最重要的特色就是不白目, 要白目就得要有足够武力. 如果有兴趣拉深细节, 可以再推文讨论, 我们再来根据具体情况追进. -- I have a dream, it's silly but beautiful. --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.167.67.203 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1598061274.A.6E3.html ※ 编辑: TonyQ (118.167.67.203 台湾), 08/22/2020 09:56:40 ※ 编辑: TonyQ (118.167.67.203 台湾), 08/22/2020 09:58:06 我想起十年前我们还在游说大家开始使用 svn ，不要使用 zip 的年代。 表面上看起来 svn 是进步，但隔了几年， 有些人反而卡在 svn 进不了 git 。 有些人当时鼓励团队转 hg ，不过没几年 git 大一统 hg 整个淡出，从我的立场是没什麽标准可言，只有能不能用。 ※ 编辑: TonyQ (114.137.216.211 台湾), 08/22/2020 10:55:45 有些地方啦(擦汗) ※ 编辑: TonyQ (118.167.67.203 台湾), 08/22/2020 13:25:47 某专案，聘用新人，新人来觉得原本的人写的太烂了。 跟主管说要重写，主管本身偏 pm ， 没有该技术专业，但同意原本的结构不良。 於是同意他自己重写，中间没设 check point ，也没定期 merge 回来。 旁边有另一个同事在旧专案开发新的需求进度。 搞到最後三个月过去，新的东西完成度约只有 40%，且完全未经可靠测试验证。 这段期间已经在旧版新增的功能当然也没有。 我们面临一个不稳定旧版，跟一个未完成的新版的选择。 我後来的处置是整个废弃完成度过低的新版， 回来把旧版切出模组，分块重新处理...... 那个去写新版的工程师跟我杠上， 我们两边冷战了快三个礼拜，我後来调他去做别的专案， 让他不要再看到这个伤心地。 真要走这麽大的 move， 一开始就该安排 merge 计画.... ※ 编辑: TonyQ (118.167.67.203 台湾), 08/22/2020 14:19:30 超过, 因为还会造成旧专案的同仁适应问题. 而且後续收尾还有一些行政成本. ※ 编辑: TonyQ (118.167.67.203 台湾), 08/22/2020 14:34:49 从他的立场他觉得他只是需要时间. XD 我也算是理解他的感受啦, 後来有好好安排. XD ※ 编辑: TonyQ (210.61.209.201 台湾), 08/22/2020 22:09:46