p*****3
发帖数: 488 | 1 列举一下这4个月出的各种各样的错:
1. 各种exception处理，啥是re-tryable, 啥是事non-retryable，各种exception走的
路径，啥时候做log，log些啥，特别是log，以前以为记不记无所谓，onCall了一周发
现不记log完全没办法诊断，太TM重要了。Exception的处理也太TM重要了。
2. Business logic, 就那些逻辑咋就那么复杂，各种service盘根错节，我靠了。因为
逻辑理解出错导致N次修改logic code.
3. Service interface设计还是挺有学问的，还得站在其他相关组的角度考虑需求，自
己组的业务逻辑都还没整清楚.... 只能和经理说还木到那个vision ....
4. Apollo, Brazil, omnigrok, p4等各个工具各种概念很难理解啊
5. Code base不熟悉，写的code review时被告知某个package下的某个类已经实现了，
重新refactoring 。。。。
6. 有时几个组员同时修改一块code, 疲于跟随他们的refactoring做修改, 效率极其低
下。
7. 找不到各种spring, config, log文件在各种环境下不同的稀奇古怪的路径，效率极
其低下
8. Linux command不熟，效率极其低下
9. 一次修改Hibernate的code导致production下trigger DB的query plan, 导致
service throw各种time out exception
10. 不知道谁把Beta env 的"test"改成了"Prod", 后来copy了该parent env, 开了一
个小时的service, 没有DB访问权限，正好service的一个bug swallow了DB的time out
exception, poll了message queue并发送了positive 的 ack, 但是实际上message没有
在desktop上处理，导致3000+ order pending了10天，经理提交了一份检讨,这也能碰
上...
11 - +oo. 没脸写了
TMD, 太挫了.... |
A******g
发帖数: 612 | 2 原来三爷在我A...
【在 p*****3 的大作中提到】
: 列举一下这4个月出的各种各样的错:
: 1. 各种exception处理，啥是re-tryable, 啥是事non-retryable，各种exception走的
: 路径，啥时候做log，log些啥，特别是log，以前以为记不记无所谓，onCall了一周发
: 现不记log完全没办法诊断，太TM重要了。Exception的处理也太TM重要了。
: 2. Business logic, 就那些逻辑咋就那么复杂，各种service盘根错节，我靠了。因为
: 逻辑理解出错导致N次修改logic code.
: 3. Service interface设计还是挺有学问的，还得站在其他相关组的角度考虑需求，自
: 己组的业务逻辑都还没整清楚.... 只能和经理说还木到那个vision ....
: 4. Apollo, Brazil, omnigrok, p4等各个工具各种概念很难理解啊
: 5. Code base不熟悉，写的code review时被告知某个package下的某个类已经实现了，
|
z****e
发帖数: 54598 | 3 知足吧，你到了其它公司就知道
amazon的东西和架构其实很牛逼
其它公司经常会有新人半年无法上手的情况 |
z****e
发帖数: 54598 | 4 不过每次处理log，我都会感慨，aop要是被用上了
将会多么简单
【在 p*****3 的大作中提到】
: 列举一下这4个月出的各种各样的错:
: 1. 各种exception处理，啥是re-tryable, 啥是事non-retryable，各种exception走的
: 路径，啥时候做log，log些啥，特别是log，以前以为记不记无所谓，onCall了一周发
: 现不记log完全没办法诊断，太TM重要了。Exception的处理也太TM重要了。
: 2. Business logic, 就那些逻辑咋就那么复杂，各种service盘根错节，我靠了。因为
: 逻辑理解出错导致N次修改logic code.
: 3. Service interface设计还是挺有学问的，还得站在其他相关组的角度考虑需求，自
: 己组的业务逻辑都还没整清楚.... 只能和经理说还木到那个vision ....
: 4. Apollo, Brazil, omnigrok, p4等各个工具各种概念很难理解啊
: 5. Code base不熟悉，写的code review时被告知某个package下的某个类已经实现了，
|
p*****3
发帖数: 488 | 5
说说为什么AOP用上了就简单了？？
【在 z****e 的大作中提到】
: 不过每次处理log，我都会感慨，aop要是被用上了
: 将会多么简单
|
z****e
发帖数: 54598 | 6 代码分离，不用看了一半半的business logic，不停滴被logger.debug所骚扰
烦啊，你看到这种代码片段不烦吗？
【在 p*****3 的大作中提到】
:
: 说说为什么AOP用上了就简单了？？
|
p*****3
发帖数: 488 | 7
还能这样？？
不会吧，怎么能做到的？举个例子？
【在 z****e 的大作中提到】
: 代码分离，不用看了一半半的business logic，不停滴被logger.debug所骚扰
: 烦啊，你看到这种代码片段不烦吗？
|
z****e
发帖数: 54598 | 8 你居然不知道
去看aspectj或者spring aop随便研究一个example就懂了
【在 p*****3 的大作中提到】
:
: 还能这样？？
: 不会吧，怎么能做到的？举个例子？
|
s***o
发帖数: 2191 | 9 这些可都是血淋林的宝贵经验，就算每个月疼那么几天也值了 |
u****q
发帖数: 24345 | 10 请问Brazil, omnigrok, p4都是什么？ |
|
|
N*****m
发帖数: 42603 | 11 p4是perforce的cli
其他的应该是他们公司内部的tools
【在 u****q 的大作中提到】
: 请问Brazil, omnigrok, p4都是什么？
|
t**********h
发帖数: 2273 | 12 用git吧，好用多了，比p4
【在 p*****3 的大作中提到】
: 列举一下这4个月出的各种各样的错:
: 1. 各种exception处理，啥是re-tryable, 啥是事non-retryable，各种exception走的
: 路径，啥时候做log，log些啥，特别是log，以前以为记不记无所谓，onCall了一周发
: 现不记log完全没办法诊断，太TM重要了。Exception的处理也太TM重要了。
: 2. Business logic, 就那些逻辑咋就那么复杂，各种service盘根错节，我靠了。因为
: 逻辑理解出错导致N次修改logic code.
: 3. Service interface设计还是挺有学问的，还得站在其他相关组的角度考虑需求，自
: 己组的业务逻辑都还没整清楚.... 只能和经理说还木到那个vision ....
: 4. Apollo, Brazil, omnigrok, p4等各个工具各种概念很难理解啊
: 5. Code base不熟悉，写的code review时被告知某个package下的某个类已经实现了，
|
o***i
发帖数: 603 | 13 这得事先构架好
不然代码重写起来，很头疼的
【在 z****e 的大作中提到】
: 不过每次处理log，我都会感慨，aop要是被用上了
: 将会多么简单
|
g**e
发帖数: 6127 | 14 经验要靠慢慢积累。实际工作跟做题还是很不一样的
out
【在 p*****3 的大作中提到】
: 列举一下这4个月出的各种各样的错:
: 1. 各种exception处理，啥是re-tryable, 啥是事non-retryable，各种exception走的
: 路径，啥时候做log，log些啥，特别是log，以前以为记不记无所谓，onCall了一周发
: 现不记log完全没办法诊断，太TM重要了。Exception的处理也太TM重要了。
: 2. Business logic, 就那些逻辑咋就那么复杂，各种service盘根错节，我靠了。因为
: 逻辑理解出错导致N次修改logic code.
: 3. Service interface设计还是挺有学问的，还得站在其他相关组的角度考虑需求，自
: 己组的业务逻辑都还没整清楚.... 只能和经理说还木到那个vision ....
: 4. Apollo, Brazil, omnigrok, p4等各个工具各种概念很难理解啊
: 5. Code base不熟悉，写的code review时被告知某个package下的某个类已经实现了，
|
x****o
发帖数: 29677 | 15
这是牛人啊
【在 p*****3 的大作中提到】
: 列举一下这4个月出的各种各样的错:
: 1. 各种exception处理，啥是re-tryable, 啥是事non-retryable，各种exception走的
: 路径，啥时候做log，log些啥，特别是log，以前以为记不记无所谓，onCall了一周发
: 现不记log完全没办法诊断，太TM重要了。Exception的处理也太TM重要了。
: 2. Business logic, 就那些逻辑咋就那么复杂，各种service盘根错节，我靠了。因为
: 逻辑理解出错导致N次修改logic code.
: 3. Service interface设计还是挺有学问的，还得站在其他相关组的角度考虑需求，自
: 己组的业务逻辑都还没整清楚.... 只能和经理说还木到那个vision ....
: 4. Apollo, Brazil, omnigrok, p4等各个工具各种概念很难理解啊
: 5. Code base不熟悉，写的code review时被告知某个package下的某个类已经实现了，
|
L*******r
发帖数: 119 | 16 2、7、8、9、10是不是因为没有好的unit test coverage?没test，又不熟悉legacy
code，肯定会出事的。我觉得在已有系统上继续开发，一开始都是不求有功但求无过。
。。
几个人一起改code的关键是比谁先checkin吧。先进去的赢。关键是写一点就赶快check
in；再写一点再进去一点；别攒个大的一起checkin，会被累死的。
新手找不到config在哪其实也很正常，不过你们内部没有wiki么？没的话你自己写一个
好了。。
另外设计interface这么重要的活，为啥让你一个新来的干？印度老板？
【在 p*****3 的大作中提到】
: 列举一下这4个月出的各种各样的错:
: 1. 各种exception处理，啥是re-tryable, 啥是事non-retryable，各种exception走的
: 路径，啥时候做log，log些啥，特别是log，以前以为记不记无所谓，onCall了一周发
: 现不记log完全没办法诊断，太TM重要了。Exception的处理也太TM重要了。
: 2. Business logic, 就那些逻辑咋就那么复杂，各种service盘根错节，我靠了。因为
: 逻辑理解出错导致N次修改logic code.
: 3. Service interface设计还是挺有学问的，还得站在其他相关组的角度考虑需求，自
: 己组的业务逻辑都还没整清楚.... 只能和经理说还木到那个vision ....
: 4. Apollo, Brazil, omnigrok, p4等各个工具各种概念很难理解啊
: 5. Code base不熟悉，写的code review时被告知某个package下的某个类已经实现了，
|
l***x
发帖数: 393 | 17 看了前两条就想这不是Amazon的吧，再往下看果然是。
第一条深有同感，不过不是在A才有的体会。
第三条感觉A有的组abuse了service，导致接口混乱，为了实现一个简单逻辑，需要多
个service call
第四条，开始和你同感。来5个月后现在感觉好多了，除了对package dependency的确
定觉得还是有点乱。我们全是在git上。
第七条和第八条应该结合起来，对工具熟了就好了
另外，现在越发觉得A招人只面算法无法区分developer的实际经验和能力。吐槽一下我
们组的一个女developer实在是太弱了，唉，写的code还不如本科生在读的。一个二三
十行很基本的java code要来回code review不下30遍都过不了，各种错误，改一个又引
入其它的或者旧的错误。其它的developer都不好意思再给她review了，但是实在没办
法让她check in。还一点分析能力都没有，基本什么都得其他developer手把手教，英
文又差，基本所有的问题都得两遍以上别人才懂。唉，实在觉得她给广大中国人丢脸了
。不知当初怎么进来的。 |
z****e
发帖数: 54598 | 18 我看他们用了spring
直接在spring上加aop就好了
这样就不需要重写代码了
旧的log照用不误
这样还可以避免跟同组的人一起checkin代码
【在 o***i 的大作中提到】
: 这得事先构架好
: 不然代码重写起来，很头疼的
|
e*******s
发帖数: 1979 | 19 妹纸在IT界优势是巨大的..
【在 l***x 的大作中提到】
: 看了前两条就想这不是Amazon的吧，再往下看果然是。
: 第一条深有同感，不过不是在A才有的体会。
: 第三条感觉A有的组abuse了service，导致接口混乱，为了实现一个简单逻辑，需要多
: 个service call
: 第四条，开始和你同感。来5个月后现在感觉好多了，除了对package dependency的确
: 定觉得还是有点乱。我们全是在git上。
: 第七条和第八条应该结合起来，对工具熟了就好了
: 另外，现在越发觉得A招人只面算法无法区分developer的实际经验和能力。吐槽一下我
: 们组的一个女developer实在是太弱了，唉，写的code还不如本科生在读的。一个二三
: 十行很基本的java code要来回code review不下30遍都过不了，各种错误，改一个又引
|
s*****r
发帖数: 43070 | 20 胸大吗？大就当花瓶看吧
【在 l***x 的大作中提到】
: 看了前两条就想这不是Amazon的吧，再往下看果然是。
: 第一条深有同感，不过不是在A才有的体会。
: 第三条感觉A有的组abuse了service，导致接口混乱，为了实现一个简单逻辑，需要多
: 个service call
: 第四条，开始和你同感。来5个月后现在感觉好多了，除了对package dependency的确
: 定觉得还是有点乱。我们全是在git上。
: 第七条和第八条应该结合起来，对工具熟了就好了
: 另外，现在越发觉得A招人只面算法无法区分developer的实际经验和能力。吐槽一下我
: 们组的一个女developer实在是太弱了，唉，写的code还不如本科生在读的。一个二三
: 十行很基本的java code要来回code review不下30遍都过不了，各种错误，改一个又引
|
|
|
c*****a
发帖数: 808 | |
x****d
发帖数: 1766 | 22 the worst mistake I knew was a guy watching porn while on call late night
within company firewall, within a week, gone. fucking amazing that they can
catch him that fast. I was wondering why the fuck they don't block that porn
site in the first place? was that a trap or something? |
g**e
发帖数: 6127 | 23 With this kind of performance, she would have been fired in my team within a
few months.
【在 l***x 的大作中提到】
: 看了前两条就想这不是Amazon的吧，再往下看果然是。
: 第一条深有同感，不过不是在A才有的体会。
: 第三条感觉A有的组abuse了service，导致接口混乱，为了实现一个简单逻辑，需要多
: 个service call
: 第四条，开始和你同感。来5个月后现在感觉好多了，除了对package dependency的确
: 定觉得还是有点乱。我们全是在git上。
: 第七条和第八条应该结合起来，对工具熟了就好了
: 另外，现在越发觉得A招人只面算法无法区分developer的实际经验和能力。吐槽一下我
: 们组的一个女developer实在是太弱了，唉，写的code还不如本科生在读的。一个二三
: 十行很基本的java code要来回code review不下30遍都过不了，各种错误，改一个又引
|
g*****g
发帖数: 34805 | 24 楼主不够有经验一点，新手碰上这些问题也很正常。
我们做的其实是SOA下不断推出新的service来取代旧的，一些legacy code没人想碰。
Amazon想必也类似。 |
g**e
发帖数: 6127 | 25 migrate老service也是一件很头痛的事。从API到datastore都要重新设计。credit也不
多，
毕竟只是refactoring
【在 g*****g 的大作中提到】
: 楼主不够有经验一点，新手碰上这些问题也很正常。
: 我们做的其实是SOA下不断推出新的service来取代旧的，一些legacy code没人想碰。
: Amazon想必也类似。
|
l*****z
发帖数: 3022 | 26 A 对logging的策略就是宁可错杀一千，不可漏网一个。每天几个G的log文件很正常，
反正timber 的storage貌似无限。。。。。 |
g*****g
发帖数: 34805 | 27 都是加一点新功能，吹嘘成十，这就看老板本事了。总归这些人也得有活干。
你看office不是每一版改改界面就拿出来了，越改越烂。
【在 g**e 的大作中提到】
: migrate老service也是一件很头痛的事。从API到datastore都要重新设计。credit也不
: 多，
: 毕竟只是refactoring
|
l*****z
发帖数: 3022 | 28 Brazil，apollo的内核概念很牛逼，一般没有几个月是不能完全领会其精华的。同时可
以利用自己的desktop env去动手修改apollo的setting，有助于理解。新手尽量少
touch prod environment，不小心搞个sev1就有可能走人了。 |
p*****2
发帖数: 21240 | 29
嗯。这个确实是。我一般都愿意自己重写一遍，用新的architecture.
【在 g*****g 的大作中提到】
: 楼主不够有经验一点，新手碰上这些问题也很正常。
: 我们做的其实是SOA下不断推出新的service来取代旧的，一些legacy code没人想碰。
: Amazon想必也类似。
|
p*****2
发帖数: 21240 | 30
用sev0吗？
【在 l*****z 的大作中提到】
: Brazil，apollo的内核概念很牛逼，一般没有几个月是不能完全领会其精华的。同时可
: 以利用自己的desktop env去动手修改apollo的setting，有助于理解。新手尽量少
: touch prod environment，不小心搞个sev1就有可能走人了。
|
|
|
l*****z
发帖数: 3022 | 31 sev1已经最高了。amazon.com当了也就sev1.据说sev1会page除Jeff外的所有高层。
【在 p*****2 的大作中提到】
:
: 用sev0吗？
|
