写一个玩具

核心理念

1. 以对话的形式
2. 用摇签的交互方式
3. 通过信息掮客赚心里按摩的钱

模型设计

用例图

@startuml
left to right direction
skinparam packageStyle rectangle

actor "求问人" as Seeker
actor "解签人" as Interpreter
rectangle "系统" as System {
  usecase "摇晃手机模拟摇卦" as UseCase1
  usecase "向解签人求问卦象" as UseCase2
  usecase "解签人回答并提供咨询" as UseCase3
}

Seeker --> UseCase1
Seeker --> UseCase2
Interpreter --> UseCase3

@enduml

类图

@startuml
interface Role {
  +interpretation(): String
  +shake(): Yao
}

class Account {
  -name: String
  -role: Role
}

class Interpreter implements Role {
  +interpretation(): String
}

class Seeker implements Role {
  +shake(): Yao
}

class DivinationCup {
  +shake(): Yao
}

class Yao {
  -value: Boolean
}

class Hexagram {
  -yas: Yao[6]
  -interpretation: String
  +getSession(theme: String, account: Account): Session
}

class Session {
  -hexagram: Hexagram
  -interpretationRecord: InterpretationRecord
  -theme: String
  -sender: Account
  -receiver: Account
  +sendToInterpreter(): void
}

class InterpretationRecord {
  -interpreterComments: String
  -question: String
  -theme: String
}

Account --> Role : has
Seeker --> DivinationCup : uses
Hexagram --> Yao : contains
Hexagram --> Session : creates
Session --> InterpretationRecord : records

@enduml

非核心业务需求描述

1. 使用一套代码支持多种类型程序（小程序、APP、H5等）
2. 使用相同的业务账户
3. 将收费项目移到可控代码处

技术选型

业务前端

1. 目前Taro+Taro-ui
2. 微信小程序
3. 原生APP

可控代码后端

1. 选用Java/Go均可

一些可以提供的服务思考

技术能力

1. 软件建模能力，完成过交易平台核心领域建模，完成过SaaS应用市场建模
2. 软件开发能力，Go、Java、React、Python是我的常用技术栈
3. 画过网页界面，也画过单机可运行程序
4. 写过上位机程序
5. 也能修改硬件程序
6. 有一部分运维端部署的经验，Nginx，Linux，Windows Server都使用过构建系统

沟通能力

1. 和供应商扯过皮
2. 和开发分解过工作
3. 和测试配和过测试，并且成功上线
4. 和业务喝过酒，吹过牛，还能砍需求

如何用代码挣钱

1. 卖知识
   1. 开课？
   2. 开付费渠道？
   3. 做自媒体？
2. 卖技能
   1. 比如针对特定情况查bug
   2. 部署网络环境
   3. 甚至硬件管控？

交易系统建模

平台视角

业务域

• 聚合根
  • 管理员/商家/采购员
  • 询价单
  • 交易订单
  • 交易对手方
  • 交易时间
  • 交易内容
    • 出库单/入库单
    • 库存
    • 批次
    • 数量
  • 履约单
    • 物流单
    • 仓储单
    • 配送单
  • 售后单
  • 摊位信息
  • 图片
  • 简介
  • 商品列表
  • 广告位
  • 结算单

支撑域

• 技术支撑
• 外部接入
• 对外服务

管理域

• 工单
• 入驻审核单

建模图片

翻新系统实践

基本情况

• freemark+jsp+java14的怪异组合
• 有部分内部接口采用feign
• 大部分接口采用nacos作为profile管理以及服务注册发现
• 前端部分仅使用了以jquery和easyui为主的插件，工程化程度不高

需求说明

来自于上线时候的苦恼，每次更新代码总会引发未在版本规划内的前端代码提交，且升级时间较长，失败回滚时候还有cache问题

问题分析

1. 交互代码和逻辑代码均由同一个开发人员完成，此时心智负担较大，在工期较为短的时候，非常容易造成误操作，且只有上线后才能发现
2. 系统经历了十年左右的开发，每个开发人员有不同的技术栈喜好，例如早期约定使用Spring Cloud的早期版本，而在五年后发现Spring Cloud很多功能又要二次开发，转向了nacos为主的国产。成员变换中不习惯，有部分接口就干脆采取域名+Nginx网关直连的形式
3. 除此之外业务系统的拧巴逻辑也是翻新的重大障碍

方案选择

经过和开发小组成员讨论，建议先从增量做起，避开旧有尚能完备运行的业务，其中最简单的是需要抽出一个专门的开发人力，进行前端框架的搭建。(目前使用vue2，开发人员易于招聘)

框架需要完成以下几个事项：

1. 要替换掉原来依靠服务器进行状态管理的现状，将状态管理放在前端
2. 要将功能路由管理放在前端框架进行管理
3. 要维护一个列表，标记哪些路由是用于直接走原来的逻辑，哪些路由是新增的有前端管理的逻辑
4. 需要后端软件新增接口用以维护新旧软件的状态（一次性开发成本）

在前端框架开发完成一个月后，选取更新频率最低的应用作为试点应用，避免与正在开发的任务同时进行

当前后端代码可以剥离完毕后，在考虑后端的技术栈提纯，不应将改造任务混杂

一些结局

1. 成功改造了从外包厂商回收的代码
2. 在重要业务中，成功替换了进门抬杆页面的代码
3. 为后续的业务不中断升级铺平道路

一些好玩的近况

最近出差多，不像在家里，小朋友睡觉了还要顾着点小朋友不能吵醒他。

静下心来最近好多传闻总能扰动心绪，写写文字大概能缓解下。

疫情

消息纷纷扰扰，总有人说要放开，各种奇怪的source，各种传言。虽然在物理上我们真的完全不具备条件去做这个事情，但是满天飞的传言确确实实影响了所有人的。

大概2022年的十月份看到了个对于网络空间信息污染及扭转认知的技术性文章，大概挺有意思的，也是最近这一段时间能反复相互印证的手段。

一旦有了技术性分析，事情本身可能对于我来说更多是高一个维度的观察。

主要的手段有：
1、启用冷藏多年的账号库
2、反复投放Unknown Source Speak
3、内容在普遍意义上符合一定的诉求
4、反复多账号打榜，人为攻击社交网络体系，使得本不值得讨论的问题成为了一个讨论的问题
5、一旦出现官方辟谣，一定会转为以傻子为节点的传谣

工作

加入现在的公司应该快满两年了。贡献给公司的代码是越来越少了，大部分让我还能使用编程能力都是为了我自己的服务器。反倒是真的像车库阶段的个人电脑使用方向。工具也是初创公司才会去使用。

怎么说呢，这样分裂的感觉，又使得我更好的观察了到底所谓的技术是什么。

这两年让我锻炼出的一个基本技能就是看使用的工具链能评价出具体一个开发团队会大概需要多少开发人员，凡是声称自己公司有特别强的自我研发能力，然后发现人数队伍不匹配，大概率也就是商业吹嘘了，不会有实质性的开发能力。

游戏

出差这么多天，发现我这个新买的超薄本，性能很牛逼啊，就是内存小了点，Intel的Iris Xe能打很多以前台式才能玩的游戏了，加上20w的满血CPU，而且是稳定释放。我竟然又开始静悄悄的玩一下小时后的游戏。可惜了，我已经记不起来以前玩过的好多游戏，只能支离破碎的记得一些画面。

一点观察

关于业务调查

首先需要明确，我们调研的是什么业务。
其次应该要调研目前较为频繁的操作，必须要区分主次而不是把曾经的流程死缠烂打。边缘策略不需要太关注
最后应调研的是，不同角色的不同吐槽，然后汇总

关于会议

一个有效的会议组织，应该事前分发好资料，事中做好记录，事后做好跟踪
对于傻逼议题能有效的中断。
会议必须要有时限。