日常体会(更新至 2021-08-08)

NOTE: 本文为原创, 转载请注明出处 https://blog.yangxiaochen.com

[quote, 杨晓辰, 2019-02-21 在讨论需求实现时一定程度的妥协]

当你对未来的需求有预见性, 能够估计出现在的设计如何改动, 老数据如何迁移, 就能够接受当前的并不完善的设计. 重要的是设定概念, 或者叫领域模型, 只要老的模型和新的模型都是清晰地, 就不怕从老的模型迁移到新的模型.

为什么有时候重构困难, 不是无法找到一个新模型, 而是老模型混乱, 细节上二义性多, 每一次模型的更新都没有对数据全面处理, 造成数据的历史版本多.

一个模型内部的各种字段的业务场景都要明确, 各司其职. 讲模型就是树立概念. 应该是自冾的, 能够演绎的, 能说服自己的.

[quote, 杨晓辰, 2019-03-08 如何让自己趋向专业]

工程师怎么才会想着要做到更专业? 一个工程师在觉得专业的东西离自己比较远时, 通常不会要求自己作的很专业.

但当一个工程师看到了写的很专业的代码, 文档, 就在自己身边, 并被专业性所打动时, 肯定会自己也想要做到这样.

当花费了些功夫, 自己也模仿专业的方式来要求自己, 产出成果后, 会产生很大满足感, 这样一个工程师今后都会更高要求自己.

一个同事, 之前不写测试, 或者说对写测试不感冒, 在一个优秀的测试代码上尝到甜头, 给自己的项目补充了非常整齐的测试用例.

[quote, 杨晓辰, 2019-03-08 新项目对同学们提升很大]

新项目真的能给人带来很大的提升, 尤其在一个严格要求下的新项目.

代码书写的传授在新项目里是非常高效的.

大概是自己在一个干净的环境, 也会尽力来保持整洁.

当然, 前提是这个项目由一个作为经验丰富的实践家的高级别工程师把控.

话外之意, 有一些高级工程师, 在真正的业务开发中实践较少, 在实践中总结的方法论不足, 不够优秀.

人家都转管理了, 哪有功夫跟着你泥塘里打滚.

[quote, 杨晓辰, 2019-03-08 提升整体大局观]

整体大局观, 怎么才能考虑全面, 怎么才能有高度.

一个很重要的一点是获取更多信息, 从业务上来讲, 产品的远期规划, 近期变动, 公司对现有业务的新的思考. 其他部门的业务现状. 最后行业现状等等.

从技术上来讲, op 的职责划分, 网络线路, 机房现状.

总之, 获取的信息越多, 越有利于做判断, 下结论, 以上只是这个规则在软件开发上的应用, 在其他领域, 也是吃的开的.

但是反过来讲, 要求开发人员做到这些, 要求太高了. 明明应该是各司其职, 结果让开发人员全包. 就因为开发同学是最接近真实实现的. 无法调和.

[quote, 杨晓辰, 2019-03-26 review 代码有感]

写代码优雅果然不是一蹴而就的.

没有亲身体会是不行的.

[quote, 杨晓辰, 2019-04-10 review 代码有感]

写代码时要告诉自己, 代码是给别人读的, 换位思考, 把自己的意图展示出来, 把自己的意图展示出来, 把自己的意图展示出来.

[quote, 杨晓辰, 2019-04-16 杂乱业务设计有感]

找到一个合适的设计很重要, 但是知道当前的设计不合适更重要. 只有指导不合适, 才会抓耳挠腮, 辗转反侧, 去找到一个合适的设计.

[quote, 杨晓辰, 2019-04-25 杂乱业务设计有感]

一个复杂多变的业务一定要进行抽象梳理, 找出不变的东西, 核心的流程. 流程上的细节处理通过各种策略模式来实现.

[quote, 杨晓辰, 2019-04-26 杂乱业务设计有感]

一个事情没想清楚, 不要往大了做, 拆系统

[quote, 杨晓辰, 2019-04-26 杂乱业务设计有感]

不要以程序不报错为目标写代码, 要以逻辑正确为目标写代码.

[quote, 杨晓辰, 2019-04-30 杂乱业务设计有感]

写代码决不能只看自己这一块, 要往上游多看, 往下游多看, 才能写的正确.

[quote, 杨晓辰, 2019-05-05 杂乱业务设计有感]

创建请求凭证跟发起请求不要在同一个事务中.

可能需要一个全局的异步补偿逻辑注册中心.

[quote, 杨晓辰, 2019-05-06 杂乱业务设计有感]

写单测是对系统逻辑的 review

能顺利写出单测, 说明开发对系统逻辑了解, 业务逻辑设计的时候就想好了怎么用.

[quote, 杨晓辰, 2019-05-06 杂乱业务设计有感]

写代码要让别人知道自己在做什么, 而不是怎么做. 不要让别人通过复杂的逻辑代码, 猜测你在做什么.

举个例子:

if (time == null || time.notAfter('1970-01-02 00:00:00')) {
    time = newTime
}

项目中有个 time 字段, 要求如果没有设置过值, 则这设置为当前时间. 如果改为

if (isInitialTime(time)) {
    time = newTime
}

当别人读到下面这段代码时, 就知道你在做什么, 而不是通过复杂的判断来推断.

[quote, 杨晓辰, 2019-05-06 杂乱业务设计有感]

一个项目, 从产品到开发都没有一个有能力把产品, 业务, 概念, 抽象好的人, 这个产品就没啥可维护性可言了.

最后造成产品各种变动, 开发疲于奔命.

[quote, 杨晓辰, 2019-08-09 封装]

我们总是想封装, 自动化配置, 让他人更少的了解细节. 但同时我们又要求了解实现, 以完成更优的使用.

[quote, 杨晓辰, 2019-10-23 字段命名]

为什么总是强调字段和方法命名? 为了统一语言和概念, 为了表达意图. Name things 是软件开发中最难得两个事情之一.

[quote, 杨晓辰, 2019-05-06 杂乱业务设计有感]

最开始没有订好概念, 没有想清楚, 不坚持原则, 为实现而实现, 后面迭代重构就会连本带利还回来.

[quote, 杨晓辰, 2019-05-06 杂乱业务设计有感]

流程需要更高一层的人来梳理, 更高一层的人深入下层

[quote, 杨晓辰, 2019-12-20 杂乱业务设计有感]

PM 出需求, 要有文档, 原型, user case. user case 可以有 rd 来出.

[quote, 杨晓辰, 2020-01-06 下定义]

下定义本身就是件非常要动脑的事; 把定义写出来做好解释更是费劲. 只有写下来, 才能不被大脑欺骗, 才是把事情真正的想清楚了. 写出来才是想清楚, 才能把概念传播. 避免陷入系统一的陷阱.

[quote, 杨晓辰, 2020-05-15 管理工作中的几个想法]

传递思想, 对齐认知. 是一件难而正确的事.
一个项目上, 要有能去想这个事情的人, 能持续培养, 纠正一个项目的人, 投入感情的人, 而不仅仅是让一个项目或者. 带着感情编程.
写清楚目标, 就是为了避免做着做着不知道自己要干啥. 或者不知道让下属干啥.

[quote, 杨晓辰, 2020-05-15 临时方案]

临时方案总是不可避免的, 但是临时方案也要遵循一些原则:

尽量在外部看起来, 不像一个临时方案. [optional]
一定要思考过完整方案, 或者完整方案的方向. [required]
尽量让临时方案和预期的完整方案在一个方向上. [optional]
思考将临时方案改成完整方案的成本. [required] 最终我们会得到一个容易拆除, 容易替换, 对本体基本无害的方案.

[quote, 杨晓辰, 2021-08-13 ]

好的设计，代码千篇一律。坏的设计就是人类思维精华大赏所以我不喜欢去总结和报告一个项目里各种各样的问题及影响，我只想推出我认为合理的设计

[quote, 杨晓辰, 2021-08-13 ]

对于 saas 平台而言，不一定非要对业务了解的面面俱到，一个业务进来之后可能自己也都没想好，然后在运行时慢慢完善。我们能够支持他们做这个优化完善的过程即可。说到底，我们需要一个可维护性好的，能够持续改进的系统

[quote, 杨晓辰, 2021-08-18 ]

抽象存储层，强行进行抽象，提升业务拓展性。低代码、无代码。

评论