软件开发中的注意事项(常见问题整理)

一、函数定义原则

1、一个函数/方法只做一件事情,不能将多个事情放在一个函数中处理(单一职责原则 SRP)

函数/方法的最小粒度是功能,函数在设计/定义的时候,不能将多个功能柔进一个函数里面,这样函数会变得得膨胀,增加了函数的耦合性,不便于函数管理维护。

例如,有这么一个业务逻辑:用户每天来网站阅读文章,当阅读完毕不同的10篇文章之后,就给他增加10个用户积分。

这个业务逻辑可以拆分为4个功能,也就需要定义为4个函数/方法来实现。

Continue reading "软件开发中的注意事项(常见问题整理)"

在PHPStorm中使用Lge_CodeSniffer(Linux+Windows)

在PHPStorm中使用Lge_CodeSniffer其实相当于在PHPStorm中启用PHP_CodeSniffer检测,并设置检测标准为Lge即可。

在开始本篇文章之前,请先在本地安装好 PHP_CodeSniffer + Lge_CodeSniffer,请参考:

1、Windows:Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Windows)

2、Linux:Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Linux)

Continue reading "在PHPStorm中使用Lge_CodeSniffer(Linux+Windows)"

Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Linux)

Lge_CodeSniffer是基于PHP_CodeSniffer的自定义编码规范检测脚本,编码规范基于PSR-2,对于少部分编写风格做了自定义调整,PSR-2 规范请参考:http://www.php-fig.org/psr/psr-2/,自定义Lge编码规范请参考PDF编码规范文件

本文是在Linux下配置PHP_CodeSniffer+Lge_CodeSniffer代码检测工具的介绍,如果是Windows下的配置,请参考我的另外一篇文章:Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Windows)Continue reading "Lge_CodeSniffer/PHP_CodeSniffer的安装配置使用(Linux)"

Gitlab的server端hook简要使用说明

Gitlab的server端hook配置大体步骤是这样的:

1、在gitlab的server端要配置server端hook的项目目录下新建一个 custom_hooks 目录;

2、在custom_hooks目录下新建post-receive钩子文件,chmod该文件的权限为777;

3、在post-receive钩子文件中添加相应的逻辑;

补充说明:gitlab或者github的一个特性是, projectX.git如果是项目的repo地址,那么,与之对应的wiki项目也有一个git的repo地址, 遵循一个命名convention, 即如果项目的地址是projectX.git,那么wiki的项目地址就是projectX.wiki.git, 我们的server端hook的执行逻辑根据这一convention而来;

Continue reading "Gitlab的server端hook简要使用说明"

Git Hooks

和其它版本控制系统一样,Git 能在特定的重要动作发生时触发自定义脚本。 有两组这样的钩子:客户端的和服务器端的。 客户端钩子由诸如提交和合并这样的操作所调用,而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。 你可以随心所欲地运用这些钩子。

安装一个钩子

钩子都被存储在 Git 目录下的 hooks 子目录中。 也即绝大部分项目中的 .git/hooks 。 当你用 git init 初始化一个新版本库时,Git 默认会在这个目录中放置一些示例脚本。这些脚本除了本身可以被调用外,它们还透露了被触发时所传入的参数。 所有的示例都是 shell 脚本,其中一些还混杂了 Perl 代码,不过,任何正确命名的可执行脚本都可以正常使用 —— 你可以用 Ruby 或 Python,或其它语言编写它们。 这些示例的名字都是以 .sample 结尾,如果你想启用它们,得先移除这个后缀。

把一个正确命名且可执行的文件放入 Git 目录下的 hooks 子目录中,即可激活该钩子脚本。 这样一来,它就能被 Git 调用。 接下来,我们会讲解常用的钩子脚本类型。

Continue reading "Git Hooks"

Git rebase

git rebase是对commit history的改写。当你要改写的commit history还没有被提交到远程repo的时候,也就是说,还没有与他人共享之前,commit history是你私人所有的,那么想怎么改写都可以。

而一旦被提交到远程后,这时如果再改写history,那么势必和他人的history长的就不一样了。 git push的时候,git会比较commit history,如果不一致,commit动作会被拒绝,唯一的办法就是带上 -f参数,强制要求commit,这时git会以committer的history覆写远程repo,从而完成代码的提交。虽然代码提交上去了,但是这样可能会造成别人工作成果的丢失,所以使用 -f参数要慎重。

楼主遇到的问题,就是改写了公有的commit history造成的。要解决这个问题,就要从提交流程上做规范。

Continue reading "Git rebase"

面向服务(SOA)与微服务(MAS)架构

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。

Continue reading "面向服务(SOA)与微服务(MAS)架构"

Mecurial(hg)学习要点(团队管理)

Mecurial的基本介绍可以查看百度百科,以下知识是个人对Mecurial经验的简要说明。
Mecurial(hg)是一款分布式版本控制软件,可以称之为轻量级的git,比git和svn都要简单易学,但是在版本控制的理念上与svn有所区别。

分布式版本控制的核心理念是“分支”和“合并”,每个开发者在本地拥有很多开发分支,最常见的一个分支可以是一个功能的开发或者一个BUG的修改,每个分支有一个独立的名称,相互之间相互独立、互不影响。当分支代码开发完成之后,需要将该分支的代码“合并”到主分支,该主分支即是软件最终的分支。需要发布的功能都需要合并到该主分支,不发布的功能或修改不用合并。

Mecurial在Linux开发环境下一般使用命令行完成版本控制操作,在Windows环境下可以使用命令行或者图形界面,图形界面的话会隐藏所有的命令细节。

Continue reading "Mecurial(hg)学习要点(团队管理)"

Git学习要点(团队管理)

一、Git介绍

Git的基本介绍可以查看百度百科,以下知识是个人对Git经验的简要说明,以方便帮助大家快速学习。

分布式版本控制的核心理念是“分支”和“合并”,每个开发者在本地拥有很多开发分支,最常见的一个分支可以是一个功能的开发或者一个BUG的修改,每个分支有一个独立的名称,相互之间相互独立、互不影响。当分支代码开发完成之后,需要将该分支的代码“合并”到主分支,该主分支即是软件最终的分支。需要发布的功能都需要合并到该主分支,不发布的功能或修改不用合并。

Git在Linux开发环境下一般使用命令行完成版本控制操作,在Windows环境下可以使用命令行或者图形界面(TotoiseGit)。
图形界面的话会隐藏所有的命令细节,所以建议大家学习的时候以命令为主,这样知其然并知其所以然。

二、Git配置

• (Linux) /etc/gitconfig文件:系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项,读写的就是这个文件
• (Linux) ~/.gitconfig文件:用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项,读写的就是这个文件
• 当前项目的 git 目录中的配置文件(也就是工作目录中的 .git/config 文件): 这里的配置仅仅针对当前项目有效,每一个级别的配置都会覆盖上层的相同配置,所以.git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量

用户信息设置(必须)

文本编辑器(可选,默认是vim)

差异分析工具(可选,默认是vim)

输入一次后保存用户名和密码

查看已有的配置信息

Continue reading "Git学习要点(团队管理)"