# SmallCompanyJavaManual

**Repository Path**: xuzhouwang/SmallCompanyJavaManual

## Basic Information

- **Project Name**: SmallCompanyJavaManual
- **Description**: 我工作的小公司，记录下一些工作中的经验
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2020-09-06
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# SmallCompanyJavaManual

## 1. 概述
```
我想记录一些开发原则，这些原则既利于个人研发效率的提供，也利用团队，甚至是整个公司或者行业从业提供一些借鉴。这个思路来自于2个点：

    1. 我对达利欧《原则》这本书的阅读 
    2. 我对自我研发效率的怀疑，我每天在做什么的思考，可能这些思考存在共性
基于以上2个点，我开始在项目中写readme，写一些项目规范和自己遵守的事。但是，做为一个程序员，应该遵守的事情太多，例如《effective XXX》
或者《阿里巴巴编程规范》等等，而那里中的点我又100%的吃透，故这里只记录一些我个人以为有一些个人理解的规则。

这里整体有个大原则：每条规则都必须遵守，每条规则都可以破。什么时候去OPEN，这是一种艺术。
```

## 2. 内容范围

```
这份规则的出现，是基于一个自己思考的一个议题：“需求转化为可运行系统工程化“，这个可能就是软件工程的另一种说法，让我自己更加通俗易懂。
我们coding，不就是完成需求嘛？对工程化的理解，又可以转化为三个层次：1. 可量化，2. 存在转化公式，3. 存在sigma；这里会产生出另外一
个议题：“从可运行系统到满足需求的可运行系统来得快，还是从需求到可运行系统来的快？”，同时，在这个新议题上添加多少个不同的约束，会产生
多少不同的结果。规则来自于对上面问题的思考。

其二业务存在各种的软件工程方法学，从老板的角度来说，只要一个字，那就是“Kuai”，所以“敏捷开发”占了很多命名上的便宜，取名字很重要（LOL）。
然而更深层次的思考，其实就是效率问题，再进一步，就是公司的组织设计问题。软件开发效率的提升，就是公司组织效率的提升。所以所有方法学，其实
都是“组织效率方法学”，在组织管理里，我们讨论了如何沟通，如何协作，如何执行等等问题。而软件工程方法学也就只是这些内容和加一些领域知识。这
里就推导出一个软件方法学的推广，必然影响着公司的组织文化和组织结构，其他都是伪命题。我这里希望继续将领域驱动设计在小公司中的推广。这里长
期思考如何落地领域驱动设计（741342093@qq.com),可以写这个邮件联系。

其三由于个人的知识体系关系，可以可能主要以JAVA体系相关的应用开发原则，但是在架构和知识层面都是雷同。JAVA只是一种实现，我们聊的都是设计上
的事情，这些事情能否提升我们的效率

其四最后一个问题：“提升效率的最小集是什么？”

```