首页 (27) - 码厩

#817 一些微不足道的开发经验

开发者开发者的思考 2022-06-17

设计

方案设计要留有余地，在满足需求的前提下，尽量更加通用一点。
前提是要认真理解需求，认真理解现有的架构，多想想，再多想想。
但是也要避免过早地、过度地优化。
我们应该了解对团队来说更有价值的事情是什么，然后把主要的精力放在更加有价值的业务上。
基于这个认知，我们就能更清楚需求到底是什么，应该如何去设计。

编码

遵守业界通用的编码规范非常重要。
代码可读性非常重要，简洁、美观。
如果一个逻辑有好多步骤，尽量分成几个更小的单元实现。
避免写重复的代码，将重复的部分抽离出来（有时需要考验设计能力）。
关键的点打印日志很重要，尤其是功能刚上线的时候，嫌多的话可以后面调整。

协作

沟通非常重要，沟通非常重要，沟通非常重要。
要通知到相关人，不只是消息发送出去就行，要确保他们真的理解你的意思。
有些时候，作为经手人，还需要继续跟踪，了解他们的后续操作以及整件事情的进展。
对接时须对细节再三确认，然后形成约定，比如接口提供方将小数统一整理成保留两位，接口提供方应该保证默认排序规则。
如果不确认，形成约定，日后有变更，可能就是意想不到的坑。
如果是一些简单的工作，两边都处理一下也未尝不可。

工程

开发的预估时间往往是比较保守，及时你认为这个时间绝对没问题，也往往免不了延期。
可能是需求会变化，可能是方案的实现中会遇到一些变数，还可能是有别的事情会占用时间。
即便是在公开会议上也应该顶住压力，留有余地。如果真的是非常紧急，至少需要确保优先级真的比较高。

#816 号称 Redis 25 倍性能的 DragonflyDB

DB 2022-06-13

之前的 KeyDB 宣称是 Redis 的 5 倍性能，这次可好，DragonflyDB 说是 25 倍。

相对于 Redis 服务，主要的改进是自带集群，可以利用多核，接口层面完全兼容 Redis (还支持 Memcached API，只是默认关闭)。
而 Redis 需要利用好多核就必须要有丰富的经验、额外的配置，以及更复杂的集群管理。
所以我觉得这个 DragonflyDB 是非常有意义的。

https://github.com/dragonflydb/dragonfly
https://dragonflydb.io/

docker run --network=host --ulimit memlock=-1 docker.dragonflydb.io/dragonflydb/dragonfly

https://zhuanlan.zhihu.com/p/554409312
是什么让Redis“气急败坏”回击：13年来，总有人想替Redis换套新架构

#815 Go iota

Golang 2022-06-10

type Weekday int

const (
    Sunday Weekday = iota // 0
    Monday                // 1
    Tuesday               // 2
    Wednesday             // 3
    Thursday              // 4
    Friday                // 5
    Saturday              // 6
)

func (day Weekday) String() string {
    names := [...]string{
        "Sunday",
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday",
        "Saturday",
    }

    if day < Sunday || day > Saturday {
        return "Unknown"
    }

    return names[day]
}

type FileSizeUnit int

const (
    _ = iota // 忽略第一个值 0，让后续常量从 1 开始递增
    KB FileSizeUnit = 1 << (10 * iota)  // 1 << (10*1) = 1 << 10 = 1024
    MB                                  // 1 << (10*2) = 1 << 20 = 1048576
    GB                                  // 1 << (10*3) = 1 << 30 = 1073741824
    TB                                  // 1 << (10*4) = 1 << 40 = 1099511627776
)

package main

import "fmt"

func main() {
    {
        const (
            a = iota
            b
            c
        )
        fmt.Printf("%+v\n", []int{a, b, c})
        // [0 1 2]
    }
    {
        const (
            a = 1
            b = iota
            c
        )
        fmt.Printf("%+v\n", []int{a, b, c})
        // [1 1 2]
    }
    {
        const (
            a = 1
            b = 2
            c = iota
        )
        fmt.Printf("%+v\n", []int{a, b, c})
        // [1 2 2]
    }
    {
        const (
            a = 1
            b = iota
            c = iota
        )
        fmt.Printf("%+v\n", []int{a, b, c})
        // [1 1 2]
    }
}

总结

首次出现是这个常量块中变量的顺序（0 开始）
后面的常量如果没有定义，就表示是按照前面的常量定义来，只是 iota 代表的值 + 1 了
如果想跳过一个值，可以使用下划线

#814 转载：中国程序员容易发音错误的单词

开发者英语 2022-06-06

不看不知道，一看，读错好多单词。

#813 winget: Windows 包管理工具

包管理工具 Windows 2022-06-04

winget list
winget list -?
winget search xxx     # 搜索
winget install xxx    # 安装
winget upgrade        # 列出 upgradable 包
winget upgrade xxx    # 升级指定包
winget upgrade --all  # 升级

winget
Windows 程序包管理器 v1.3.2691
版权所有 (C) Microsoft Corporation。保留所有权利。

WinGet 命令行实用工具可从命令行安装应用程序和其他程序包。

使用情况: winget [<命令>] [<选项>]

下列命令有效:
  install    安装给定的程序包
  show       显示包的相关信息
  source     管理程序包的来源
  search     查找并显示程序包的基本信息
  list       显示已安装的程序包
  upgrade    显示并执行可用升级
  uninstall  卸载给定的程序包
  hash       哈希安装程序的帮助程序
  validate   验证清单文件
  settings   打开设置或设置管理员设置
  features   显示实验性功能的状态
  export     导出已安装程序包的列表
  import     安装文件中的所有程序包

如需特定命令的更多详细信息，请向其传递帮助参数。 [-?]

下列选项可用：
  -v,--version  显示工具的版本
  --info        显示工具的常规信息

可在此找到更多帮助： https://aka.ms/winget-command-help

#812 常见的程序设计语言

开发者 2022-06-03

根据最新的 TIOBE 数据, 分析前面 50 中语言。
具体排名的意义对我们来说到不大，只是用来做一个比较热门语言的清单。

#811 开发者笔记本的选择

开发者 2022-06-01

基本要求

价格在 5000 ~ 8000
11 代 / 12 代英特尔 CPU，核数多一些（8+）
16G / 32G 内存
512G 固态硬盘
独立显卡
屏幕：至少 14 英寸

品牌筛选

首先确定品牌范围：惠普，戴尔，联想，ThinkPad，华为，小米

小米，华为，ThinkPad 都是四核八线程

剩下：

联想拯救者 Y7000P 2022
i5 版 6.8，i7 版 7.8

#810 思考：代码优先还是产品优先

开发者 2022-05-22

阮一峰最新的《科技爱好者周刊》中提到一个观点：代码优先和产品优先。大概是说代码优先程序员比较注重技术和代码，产品优先程序员则是更注重解决的问题。阮一峰明显是认为应该产品优先。

我看后感觉我就是文章的批判对象，从而进行了一个反思。但是我思考之后认为阮一峰说的并不全对，我的做法没有什么问题。

公司的目标，或者说研发中心的目标，就是用技术解决问题。而研发中心的开发人员的职责就是设计可行方案，然后通过代码来实现这个方案。
研发人员并不直接面向市场，面向用户，大多数时候也不负责产品的设计。甚至有些时候，研发人员都不参与产品设计方案评审。

理论上，如果我们能够吃透产品的设计，那么对开发工作肯定是有利的。但是我们的时间精力是非常有限的，平衡工作和生活之余，还有挤出时间来自学。
而且，对产品的思考更多的是产品设计人员的工作，让开发者把精力放在对产品的思考上有点不切实际。

确实，“如果产品不好用，代码也不会好”。但是，我们所处的位置真的很难左右公司的产品策略。让产品好用这个目标，在我们这边的操作空间就是写好自己代码。
所以对于开发者来说，代码优先几乎等同于产品优先，并不冲突，更好的代码等于更好的产品。

开发者根据项目背景和工期安排设计方案就行了。需要在代码和产品上做取舍的，是技术部门负责人的工作。

我知道很多人都说打工人要有更高层次的思维，思考更多，做得更多，才能有更好的发展。我自己确实也是这么想的，积极主动的承担起份外的工作，将能创造更大的影响力，然后决定你在组织中的角色。但我觉得这是工作之余的一些额外的投入，和日常开发工作无关，没有什么产品优先的问题，开发者还是应该把主要精力都放在自己的代码上。

我们应该投入一些精力去了解公司的产品设计，以及各项重点数据。
产品不是一成不变的，所以这是一个需要持续投入精力去做的事情。
我们还应该关注其他公司同事的工作，尤其是任务相关的其他同事。

#809 重启 GNOME

Linux GNOME 2022-05-17

Restart GNOME without rebooting

Ctrl–Alt–Backspace
sudo /etc/init.d/gdm restart
killall gnome-panel

以上方法没有用，下面这个方法挺好的 (My Choice)：

killall -HUP gnome-shell

在桌面还有响应的时候（比如桌面组件出了一些乱码之类的问题）：

Alt + F2, and restart/r

参考资料与拓展阅读

#808 Pipenv 生成 requirements.txt

Pipenv Python 2022-05-16

pipenv requirements > requirements.txt && pipenv requirements --dev-only > requirements-dev.txt

一	二	三	四	五	六	日