e*******o
发帖数: 4654 | 1 我有个同事, 每次review的时候, 就想办法优化，压缩我的代码。
代码应该反映最初的思路，在代码基础上优化，结果就是尼玛根本不知道最初的本意了。
就是为了省两行代码。
有时候，他还提供代码，有意思的是，超过三行以上的，对的可能性不大。我还得再调
整.
有一次，我已经commit了，他还勤快，自己改了之后，再commit，结果test 跑不过了
，又改回来。精神倒是可嘉，不过真是浪费自己和他人的时间。
还有个同事，特别喜欢抽象。
哪怕写三个class，人家非得找个共同点，然后写个 XXabstact class。有时候，这些
class 并不能很自然的提取出来一个XXabstract class， 那就在 abstract class 里
，用if else 解决。 结果是，最终的class 是短了，不过，尼玛你要看 最终的class
，根本不知道是干啥的。因为主要的逻辑转移到了那个XXabstract class。 这样下来
，就是让所有的class 同样复杂。 因为你读任意一个最终的class，都要把那个屎一样
的abstractXX class 读一遍。 |
n******7
发帖数: 12463 | 2 都是闲的，这样简单事情复杂化才有快感，不然思维力过剩
当年年少无聊的时候，特别喜欢复杂的游戏，越复杂越觉得有意思
现在只能用脊柱玩游戏了
所以这个版上的职业马工有些喜欢有挑战的搞法，觉得简洁优美hardcore，弄出来很有
快感
我这种还要花很多时间养老鼠洗试管的，最喜欢文科大妈都能搞定的东西 |
g*****g
发帖数: 34805 | 3 弄到你说的那样就是写错了，提出来是对的，但多半应该写个 helper inject到三个类
里，而不是走继承。不是明显继承关系应该用 composition.
了。
些
【在 e*******o 的大作中提到】
: 我有个同事, 每次review的时候, 就想办法优化，压缩我的代码。
: 代码应该反映最初的思路，在代码基础上优化，结果就是尼玛根本不知道最初的本意了。
: 就是为了省两行代码。
: 有时候，他还提供代码，有意思的是，超过三行以上的，对的可能性不大。我还得再调
: 整.
: 有一次，我已经commit了，他还勤快，自己改了之后，再commit，结果test 跑不过了
: ，又改回来。精神倒是可嘉，不过真是浪费自己和他人的时间。
: 还有个同事，特别喜欢抽象。
: 哪怕写三个class，人家非得找个共同点，然后写个 XXabstact class。有时候，这些
: class 并不能很自然的提取出来一个XXabstract class， 那就在 abstract class 里
|
l**********n
发帖数: 8443 | 4 java?
了。
些
【在 e*******o 的大作中提到】
: 我有个同事, 每次review的时候, 就想办法优化，压缩我的代码。
: 代码应该反映最初的思路，在代码基础上优化，结果就是尼玛根本不知道最初的本意了。
: 就是为了省两行代码。
: 有时候，他还提供代码，有意思的是，超过三行以上的，对的可能性不大。我还得再调
: 整.
: 有一次，我已经commit了，他还勤快，自己改了之后，再commit，结果test 跑不过了
: ，又改回来。精神倒是可嘉，不过真是浪费自己和他人的时间。
: 还有个同事，特别喜欢抽象。
: 哪怕写三个class，人家非得找个共同点，然后写个 XXabstact class。有时候，这些
: class 并不能很自然的提取出来一个XXabstract class， 那就在 abstract class 里
|
e*******o
发帖数: 4654 | 5 sencha js
【在 l**********n 的大作中提到】
: java?
:
: 了。
: 些
|
e*******o
发帖数: 4654 | 6 每个class 也就10来行
更新了 ExtJS之后 有个test 跑不过了
我就把相关的class 从头重新写 删掉那个抠出来的class 然后就好了 代码还更容易理解
reviewer 看了之后 说本以为那个class 会省省多少事呢 结果没多大用 还增加bug 以
后不用了
【在 g*****g 的大作中提到】
: 弄到你说的那样就是写错了，提出来是对的，但多半应该写个 helper inject到三个类
: 里，而不是走继承。不是明显继承关系应该用 composition.
:
: 了。
: 些
|
l**********n
发帖数: 8443 | 7 这样的同事我也碰到过，不过是Java，喜欢优化，教科书式的。这哥们以前是搞教学的。
【在 l**********n 的大作中提到】
: java?
:
: 了。
: 些
|
e*******o
发帖数: 4654 | 8 靠
我那个喜欢优化的同事也是搞数学的
的。
【在 l**********n 的大作中提到】
: 这样的同事我也碰到过，不过是Java，喜欢优化，教科书式的。这哥们以前是搞教学的。
|
n******n
发帖数: 12088 | 9 贴代码看看。
了。
些
【在 e*******o 的大作中提到】
: 我有个同事, 每次review的时候, 就想办法优化，压缩我的代码。
: 代码应该反映最初的思路，在代码基础上优化，结果就是尼玛根本不知道最初的本意了。
: 就是为了省两行代码。
: 有时候，他还提供代码，有意思的是，超过三行以上的，对的可能性不大。我还得再调
: 整.
: 有一次，我已经commit了，他还勤快，自己改了之后，再commit，结果test 跑不过了
: ，又改回来。精神倒是可嘉，不过真是浪费自己和他人的时间。
: 还有个同事，特别喜欢抽象。
: 哪怕写三个class，人家非得找个共同点，然后写个 XXabstact class。有时候，这些
: class 并不能很自然的提取出来一个XXabstract class， 那就在 abstract class 里
|
l****5
发帖数: 5865 | |
|
|
e*******o
发帖数: 4654 | 11 能贴早就贴了
【在 n******n 的大作中提到】
: 贴代码看看。
:
: 了。
: 些
|
n******n
发帖数: 12088 | 12 改头换面啊。空口无凭，说不定他们是对的，或者也有道理。
【在 e*******o 的大作中提到】
: 能贴早就贴了
|
e*******o
发帖数: 4654 | 13 这个对不对, 早有结论了 .
过度优化的后果就是,代码难读, 增加bug.
【在 n******n 的大作中提到】
: 改头换面啊。空口无凭，说不定他们是对的，或者也有道理。
|
g*****g
发帖数: 34805 | 14 这东西倒不是纯粹数行数，比如说你这三个类有相同功能每次都要调俩东西，哪怕就两
行也应该放
入一个方法。这样以后refactor不用改一堆的类。
理解
【在 e*******o 的大作中提到】
: 每个class 也就10来行
: 更新了 ExtJS之后 有个test 跑不过了
: 我就把相关的class 从头重新写 删掉那个抠出来的class 然后就好了 代码还更容易理解
: reviewer 看了之后 说本以为那个class 会省省多少事呢 结果没多大用 还增加bug 以
: 后不用了
|
n******n
发帖数: 12088 | 15 有什么结论？也许他们优化的对，代码见分晓。
【在 e*******o 的大作中提到】
: 这个对不对, 早有结论了 .
: 过度优化的后果就是,代码难读, 增加bug.
|
n******n
发帖数: 12088 | 16 所以我说贴代码才能评价。
【在 g*****g 的大作中提到】
: 这东西倒不是纯粹数行数，比如说你这三个类有相同功能每次都要调俩东西，哪怕就两
: 行也应该放
: 入一个方法。这样以后refactor不用改一堆的类。
:
: 理解
|
e*******o
发帖数: 4654 | 17 这些class 是ext 的 store, 都是简单的config 你看看ext 文的store 文档 就知道
了 根本没有再加一层抽象的必要
【在 g*****g 的大作中提到】
: 这东西倒不是纯粹数行数，比如说你这三个类有相同功能每次都要调俩东西，哪怕就两
: 行也应该放
: 入一个方法。这样以后refactor不用改一堆的类。
:
: 理解
|
e*******o
发帖数: 4654 | 18 结论就是 我的代码已经通过review commit 了
【在 n******n 的大作中提到】
: 有什么结论？也许他们优化的对，代码见分晓。
|
x*******1
发帖数: 28835 | 19 德霸是对的， 应该写个helper function ，compose这些类。 学点设计模式没啥坏处
。 |
T*******x
发帖数: 8565 | 20 他说的那个是搞教学的，不是搞数学的:)
【在 e*******o 的大作中提到】
: 靠
: 我那个喜欢优化的同事也是搞数学的
:
: 的。
|
|
|
n******n
发帖数: 12088 | 21 从对方的做法看，是真心不喜欢你的代码。既然是同事，还是沟通、合作为好。
通过审核提交只能说明审核者OK，不能说明代码质量高。
这种空泛的抱怨没有价值。
【在 e*******o 的大作中提到】
: 结论就是 我的代码已经通过review commit 了
|
e*******o
发帖数: 4654 | 22 我那个同事就是谁的代码都优化一下 风格就是如此
人还是不错的 他优化几次 测试都通不过 慢慢就不那么激进了
我只是吐个曹
【在 n******n 的大作中提到】
: 从对方的做法看，是真心不喜欢你的代码。既然是同事，还是沟通、合作为好。
: 通过审核提交只能说明审核者OK，不能说明代码质量高。
: 这种空泛的抱怨没有价值。
|
e*******o
发帖数: 4654 | 23 哈哈
我同事是以前是高中数学老师
【在 T*******x 的大作中提到】
: 他说的那个是搞教学的，不是搞数学的:)
|
q*c
发帖数: 9453 | 24 我们那个 Scala lover 以前也是大学助教，左派，热爱远方的劳动人民，但是不爱身
边的同
事， lol
左派的虚伪嘴脸实在是。。。而且还真是学校里面多。
【在 e*******o 的大作中提到】
: 哈哈
: 我同事是以前是高中数学老师
|
q*c
发帖数: 9453 | 25 mitbbs 上无论空洞还是实在能有啥价值？代码质量高你就能多挣钱升官生活愉快？
你还真吧别人吐槽都不让了。。。
【在 n******n 的大作中提到】
: 从对方的做法看，是真心不喜欢你的代码。既然是同事，还是沟通、合作为好。
: 通过审核提交只能说明审核者OK，不能说明代码质量高。
: 这种空泛的抱怨没有价值。
|
n******n
发帖数: 12088 | 26 编程版讨论代码质量不是很自然吗？
【在 q*c 的大作中提到】
: mitbbs 上无论空洞还是实在能有啥价值？代码质量高你就能多挣钱升官生活愉快？
: 你还真吧别人吐槽都不让了。。。
|
D******r
发帖数: 5237 | |
q*c
发帖数: 9453 | 28 但是也要容忍别人吐槽。 不能动不动就上 code.
那活着还有啥意思。
【在 n******n 的大作中提到】
: 编程版讨论代码质量不是很自然吗？
|
n******n
发帖数: 12088 | 29 吐槽抽象这么重要的原则，当然要看代码啊。可能是抽象的不对，也可能是楼主的代码
确实可以改进。
你要是吐槽测试真是不一定好，那不用上代码就会挨批。
【在 q*c 的大作中提到】
: 但是也要容忍别人吐槽。 不能动不动就上 code.
: 那活着还有啥意思。
|
l**********n
发帖数: 8443 | 30 你确定你比楼主水平高？
【在 n******n 的大作中提到】
: 吐槽抽象这么重要的原则，当然要看代码啊。可能是抽象的不对，也可能是楼主的代码
: 确实可以改进。
: 你要是吐槽测试真是不一定好，那不用上代码就会挨批。
|
|
|
e*******o
发帖数: 4654 | 31 我已经说了, 优化代码的那个.
自己连test 都跑不过, 然后又恢复我原来的代码.
抽象那个, 因为外部依赖的库变了, 有bug 出现, 我直接把原来的 parent class 删了
, 从新写了一下,容易懂, 也work.
反正, 每次看到, 硬扣出来的class 中, method 中 各种if else, 俺就 WTF 无数次.
上代码 一是不允许, 即使允许, 很难分离出来.
吐槽的也有他提醒某些nerd 的意思, 不要处处都抽象, 用各种所谓的高级feature, 自
然而然的代码, 多好.
还有所谓的refactor, 有些代码refactor 前还可以读, 某些人 refactor 之后就不可
读了.
完全是看着代码refactor, 而不是根据处理问题的思路refactor. 绝对是做负功。
【在 n******n 的大作中提到】
: 吐槽抽象这么重要的原则，当然要看代码啊。可能是抽象的不对，也可能是楼主的代码
: 确实可以改进。
: 你要是吐槽测试真是不一定好，那不用上代码就会挨批。
|
n******n
发帖数: 12088 | 32 当然不确定。但这里有高水平的。
【在 l**********n 的大作中提到】
: 你确定你比楼主水平高？
|
n******n
发帖数: 12088 | 33 测试跑不过，那说明有bug，但不应该就此否定优化本身。他改回去，可能是发现了问
题，也可能是有更紧急的任务。
硬扣class，一堆if else，很可能是抽象的不对。好原则，坏应用，这种现象常见，但
不意味着原则本身有问题。
【在 e*******o 的大作中提到】
: 我已经说了, 优化代码的那个.
: 自己连test 都跑不过, 然后又恢复我原来的代码.
: 抽象那个, 因为外部依赖的库变了, 有bug 出现, 我直接把原来的 parent class 删了
: , 从新写了一下,容易懂, 也work.
: 反正, 每次看到, 硬扣出来的class 中, method 中 各种if else, 俺就 WTF 无数次.
: 上代码 一是不允许, 即使允许, 很难分离出来.
: 吐槽的也有他提醒某些nerd 的意思, 不要处处都抽象, 用各种所谓的高级feature, 自
: 然而然的代码, 多好.
: 还有所谓的refactor, 有些代码refactor 前还可以读, 某些人 refactor 之后就不可
: 读了.
|
n******n
发帖数: 12088 | 34 破坏可读性的refactoring和抽象有何关系？抽象是为了提高可读性。
【在 n******n 的大作中提到】
: 测试跑不过，那说明有bug，但不应该就此否定优化本身。他改回去，可能是发现了问
: 题，也可能是有更紧急的任务。
: 硬扣class，一堆if else，很可能是抽象的不对。好原则，坏应用，这种现象常见，但
: 不意味着原则本身有问题。
|
e*******o
发帖数: 4654 | 35 代码私信发给你了，看看你找的出bug不？ 这个是比较好分离出来的一个。
我没有否定抽象，只是说，不要为了抽象而抽象，自然而然能解决问题，为啥要生搬硬
套规则。
【在 n******n 的大作中提到】
: 测试跑不过，那说明有bug，但不应该就此否定优化本身。他改回去，可能是发现了问
: 题，也可能是有更紧急的任务。
: 硬扣class，一堆if else，很可能是抽象的不对。好原则，坏应用，这种现象常见，但
: 不意味着原则本身有问题。
|
q*c
发帖数: 9453 | 36 简单的就是最好的， 但是搞软件的天生就有要复杂化的倾向。 这是人的劣根性， 很
难克服。
我还看到有人搞 stream reader. 夫类里面通过子类读， 子类重载那个方法， 然后子
类里面又调用父类里面的方法， 然后那些方法又在各个子类里面重载。。。读代码就
喝吃屎一样。
为啥这是人的劣根性？ 因为 99% 的人都很自我中心， 只要不被强制， 就肯定是优先
于写的爽， 不会管没有上下文的别人读的感受如何。 而且写的爽容易， 特别是使用
了各种技巧， 更有精美组合成功的成就感。 可是要让程序读的爽那就很难， 而且没
成就感。
【在 e*******o 的大作中提到】
: 我已经说了, 优化代码的那个.
: 自己连test 都跑不过, 然后又恢复我原来的代码.
: 抽象那个, 因为外部依赖的库变了, 有bug 出现, 我直接把原来的 parent class 删了
: , 从新写了一下,容易懂, 也work.
: 反正, 每次看到, 硬扣出来的class 中, method 中 各种if else, 俺就 WTF 无数次.
: 上代码 一是不允许, 即使允许, 很难分离出来.
: 吐槽的也有他提醒某些nerd 的意思, 不要处处都抽象, 用各种所谓的高级feature, 自
: 然而然的代码, 多好.
: 还有所谓的refactor, 有些代码refactor 前还可以读, 某些人 refactor 之后就不可
: 读了.
|
q*c
发帖数: 9453 | 37 人脑是非常低能的处理设备。记忆能力非常弱小。
抽象只提高信息密度， 并不一定就增加可读性。 你为了理解抽象的东西， 就必须记
住各种上下文。这就是overhead.
【在 n******n 的大作中提到】
: 破坏可读性的refactoring和抽象有何关系？抽象是为了提高可读性。
|
n******n
发帖数: 12088 | 38 抽象可以更好组织信息，简化记忆。有开销，收获更大。好的抽象就是要省下上下文。
【在 q*c 的大作中提到】
: 人脑是非常低能的处理设备。记忆能力非常弱小。
: 抽象只提高信息密度， 并不一定就增加可读性。 你为了理解抽象的东西， 就必须记
: 住各种上下文。这就是overhead.
|
e*******o
发帖数: 4654 | 39 你现在开始说好的抽象了.
好的我当然不会吐槽. 我吐槽的是坏的.
btw 发给你的代码, bug 你找出来了么?
【在 n******n 的大作中提到】
: 抽象可以更好组织信息，简化记忆。有开销，收获更大。好的抽象就是要省下上下文。
|
q*c
发帖数: 9453 | 40 好的抽象就是容易懂的东西。
根据你自己的定义，人脑善于抽象，那抽象的结果必须是更加容易理解。
【在 n******n 的大作中提到】
: 抽象可以更好组织信息，简化记忆。有开销，收获更大。好的抽象就是要省下上下文。
|
|
|
c*******9
发帖数: 9032 | 41 容易懂往往是错觉。就像法轮功山寨佛教，比佛教容易懂，实际是误导。
【在 q*c 的大作中提到】
: 好的抽象就是容易懂的东西。
: 根据你自己的定义，人脑善于抽象，那抽象的结果必须是更加容易理解。
|
q*c
发帖数: 9453 | 42 我了解， 只有你们这些左派鉴定过的容易才是容易嘛， 别人的容易不算的。你们容易
的别人再觉得恶心难受那都是错觉， wahaha.
【在 c*******9 的大作中提到】
: 容易懂往往是错觉。就像法轮功山寨佛教，比佛教容易懂，实际是误导。
|
g*****g
发帖数: 34805 | 43 要扫过厕所才不会随地大小便，说起来让自己爽别人不爽也是人性之一。
【在 q*c 的大作中提到】
: 我了解， 只有你们这些左派鉴定过的容易才是容易嘛， 别人的容易不算的。你们容易
: 的别人再觉得恶心难受那都是错觉， wahaha.
|
n******n
发帖数: 12088 | 44 不好的就不是抽象。抽象不会错。
上次玩破是十年前了。不过你这个所谓抽象，抽到哪里去了？莫名其妙的代码。
没细看，但凭感觉，那个delete有问题。
你自己的代码，back button也漏了push吧。
【在 e*******o 的大作中提到】
: 你现在开始说好的抽象了.
: 好的我当然不会吐槽. 我吐槽的是坏的.
: btw 发给你的代码, bug 你找出来了么?
|
e*******o
发帖数: 4654 | 45 从cruciable 中copy 出来的，删代码行号把那个 push 给删了。
原来的代码，都有测试的，每个页面都是这些button 怎么会漏。
另外，那个%data 应该是 %class。 我copy的时候也搞错了。
问题不在这些。
问题是 key %hash。 这个结果不是ordered。而我的代码三个 if 是按照顺序执行的，
是ordered。
我写好，我同事觉得，有重复，应该按照他给的代码。结果就是WTF。
这个是给你的优化后不可读的例子。 你是否同意？
抽象的例子你看了会更可笑，不过不好分离出来。
【在 n******n 的大作中提到】
: 不好的就不是抽象。抽象不会错。
: 上次玩破是十年前了。不过你这个所谓抽象，抽到哪里去了？莫名其妙的代码。
: 没细看，但凭感觉，那个delete有问题。
: 你自己的代码，back button也漏了push吧。
|
e*******o
发帖数: 4654 | 46 不好的就不是抽象。抽象不会错。
你这逻辑也够强大的。
【在 n******n 的大作中提到】
: 不好的就不是抽象。抽象不会错。
: 上次玩破是十年前了。不过你这个所谓抽象，抽到哪里去了？莫名其妙的代码。
: 没细看，但凭感觉，那个delete有问题。
: 你自己的代码，back button也漏了push吧。
|
n******n
发帖数: 12088 | 47 19行的代码优化成18行，这是哪门子的优化啊？
另外你的代码为何要按顺序？调换一下不应该影响逻辑。
【在 e*******o 的大作中提到】
: 从cruciable 中copy 出来的，删代码行号把那个 push 给删了。
: 原来的代码，都有测试的，每个页面都是这些button 怎么会漏。
: 另外，那个%data 应该是 %class。 我copy的时候也搞错了。
: 问题不在这些。
: 问题是 key %hash。 这个结果不是ordered。而我的代码三个 if 是按照顺序执行的，
: 是ordered。
: 我写好，我同事觉得，有重复，应该按照他给的代码。结果就是WTF。
: 这个是给你的优化后不可读的例子。 你是否同意？
: 抽象的例子你看了会更可笑，不过不好分离出来。
|
n******n
发帖数: 12088 | 48 抽象就是化繁为简。简单就是好，你不同意吗？
别人挂羊头卖狗肉，你吃了狗肉，抱怨羊肉其实不一定好吃。这不是打错了靶子吗？
【在 e*******o 的大作中提到】
: 不好的就不是抽象。抽象不会错。
: 你这逻辑也够强大的。
|
n******n
发帖数: 12088 | 49 还有，这里三个按钮，用不用循环问题不大。十个的时候就有用了。
【在 n******n 的大作中提到】
: 19行的代码优化成18行，这是哪门子的优化啊？
: 另外你的代码为何要按顺序？调换一下不应该影响逻辑。
|
e*******o
发帖数: 4654 | 50 如果一个页面有continue btn 和 back btn, 必须 back 在左面, continue 在右面.
他也这样说, 关键是会不会有 十个? 杞人忧天.
【在 n******n 的大作中提到】
: 还有，这里三个按钮，用不用循环问题不大。十个的时候就有用了。
|
|
|
n******7
发帖数: 12463 | 51 你的观点我很喜欢
越简单完成事情越好
以后跟着你的看法混
【在 q*c 的大作中提到】
: 简单的就是最好的， 但是搞软件的天生就有要复杂化的倾向。 这是人的劣根性， 很
: 难克服。
: 我还看到有人搞 stream reader. 夫类里面通过子类读， 子类重载那个方法， 然后子
: 类里面又调用父类里面的方法， 然后那些方法又在各个子类里面重载。。。读代码就
: 喝吃屎一样。
: 为啥这是人的劣根性？ 因为 99% 的人都很自我中心， 只要不被强制， 就肯定是优先
: 于写的爽， 不会管没有上下文的别人读的感受如何。 而且写的爽容易， 特别是使用
: 了各种技巧， 更有精美组合成功的成就感。 可是要让程序读的爽那就很难， 而且没
: 成就感。
|
e*******o
发帖数: 4654 | 52 所以我来吐槽啊.
本来简单简洁的代码, 非得改成一坨.
【在 n******n 的大作中提到】
: 19行的代码优化成18行，这是哪门子的优化啊？
: 另外你的代码为何要按顺序？调换一下不应该影响逻辑。
|
e*******o
发帖数: 4654 | 53 他是经历多了, 平平淡淡才是真.哈哈.
【在 n******7 的大作中提到】
: 你的观点我很喜欢
: 越简单完成事情越好
: 以后跟着你的看法混
|
q*c
发帖数: 9453 | 54 你这逻辑我间的太多了， 如果 xxx, Long term yyy... 都是搞笑
绝大多数根本就没有 Long term 那天。
基本上各种 over engineer 的狗屎都是这样出来的。 绝大多数最后没有享受到长远利
益就被替换了，或者真到了场馆的时候由于过于复杂而且人都换完了，导致巧妙的设计
都是浪费，后面的人重起一套。
绝大多数， 直观简单的东西就好
【在 n******n 的大作中提到】
: 还有，这里三个按钮，用不用循环问题不大。十个的时候就有用了。
|
q*c
发帖数: 9453 | 55 别幻想了，物理上有能量守恒，信息上有复杂度守恒。 一件事物，有基本的复杂度，
无法通过人方式变得更简单， 你无非是个乾坤大挪移，把复杂度移动到不同的地方藏
起来。
抽象只是形势上化翻为简，实质的复杂度一点也无法减少，而且因为抽象增加了间接的
层次，其实变得更加的复杂。
抽象其实是增加了复杂密度，减少了表面积。 这玩意一点不简单。
哥就是物理专业的，各种复杂的物理现象抽象成简单的规律，看着简单吧？大部分人拿
着规律根本毫无办法应用， 因为地下的复杂情况一点没减少，你光抽象顶毛用。
你这样的小左来个空洞的理论到处忽悠，简单就是好，抽象就是简单，哈哈。 共产主
义世界真美好
【在 n******n 的大作中提到】
: 抽象就是化繁为简。简单就是好，你不同意吗？
: 别人挂羊头卖狗肉，你吃了狗肉，抱怨羊肉其实不一定好吃。这不是打错了靶子吗？
|
e*******o
发帖数: 4654 | 56 re
这点我感受比较深
某些nerd 抠出来一个class 之后 炫耀 你看现在多简单 就config几下就好了 所谓
config 代替code
结果根本不知道那几个config干啥的
【在 q*c 的大作中提到】
: 别幻想了，物理上有能量守恒，信息上有复杂度守恒。 一件事物，有基本的复杂度，
: 无法通过人方式变得更简单， 你无非是个乾坤大挪移，把复杂度移动到不同的地方藏
: 起来。
: 抽象只是形势上化翻为简，实质的复杂度一点也无法减少，而且因为抽象增加了间接的
: 层次，其实变得更加的复杂。
: 抽象其实是增加了复杂密度，减少了表面积。 这玩意一点不简单。
: 哥就是物理专业的，各种复杂的物理现象抽象成简单的规律，看着简单吧？大部分人拿
: 着规律根本毫无办法应用， 因为地下的复杂情况一点没减少，你光抽象顶毛用。
: 你这样的小左来个空洞的理论到处忽悠，简单就是好，抽象就是简单，哈哈。 共产主
: 义世界真美好
|
n******n
发帖数: 12088 | 57 复杂度守恒，你怎么不把循环语句全部展开，把helper全部inline呢？
要从人的角度看。
【在 q*c 的大作中提到】
: 别幻想了，物理上有能量守恒，信息上有复杂度守恒。 一件事物，有基本的复杂度，
: 无法通过人方式变得更简单， 你无非是个乾坤大挪移，把复杂度移动到不同的地方藏
: 起来。
: 抽象只是形势上化翻为简，实质的复杂度一点也无法减少，而且因为抽象增加了间接的
: 层次，其实变得更加的复杂。
: 抽象其实是增加了复杂密度，减少了表面积。 这玩意一点不简单。
: 哥就是物理专业的，各种复杂的物理现象抽象成简单的规律，看着简单吧？大部分人拿
: 着规律根本毫无办法应用， 因为地下的复杂情况一点没减少，你光抽象顶毛用。
: 你这样的小左来个空洞的理论到处忽悠，简单就是好，抽象就是简单，哈哈。 共产主
: 义世界真美好
|
n******n
发帖数: 12088 | 58 物理专业来编程版喷啥。
【在 q*c 的大作中提到】
: 别幻想了，物理上有能量守恒，信息上有复杂度守恒。 一件事物，有基本的复杂度，
: 无法通过人方式变得更简单， 你无非是个乾坤大挪移，把复杂度移动到不同的地方藏
: 起来。
: 抽象只是形势上化翻为简，实质的复杂度一点也无法减少，而且因为抽象增加了间接的
: 层次，其实变得更加的复杂。
: 抽象其实是增加了复杂密度，减少了表面积。 这玩意一点不简单。
: 哥就是物理专业的，各种复杂的物理现象抽象成简单的规律，看着简单吧？大部分人拿
: 着规律根本毫无办法应用， 因为地下的复杂情况一点没减少，你光抽象顶毛用。
: 你这样的小左来个空洞的理论到处忽悠，简单就是好，抽象就是简单，哈哈。 共产主
: 义世界真美好
|
n******n
发帖数: 12088 | 59 我觉得你是因噎废食。他那么设计，如果好，试着去理解，消化。如果不好，你也可以
指出问题。而不是泛泛否定。
【在 e*******o 的大作中提到】
: re
: 这点我感受比较深
: 某些nerd 抠出来一个class 之后 炫耀 你看现在多简单 就config几下就好了 所谓
: config 代替code
: 结果根本不知道那几个config干啥的
|
n******n
发帖数: 12088 | 60 没看懂。你们假定容器里的顺序对应页面由左向右的位置？有点古怪。
如果有十个，你怎么改进？有没有简洁正确的写法？这次用不上，以后可能有用。
你这个同事至少有优化的意识。你自己是不是只想按最熟悉的方式交差了事？
【在 e*******o 的大作中提到】
: 如果一个页面有continue btn 和 back btn, 必须 back 在左面, continue 在右面.
: 他也这样说, 关键是会不会有 十个? 杞人忧天.
|
|
|
d******e
发帖数: 2265 | 61 哈哈 赞同这一点
看到的寿命最长的代码是15年的万行大函数。
现在的语言能不能活过这个年纪都难说
而且一有新的平台。比如kaddop 什么的老代码还得丢
最后代码重复算个屁，上神器source insight
另外动态语言写的太烦代码性能也会有影响
【在 q*c 的大作中提到】
: 你这逻辑我间的太多了， 如果 xxx, Long term yyy... 都是搞笑
: 绝大多数根本就没有 Long term 那天。
: 基本上各种 over engineer 的狗屎都是这样出来的。 绝大多数最后没有享受到长远利
: 益就被替换了，或者真到了场馆的时候由于过于复杂而且人都换完了，导致巧妙的设计
: 都是浪费，后面的人重起一套。
: 绝大多数， 直观简单的东西就好
|
d******e
发帖数: 2265 | 62 你以为。搞OS的系统的大多数代码都是这样的
没事谁敢抽出代码重构
你能保证不会引进新的错误
【在 n******n 的大作中提到】
: 复杂度守恒，你怎么不把循环语句全部展开，把helper全部inline呢？
: 要从人的角度看。
|
l**********n
发帖数: 8443 | 63 动态语言没有测试，不放心啊，昨天把我的代码做了下优化，因为涉及太多改动，怕
有typo，幸好有完整的unit tests 和 integration tests, tests 一 run， 心理很放
心。昨天涉及到的改动是database 有个 validation error， 但是却没有处理，直到
用户使用时提出来，自己写的时候往往考虑不周全。动态语言productivity还是高。开
始我还以为mongoDb见鬼了。
【在 d******e 的大作中提到】
: 哈哈 赞同这一点
: 看到的寿命最长的代码是15年的万行大函数。
: 现在的语言能不能活过这个年纪都难说
: 而且一有新的平台。比如kaddop 什么的老代码还得丢
: 最后代码重复算个屁，上神器source insight
: 另外动态语言写的太烦代码性能也会有影响
|
l**********n
发帖数: 8443 | 64 我觉得所谓优化就是处理异常，而不是OOP。OOP又不能处理异常。FP好在对异常有清晰
的处理。 |
q*c
发帖数: 9453 | 65 以后有 100 个以后再改，现在杞人忧天那么多干啥？好处没得到，麻烦先到手。
【在 n******n 的大作中提到】
: 没看懂。你们假定容器里的顺序对应页面由左向右的位置？有点古怪。
: 如果有十个，你怎么改进？有没有简洁正确的写法？这次用不上，以后可能有用。
: 你这个同事至少有优化的意识。你自己是不是只想按最熟悉的方式交差了事？
|
e*******o
发帖数: 4654 | 66 我不理解也不会在这喷了. 就因为理解了才觉得完全不必要.
当然指出了. 结果是我以后牵涉到他代码的部分, 一律跳过, 从头写. 这个reviewer
也都同意的了.
【在 n******n 的大作中提到】
: 我觉得你是因噎废食。他那么设计，如果好，试着去理解，消化。如果不好，你也可以
: 指出问题。而不是泛泛否定。
|
e*******o
发帖数: 4654 | 67 从左往右, 太正常不过了. 你看网页从右往左? 还是像我同事一样random?
我不需要优化意识, 烂代码看起来就不舒服, 我写出来的代码自己觉得舒服了, 一般
就没有太多优化的空间. 再优化十有八九是画蛇添足, 连test 都跑不过.
【在 n******n 的大作中提到】
: 没看懂。你们假定容器里的顺序对应页面由左向右的位置？有点古怪。
: 如果有十个，你怎么改进？有没有简洁正确的写法？这次用不上，以后可能有用。
: 你这个同事至少有优化的意识。你自己是不是只想按最熟悉的方式交差了事？
|
z***y
发帖数: 73 | 68 不能本末倒置，为了抽象而抽象显然是不妥的。
另外过度设计也不可取，100人在线的系统和100万人在线的系统架构能是一样的吗？不
用考虑的过于长远，根据现有的情况留有一定余量足可。 |
h**l
发帖数: 168 | |
