|
CEO主要管四方面：人事物财。对于CTO，我认为也是管四个方面：人事物文。 ·人- 团队管理 ·事- 项目管理 ·物- 技术管理 ·文- 文化建设 团队管理团队由追求一个或多个共同目标的一群人组成，经过一些规则约束在一起工作。要让高效协作，需以人为本，让成员在各自位置得到最有效发挥，个体与整体相互促进成长。 1. 组织架构 组织架构是公司骨架，明确各个岗位的职责、管理范围、责任链。以下为负责技术开发部分：
组织架构 2. 招聘 招人这件事本身就是个技术活。从哪儿招？要发什么样的招聘文案吸引人？面试时问什么？怎么知道对方是不是有料？什么样的人适合留下来？ 有效过的招聘渠道大概有3种：内部推荐，专业招聘网站，社区论坛。其中内推最靠谱。为了鼓励更多内推，我们推行了内推奖励机制：内部推荐成功后，推荐人可获一定奖励。 不同的技术岗位需要掌握的技术技能自然不同，因此刷选时也需要面试官对面试岗位技能都有所掌握，然而每一门技术的技能树各不相同。
前端工程师技能树 技术岗位都需要定一些面试题目来提高候选人筛选效率和标准化结果评估。 面试很占用人的时间、精力，对于应聘者，耐心引导，应避免面试紧张导致应聘者没有发挥好从而给出错误结论。 让新人尽快通过磨合，熟悉开发流程，掌握专业技能，尽早能独立完成开发任务。以下方案： ·引入Mentor导师制度 ·[xx公司新人注意事项] ·code review：[Code Review Tips] ·pair programming ·内部培训、分享 ·官方BLOG ·外部技术交流会 Mentor制度 指定一名同类岗位、高一级别的同事任“导师”，带新人熟悉环境、流程、规范等，尽快通过磨合，熟悉团队、有归宿感。 开发人员一开始也可能不懂如何指导新人。为解决这种问题，我整理了一份文档，可以是WIKI中的的链接索引。不要分享整个文档给新人，让他锻炼自学能力。
新人注意事项 Code Review 我们在日常开发中鼓励并推行代码审查。 项目开发阶段时，我会根据开发组成员的级别设定审查链，按照“中级审初级，高级审中级，高级互审”。 没有合适的人时我来审查，开发任务完成后，任务开发者需要发Pull/MergeRequest给指定好的审查者进行审查和合并，确保每次代码合并前都有2个人能看到过，一般只有在做演示出现exception，需要紧急合并做部署时才会跳过code review流程。 推行代码审查需要有两个人以上的协作，自然是有代价的，那有什么好处？
让一个新人融入团队没有比在一起讨论代码更快的方式了，特别是对于新人而言，对代码规范不熟悉，通过Code Reivew能有效减少低质量代码的Check in，对个人、对团队、对项目都是很有益的一项安排。 我日常对进行Code Reivew发现问题做总结，在团队内也做过一次专题培训。
code review examples 特别提一下，设定固定的审查链的好处是减少审查者的负担，每个人只需负责1~2个的代码审查；阶级式的安排，可以让高级的不用反复的去提点低级人的一些低级错误，反复指出一些低级问题对高级人员是负担也是干扰，容易累积高级人员缺乏成就感的情绪（程序员的一个特质是喜欢有挑战性的任务）。 结队编程 结对编程的好处不用多说，应鼓励结对编程。我不会强制安排，不会要求像教科书般要求在某个时间规规矩矩的一个看一个写，实际上一般的情景是某个同事有问题时，需要找我或作指导的其他同事，拿上电脑大家坐在一起讨论、直接敲代码：
pair programming 内部培训、分享 团队的强大不能依赖个体，新知识只有一个人掌握时，不等于团队掌握了，分享出来团队技术才能成长。 在每周五下午，我会不定期的安排一些内部的培训，技术的、设计的、产品的，不限制领域，既是对个人的一次锻炼，又同时是给大家一个休息、坐在一起讨论的时间。 技术博客 知识的累积和巩固途径由浅到深可分为“听读写说”，但听别人说不如自己读书，读书不如动手写，写不如说出来给别人听。能亲口说出来的知识掌握得最牢固，不是人人都有勇气在别人面前开口，因此开设技术blog，把掌握到知识“写”出来。 只是内部交流是不足够的，还要看看别人是怎么做的，做法很简单要么走出去要么请人来。我们会不定期安排一些优秀的员工，参加的一些技术沙龙活动开拓眼界和学习。 5. 效率管理 程序员最烦什么？最烦的不是任务有多难多重，而是在写代码时被干扰打断。为此我需要从沟通方式、工作流程、协作方式各种方面来解决干扰的问题，我大概归纳为“四化”： ·沟通明朗化 ·工作流程化 ·开发自动化 ·协作清晰化 提高沟通效率 微信或QQ混合了非工作消息的通知，开发人员不能很好的区分开这是有工作消息、还是普通社交聊天消息，很容易错过重要的工作信息。注意，这里说的是“企业内部的沟通工具的选择”，对外该用什么的还用什么，两者并不冲突。 工作流程化 在团队中，特别是进行软件开发项目时，需要有一定的流程指引。大家在一起进行工作时可以分工、分步协作，清楚知道自己、别人下一步会做什么，自己会不会被干扰，从而提高协作效率。 ·开发流程规范- 规范了从需求确定、项目评估、项目确立、开发、验收交付到项目结束总结各个阶段的各角色的工作内容范围和输入输出的文档 ·开发流程图- 创建feature分支-> 提交PR/MR -> code review -> 部署staging-> QA -> 部署production ·提倡Git flow - 使用Github/Gitlab flow，代码提交使用Pull/MergeRequest来进行code review。 定好工作流程，大家从中找到自己的位置和角色，知道在什么阶段要做什么、下一步做什么、要跟谁协作，不能有“一头雾水”的感觉。 开发自动化 提倡善用工具最大程度做到自动化，这种思维是贯穿整个开发流程各个环节的。比如最普通的Terminal（终端shell），推荐使用带交互的shell（如zsh/Fishshell）来辅助cli的操作，鼓励善用alias来简化重复的使用命令； 代码开发时鼓励使用支持自动完成的IDE、编辑器（如SublimeText），鼓励善用代码snippet来减少重复编码的操作； 代码测试使用自动化测试（可配合guard或者livereload达到保存时自动跑相关测试）； 代码提交使用自动化命令（gitlab-send-merge-requestof git-cmd-helpers），一步完成代码提交并发Merge request； 项目部署使用自动化部署工具（如Chef、Capistrano），做到一键部署； 使用CI（GitlabCI）进行自动化测试、自动构建、构建结果通知、自动部署、自动打包上传app package，达到DevOps的自动化； 服务使用健康监控（如Monit，God），自动监测服务健康并自动重启服务； 一句话就是尽量把重复的工作丢给机器去做，人力应该专注在机器解决不了的地方。 协作清晰化- 让你知道什么时候要去找谁做什么 为了解决协作清晰问题，我们使用3种管理方法： ·团队共享日程表 ·团队协作（非特定项目）任务管理 ·具体的项目管理布告板 一个项目开发时必定会定下一些关键的时间节点，如何时开会、开发完成、会议演示、正式上线；公司内人员活动变化，如公共节假日安排、团建、面试安排、团队成员生病请个假什么的等等。 在团队中清晰透明、避免冲突。具体做法使用GoogleCalendar进行日历共享，客户端使用MacCalendar查看，约定好事件的标题格式“[公司名-项目名] 事件类别: 事件标题”。 在推行新制度时，使用流行的服务和系统自带的工具，可降低推行阻力。 日历只能也只应该记录事件标题和日期时间，更具体的内容，我们在Trello上建了一个board来进行管理，如我们的团队分享安排、团建安排、假期的安排等。 至于更具体的项目开发任务，可使用独立项目管理工具 6. 情绪管理 是人就会有情绪，了解员工的情绪问题也是管理的日常之一。在公司还没有强大到有专职的“程序员鼓励师”时，也只有亲身上阵，我推行了3种方式： ·员工一对一谈话- 聊天是舒缓情绪很简单有效的一种方式，无论工作问题、生活问题，都可以坐下来面对面聊一聊，讨论下解决方法 ·员工年度调查- 有些话不适合、不方便当面说的，那么可以写下来，，收集对工作流程、工作环境、薪资待遇、公司发展建议等 ·户外团建活动- 离开工作环境人的情绪会得到放松，为此我拟订过团队建设活动计划 项目管理要注意三点： ·需求清晰- 要做什么，做给谁用，做成什么样 ·任务清晰- 安排什么人，在什么时候，具体做什么 ·节点清晰- 要在什么时候做完 针对以上这3点我制定了以下文档、规范： ·明确需求- [PRD文档规范] ·明确任务- [Trello使用规范] ·明确节点- [Agenda] 文档规范 PRD（产品需求文档），相当于是产品的工程设计图纸。一份PRD应该包括：产品说明文档、信息架构图、功能结构图、逻辑流程等。 当整理过一份完整的PRD后，其实已经对产品的逻辑性、合理性做了一次梳理，再传达到开发团队手里时，能有效减少返工、无效需求的“折腾”。 Trello规范 Trello是个看板风格的协作工具，上手简单。由于Trello本身十分松散灵活，100个团队有100种用法，因此为了方便统筹管理，我制定了一些使用流程并整理成规范文档，包含对list、label使用以及card生命周期的流转，让每个任务从需求转化为任务，分配、评估、开发、部署、测试、上线，意图让每一步都清晰可预期，参与者之间协作配合清晰可见。 项目管理布告版也会对客户（外部客户或其它部门）开放，希望从一开始大家就可以参与到日常开发流程中，掌握项目开发进度，也方便收集对需求讨论、BUG反馈，以及分配一些他们要配合的工作，让协作内外贯通。 Agenda 一个项目开发，需要定一些时间节点，如什么时候正式立项，以便项目经理可以召集开发团队、召开立项会议；什么时候做交付演示，以便让QA工程师可以准备用户故事；什么时候正式上线，以便项目组技术组长可以准备交付文档；时候做上线推广以便运维人员可以做好服务器压力测试调整服务器配置。 前面在说如何解决团队协作清晰化中，提到了使用“团队日历共享计划”。因此要求项目经理给每个项目添加2种事件类型，一个是CHECKPOINT（检查点），一个是DEADLINE（最后期限）。 CHECKPOINT是阶段性的时间节点，DEADLINE是当前版本最终的交付限期；一个开发版本内可以有多个CHECKPOINT，但只有一个DEADLINE。 做事应有始有终，我要求每个项目的每个大版本开发，都要定一个DEADLINE（最后期限），期限是构成目标的要素，没有期限则没有目标，没有目标何从谈管理？ CHECKPOINT则是一些阶段性的目标，到达一个DEADLINE之前，可以有多个CHECKPOINT；一个CHECKPOINT可以是任何关键事件，如阶段演示、交付演示，可安排阶段小结会议来讨论技术问题调整开发计划。 个人管理 在日常工作中，往往又有一些个人的自我管理&代办事项。如某项技术调研、培训文档准备等不适合放入协作的任务列表的，也要管理起来，做法如下： ·不需要协作的，放入Wunderlist（可跨多终端）; ·需要team范围知晓的、有明确日程安排的，放Agenda; ·跟具体项目相关的，放在对应的项目trello board 控制节奏 项目开发有如组织团队赛跑，需要控制好节奏，什么时候要留力调整速度，什么时候要加速冲刺，都应该有规划。 根据这些年来的项目开发经验，我整理了一个开发流程规范，划分出几个阶段，每个阶段有主要参与的角色及其主要任务、有输入输出的结果，以便项目参与者明确自己角色的任务。 - 选定项目管理框架/风格：Kanban + Scrum - 选定项目管理工具：- 默认：Trello + Scrum Extension - 其他：Redmine，Teambition，Worktile，Tower - 角色安排：项目经理，产品经理，项目组长，开发，测试，运维- 流程安排： 1. 需求确定- 确立需求可行性2. 项目评估- 根据PRD评估开发量，确定项目周期3. 项目确立- 项目组角色安排，项目周期、确定技术栈4. 开发- 日常开发迭代5. 验收交付- 交付项目，收集客户反馈6. 项目结束- 进行项目汇总，总结开发收获、工作流程改进意见- 会议安排： * 项目启动会议- 成立开发组、通告项目背景、周期、技术栈* 项目阶段会议- 阶段性小结，了解当前实现进度及出现的问题，调整下阶段的目标和做法* 项目总结会议- 进行项目汇总 在一个完整的开发流程中，每个环境牵扯到不少细节，团队会不时增补新人员，要形成统一的团队风格，少不了要制定规范文档，让每个成员可以达到一致输出，其他同事协作时则有规可循。 以下是项目开发流程相关实例： ·开发流程规范 ·文档规范 ·Trello使用规范 ·Trello board template ·项目周报规范文档 ·阶段小结会议规范 ·项目总结会议规范 ·项目总结报告规范 ·会议记录书写规范 使用成熟项目管理工具，可以解决一些流程的规范、自动化，自然省事不少。但工具很重要也只是辅助。我接触过一些团队，使用了一些复杂的管理工具，然而管理层不去推行、监督，执行层不落实执行，工具再多再强大也没有意义。 在工具的使用上，适合自己团队的才是最好的，不必过于纠结在工具选择上。 例如使用Scrum管理框架，但也不是完全照搬Scrum全家桶，有每日站会、有Sprint 评审/回顾会议（我合并为“阶段小结会议”）、使用Backlog列表、任务评估使用Story Point、使用User Story做验收交付文档，没有ScrumMaster（但有项目组长），根据团队的实际情况做了简化调整，可以落实执行的方案才是好方案。 总的来说，即使团队只有一个人时，做事也应该有章法，才能做到事多不乱，团队壮大了再由己及人，保持团队一致的调性。只有做到以上这些，我们才能从复杂多变的环境中做到“有的放矢”，从容应对变化。 技术管理核心思想: 喜新厌旧 ·喜新（Upgrade）：升级技术栈 ·厌旧（Migrate）：偿还技术债务 喜新（Upgrade）：升级技术栈 大家都知道摩尔定律，然而此定律不止作用在芯片更新换代上，在编程领域也可适用。 几乎每年都有一些新编程语言、技术框架、系统架构的出现，其中一些有重大突破性的还能引起热潮。对于技术团队，其能掌握的技术栈就是其战斗力，而今年掌握的很有可能第二年就变为过时，因此一个有活力的技术团队是需要不断吸收外界新鲜有活力的技术点，吸纳融合入团队技术栈，转化为团队的战斗力。 然而新技术会不断提出、旧技术会迅速过时，我们既不能被新技术牵着鼻子走又不能过于落伍。因此在选定技术栈时需要具备有前瞻性，不能被新热的技术吸引分散精力，也又不能把团队绑定到一些没有生命力的技术上，这不是简单的选择题，需要经过探索、调研、实践到最后掌握化为生产力。 厌旧（Migrate）：偿还技术债务 在项目开发过程中，有时会根据当时的人、财、物及知识经验限制等，对技术框架、架构选型做一些当时认为“最适合”的设计或选择，但随着时间推移，需求变更、经验提升、新技术提出等，回过头来会发现当时的“最佳实践”已经不适合了，有的严重更会成为推进项目的负担，这种情况我们称之为“技术债务（technicaldebt）”。 欠债要还，没有反思不会进步，因此要给团队“还债”的时间，团队才有进步。但这点在外包开发团队中其实是很难彻底实践，因为需要跟客户解释什么是“重构”，为什么要花时间去做一些没有明显输出的工作；又得在尽量不影响工期的情况下，定下更“正确”的架构，这也很考验架构能力。 作为技术负责人，我进行技术管理主要看以下6个方面： ·技术调研- 探索新技术、调研工作上需要用的服务等，以保持技术团队的先进性 ·技术实践- 有实践过的技术才敢引入团队中，不要做拍脑袋决策 ·技术培训- 得到认可的技术要推广和普及给其他成员，提升团队整体战斗力 ·技术复用- 提取出可复用的技术点，进一步提高团队生产力 ·规范化- 技术团队应保持一致行事风格，以降低沟通、代码维护、工具使用的成本 ·自动化- 解放生产力，让机器去做重复工作，人力去做突破性工作 以下是具体实践过的一些调研报告（report）、培训讲稿（ppt）、规范文档（doc）、知识库（wiki）、内部开源项目（project）以及公开博客文章（blog post），涉及的内容其实很多我这里只列出一些比较有代表性的、在团队内实践分享过的内容： §report:[AngularJS vs reactjs] §report:[2016Rails popular app servers] §report:[chromeextension开发调研] §report:[CrashReporting Service] §report:[React-NativeHot Update Services Research Report] §report:[国内外流行字体CDN调研] §project:[jpush-ionic-demo] §project:[pushwoosh-example] §project:[beansmileteam/react-components] ·技术培训 §ppt:[how todo model design] §ppt:[toolbox-for-optimizing-rails-project] §ppt:[rails项目中性能调优要注意什么] §ppt:[rails-debug-tips2016] §ppt:[如何写一份压力测试报告] §project:[bean-hub] §project:[beansmile-quickstart] §project:[beansmile-rails-composer] §project:[beansmile-react-boilerplate] §doc:[Beansmilestyleguide(代码规范指南)]（ §wiki:[Beansmilecoding standard] §wiki:[CodeReview Tips] §wiki:[Rulesfor committing] §wiki:[trello+ git开发流程规范] §wiki:[howto write a rake task] §doc:[TechStack Example] §doc:[APIdesign example] ·自动化 §wiki:[SetupGitLab CI] §wiki:[SetupGitLab CI Runner] §wiki:[DeployProject to Staging Using Capistrano on Ubuntu] §blogpost:[RSpec 使用一周小结（上篇）] §blogpost:[RSpec 使用一周小结（下篇）——使用FactoryGirl 准备测试数据] §blogpost:[rails集成测试学习总结] §blogpost:[rspec集成测试的总结] §blog post:[简介如何测试Rails应用] §blog post:[压力测试总结] §自动化测试 §自动化部署 §DevOps - 持续集成 §ChatOps -Slack+Lita 自动化 提倡开发中用工具最大程度做自动化。 如果你用最普通的Terminal（终端shell），推荐使用带交互的shell（如zsh/Fishshell）来辅助cli的操作，鼓励善用别名来简化重复的使用命令； 代码开发时，推荐使用支持自动完成的IDE、编辑器，鼓励善用代码snippet来减少重复编码的操作； 代码测试使用自动化测试（可配合guard或者livereload达到保存时自动跑相关测试）； 代码提交使用自动化命令（gitlab-send-merge-requestof git-cmd-helpers），一步完成代码提交并发Merge request； 项目部署使用自动化部署工具（如Chef、Capistrano），做到一键部署； 使用CI（GitlabCI）进行自动化测试、自动构建、构建结果通知、自动部署、自动打包上传app package，达到DevOps的自动化； 服务使用健康监控（如Monit，God），自动监测服务健康并自动重启服务； 一句话就是尽量把重复的工作丢给机器去做，人力应该专注在机器解决不了的地方。 以下是团队开发中，从本地终端使用一行代码发起MR（MergeRequest），Code Review通过合并MR，触发CI自动进行构建、测试、部署到通知Slack的过程。 自动化有助减少人工参与，提高效率的同时减少误操作可能，技术团队当大力推行。 今年莫过于前端圈的火热和容器架构的盛行，层出不穷的概念、辅助工具，新技术还没来得及掌握转眼已经变为淘汰，意味着对技术的细分越来越专业，同时也意味IT项目的工程化越来越专业。 文- 文化建设团队文化是指团队成员在相互合作的过程中，为实现各自人生价值，并为完成团队共同目标而形成的一些行事态度、思考方式和行为准则。在技术管理方面，我主要负责塑造技术文化氛围，并通过这些思想、准则来影响及推行“团队管理”、“项目管理”及“技术管理”等方面。 工程师文化应该是“八面”玲珑，并不是要把人培养成圆滑的人。我认为在一个以工程师为伍的技术团队中，应该建立以下八个方面的文化： ·学习文化 ·创新文化 ·工程文化 ·工具文化 ·自动文化 ·脚本文化 ·开源文化 ·流程文化 学习文化： ·技术调研 ·技术总结 前面“技术管理”中说过要“喜新厌旧”，不断扩宽知识边界、填平知识短板，团队技术水平才能不断提高。对新出现、不熟悉的技术点要进行调研，出调研报告；对已经熟悉用过的，要做技术总结，使得经验可以复用。如何鼓励内部分享，外部交流、互通有无，在前面“团队管理”如何“培养”已经具体说过就不再展开。 创新文化 我认为“创新”不止是说创造新的工具、组件，勇于使用新技术、引进新框架、打破陈规做法也是一种创新，能引起“有益的变化”就是创新，应大力鼓励。 比如有一个项目后端是Ruby，前端是Coffee语言编写，都有大量的类定义，新加入的开发人员上手会比较困难，为此我编写了一个文档构建脚本，能自动对2种语言的代码分别生成统一的YARD风格的文档，再合并在一份文档中，以方便大家查看熟悉程序结构。 工程文化 一个完整的软件工程，需要考虑程序语言、数据库、开发工具、系统平台、依赖包管理、代码目录结构、设计模式、日志记录等方面，开发项目交付时，除了代码，还要功能说明文档、代码说明文档、单元测试、压测报告、部署说明文档。一个开发框架的工程化成熟度，就是看以上这些方面的覆盖程度。 前面“技术管理”中说过了我们的Web 开发框架是用Rails，而Rails是fullstack的、从一开始就走工程化的风格，从初始化一个rails项目的第一步的命令：rails new MyProject--database=postgresql --Java=jQuery看出它会期待你预先考虑好后端使用什么数据库，前端使用什么js库，当然这些参数都是可选，不选择则使用默认配置，Rails遵从CoC（约定优于配置）原则。 以下是Rails 5生成的项目目录结构： ├── Gemfile # gem依赖管理(Gem是Ruby领域的apt) ├── README.md # 说明文档 ├── Rakefile # 构建任务管理入口（Rake是Ruby领域的Make） ├── app/ # 应用代码 │ ├── assets/ # 静态资源文件（js,css,img,font） │ ├── channels/ # 基于WebSocket 的Pub/Sub实现 │ ├── controllers/ # 控制器，负责处理请求，调取Model，选择View渲染 │ ├── helpers/ # view 的辅助模块 │ ├── jobs/ # 队列任务 │ ├── mailers/ # 邮件内容 │ ├── models/ # 业务模型 │ └── views/ # 视图（HTML模板） ├── bin/ # 一些项目CLI命令、自定义脚本 │ ├── bundle*│ ├── rails* # 主要CLI，提供启动app server、控制台、生成器、运行测试 │ ├── rake*│ ├── setup* # 项目初始化脚本，一步完成安装依赖、数据库初始化、启动rails server │ ├── spring*│ └── update* # 开发过程更新脚本，一步完成安装依赖、数据库迁移、清理临时文件、重启rails server├── config/ # 各种配置，如启动方式、数据库配置、路由配置、环境配置、密钥配置、i18n配置├── config.ru # Rack架构服务调用接口├── db/ # 数据库迁移改动、种子数据├── lib/ # 独立的类、模块、app相关的rake任务├── log/ # 各种日志文件├── public/ # 不用预处理、可公开访问资源目录，如404.html,robots.txt│ ├── 404.html│ ├── 422.html│ ├── 500.html│ ├── favicon.ico│ └── robots.txt├── test/ # 单元测试、集成测试 │ ├── controllers/│ ├── fixtures/│ ├── helpers/│ ├── integration/│ ├── mailers/│ ├── models/│ └── test_helper.rb├── tmp/ # 缓存、临时文件 │ └── cache/└── vendor/ # 第三库、资源 └── doc/ # 文档存放目录，从rails 4不再默认生成，但可以通过`rake doc:app` 来检查并生成app代码文档 从所生成目录就能看出，在rails 项目里会涉及到依赖包管理、构建任务、静态资源处理、消息订阅处理、消息队列处理、MVC架构、邮件处理、提供CLI、i18n处理、多环境适配、Rack架构、数据库连接、数据库查询（ORM）、数据结构迁移管理、初始化数据管理、日志处理、单元测试、集成测试等概念，几乎涵盖了一个Web项目需要用到的方方面面，可以大方说句使用rails的开发者相对是比较“幸福”的，因为有很多细枝末节的地方都已经有被考虑到，而且还在不断的补充引入新的feature。 在前后端分离的架构中，前端现在大量应用Backbone/angularjs/React& Redux，在移动开发中使用Ionic/React Native，但这些技术框架中有些没有很统一、符合要求的工程化规范。我安排整理了一些规范文档。 ·angularjs 项目目录结构规范文档 ·react-redux 项目目录结构规范文档 ·React Native项目结构规范 以便开发项目时更工程化、结构化，可在新项目中可以复用架构、组件。 工具文化 “工欲善其事，必先利其器”。如果说任务开发是战场，那么开发者使用的工具就是武器，把“武器”打磨得是否顺手就会成为战场生存的关键之一。我经常在团队中推荐并鼓励每个人都分享、推荐自己使用过、认为高效的工具。如： ·Shell：zsh/fish - 交互式shell，提高CLI操作效率 ·代码提交：GitX - 我鼓励在代码提交时使用git的GUI工具如GitX而不是命令行，因为GUI工具可以进行代码整理，有利合理的代码提交记录 ·终端操作：TotalTerminal/iTerm - 随时随地可以进行敲命令 ·文档编辑：MacDown - 所写己所得、兼容github GFM格式 ·API查看：Dash - 快速离线查看各种技术API文档，开发者必备 ·窗口操作：Spectacle - 多屏幕操作利器 ·应用访问：Alfred - 把Mac变成Google Instant Search 般的体验 ·图片编辑：Skitch - 一图胜千言，快速给截图加上注释 ·数据库操作：Navicat Lite - 支持链接MySQL/postgres/Oracle/sqlite/sqlserver，开发者必备 ·代码编辑器：Sublime Text/Vim/Emacs/Atom - 编辑器的选择对程序员而言是场“圣战”，这个以后再谈。 脚本文化 无论是用Java，C++，.Net ，还是用Ruby，PHP，Python，Java 脚本语言的程序员，都要掌握基本的Shell操作，会有效提高效率。。 简单做法是增加一些alias作为常用命令的组合，使用有语义的命名，配合可交互Shell的提示，降低操作成本，减少重复敲键、错误输入。如给不熟GIT的人建了个git-cmd-helpers，无非增加一些常用git 操作的封装，用以提高GIT的使用效率。 作为技术开发者，我们是技术开源社区的收益者。我会经常在团队中鼓励在开发中使用一些开源组件遇到问题修复时，给源作者发PR，同时也在github上发布。 流程文化 制订流程，是团队多人协作的基础，是“规范化”的细节，是“自动化”的前提。 前面的“团队管理”提到工作流程化，我制定了涵盖从招聘到入职、升退评价的招聘和入职流程；“项目管理”中，我制定了[开发流程规范]、[Trello使用规范]，涵盖从需求对接到项目结束交付；“技术管理”中提到[trello +git开发流程规范]，涵盖了代码提交流程、审查流程、部署流程步骤的细节。 制订制度、规范的流程 同样，在公司中制定一种新的制度、规范时，也应遵从类似以下流程： 1.调研- 先看人家怎么做 2.制订- 自己要怎么做 3.发布- 跟团队说明是什么、怎么做 4.执行- 怎么说就要怎么做，最忌光说不练 5.监督- 了解执行效果，收集反馈 6.修正- 根据反馈意见调整细节，收集到足够多的改动后发布新版 7.发布新版-> 执行-> 监督-> 修正->（重复） 思路：跟写单元测试一样 ·编写测试代码 ·运行测试 ·观察结果 ·修正实现代码-> 运行测试-> 观察结果-> (重复) 小结 以上是我认为是对技术团队有益的文化总结。 公司文化建设是门不简单的技术，更大程度上受创始人、管理层影响，因此不同技术团队中即便是使用相同的技术栈。由于创始人不同，所施行的管理理念、思考方式不同，执行结果也会不一样。 我不认为有“最好”的团队文化，只有“最适合”的团队文化，因地制宜、量身打造的才是适合自己的。 转自html |
|
|
