|      1raincious      2014-12-19 13:44:07 +08:00 via Android 第一步怎么不是禁止ORM执行原生SQL?禁了这个其他都好办。 另外SELECT *也不是最佳操作吧? | 
|  |      3tabris17 OP 现在的问题是不符合DDL规范的表,运维部门不给部署到生产服。现在的目的只要能骗过运维部让项目上线就行 | 
|  |      488250      2014-12-19 13:50:18 +08:00 花点时间改呗.... | 
|  |      566450146      2014-12-19 13:55:11 +08:00  1 :%s/_/UNDERSCORE/g | 
|  |      666450146      2014-12-19 13:55:35 +08:00 千万不要真的这么做…… | 
|  |      8xiaogui      2014-12-19 14:00:14 +08:00 为什么禁止下划线?那你们用什么分词? | 
|  |      12wesley      2014-12-19 14:06:56 +08:00 给运维不熟的数据库里只放几个假表,部署完之后,在服务器上放个phpmyadmin,把真正的表导进去 | 
|  |      13nicai000      2014-12-19 14:07:37 +08:00 规范应该先于代码啊.... | 
|  |      16dorentus      2014-12-19 14:09:08 +08:00 via iPhone  1 话说,Google 的各种语言的代码规范里面,大都会提到旧代码如果不符合规范该怎么办,其中一个很重要的原则就是不要*仅仅*去为了让代码符合规范而去改。 所以在我看来这要求的确有点神经病了… 没啥特别省事的方法了,也就是修改-单元测试如此循环,该多少工作量就上报多少工作量吧。如果有什么来不及,那责任肯定不在开发这边。 | 
|  |      17xiaogui      2014-12-19 14:12:07 +08:00 @tabris17 那就把修改这个需要的真实时间 * 2.5 提交给你的上级,然后列出因为要做这个所谓的规范,然后目前其他所有项目完全停工。 | 
|  |      19cloudzhou      2014-12-19 14:14:25 +08:00 使用下划线有任何问题吗?我不理解,一直依赖我们都是使用下划线作为分隔符号。 | 
|      24wdd2007      2014-12-19 14:22:41 +08:00 你是上级。。。你需要有能力拒绝这个要求。。。 | 
|  |      27xiaogui      2014-12-19 14:27:26 +08:00 @tabris17 加班的话,也会影响其他项目的进度,把这些都弄清。你肯定是要向上面汇报这样造成的后果。 另测试部可以提功能需求,任何人都可以。但是研发部要有自己的开发计划,以及预估出其他人提的需求需要的开发时间和重要性,结合实际情况,然后同意、拒绝或者放入需求池等等。 | 
|  |      28tabris17 OP @xiaogui 测试提需求的意思如果不实现这个功能就认为是程序BUG不让过测试,另外测试直接和开发提,当产品经理死了吗 | 
|  |      29ls25145      2014-12-19 14:34:03 +08:00 这个必须反映一下,不管上面是不是管技术的。 代码先写的,规范后定的。明显是运维的问题,这个要是不强硬对待,以后有的是办法收拾你。 要么延期,要么无视这个规范。 | 
|  |      30xiaogui      2014-12-19 14:35:34 +08:00 @tabris17 按这样的话,就只能拖着了,嗯。加班的时候记着拉上测试,随时让他们测试。 另如果你是研发部门的头的话,你是有权力去拒绝任何你感觉不对的研发需求,规范,并参与对这些需求的谈论,规范的制定中的。否则的话,相信我,你们研发部估计是这公司最苦逼的部门,注意部门小伙伴们可能会陆续离开。 | 
|      32raincious      2014-12-19 14:37:49 +08:00 @tabris17 如果仅仅是想刷存在感: 1、查一下你拿到手的需求以及之前所有的Note,看看运维在开发之前有没有提出规范限定,如果有,但是你的团队没遵守,那就是你的问题,如果没有,那就是没有必要遵守。 2、如果之前没有提出,上线时临门一脚,你直接说明原因和后果报给Boss让他解决这个问题好了。 其实作为Leader有的时候需要问一下各部门的,比如各种规范什么的,只需要一句话就能解决很多问题。 3、运维竟然以非关键(且未知会过)的原因阻止项目上线,这你必须和Boss谈下,了解和规范下他们的权利。 | 
|  |      33tabris17 OP 我觉得有点跑题了,咱们还是回到技术问题上来好吗 | 
|      34raincious      2014-12-19 14:43:54 +08:00 @tabris17  如果你真的要这么做,那就一点点修改代码,改成符合运维要求的 > 我尝试写了个SQLParser来替换SQL语句中的表名和字段名,但是因为SELECT * 的关系,返回数据集的字段名没法替换掉。 不要这么玩,增加了复杂度和不确定性。未来维护会非常麻烦。 | 
|  |      35xiaogui      2014-12-19 14:46:05 +08:00 快速替换的方法,有任何后果是需要你承担的。 | 
|  |      36skybr      2014-12-19 14:46:14 +08:00  1 我在想, 写django或者rails的没下划线怎么活 | 
|  |      37cloudzhy      2014-12-19 14:53:02 +08:00  1 蛇形法明显比驼峰法更容易一眼看出来。 | 
|  |      38tabris17 OP  1 @skybr 还真被你说中,手头还有个django项目,我准备到时候用ansible playbook自动部署,他们运维不懂的话也就闭嘴了。 | 
|      39shadyxu      2014-12-19 15:19:24 +08:00 “管不到其他部门”,其他部门当然不能管,沟通,沟通不了就向上反馈让上面决定。“不想得罪运维”,就不怕得罪自己组的人? 作为一个leader,跨部门合作怎么能这么被动。这个就不应该是技术问题,无厘头的要求就必须说no。 | 
|  |      40tabris17 OP  1 | 
|      41shadyxu      2014-12-19 15:21:51 +08:00 LZ你就想想,你自己都这么排斥,你的组员,也就是最后真正去改的人,会是什么想法。如果这种没来由且滞后还又跨部门的要求你都直接妥协,你的组员会怎么想你。 | 
|      42shadyxu      2014-12-19 15:29:28 +08:00 @tabris17 不仅仅是这次上线的问题,你们以前的项目也全部要改吗,新项目以后也要这样吗。既然你管不动跨部门的运维,那他们跨部门给你们提的要求你怎么就直接接受了。这种你觉得不对的东西,还要折腾耗费工作量,又会引起组员反感,这都不去据理力争,别人还能指望你什么。 | 
|  |      43tabris17 OP @shadyxu  规范和项目在我来公司之前就都存在了,是当时负责的开发没有留意规范,而项目一直没上线,所以直到最近要上线前才发现不符合规范的问题(当然这个规范有多傻逼就不提了),所以我没找开发算账已经不错了,开发还反感个毛啊。 | 
|      44aru      2014-12-19 16:13:30 +08:00 老老实实改代码,或者去掉这个规划 | 
|  |      46loryyang      2014-12-19 16:20:21 +08:00 这,你作为技术总负责人居然没有怼回去?难道你们那边rd还不如运维强势? 要是我我就给他排期排个三个月,给他慢慢改。上头要是对我有意见,老子拍拍屁股走人,哪儿不是一样干,干这样傻逼的事情,还不如不干 你就这样想,你这么干对得起手下的弟兄吗? | 
|  |      47dingyaguang117      2014-12-19 16:22:04 +08:00 表明字段名有下划线 有啥缺点呢 | 
|  |      48loveyu      2014-12-19 16:33:19 +08:00 我咋觉得下划线明显比那个驼峰好区分 | 
|  |      49sunhk25      2014-12-19 16:35:17 +08:00 用的cakephp,官方文档,例子里面的表名,字段名全都是下划线来标识的。。。 | 
|  |      50tabris17 OP  2 @dingyaguang117 完全没有,反而是驼峰法会有问题,在不同系统下,mysql表名大小写敏感是不一样的。 | 
|  |      51akira      2014-12-19 16:36:11 +08:00 按照你说的话,规范应该是一直存在的,老老实实的改代码吧,别取巧。 | 
|  |      52akfish      2014-12-19 16:40:29 +08:00 这种事情运维也来指手画脚?真是醉了。 | 
|      53kaneg      2014-12-19 16:47:19 +08:00 这就是软件开发中的蝴蝶效应。 | 
|  |      54edwardtoday      2014-12-19 16:47:46 +08:00 这个月刚把原先驼峰命名的MySQL表名改成全小写用下划线分词。 开发环境MySQL是跑在linux上的,一直没问题。 直到在某台Windows上装了MySQL,发现默认不区分大小写表名,真是悲伤。 我不知道你们是否会遇到跨平台的问题,但是就表名而言,你们新来的话事人是不是还要把 information_schema 改成 InformationSchema 呢?问问MySQL同不同意?? 规范不对的时候改规范。规范不合理的时候,争取改合理了。忍气吞声埋头做,出问题谁负责?延期谁负责?责任都你团队负,权利都在其他部门,这不搞笑呢么。玩不转的。 | 
|  |      55tabris17 OP  1 @edwardtoday 本地开发环境是windows的,不过以后项目我会让他们都在vagrant虚拟机上开发。 定这个规范绝对是人绝对是脑子进大便了,没办法 | 
|  |      56evlos      2014-12-19 17:14:54 +08:00 via iPhone 卧槽 表名还不让用下划线了 哪个逗比定的规范。。。 | 
|  |      57cloudzhou      2014-12-19 17:37:04 +08:00 @tabris17 让运维发出邮件,详细列出这样做的目的、好处。并且表示,出于xxx的原因,如果没能说服这样修改的合理性,将不做这样的更改。 | 
|      58aa88kk      2014-12-19 18:08:45 +08:00 你们公司运维是个大5B, mysql默认的命名方式就是小写加下划线,查询是不区分大小写的。所以大小写只会在显示上有区别。你们公司也奇葩,运维能管这个? 换个公司吧。 | 
|      59huigeer      2014-12-19 18:09:28 +08:00 别人吃大便就让他吃, 用不着赔他吃, | 
|      60zzColin      2014-12-19 18:29:05 +08:00 显然楼主措辞上有点问题,以致于几乎所有回复都当成是运维故意找茬了,但不管规定再怎么脑残,楼主显然已经在 43 楼承认了是自己和手下开发人员的疏忽 | 
|  |      61cdxem713      2014-12-19 18:44:43 +08:00 via iPhone 我记得sql是大小写不敏感的啊 | 
|  |      62dong3580      2014-12-19 19:44:19 +08:00 | 
|      63jjx      2014-12-19 20:00:02 +08:00  1 你这当领导真没有领导的能力, 这种事情要是我,直接就顶回去,顶到最高层, 大不了不干了,如果公司同意这种sb做法,这种公司有什么留的必要 | 
|  |      65mhycy      2014-12-19 20:12:09 +08:00 说起来 这个规范真的是脑子被夹了.... SQL的保留字符统统大写,表名,字段名小写+下划线在调试的时候容易看很多..... | 
|  |      66lincanbin      2014-12-19 20:31:41 +08:00 运维脑子进水了,代码规范应该由开发团队自己制定,运维手伸这么长干嘛? | 
|  |      67billwang      2014-12-19 21:46:49 +08:00 DDL,让我想起来灾备了,赶紧把检修期间注意的记了下来。 | 
|  |      69kurtis      2014-12-20 00:57:41 +08:00  1 下次运维规定你们不许用大拇指以外的手指来按空格,不许你们打字时看键盘,因为都违反指法规范。 若是发现,一次警告,两次剁手指,三次挖眼珠。 运维在给你下马威呢,强烈不推荐留在这样的公司,以后玩政治会很厉害的。 | 
|  |      70revlis7      2014-12-20 01:49:26 +08:00 看了半天,我突然明白了,这就是传说中真真正正的DevOps啊 | 
|  |      71wy315700      2014-12-20 09:43:21 +08:00 |