Group items tagged

语义

版本控制

正确地拼写一个单词是底线

认真地注意 IDE 的 typo 提示（单词拼写错误提示）

state 是整个 Component 状态机中的某一个特定状态，既然描述为了状态机，那么状态和状态之间是互相切换的关系。所以对于初始状态，用 initial 来修饰。

props 是指 Element 的属性，要么是不存在某个属性值后来为它赋值，要么是存在属性的默认值后来将其覆盖。所以这种行为，default 是合理的修饰词。

成对出现的词应该是：show & hide、open & close。

成对出现的正反义词不可混用

在复数的风格上保持一致，要么所有都是 -s，要么所有都是 -list。

涉及到诸如字典（Dictionary）、表（Map）的时候，不要使用复数！

「map」本身已经包含了这层意思，不需要再用复数去修饰它

最好遵从惯例，使用名词组合 success 和 failure

方法命名用动词

属性命名用名词

布尔值类型用形容词

首字母缩写词的所有字母均大写。（如果某个语言环境有明确的业界惯例，则遵循惯例。）

如果什么都没定，也没业界惯例，那么把单词写全了总是不会错的。

React 采用了 componentDidMount 这种过去时风格，而没有使用 componentMounted，从而跟 componentWillMount 形成对照组，方便记忆。

尽量避免使用被动语态。因为被动语态看起来会比较绕，不够直观，因此我们要将被动语态的 API 转换为主动语态。

在文件（file）层面同样如此，一个文件只编写一个类，保证文件的职责单一（当然这对很多语言来说是天然的规则）。

将混杂在一个大坨函数中的两件独立事情拆分出去，保证函数（function）级别的职责单一。

现实中的 OOP 编程场景难免触及副作用。

函数本身的运行稳定可预期

函数的运行不对外部环境造成意料外的污染

SPM 是阿里通用的埋点统计方案

对外部造成污染一般是两种途径：一是在函数体内部直接修改外部作用域的变量，甚至全局变量；二是通过修改实参间接影响到外部环境，如果实参是引用类型的数据结构。

控制读写权限

可省略的参数后置，以及 为可省略的参数设定缺省值

将可省参数后置同样是最佳实践。

重载（overload）

如果入口参数无法进行有效区分，不要选择重载

根本不明白某个 Boolean 标记位是用来干嘛的，这大大降低了用户的开发体验，以及代码可读性。

同时支持单个和批量的处理，可以降低用户的认知负担。

让 setter 型 API 始终返回 this。这是 jQuery 为我们带来的经典启示 —— 通过返回 this，来产生一种「链式调用（chaining）」的风格

对异步操作都返回一个 Promise

对于一些创造出来的、业务特色的词汇，如果不能用英语简明地翻译，就直接用拼音

一致性可以最大程度降低信息熵

打 log 要么都用中文，要么都用英文。

所有的 setter 操作必须返回 this

「大版本号」即「语义化版本命名」<major>.<minor>.<patch> 中的第一位 <major> 位

接口的扩展方式有很多，比如：继承（extend）、组合（mixin）、装饰（decorate）

在逻辑上确实存在派生关系，并且需要沿用基类行为同时自定义行为的，采用重量级的继承

仅仅是扩充一些行为功能，但是逻辑上压根不存在父子关系的，使用组合

装饰手法更多应用于给定一个接口，将其包装成多种适用于不同场景新接口的情况

合理的做法是新增一个 subType 字段

抽象级别一般来说越高越好，将 API 设计成业务无关的，更通用，而且方便扩展

利用多态性（Polymorphism）构建 Consistent APIs。

作为 API 的开发者，一定要提供足够场景适用的 API，来引导我们的用户，不要让他们做出一些出人意料的「妙用」之举

写代码，就像写作，而设计 API 好比列提纲。

Return an ActiveRecord::Relation

Filtering in Ruby is slower

trigger the query and therefore, we lose our Relation

leaving trivial ordering out of scopes all together.

where

where

ActiveRecord provides an easy API for doing many things with our database, but it also makes it pretty easy to do things inefficiently. The layer of abstraction hides what’s really happening.

first pure SQL, then ActiveRecord

Databases can only do fast lookups for columns with indexes, otherwise it’s doing a sequential scan

Add an index on every id column as well as any column that is used in a where clause.

use a Query class to encapsulate the potentially gnarly query.

subqueries

Single Responsibility Principle

Avoid ad-hoc queries outside of Scopes and Query Objects

encapsulate data access into scopes and Query objects

An ad-hoc query embedded in a controller (or view, task, etc) is harder to test in isolation and cannot be reused

to scopes and Query objects

Every databases provides more datatypes than your ORM might have you believe

Both Postgres and MySQL have full-text search capabilities

DI means that you can declare components very freely and then from any other component, just ask for an instance of it and it will be granted

do test-driven development iteratively in AngularJS!

only do DOM manipulation in a directive

with ngClass we can dynamically update the class;

ngBind allows two-way data binding;

ngShow and ngHide programmatically show or hide an element;

The less DOM manipulation, the easier directives are to test, the easier they are to style, the easier they are to change in the future, and the more re-usable and distributable they are.

still wrong.

Before doing DOM manipulation anywhere in your application, ask yourself if you really need to.

a few things wrong with this

jQuery was never necessary

use angular.element and our component will still work when dropped into a project that doesn't have jQuery.

just use angular.element

the element that is passed to the link function would already be a jQuery element!

directives aren't just collections of jQuery-like functions

Directives are actually extensions of HTML

If HTML doesn't do something you need it to do, you write a directive to do it for you, and then use it just as if it was part of HTML.

think how the team would accomplish it to fit right in with ngClick, ngClass, et al.

Don't even use jQuery. Don't even include it.

ry to think about how to do it within the confines the AngularJS.

In jQuery, selectors are used to find DOM elements and then bind/register event handlers to them.

Views are (declarative) HTML that contain AngularJS directives

Directives set up the event handlers behind the scenes for us and give us dynamic databinding.

Views are tied to models (via scopes). Views are a projection of the model

In AngularJS, think about models, rather than jQuery-selected DOM elements that hold your data.

AngularJS uses controllers and directives (each of which can have their own controller, and/or compile and linking functions) to remove behavior from the view/structure (HTML). Angular also has services and filters to help separate/organize your application.

Think about your models

Think about how you want to present your models -- your views.

Attach a controller to each view (using ng-view and routing, or ng-controller)

You can do a lot with jQuery without knowing about how JavaScript prototypal inheritance works.

jQuery is a library

AngularJS is a beautiful client-side framework

VMware offers a Cloud Provider known as the vSphere Cloud Provider (VCP) for Kubernetes which allows Pods to use enterprise grade persistent storage.

A vSphere datastore is an abstraction which hides storage details (such as LUNs) and provides a uniform interface for storing persistent data.

the datastores can be of the type vSAN, VMFS, NFS & VVol.

VMFS (Virtual Machine File System) is a cluster file system that allows virtualization to scale beyond a single node for multiple VMware ESX servers.

NFS (Network File System) is a distributed file protocol to access storage over network like local storage.

vSphere Cloud Provider supports every storage primitive exposed by Kubernetes

Kubernetes PVs are defined in Pod specifications.

The biggest problem is that many long-running branches emerge that all contain part of the changes.

It is a convention to call your default branch master and to mostly branch from and merge to this.

Nowadays, most organizations practice continuous delivery, which means that your default branch can be deployed.

Continuous delivery removes the need for hotfix and release branches, including all the ceremony they introduce.

Merging everything into the master branch and frequently deploying means you minimize the amount of unreleased code, which is in line with lean and continuous delivery best practices.

GitHub flow assumes you can deploy to production every time you merge a feature branch.

You can deploy a new version by merging master into the production branch. If you need to know what code is in production, you can just checkout the production branch to see.

Production branch

Environment branches

have an environment that is automatically updated to the master branch.

deploy the master branch to staging.

To deploy to pre-production, create a merge request from the master branch to the pre-production branch.

Go live by merging the pre-production branch into the production branch.

Release branches

work with release branches if you need to release software to the outside world.

each branch contains a minor version

After announcing a release branch, only add serious bug fixes to the branch.

merge these bug fixes into master, and then cherry-pick them into the release branch.

Merging into master and then cherry-picking into release is called an “upstream first” policy

Tools such as GitHub and Bitbucket choose the name “pull request” since the first manual action is to pull the feature branch.

Tools such as GitLab and others choose the name “merge request” since the final action is to merge the feature branch.

the merge request automatically updates when new commits are pushed to the branch.

If the assigned person does not feel comfortable, they can request more changes or close the merge request without merging.

In GitLab, it is common to protect the long-lived branches, e.g., the master branch, so that most developers can’t modify them.

After you merge a feature branch, you should remove it from the source control software.

Having a reason for every code change helps to inform the rest of the team and to keep the scope of a feature branch small.

For example, the issue title “As an administrator, I want to remove users without receiving an error” is better than “Admin can’t remove users.”

create a branch for the issue from the master branch

If you open the merge request but do not assign it to anyone, it is a “Work In Progress” merge request.

Start the title of the merge request with [WIP] or WIP: to prevent it from being merged before it’s ready.

When they press the merge button, GitLab merges the code and creates a merge commit that makes this event easily visible later on.

Suppose that a branch is merged but a problem occurs and the issue is reopened. In this case, it is no problem to reuse the same branch name since the first branch was deleted when it was merged.

GitLab closes these issues when the code is merged into the default branch.

If you have an issue that spans across multiple repositories, create an issue for each repository and link all issues to a parent issue.

use an interactive rebase (rebase -i) to squash multiple commits into one or reorder them.

Rebasing creates new commits for all your changes, which can cause confusion because the same change would have multiple identifiers.

if someone has already reviewed your code, rebasing makes it hard to tell what changed since the last review.

it is a bad idea to rebase commits that you have already pushed.

If you revert a merge commit and then change your mind, revert the revert commit to redo the merge.

Often, people avoid merge commits by just using rebase to reorder their commits after the commits on the master branch.

Using rebase prevents a merge commit when merging master into your feature branch, and it creates a neat linear history.

every time you rebase, you have to resolve similar conflicts.

A good way to prevent creating many merge commits is to not frequently merge master into the feature branch.

keep your feature branches short-lived.

If your feature branches often take more than a day of work, try to split your features into smaller units of work.

You could also use feature toggles to hide incomplete features so you can still merge back into master every day.

Your codebase should be clean, but your history should represent what actually happened.

If you rebase code, the history is incorrect, and there is no way for tools to remedy this because they can’t deal with changing commit identifiers

Commit often and push frequently

You should push your feature branch frequently, even when it is not yet ready for review.

A commit message should reflect your intention, not just the contents of the commit.

each merge request must be tested before it is accepted.

test the master branch after each change.

If new commits in master cause merge conflicts with the feature branch, merge master back into the branch to make the CI server re-run the tests.

Do not merge from upstream again if your code can work and merge cleanly without doing so.