性能监控 以及 开发自动化 -- Java

前一阵在找性能监控的工具，自己对Java比较关注点，因此在java上找到一些工具，比较著名的就是JProfiler，在Java1.5以后，在JDK中也带有一些性能监控的工具，如jconsole等，还有一些开源的产品，但是JProfiler分析的程度比较深，因此使用的效果相对好点。

（十个最好的Java性能故障排除工具 ： http://www.kuqin.com/developtool/20080721/11869.html）

在进行性能监控工具的查找中，发现问题的根源很多时候还是出在开发上面，在开发时对性能不重视，以为Java有内存自动回收（gc）就万无一失了，对Java的内存分配方式、回收方式都不去了解它，造成开发出来的程序问题一大堆。

网上看到IBM有一个开发自动化的专题（以前看到过，但是没有这次这么有感触），要仔细的揣摩一下

http://www.ibm.com/developerworks/cn/

• CheckStyle 报告与项目预定的编码标准的偏离度。
• CPD 报告代码重复。
• JavaNCSS 可以帮助团队专注于更高级的代码复杂性领域。

BugFree 2.0.2 指派人员支持多个邮件发送

测试小组，每人负责某几个产品，开发人员要知道什么产品谁负责也是比较讨厌的。一个开发人员同时参与几个产品的开发（不同产品有不同的人员负责测试），而且开发人员更换的有时也比较快，又要重新培训也比较麻烦。因此一开始规定，将所有的测试人员邮件编辑成一个小组，开发人员版本提交的时候，发送到这个测试小组。测试人员收到邮件，如果是自己负责测试的产品就进行测试。

一段时间用下来，平安无事。有一次客户又提出相同的bug，这个问题早已经解决过了，怎么客户还提这个问题。一路检查下来，发现公司的邮件不正常。

原来开发人员发送邮件，发送给测试小组，测试小组相关人员收到邮件后会进行处理。但是现在负责该产品的测试人员没有收到这个邮件，造成了整个环节上的脱钩，无法联系起来。因此发送邮件通知版本发布还是有问题。现在内部的bug测试使用的是bugFree2.0.2，因此想使用bugfree进行版本提交，这样即使有邮件丢失，测试人员也可以通过检查bugfree工作记录重新拾起来。

原本考虑使用bugfree发送邮件，发送到一个邮箱，测试人员都通过IMAP方式接收这个邮箱的邮件，但是公司内部使用的邮件服务器不支持IMAP服务（shit），只能通过修改BugFree来进行了。

BugFree用的是Php开发的，从未接触过PHP，不过这些脚本式的语言应该可以依样画葫芦来进行处理。

需要修改的地方有：

1. 增加用户，可以输入多个邮件地址

2.修改用户： 可以输入多个邮件地址

3.可以往多个地址发送邮件

看了一下Bugfree的源码，发现一个比较有趣的地方（觉得有趣，估计bugfree的一些功能根本没有使用到）：

1. 增加用户，检查邮件使用的是函数：sysCheckEmailFormat

2.修改用户：发现直接在修改用户的函数中设置了正则表达式进行验证：xAdminEditUser

3.发送邮件：在sysMail函数中，支持用逗号分割多个邮件地址。

既然找出来的这几个地方，就依样画葫芦进行修改（谁叫自己不懂PHP）

找到：sysCheckEmailFormat，将原来直接验证邮件的地方进行修改：

  原来： if(!eregi("^[ ......." , $EmailStr)

  修改成： $EmailList = explode(',', $EmailStr);

                   foreach($EmailList as $Singlemail)

                   {

                       if(!eregi("^[ ......." , $Singlemail) ....

                   }

      

修改用户信息的地方，将直接判断邮件的地方改成用sysCheckEmailFormat进行验证就可以了。

发送邮件的地方看了一下，在接收者的地方没有问题，Bugfree通过逗号进行了分割。但是抄送的地方没有进行判断，在CC的地方按照一样的方式，对每个人的邮件按照逗号进行分割，重新获取邮件地址。

----------------------------------------------------

学习到的知识：

1. PHP中的explode：将字符串变成数组，按照指定的字符进行分割

2. 函数array_diff/array_unique，数组的方法，进行数据判别

3. PHP的输出：在调试过程中，发生错误，但是不知道如何调试，找到的资料：

    通过syslog(LOG_NOTICE, 输出的内容）

    可以在/var/log/message中输出调试信息

4.jsAlert：直接在页面上显示信息出来，没有仔细看这是Bugfree自己写的方法还是php的方法

-----------------------------------

调试过程中，遇到的问题：

1. 原来以为通过分号分割用户的邮件地址，就可以向多个地方进行发送（类似于outlook等发送给多人的方式，实际使用下来不行，后来看到sysMail中用逗号分割，全部改成了逗号）

2. 获取调试信息：

    修改了代码，但是结果不对，无法看到调试信息，上网找了一些资料，自己当前情况最方便的就是用syslog方式输出调试信息

开发语言的选择

昨天讨论后续的开发工作，讨论讨论，就讨论到开发语言的选择上了。

现在的后台有一个系统使用Java+Jython做的，但是目前的技术负责是C++出身，一直认为Java的性能不行，对内存使用、内存管理有局限，一直排挤Java。领导呢对Python的某些功能比较青睐，又从网上找了一些的开源工具，可以节省开发难度，节省开发的工作量，因此想选择使用Python完成其中部分的工作 -- 对领导而言是比较重要的计算功能。

为了这个问题，大家争论不休，意见难以统一。

在这里也记录一下自己在会议上的意见：

自己的意见就是： 采用哪种语言开发应该不是目前最关心的，而且效率不是现在唯一要考虑的因素，需要从以下各个因素上综合考虑：

1. C++语言的效率优势已经不那么明显了：
    现在机器的性能上去了，原来C++效率的优势没有原来这么大了。而且随着语言的不断进化，语言本身的效率也在不断的提高，虽说C++的效率还是比较高，但是各个语言间的效率已经越来越接近了；
   
2. 需要考虑工作进度、公司的人员配备：
   虽说C++语言在效率上还残存一些优势，但是C++的开发周期、开发的工作量，都相对较大 --- 从实际情况来说，这个还是比较客气的说法。每次出产品，C++开发的服务器，都是时间最长最长的，开发人员需要的技术、开发过程中的成本也是最高的，和目前的快速维护、快速增加功能的原则背道而驰。关键的部分（如只能唯一的服务器）、最为核心的部分要用C++开发，达到稳定、高效的目的，这个无可厚非，但是系统中所有的地方都用C++，在开发周期、开发成本上就无法接受；
3. 发挥每种语言的优势：
   每种语言的产生，必定有其出现的道理，有其存在的理由、优势。在开发过程中，要发挥每种语言的优势，进行合理的搭配，达到快速有效的开发，这样才是最合理的配置；
4. 体系结构优于语言的选择：
   现在的开发，尤其是后台支撑系统的开发，已经是体系上的竞争，架构体系的优劣已经远远超越语言的竞争了。
   体系方面，譬如简单的增加一级缓存，带来系统性能的提升、服务能力的提升、吞吐量的提升可能是数个数量级上的提升；而语言的不同，带来的可能仅仅是同一级别、同一层次上的提升；何况通过多种语言的协作，发挥各种语言的优势，不仅能够充分使用到公司目前的资源，而且使用到语言本身的优势，快速推出新功能，尽快的响应市场的呼声。开发语言相争和架构体系上比较起来，相对而言只是一个很局部的问题（目前在架构体系上，可以优化、可以提升的地方太多了）。

最终的结果还是按照在原来的基础上，先完成功能，语言上的选择再议。

GTD --Getting Things Done

最近一阵狂热把工作搬到网上去，主要的原因还是有大量的工作需要在家里进行思考一下（周末不来公司，太远了，一来一回2个多小时，这些时间还不如在家里好好思考一下）。

在网上工作，主要用到的还是google的日历以及google的文档，包括现在在看的google的code源码保留：当然，在google code上只放一些测试代码，公司运行的商业代码不放上去。

在寻找网上任务管理的时候，看到有一个GTD的大家都挺推崇的（以前工作只能在局域网中工作，对现在的这些在线工具都孤陋寡闻了），GTD不知道是什么，在维基百科中查了一下：

相关资源：

http://www.chedong.com/blog/archives/000790.html 车东的blog，我比较喜欢的一个

http://www.rememberthemilk.com 网上的DTD网站，评价很高

维基百科中的注释：

http://zh.wikipedia.org/wiki/GTD：

原来不打算抄的，后来看一下还是抄录过来比较好，以下是维基百科上的内容：

GTD是英文Getting Things Done的缩写，是一种行为管理的方法，也是David Allen写的一本书的书名。

GTD的主要原则在于一个人需要通过记录的方式把头脑中的各种任务移出来。通过这样的方式，头脑可以不用塞满各种需要完成的事情，而集中精力在正在完成的事情。

目录  [隐藏] 1 GTD是关于什么的 2 原则 2.1 搜集 2.2 处理 2.3 组织 2.4 检查 2.5 做 3 工具和技巧 3.1 DIY Planner Hipster PDA 4 引用 5 外部链接 5.1 软件 5.2 Excerpts from Getting Things Done（Business Week）:

[编辑]GTD是关于什么的

和其他时间管理专家不同的是，Allen并不把重点放在设置任务的优先级。他提出制定出在各种环境下的任务列表，例如，制定一个需要打电话的列表，或者在市区才能完成的事情的列表。他也建议任何两分钟之内就能完成的任务应该马上做。

GTD在心理上的好处在于使你需要完成的事情相关的信息易于保存，跟踪和获取。Allen认为导致很多我们在做事的时候碰到的脑力上的障碍的原因是前期的计划不足（举个例子，对任何项目我们需要弄清楚要达到什么目标，还有什么措施需要完成）。

Allen认为我们的脑力上的“提醒系统”相当的低效，很少能够在恰当的时间和地点提醒我们需要做的事情。因此，把“下一步行动”根据场景分类存放在“可信的系统”当中，是一个能使我们在正确的时间得到正确的提醒的手段。在“GTD”中有很多个人的管理小技巧在实行Allen描述的工作流程中很有用的。

一个很概括的对于Allen的书的内容的描述是对于任何事情都准备好:

“把所有事情都从你的脑袋里弄出来。在事情出现，而不是在事情爆发的时候,就做好相关行动的一系列决定。以合适的类别组织好你的项目的各种提醒以及下一步的行动。保持你的系统更新和完整，充分地检查，使你在任何时候都能信任你的对于你正在做（或者不做）的事情直觉的选择。”

[编辑]原则

GTD的核心原则如下：

[编辑]搜集

把任何你需要跟踪或者记住或者做的事情记在Allen称之为‘水桶’的地方：一个收件箱，电子邮箱，磁带，笔记本，PDA，或者它们的组合。把你脑子里的任何东西都拿出来放到你的搜集设备里，准备好做下一步的处理。每星期所有的水桶都应该被至少清空一次。

[编辑]处理

处理你的收件箱要遵循一个严格的工作流程：

• 从最上面开始。
• 一次处理一项。
• 不把任何东西放回收件箱。
• 如果任何一项需要做：

• 做（如果花的时间少于两分钟）
• 委托别人完成，或者
• 把它延期。

• 否则

• 把它存档以便查询，
• 把它扔掉，或者
• 使它成熟以便下一步的处理

两分钟原则：任何事情如果花的时间少于两分钟，那么马上就去做。两分钟是一个分水岭，这样的时间和正式地推迟一个动作所花的时间差不多。

[编辑]组织

Allen描述了一个建议的列表集合，你可以用来跟踪需要关注的项目：

• 下一步行动(Next actions) - 对于每个需要你关注的事项，定好什么是你可以实际采取的下一步行动。例如，如果事项为“写项目报告”，下一步行动可能会是“给Fred发邮件开个简短会议”，或者“给Jim打电话问报告的要求”，或者类似的事情。虽然要完成这个事项，可能会有很多的步骤和行动，但是其中一定会有你需要首先去做的事情，这样的事情就应该被记录在“下一步行动”列表上。较好的做法是把这些事项根据能够被完成的“环境”整理分类，例如“在办公室”,“用电话”,“在商场”.
• 项目(Projects) - 每个需要多于一个实际的行动才能达到的生活或者工作中的“开放式回路”就是一个“项目”.使用跟踪以及周期性的回顾来确保每个项目都有一个下一步的行动进行下去。
• 等待(Waiting for) - 当你已经指派了一个事项给其他人或者在项目进行下去之前需要等待外部的事件，就应当在你的系统当中跟踪以及定期检查是否已经可以采取行动或者需要发出一个提醒。
• 将来／可能(Someday/Maybe) - 这些事情你需要在某个点去做，但是不是马上。例如：“学习中文”，或者“进行一个潜水假期”.

对于跟踪你的预约和委托，一个日历也是重要的；另外，Allen特别推荐日历应该被用在他所谓的“硬工程”上：必须在某个特定的期限之前完成的事情，或者在约定的时间和地点完成的会议和约会.“待办”事项应该用在下一步行动列表当中。

GTD的最后一个关键组织模块是归档系统.“Getting Things Done”书里说如果要用一个归档系统，那它必须得是简单易用和有趣。即使是一张纸，如果你需要用来记录参考信息，如果不属于你已经有的一个目录，也要有自己的文件组织方式。Allen的建议是你可以维护一个按照字母顺序组织的归档系统，这样可以比较容易快速的存储和提取你所想要的信息。

Google的Gmail的用户可以用创建标签的方式来创建“待办事项”和“项目”，这种方式在Bryan Murdaugh的 “Getting Things Done with Gmail” [1]白皮书中有清楚的描述。它保留了很多GTD的相同概念，但是是在在线的电子邮件系统中实施。

[编辑]检查

如果你不至少每天或者只要你有时间就回顾检查，那么你的行动和提醒的列表将会变的毫无用处。以你当时拥有的精力，资源和时间，决定什么是对你来说最重要的事情，然后做。如果你倾向于拖延，你可能会老是做最容易的事情，避免那些难的。为了解决这个问题，你可以一个接一个地做列表上的事情，按照它们的顺序，就象你处理你的收件箱一样。

至少以星期为周期，GTD要求你回顾所有你比较主要的“行动”,“项目”和“等待”的事项，确保所有的新任务或者即将到来的事件都进入你的系统，而且所有的事情都更新到符合最新的情况。Allen建议制作一个难题档案来帮助你更新你关于主要行动的记忆。

[编辑]做

如果你把你的时间都花在组织工作、而不是做它们，那么这样的系统是不好的！David Allen的观点是，如果你可以把必须做的事情，让它变得简单、容易、有趣的话，那你就比较不会拖延、或者被太多的“开放性回路”所压倒。

[编辑]工具和技巧

A slice of '43 Folders'

一个Allen推荐的工具是难题文件夹，用来组织你的GTD的文字工作（也被称为‘43文件夹’）.12个文件夹用来表示每一个月，另外的31个文件夹用来表示每一天。这些文件夹用来帮助提醒你当天的活动。每天你打开表达当天的文件夹。你把所有的事项都拿出文件夹，然后把空文件夹放进下一个月里。这种处理允许你为自己保存提醒的硬拷贝。例如，如果你在这个月的12号有一个音乐会，你可以把票放在第12个文件夹当中。当12号到的时候，它就在那里等着你。

[编辑]DIY Planner Hipster PDA

这是一种用来执行GTD的纸本DIY范本，对于习惯用实体纸本计划的人来说，可作为另一种优质选择。[2]

测试 --- 背后的英雄，流程的改进

昨天又一次感受了测试人员的悲哀。

系统一有问题，领导第一个想到的就是测试人员。昨天领导关心的一个产品发现了一个bug（应该说是没有实现高农恩），就在追问：这个系统怎么测试的？测试人员平时都在干什么？当系统正常运行，甚至运行尚可的时候，都是业务设计人员、系统设计人员、开发人员的功劳，这个时候测试人员就退居2线了，甚至于退居N线了，在考评、奖励上都得不到倾斜，一旦有问题，测试人员就首当其冲，当然不让承担责任。--- 昨天的问题确实是测试中的失误，现在的问题不仅是测试的问题，昨天同样发生部署人员没有按照开发流程出的部署流程操作，造成系统的故障。这些问题累计起来，看上去问题不少，虽说都是可以避免的，但造成了对测试效果的下降，使领导对测试的成果带来怀疑。

还好昨天说了一句：有问题都是测试人员的问题，但测试人员已经发现、已经排除了多少个bug有谁知道。领导也默认接受，为测试人员稍微平反了一下。

但是从这句话中，也看到了自己工作中的失误。

测试人员排查了多少个bug，为什么不能让领导知道？如果领导知道每周测试人员测试了多少个系统、测试了多少个版本、发现了多少个bug，能够让测试的工作有一个具体的量化的数字，从一个侧面、一个系统的角度来体现测试人员的工作量，这个比口头的交流更有说服力 （这个不代表测试的工作不能改进）。

当领导不能发现某项工作的工作量时候：也是需要我们把问题和领导说明白，说清楚，领导也是需要交流、需要培训的，尤其是一项对于他看来很简单，当其实工作量非常非常大，或者涉及面很广、时间拖得很长的时候：

1.譬如目前网站的修改工作，一直以为也就几个页面，弄一下也就几个小时，工作量大一些的也就2，3天的时间； 其实修改牵涉到多个部门共同工作，弄一个会员专区，从开始到结束，用了1个多月，而整个过程中，开发人员开发的只有不到1周的时间，其他的时间都用在业务部门设计、美工美化、外网系统人员部署上面，不把这些时间统计清楚，清一色的算在开发上，说开发人员的工作效率低下，实在是真不知道怎么说了；

2.譬如目前开发的信息流项目：这个正在让测试人员把信息流的功能点用脑图的方式全部列出来---本来测试就要对这么多功能点进行测试的，做一个脑图，将功能精简一下给领导看，说明说明工作量。主要使用到这个系统的其他部门的人员目前也已经参与到培训、客户化测试阶段了，他们看到这个图都吓一跳，简单的几个字已经说明了一切：这么复杂啊，这么多功能。如果只有底下的人知道，领导不知道，干活的人又白辛苦了。

改进措施：

1. 完善测试流程：
   主要对测试的功能点、测试的覆盖面再做一次整理；尤其是经常用的功能、领导关心的功能（是不是有点太功利了，谁让领导具有一票否决权）
   
2. 测试人员的测试工作进行量化：
   将测试人员每周测试了多少系统、测试了多少版本、发现了多少bug进行统计，这样一来可以监督测试人员的工作，二来也让领导知道一下测试的工作进展、测试的工作量，要知道测试人员不是只对某个产品进行测试，公司目前可以算上产品的数量是测试人员数倍都不止，不把这个列出来，领导只看到有问题的产品，而完好的产品看不到（运行正常没有事情，没有人反映问题，领导甚至把这个产品给忘了），对整个部门的工作评价也是不利的；
3. 对每个产品进行错误统计：
   由于开发人员的因素，有些产品质量一直很好，有些产品反反复复的次数占多数，不仅占用测试人员的时间，而且开发小组本身的工作效率也提不高。通过这个统计，把每个产品的质量进行统计，作为对产品组的一个考评依据。
4. 对测试要树立一个评价体系：
   这个是最难的，如果按照bug率来进行统计，如何统计bug率？按照功能模块来限定bug数量，大功能点和小功能点包含的强度不一样的，按照代码行bug数量来统计，现在的系统泥中有我，我中有你，还真是一件麻烦事。上网看一下测试理论是怎么养的，别人是如何进行评价的。

和Eclipse-Mylyn结合的流程管理工具寻找

下载安装了Mylyn，可以在本地管理工作，并且保存每个工作的工作环境。对于个人工作确实不错，但是现在的工作基本上都是团队工作，应该有和Eclipse-Mylyn相结合的工作流程管理的工具，这样可以在一个Team中进行合理的工作分派，工作汇报。

在Mylyn本身的下载页面上，文档是指向TaskTop站点，TaskTop的Starter版本是free的，后台可以和Bugzilla、JIRA、CollaNet，Rally等。

其中就只有Bugizilla是免费的，其他都是要收费的商业软件，不考虑。

除了bugzilla, 还看到有trac，自己在网上也找了找，看到有一个EmForge，有Mylyn的Connector（http://www.emforge.org/project/EmForgeMyLynProvider）。

准备在这几个系统之间比较一下，看哪个更适合我们的使用。

原来bugzilla、trac原来的理解都是一个bug管理系统，现在看介绍也可以对任务的管理（希望是真正的任务管理，譬如一个任务有多个分支，多人同步进行，最后还可以合拢，任务有先后关系，先后依赖关系等。bug系统原来bug只能指派给一个人的）

Emforge看它主页上的介绍是一个workflow-based integrated solution for managing software development process。反正是free的，下来看一下。

安装了Screen Anytime

重新在看程序员杂志，在开源项目中，看到了Screen Anytime，一款运行在Windows平台下，用于监控、管理服务器或者工作站屏幕操作细节的视频日志软件。既然程序员上推荐，就下载了一个感觉一下（http://www.screen-record.com/screen_anytime.htm ）

在：http://www.screen-record.com/download.htm 上下载Screen2Exe，free版本（其他几个版本都是商业软件，不free），使用下来感觉不错。

• 录制时，对其他程序没有什么影响，感觉不到它的存在；
• 最主要的录制结果比较小
  录制了几次1分多钟，生成的exe文件在500-600K之间，比其他的程序生成的要小。
• 结果直接生成exe，播放的时候也不用担心使用机器文件格式兼容性的问题。

于是马上想到了测试，在测试过程中，使用这款软件对测试过程进行记录（原来就是担心截屏结果过大，没有使用）。将测试过程记录下来，可以

1.  便于回忆测试过程，和开发人员交流：
   如果发现问题，进行回放就可以了，不用向以前那样为了重现错误，不断回忆操作过程；或者开发员不在的时候，事后和开发员说他们不承认，至少截获下来，眼见为实（虽然当时的环境不复存在）；
2. 记录测试过程，测试人员不能偷懒：
   将测试过程记录下来，测试人员在测试中的一切操作，如何操作，重复了几次，检查了一些什么功能、检查了一些什么环境参数都被记录下来。在提交测试报告的时候，一同提交测试录像，这样，就是想在测试中偷懒，也要考虑后果。对于测试报告中的每一条测试用例，如果检查的时候觉得有怀疑，也可以通过录像进行播放出来；
3. 准备向高层领导进行交流的材料：
   现在测试后，结果还是有很多bug出现。虽然知道在就这么几个人，就这么点环境资源，这么点测试时间，无法做到全面、完整的测试，测试不可能100%捕获bug。就是有相对充足的资源，也不可能100%的堵住漏洞（尤其目前只有黑盒测试，没有代码复查、白盒测试等手段）。
   在使用中遇到bug，高层领导就骂测试是吃白饭的，这些问题怎么都没有发现等等（有时候不是程序的问题，都会怪到程序上来 --- 部署是另一个中心完成的事情，虽然可以安排他们某些工作，但是不是直接的隶属关系，怪罪起来不是很方便）。有了录像，以后有问题，可以用这些录像可以进行检查：如果真的测试人员偷懒，没有按照要求进行测试，进行内部纪律处理；如果测试人员对这些功能进行了充分的测试，拿着录像和高层进行交流，证明这些功能都已经测试了，没有发现问题；领导机器上发现问题，这说明我们现在的测试环境不够或者测试方式不对：如果测试环境还不够，很多应该测试的环境没有资源搭建起来的话，这样也可以名正言顺的要求机器资源了；如果测试方式不对，则修改测试方式，找到一条适合我们自己的测试方式
4. 生成环境中的测试，和其他部门进行交流：
   现在产品出来，需要测试人员在正式环境中的测试环境进行测试一次，有了录像，至少测试人员可以跟着自己提交产品、提交测试报告的测试过程再重复执行一次，其他部门的人员也可以通过测试录像进行验证一次；
5. 也可以作为对客户的操作说明：
   现在使用软件的客户，有相当一群对计算机基本操作一窍不通的，在电话中遥控指挥他们操作真的要累死。有了这个软件，可以通过电话摸清客户的环境，将操作步骤全部录下来，发送给客户，让客户跟着录像执行就可以了；

为什么组长安排的任务完成不了，要自己安排才行

公司有一个开发员，组长安排的工作都完成不了，非要自己安排才能完成工作？

是没有树立组长的威信？还是组长自己的问题？或许是这个开发员的问题？

目前至少发现2点：

1.  这个开发员本身的问题：
   还是最根本的是先有鸡还是先有蛋的问题： 不加工资工作状态、学习积极性下降，看着他这种状态，加工资更加没有希望。
   已经和他明确的讨论过这个问题：没有为公司创造更高的效益，是不可能给他涨工资的，如果一直这种状态，有失业的危险。估计是自己手上有这个权利，安排的工作他才完成。另外平时自己技术上有底子，也不用计自己的开发量开发时间，他们有问题，可以从解决方案、采用的技术给他们讲解讲解、包括技术的原理、为什么这么做以及这么做解决的是什么问题等等很系统的给他们培训一下，在技术上他们也不得不服。（经常他们做不出来的，或者觉得很耗时的工作，给他们讲解一下，工作时间成倍的缩减）
2. 组长的权威不够、强硬度不够：
   现在的组长，因为工作相当努力，在一群人中，技术还是有可取之处，选拔上来作为组长（也实在是没人）。平时他也是和大家嘻嘻哈哈，比较容易逆来顺受，说的好听点比较乐观。在工作中思考的也不多，安排一个工作，讲了几次，业务上还是稀里糊涂的，大量的事情还需要自己亲自安排、亲自流程制定，这样对组长的威信也是削弱。遇到事情，组长没有手腕，自己解决不了，时间长了大家也不把他当回事（但是实在没人，每个公司的老板都想用最少的代价用最好的人才，但代价是有上限的--相当低的上限，人才的级别可以浮动的。所以现在人员的水平、素质真的是一代不如一代）。
   还好，组长还是比较上进的，也在一点点的改变，自己也在不断的帮助他、要求他，往组长的要求上靠。平时开会的时候，也在他的组员面前不断树立他是组长的意识，有事情你们向组长汇报的，不是向我汇报。对于组长再观察一下。

这个问题再仔细的观察一下：

如果真的是这个开发员工作态度上的问题，ok，没有讨价还价的余地 ----- 走人。 

如果是工作安排上的问题，不仅组长、连自己也要好好的反思一下，如何更好的安排工作，使得大家工作起来更开心、效率更高