在路上...

软件开发的主要风险不是来自技术层面，而是在于项目计划和需求分析。做好前期的准备工作，能最大程度地降低风险！

<br />      因为.Net和Java是国内市场占有率最高的两门技术，对于准备学习编程语言的初学者来说，.Net和Java是初学者首先考虑的两门技术，因此很多人一遍遍的问“学.Net还是学Java”，社区中也每天都有“.Net控”在唱衰Java，也有“Java控”在唱衰.Net，一时间硝烟四起，让初学者更加迷惑。<br />　　做为一个.Net、Java、Delphi、Python、PHP等语言都进行过有一定复杂度的项目开发的人来说，我对任何一门语言都没有宗教式狂热崇拜，因此我也相对理性的对

1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。 　　2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行

老外讲解验收测试（Acceptance Testing)和单元测试(Unit Testing)。说的很精辟！好好学习一下。Acceptance and integration tests tell you whether your code is working an

What makes good unit test?Good Tests should be A TRIP (The acronymn isn't sticky enough - I have a printout of the cheatsheet in the boo

Is Unit Testing worth the effort?Unit testing is a lot like going to the gym. You know it is good for you, all the arguments make sense,

In a sentence: Code coverage tells you what you definitely haven't tested, not what youhave.Part of building a valuable unit test suite

Synergy/CM用了已经两年多的时间了，两年多的时间里，从陌生到熟悉，一些感悟和总结，把它贴出来，也算是对自己这两年的一个总结。其实相对于ClearCase这是一个相对简单许多的配置管理工具。绝大部分的开发人员对这套工具的抱怨，我想是来自于它对传统观念的挑战，并且面对众多

Gerrit 版本维护与代码评审系统的搭建。 最近在公司内部推广Gerrit，趟过不少坑，好记性不如烂笔头，先记下来。   注：本文是在Windows Server 2016下进行的验证，Linux平台大同小异。 准备工作：安装Git, 安装Java。 一、安装Apache 下载 Apache:https://www.apachehaus.com...

最近公司要求重新回顾单元测试的实际效果，作为一个开发经理，我个人对单元测试也有很多疑惑。就个人而言，我自己也写过很多单元测试，也鼓励程序员写单元测试，但实际效果似乎不尽如人意。因此，写了这篇短文，想和大家一起探讨。1. 背景介绍 我所在的公司是一家外资软件公司，主要工作是开发一个复杂的在线系统(java based web applicaiton). 该系统的主要特点是：定制化程度比较高，业务逻辑相当复杂。系统的技术栈是Struts, EJB (JBo

Ask, “What Would the User Do?” (You Are Not the User)WE ALL TEND TO ASSUME THAT OTHER PEOPLE THiNK LiKE US. But they don’t. Psychologists call this the false consensus bias. When people think or act differently from us, we’re quite likely to label them

1.做前期准备活动的开发或管理人员并不具备完成这一任务的专业技能。2.程序员“尽快编码的欲望。3.管理都对计划和需求的漠视。 

McConnell在《代码大全》中的一个十分贴切的比喻：程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。我们用真实的食物链来比喻软件食物链。在健康的生态环境中，海鸥吃新鲜的鲑鱼。这对海鸥是营养丰富的大餐，因为鲑鱼吃的是新鲜的青鱼，而青鱼吃的是新鲜的水蝽。这是一条健康的食物链。在软件开发中，如果食物链的每一级都有健康的食物，那么最终就会获得由快乐的程序员编写

问题定义在具体的需求分析工作之前，而需求分析是对所定义的问题的深入调查。问题应该用客户的语言来书定，从客户的角度来描述问题。如果没有一定义良好的问题，你努力解决的可能是一个错误的问题。

在构建期间，要最好地应对需求变更，有以下一些可以采用的方式。使用本节末尾的需求核对表来评估你的需求的质量  如果你的需求不够好，那么就停止工作，退回去，先把它做好，再继续前进。当然，因为在此期间你会停止编码，所以感觉似乎进度会落后。不过，假设你正开车从芝加哥到洛杉矶，突然看到纽约的路牌，那么停下来查看路线图是浪费时间吗？当然不是，如果没有对准正确的方向，那就要停下来检查一下路线9。确保每一

这张需求核对表包含了一系列的问题——问问自己项目的需求工作做得如何。本书并不会告诉你如何做出好的需求分析，所以列表里面也不会有这样的问题。在开始构建之前，用这份列表做一次“心智健全”检查，看看你的地基到底有多坚固——用“需求里氏震级”来衡量。 并不是核对表中所有的问题都适用于你的项目。如果你做的是一个非正式项目，那么你会发现有些东西根本就不需要考虑。你还会发现一些问题你需要考虑，但不需要做出正式的

      医生比病人更了解疾病的危险。同理，开发者比其它涉众（经理，营销人员，用户）更了解糟糕设计和代码的风险，因为你比他们更加专业，那就请你主动做好你的分内事。我们称之为专业精神。      如果别人不理解你的工作，你有责任帮助别人了解！只有当别人了解你的工作，才能更好的配合你，双方才得以提高效率。

先求运行，再求正确，最后求快！

<br />下面这段文字来自《程序员修炼之道——从小工到专家》的摘抄。<br /><br />你不可能写出完美的软件<br />当每个人都要确实对你不利是，偏执就是一个好主意。<br />                                            ——Woody Allen<br />那么，给定了这个让人压抑的现实，注重实效的程序员怎样把它转变为有利条件？<br />……<br />每个人都知道只有他们自己是地球上的好司机。所有其他的人都等在那里要对他们不利，这些人乱冲停车标志、

<br />我先说说我的管理理念，我认为第一件事就是将“管理”这两个字扔了，没有人愿意让别人管的，所以你的企图去管人就已经让你进入困境，作为领导，重要不是学习什么管理技巧，而是要掌握正确领导者应有的心态，那就是以帮忙自己下属成功为自己的成功，没有这个心态，你整天只会在一些人际关系里面折腾：）<br /> <br />作为领导，你要将团队的目标勾画清楚，然后帮助你每一个下属充分了解他的岗位的成功标准，然后就帮助他们去取得这个成功，在执行过程中，不断给你下属提出及时的反馈，但主要是鼓励为主，千万

本文采用docker-compose配置，如直接使用dockr run....类同。创建docker-compose.yml，内容如下：web:image: 'gitlab/gitlab-ee:latest'container_name: gitlabrestart: alwayshostname: 'localhost'environment:GITLAB_O...