跳到主要内容

工程哲学

工程哲学适用于软件开发、产品管理、架构设计、用户体验设计等多个工作领域。

软件工程​

虽然我们在工作中会不断面对新技术、新名词、新实践方法，但就世界运行的底层逻辑来说--一切都是哲学问题。

系统设计 101 使用视觉效果和简单的术语来解释复杂的系统，帮助我们快速进入架构设计的世界。

Unix 设计哲学​

17条Unix的设计哲学, 引用自 《Unix 编程艺术》

Python 之禅​

PEP 20 – The Zen of Python

云原生 12 要素​

The Twelve-Factor App

系统架构演进​

Scaling webapps for newbs & non-techies

面向对象设计原则​

Principles of Object-Oriented Design

敏捷开发​

敏捷实现过程会划分如下几个颗粒度：

  • Task（任务）
  • Millstone（里程碑）
  • Release（发布版本）

多个任务=新版本，若新版本周期比较长，用户可能会焦急等待，这时候就会发布 Millstone 的中间结果。

多元化团队​

一个优秀的软件团队，需要各种不同类型的人才：

  • 具备商业思维和产品化思维的高层
  • 具备产品化思维的产品经理
  • 人际关系良好的团队粘合剂人才
  • 卓越的项目解构能力的项目经理
  • 单点突破的技术好手
  • 指哪打哪的技术执行者
  • 有耐心的重复任务执行者

看板​

看板是一种简单高效的工具，它适用于多人协作的任务视图

Issue​

将问题分解成可以由个人主导完成的 Issue 是至关重要的工作哲学。

文档​

软件工程文档是一个总称，涵盖了涉及软件产品开发和使用的所有书面文档和材料。所有软件开发产品，无论是由小型团队还是大型公司创建，都需要一些相关文档。整个软件开发生命周期（SDLC）会创建不同类型的文档。存在文档来解释产品功能，统一与项目相关的信息，并允许讨论利益相关者和开发人员之间出现的所有重要问题。

文档类型众多，但抽象起来，其实就是两种类别：

  • Product documentation（产品文档）：包含描述产品生命周期的需求、设计、架构、原型等开发者所需的相关的文档，另外一方面包括用户所需的操作手册、管理员手册、API手册等
  • Process documentation（过程文档）：管理产品开发过程的项目计划，测试计划，报告，标准，会议记录等

产品文档中的需求文档（PRD）又是最为关键的部分，它包含用不同的角色的所需解决的问题、人机交互设计、是否符合商业目标等内容，它需要用精准的文字来描述目的、功能和行为。

编写需求文档的时候，很多人会不经意陷入技术陷阱：“谈需求的时候，牵扯实现；讲宏观的时候考虑微观”。

Websoft9 工程化过程中，主要有如下几种必须的文档：

  • 需求说明书（PRD）：成品需求的描述
  • 备注（Notes）：产品开发过程中的注意事项与创意想法记载
  • 用户手册（User Guide）：最终用户的操作指南
  • 管理员手册（Administrator Guide）：软件安装、维护的系统管理手册
  • 开发者手册（Developer Guide）：软件架构说明、软件核心功能（函数）参数说明、软件插件的开发指南、软件代码合并与开源协作等面向开发者指南

多路复用​

线程与进程​

开源思维​

传统的开发（相对于开源来说），受制于封闭的代码和自雇团队的人力模式，导致有局限性。

长期在这种环境下工作，可能会养成如下的思维定式：

  • 任何事情喜欢自己动手折腾到底，即调研和实施全过程都独立完成
  • 觉得沟通成本高，还不如自己搞定来得方便
  • 编写的文档主要是给“懂的人”看，文风晦涩难懂而当事人未察觉
  • 80%的时间用在基于已有的知识和技能创作解决方案，20%的时间寻找工具，重复低效地造轮子

与传统开发局限性思维相比，开源思维的好处更多：

  • 集成化思维：先设计架构，再找工具（组件），最后通过集成形成解决方案，减少重复造轮子
  • 全球化视野：产品面向全球开源，推动文档、readme、issue英文化，自然形成全球化思维
  • 广泛的人力：全球开源参与人才广泛，理论上都为我所用
  • 利他主义观：开源文化倡导“我为人人，人人为我”

协作​

代码分支​

项目在 Github 存在 main 和 dev 两个分支，其中 main 是主分支，dev 是开发测试分支。

  • 本地同步-dev分支
  • dev 分支合并到 main 分支需要人为确认

两人协作工作制​

在复杂任务中采用专业协作、多人分工的工作流程。

一般有两种角色：

  • 需求者
  • 架构师

需求者即工作的发起者、业务负责人，例如：产品经理、营销经理等。

架构师是具备专业素养的技术设计能力，两者角色配合的工作流程如下：

最核心的原则：

  1. 需求方自行在设计工具上创作一个草图，同时编写设计需求
  2. 设计师在需求方的工作成果基础上进行进一步创作

包管理​

30多种开发语言的包管理

测试​

以下是对软件测试理论进行的结构，便于快速掌握测试技术哲学：

测试工作先要明白测试对象是什么？测试对象是对软件组件或模块进行功能、性能和接口三方面的测试。

测试对象是主线，结合下面的几个维度，最终转换成一个个具体的测试任务（通常叫做测试用例）：

  • 时间：开发、上线前、上线中、维护中
  • 方法：白盒、黑盒、灰盒、静态、动态、自动、手工
  • 维度：函数级测试、最小单元功能级测试、场景级测试

UI 设计工程​

UI 设计也是一门技术，而且是对综合知识要求极高的工程技术。

如下想系统的学习 UI 设计，最好的方式是研读：《了解 143 个设计系统》

UI 设计技术的本质：设计单元化组件的组合，最终形成统一的风格。

它与软件技术是同等的技术哲学，最好由三层结构实现：

  • 单元化组件：单元化组件是可以被图片引用，并无需任何更改即可使用的设计元素。 例如 字体、颜色、矢量图标、插画、照片等
  • 盒子化中间件：具有一定的“盒子化”特征，单元的设计具有整体性，不可被分割，但又比最小单元展示出更多的内涵
  • 整体系统：网页、画册、场景化图片

架构师​

企业架构师​

所谓架构师，就是掌握大量设计理念和原则、落地到各种语言及附带工具链（生态）下的实践方法、垂直行业模型理解，定制系统模型设计和工程实践规范细则，进而控制30万+行代码项目的开发便利性、可维护性、可测试性、运营质量的资深研发群体。

设计架构师​

如果我们准备在设计上提升能力，那么必须有一个设计架构师的角色。

之所以称之为架构师，是因为需要这个角色能够对设计进行系统化设计，包括：

  1. 设计工作整体规划
  2. 设计建模
  3. 业务流程规范化
  4. 单元化组件制作
  5. 设计工具选型
  6. 设计风向与迭代

当前，我们继续解决的问题包括：

  1. 设计工具选型
  2. 单元化组件制作

技术高手-不可低估的意志​

掌握了方法论，也只是解决故障的一个方面。实际上，还有一个方面与它是相辅相成的，那就是问题处理者的软实力。

个人软实力（Soft Power ），是指难以直接估量的能力，比如思维学习、沟通表达、文化修养、团队协作等能力。

技术价值观​

技术价值观就是：摆正位置，放弃陈旧观念，从思想上彻底改造自己。

  • 一切的软件问题均可解决，解决不了是因为你还没有驾驭此项技术的能力
  • 事出必有因，请找出符合逻辑的因果关系
  • 故障归因于成熟的组件错误（或缺少基本功能）时，不妨扪心自问自己对它了解了多少
  • 故障天天有，解决一个算一个，生命不止解决问题不息
  • 对于新事物，在没有深度研究与实践下，请勿妄下结论
  • 解决问题的工具是存在的，普通能力的人十有八九找不到合适的
  • 敢于担当 Owner，是快速成长的关键
  • 解决问题后收获不到快乐，说明你不合适

学习、思考与总结​

  • 广度与深度：微观蕴含宏观，宏观包含微观，广度与深度并不冲突
  • 通俗化：对于精英人才来说，承担总结、辅导和架构的责任，以通俗易懂的方式掌握核心要点方可引领团队
  • 战略思考：不谋全局者，不足谋一域；战略上清晰，执行上少走弯路；战略上模糊，执行上低效
  • 实践效率：做精准的实验，少做类比实验
  • 搞清楚一个系统的主要突破口：系统架构以及组件的连接关系
  • 解决掉一个问题的主要突破口：主要矛盾与次要矛盾，矛盾的主要方面与次要方面

沟通、表达与协作​

  • 理论实践结合：一边解决问题，一些总结别人看得懂的文字
  • 说不清楚 && 写不清楚 = 没有掌握；说得不通俗 && 写得不通俗 = 没有深刻掌握
  • 三个臭皮匠=一个诸葛亮，多邀请他人参与故障会诊可事半功倍
  • 沟通=问问题或反馈问题
  • 任何情况下的低级错误，都不可以推卸责任，即便是“我是按照×××说的去做的”
  • 驾驭效率工具和能人，集中可用的资源进行问题单点突破

斗争与意志力​

方面强者表现弱者表现
定位为结果负责别人怎么看我（刷存在的价值）
犯错发自内心的自我批评和反思不断安慰自己并告诫外界：这事情本来就很难
心态与问题斗争，其乐无穷视问题为严重的精神负担
耐力咬住不放，问题没有解决，吃不下饭，睡不着觉找到问题无法解决的理论依据，草草了事，快速交差
人际关系扫清解决问题路上的一切人际沟通障碍，深刻理解“胜利者是不受谴责的” 的做事哲学不好意思打扰别人，不好意思得罪别人，担心别人不爽，担心他人对自己有看法

参考书目​