遇到在职读博的伪it 和小人了
话说老客户公司听了BSC的重组方案把分公司集中到了S城，偶没办法就做了甲方。在甲方感觉还好，不用出差了。公司IT项目差不多都外包了，只有DWH这块自己人在做。期间做DWH的大哥因为上班路程过远离职了（跟偶原因一样-;)). 公司没聘到其他人，偶脑子一热，就去做DWH了，偶以前做过一年DBA，大学上过师兄们（不是教授）的DWH的课，注偶师兄们那时已经写了一本德语区比较有名的DWH的书，所以还有点基础。这期间公司新的ERP上线，DWH所有的东西要重写或migrating，偶和一个学BWL的同事要做在所有的东西，同事是我见过数学最好的德国人，对数字特敏感， 心算无敌，sudoku 没有就不出了的。项目特紧，跟头说要人，就来了个Extern的Berater。偶就逐渐成了东郭，这个时后话。
偶看了这人在linkedin上简历，NB啊， DWH&BI Expert 做过无数Projekt，在职博士，SAP， IBM DWH Expert， Prince2认证。 心想有个好帮手。偶和这人谈了一下，知道挺多，可是专的厉害，以前用 Datastage， Talend OS 做过ETL。不过 OLAP cube组成，dimension居然不太了解， SCD听都没听过。BI前端没用过。这人以前一直在大公司做，估计一人就做那一点东西。大公司，挺害人的。
就这样合作了2月，这人还能写点东西，就是以前都是做DB2的，O记的DB好多东东不知道。这人抄东西挺快，照着偶写好的东东写了些东西。期间偶把新的ETL包的框架，大部分Code写好，不过过年要回家，就把没做完的工作交接給了他。这厮先是把偶的Code一行一行用他特有的Format手动改写一边，这个是PLSQL，不是Java， 没有Eclipse，netbeans，用Strg+Shift+F Code就自动Format。估计有10k lines吧， 德国人的毅力还是挺牛B的。估计没有那个中国人可以手动format 10k 行的Code吧。不过这是他特有的Format，别人看不懂，偶和偶同事都看不懂。
四周后偶过年回来用SVN diff一下ETL包，一看变化挺多，偶同事对这厮工作也没有异议，有些ETL包还Fachtest了。我心想，还好有人在偶Urlaub 时继续做，项目没耽误。偶就又接手了过来，开始Code Review，测试，开始还好，两天以后越做越心虚。呀，遇到南郭了，这厮写的东东逻辑上错误无比多，经常无厘头的就把偶写的重要Where的Cluase給改了，直接！＝ 变＝。-:(. ->(.偶就开始了一个月的痛苦的改写过程，因为除了逻辑上的错误，这厮coding的format偶基本是没办法理解。偶开始基本是把这厮的Code又手动改回偶熟悉的Format，偶承认，我毅力没有德人强，偶只改了有错的代码。期间偶跟这厮说了他的Coding Style 不太好，这厮开始开始跟偶顶牛起来，说偶和偶同事的Coding Style 他读不懂，所以全改了。偶说以后有新人来看不懂你写的啊，这厮就说也许后来人认为他的好。就这样不欢而散， 哥们记仇了，偶也没办法只好小人了。
今天到此为止，未完待续。。。 好专业。。。。 听你的职场故事，期待下集 哈哈，最烦就是 那些 自以为是 并且班门弄斧的人，一开始你很想尊敬他，但后来发现没啥共同语言，他总是想办法来说明他要领导你，但他的见识比你十年之前的还要浅。当他碰壁的时候你要罩着他，当你出小差错他就恨铁不成钢。。。你还想和他说话吗？ woo2333 发表于 2013-8-9 21:33static/image/common/back.gif
话说老客户公司听了BSC的重组方案把分公司集中到了S城，偶没办法就做了甲方。在甲方感觉还好，不用出差了。公司IT项目差不多都外包了，只有DWH这块自己人在做。期间做DWH的大哥因为上班路程过远离职了（...
你做了几年dwh bi etl 这块？ 本帖最后由 woo2333 于 2013-8-9 23:19 编辑
pentaho 发表于 2013-8-9 23:05
你做了几年dwh bi etl 这块？
1年, 不过偶做过一年DBA。Backend，UI ， ECM，Workflowsystem都做过。与只做过DWH的人相比，我可能更理解OLTP系统的运作。 不明觉厉的节奏！ 我感觉你最好别和他混着工作，模块分开写
他的模块有BUG直接让他改，顺便CC给你上面，几次之后他就虚了
不过你们也必须提前规定每个模块有啥具体功能的，要不也是扯皮的事情
个人经验，供参考 我们用Toad写plsql，可以autoformat的。 上面写了好多跟技术无关的话， 给一个PL／SQL Coding Style 的link， 来自Steven Feuerstein的宝书，
http:// oreilly . com/catalog/oraclep2/chapter/ch03.html
上面的书中写了一个SQL coding比较供认的观点，就是Right-align the reserved words for the clauses against the DML statement.就是说SQL 命力的关键字 select, from, where, and, or, group by, having 要在每一行的右边，要尽量右对齐。如下表显示
SELECT column1, column2，column3, column4
FROM tab1, tab2
WHERE
AND
OR
GROUP BY
HAVING
AND
OR
ORDER BY；
偶和偶同事不能忍受不了南郭先生的代码一个重要的原因，因为这厮的除了select Where 以外好多的关键字都在左边，尤其时and，or。
还有一个问题对我比较困惑，就是偶的南郭先生写Select 从来是一个Column一行，一个屏快写满了，还没看到Where。 一般来说写过代码的人希望在一个Editor屏幕上不需要Scroll的条件下看到尽量多的Code。有两种方法可以实现这个:
一个是利用硬件 简单地说大屏幕，比如用高解线度的屏幕， 1920x1200 Pixel ， 2560 x 1440 pixel。 4K现在基本上还是神话。
另一个是你要用规划简化你的Code，有个好的CodingStyle。 比如用SQL，PL／SQL， 定义Cursor或直接写Select时，如果要返回许多Columns不要每个Column用一行，如果有30 个Columns，一个屏幕很快就会被占满了。 要尽量把有关联的Columns写在一行，这样可以节省很多Editor的空 间，以后读Code来会比较容易。
偶跟他说，偶们有24寸屏幕，1920pixel的宽度，能否把有关联的Columns写在一行，这样可以不上下Scroll就可以看到更多有用的信息。 这厮说特别特别赞同我的建议，马上把他写的一部分代码从新Format一下。偶心里话，这厮有时还是可以交流的。 两天后，偶看了一边这厮改的代码，这回不是1行一个Column了，改成所用的Columns都写一行了。 现在偶不需要上下Scroll， 要左右Scroll了。结果有骂人的，不好不好，这世界还有这样愚蠢的人，还要读博士。
未完待续。。。
页:
[1]
2