项目主管新手求助， java 开发人员配合问题

这真的是 5 年经验的人干出来的事么...膛目结舌。

@haozhang 正常吧
即便是科班出身的 java 程序员我见过也好多不靠谱的
异常都不处理

json 里多余的空格应该无所谓吧。

至于返回 json ？一个正常的语言都不会很麻烦， java 里自然也不是特别麻烦，我倒是怀疑你的同事是，呃，手动拼出来的 json 。

@haozhang 确定是的，难道是外包公司难道要求很低吗？

@oott123 js 就没法直接用这个结果，需要去掉开头的空格，然后再转成 json 对象操作，我是很无语，是不是我的要求太高？

难道手工拼接的 json ？


Examples example1 = new Examples();
Gson gson = new Gson();
String json = gson.toJson(example1);

还有恳求各位，遇到这个恶意不配合的我该怎么呢处理？

@gamexg 具体的不清楚，我明天再看下代码。只是知道 js 用这个接口的数据是想死的

@jugelizi 如果是异常不处理，我倒还好接受些，每次都要对调用的结果进行处理，是很恼火的。

1. 要求不高，都是合理要求
2. 尝试下不要“要求”对方、或者给对方“指派”某工作，而是“向对方提示代码中问题，然后一起研究解决方案”
3. 如果经过耐心沟通还是无效的话，建议自己先顶上，你的方向是“ js 、 nodejs 、 python 、 C#”，上手 java 一个星期内的事情。之所以要这样做是因为你只是“暂时负责项目管理”，你的上司应该也是正在对你考核的，所以要先把手头上的事情做好
4. 上司对你比较肯定后，建议还是和上司提出换人的要求，坏情绪的人在团队里百害无一利

@simonrleung 过来人表示 2 ， 3 条都是坑自己。
他要是有情绪你跟他不谈根本问题怎么谈都没用，所以第二条无效。
更加不能自己顶上，你的工作是项目管理，跑去编码是本末倒置，长期以往必然影响老板给你的工作，在老板那会认为你的能力不行，那就完了。而且让员工闲着白拿工资对整个团队不利。

java web 返回格式化 json 我都是直接拿 jackson 直接返回的
没要求的话从来不主动拼 json 的

撸主只说了你的职责，没有说你有什么权力，如果老板只把责任扔给你没给你一点权力那是耍流氓，你这工作没法做，趁早卸任或者让老板给你相应的权力。

下面的人对你有意见要是不影响工作随他便，不用往心里去，你又不是要和他处对象。

但是到了 b 的情况就得把事和他挑明，要让他知道这个工作的验收人是你，不是他想做成什么样子就做成什么样子的。

沟通如果无效就该动用你的权力了，他们之所以这么肆无忌惮就是没有触及他们的利益，果断杀鸡儆猴

科班？见过连 console.log 都没听过的，拿 14K

没打完发出去了……

如果引起反弹，你自己要能顶上，少个人天塌不了，让他滚蛋。

同时你要尽快建立自己的后备人才，招聘都要自己亲自来，包括人员培训，保证进来的人都是你能用的。

最后你就是欺上瞒下的部门领导了。

Java 处理 json 不是一大堆现成的包吗

1. 首末空白字符不应影响 parse 结果，你先检查自己是不是搞错什么了
2. 验收标准你就以浏览器 JSON.parse 能通过为准，不通过就发 issue ，这标准测试人员都能验证，没什么好扯皮的
3. 还有意见就给贴 rfc
4. 既然是项目管理人员你就应该有权利制定部分 kpi ，按标准来讲这就是 blocking issue ，故意不修复你可以自己上， kpi 扣到负行不行？

Springmvc 自带 restful,fastjson 很好用，只能说你的 B 同事有一些问题，可能本身就是外包的原因，不太想担当和学习

java 返回 json 很简单。

和别人合作的项目，对方使用 java 给我返回 json ，刚开始的时候返回的 json 也是不规范的。
在 php 里用 json_encode()生成 json 数据很简单很规范，想不规范也不行。
我不懂 java ，我很奇怪 java 为什么会生成不规范的 json 的呢？

@free9fw 好可怕。
@SoloCompany 感觉他可能就是直接拼接字符串了

我就想知道他那个不规范的 json 是什么生成出来的？？？ json.org 写出来的，不太可能写出不规范的呀，难道他直接字符串连接了？

@k9982874 非常感谢你，权利确实是必要的，好在最近在招人

@simonrleung 这个建议非常好，我打算这么执行。

@k9982874 感谢过来人谈的有价值的经验。

@k9982874 我会和领导说明情况，主要是人手不够，可能暂时还的自己多干一部分

上一年我司和联通合作，他们提供的接口返回的数据就是拼接的，给他们说了也不改

我是来看头像的……

@tianshilei1992 巧合

1. java 的 webservice 返回 json 很麻烦吗？
++ 现成的东西
2.正确控制登陆用户的访问权限在公网的系统很少考虑？
3.数据库明文存储应该也是一个大忌吧？
++ 团队开发人员完全没有安全意识哈

从楼主描述，需求合情合理，对于开发来说这样的变动只是愿不愿意去改动的问题了。
团队中出现这样的问题，特别是开始就存在抵触情绪的，需要单独哟谈，无果情况下该办的还是要办掉

@SoloCompany JSON.parse() 是解析不了的，需要手动去掉空格，换行等才能正确执行

感觉能出现奇葩的数据格式的时候，一般都是手动拼的...毕竟标准接口一般不太会这么没人性

首先你要确定自己确实不是坑

作为一年开发经验的我也不会这么干....

上面都没有正确回答， ws 根基就是 xml ，改掉 xml 就不是 ws 了，如果想前端调用 python ， php ， java 都可以转下，直接让 ws 返回 json 有点不伦不类。

只说 B
从楼主描述来看，楼主说出来的要求都是非常合理的。大部分外包的代码水平最近我也算是见识到了，确实不敢恭维。
从技术上来说， Java 有一大堆好用的 Json 库，总能挑到一个自己喜欢的。当然坚持手工拼接 Json 也没问题，不过就应该必须按照要求来。
关于明文密码和权限问题，我只能说培训学校应该不教这个，所以_>
不过这里有一个小问题，就是这些 api 的返回最初是怎么定的。如果设计的时候没有明确说需要啥样啥样，那你还真不好说别人_>

@julor

> JSON.parse(' \r\n { \n \t \n "x" \n : \n 1} \n \n \t \n');
{ x: 1 }

好像很多人都遇到过手工拼 JSON 的。

webservice 是基于 SOAP 的，既然用了 WS ，为何要用 JSON ？直接用对象序列化不就行了，你这种思路本身就有问题吧！
而且我认为做技术管理的人，最好不要对技术细节有过多干预，否则很容易引起别人的反感，尤其是老员工，最烦的就是别人自以为是地指手画脚。
如果你认为这个地方有问题，请从业务的角度提出质疑，而不是简单地批评别人代码写得不好。
另外，软技能是你需要提升的地方，偶尔请人吃个饭，润物细无声地对他们的劳动表示感谢，为自己平时的坏脾气道个歉，都会对你们的关系维系起到作用，起码不会让他对你的一些批评太过抵触。

1. java 的 webservice 返回 json 很麻烦吗？
很简单， Spring mvc + jackson 或 fastjson 现成的常用的轮子

2.正确控制登陆用户的访问权限在公网的系统很少考虑？
之前公司也是上海外包回来的同事也是的，没做过权限控制。听楼主的描述，应该和我之前这个同事是一个情况，在外包公司工作 5 年，基本上就是使用外包公司自己的框架重复写业务的码农罢了。

3.数据库明文存储应该也是一个大忌吧？
能够做到数据库明文存储密码的，都是煞笔。

B 的情况，是外包公司的话就很正常了

@SoloCompany 谢谢转换方法没问题，就是麻烦些。

@hgzz 我没参与项目前，他们就有意识返回的 json ，但是格式需要接收端再处理一次

如果用 REST WebService 的话，不管是 SpringMVC 还是标准的 JAXRS ，返回数据格式基本可以从 Accept, ContentType, query 参数决定是 JSON 还是 XML ，称之为 Conent negotiation ， 不需要用什么任何工具（ jackson, 等）显式的转换。这在 Spring 3.x, JAXRS 中早就支持。

基于 SOAP 的 WebService 在 Java EE 标准 JAXWS 中几乎十几年没更新了， SOAP 是过度设计的典范， 06 年的 Java EE 5 的 JAXWS 更新仅加入 Annotation 支持。我们已经很多年在新项目中几乎不考虑使用 SOAP ，当然集成第三方还可以用到（客户端的方式）。

我对这种关系冷处理了一段时间

我对这种关系冷处理了一段时间
..............
问题在这里吧.沟通的问题.doing.no BB.

@eimsteim 恕我愚笨，那前端 js 处理起来复杂度就增加了。现在的系统只是服务器提供接口给他他终端调用，目前是浏览器，但是移动 app 也在规划中。

@hantsy 没有 rest webservice 这种东西，这完全是两码事

不行就换人 这才是做管理啊 纠结那些细节干毛

@babyhome 不行就换， 没那么多事儿，你把他搞定花的时间还不如找一个新来的靠谱的呢，他这样就是不对的， 要不走， 要不配合，扯这么多没用的，就不是一个干事儿的人。

@babyhome 这个不行，我没有权利

又在黑我大 java 系， 23333

@ming7435 不黑，真实的事情！！！

@free9fw 哪家公司，我会 console.log [捂脸]

看到 console.log

看到 console.log 我第一反应居然是“卧槽这是哪个日志”，然后搜了一下，哦，是 console.log()

@julor 如果想规范 JSON 格式，可以考虑使用 json schema 先定义你要生成的格式, 有现成的 Validation 可以加入单元中测试中去验证。

不过我觉得像 JSON Schema ， RAML 这些条条框框的东西让 REST 重新走上了 SOAP 的老路。

我依然是喜欢 Code First 方式开发 REST API ，所以现在项目也比较喜欢用 Swagger 之类的工具可视化 API ，供前端调用查看。

@hantsy 对，暂时只要嫩那个简单的让其他系统调用就可以，不要求更多。只是现在对接收的数据还需要转换

我只能告诉你 java 返回 json 简单的要死，一堆可用的库，

json 的话 spring 配合 jackson 就很好用，如果单独用就 gson ，也是好用到不行，很简单。
如果返回不规范，只能说你那个同事真的好水，这种只能强制要求用什么东西的。

这些家伙就找个机会开了吧，找别人顶上，唔，个人感觉还不如我这么没毕业的

@julor 不知道是你理解的问题还是我说的不够清楚，帖的那段代码是说明 json 对空白字符不敏感的，而不是转换程序

@SoloCompany 应该我理解错了，但是我确实是使用 JSON.parse 无法正常转换

楼主不急 , 由我个这个产品狗(顺带项目经理)给楼主解释下.

从楼主的描述里面来看. 楼主是缺少点 IT 项目经验, 特别是比较规范的 IT 开发模式. 但是楼主还是很好学的,不然也不来这咨询.

1. 行有行规,作为 IT 就需要按照标准来, JAVA 用 Webservice,还是直接的 HTTP 请求,返回 XML. 返回 JSON 都是很容易的,而且也是必须的. 现在如果接口只是给前端 Web 页面使用,都使用 JSON, 至少我是这么要求的.
XML 这个一般都是做给其他系统做接口用. 楼主可以先把相应的 JSON 格式定义好,然后交有后端人员开发.告诉他们,我就要这个格式. 前端也会按照这个格式解析. 约定好. 通过邮件,说明书的方式.

2. 很多 IT 人事虽然工作年限多,但是都是小公司到小公司.未进行系统的学习,不了解一些最佳项目实践.在他们的印象中,能完成工作就行了,不会去考虑太多的规范的事. 需要楼主去引导,拿出例子,比如上个项目怎么怎么. 对于他的态度,楼主大可放心,慢慢他回适应的,你得给他适应期.

3. 楼主需要加强学习..系统的学习 IT 最佳实践. :)

楼歪了， LZ 来问管理相关的事情，都在说技术的问题，看来一个是技术宅比较多。

我和你一样是新人，但有几点 LZ 你没有说清楚：
1 ，你目前和其他两个同事的关系（职位或管理与被管理者之间的关系）
2 ，项目管理比较抽象，最好说清楚你的具体职责内容（在不同的公司项目管理者的职责是有区别的）

就我看 LZ 的问题作出的几点推测：
1 ， LZ 工作大约在 5 年左右，或者>= 5 年
2 ， LZ 管项目，可能没有在管人

我的看法：
1 ，程序员走到带管理头衔以后，打交道的通常不是人就是机器。因为长期和机器打交道习惯，很多事情或许就有点像当然了的，因为与人打交道是最复杂也最难的，主要来源于人拥有感情和思想两种属性。
2 ，在做管理层的时候，除非是老板，其实都是夹心层。凡事不能仅仅看结果，还要多少关注过程。有些指令也好，软磨硬泡也罢，表面上看达到了效果，其实对方有千万个神兽在奔跑。这次的合作“成功”不代表长期的合作“成功”
3 ，作为项目管理，也分为产品类和技术类。不管自身出身如何，主要看头衔属于哪一类。如果偏向于产品类，最好多用产品方面的思维和语言同程序员打交道。如果属于技术类管理者，除了要用技术的思维和语言打交道，关键还有了解产品的一些“细节”（但不需要了解的太细），同时也需要了解到实现的难度与意义。
换句话说，如果你是偏向产品类的项目管理者，你用产品的思维去处理最合适，千万不要带着你曾经的技术背景去和程序员打交道，因为具体的开发人员并不买这一套，而且最终做下来，你会发现你的管理产品不像产品，技术不像技术。
对于偏向技术类项目管理者，你最好用技术的思维处理问题，但也要学会体谅开发人员的难处。
4 ，信任手底下的人，但也不要太信任。正如人是具备思维和感情的，你不能保证情商极低的程序员把对公司的火发在你的项目上，直接导致项目流产或者失败。所以应有的信任应该给予，但对于那些不该信任的人，你要小心点。
5 ，技能水平和工作年限不一定存在比例关系。我这么给你说，我曾经遇到的一个 82 年的人，硕士毕业，按照从本科毕业+硕士折算工作经验的方式计算，这哥们差不多也有 10 年工作经验了。但事实上呢？连个 mfc 的工程都不会建，最简单的 C++内存泄漏都不会检查，什么是野指针和零指针都不知道。还成天宣扬自己工作 10 年，写了 10 年的 ace ，做了 10 年的内存池和线程池，最简单的用 win32 api 都不会开线程，最基本的线程通讯都不会。
所以，不要简单的按照工作经验或工作市场看待人。工作经验或工作时长，只是工作的一个敲门砖而已！



说这么多，祝 LZ 一切顺利。以前成天当个板砖的小丝快快乐乐的写代码，没心没肺的过日子。当作上包工头以后，没见工资涨，但烦恼就来了。共同磨练哈！

等等，我最近对接过一个公网项目，对方是 java 开发的接口，返回的是不标准 json ，主要是自己拼接了某个字段导致的 o(□)o

@salltm 明显发现基本不按讨论来，看来还的用邮件强制说明，规定一些要求。

@salltm 我倒非常想定下规定，可是没这个权利，算来算去只有责任没有权利，听无听对他们影响不大。

@julor @hantsy 的建议是非常中肯的，如果你有探讨技术架构的权限，我觉得你可以尝试改变一下，这也是技术管理者的义务和职责，没必要总是把眼光看着下面的人。