经验和预见的重要性
老大说，我们发布的软件只需要指定一个固定的端口，hard code无所谓。我说，谁把这东西hard code我杀了他。后来，一见到hard code端口我就跳起来找人拼命。
结果系统没有hard code这个端口。今天老大在第一个客户上装系统，第一件事就是开了一个“非标准端口”，
奶奶的，如果不是我之前坚持，他现在就够头痛的了。 原帖由 key 于 3-8-2010 13:37 发表 http://freeoz.org/ibbs/images/common/back.gif
如果不是我之前坚持，他现在就够头痛的了。
他忍了你这么久才够头痛呢
你能坚持到现在也算幸存者了
我现在的做法是大家高兴就好，将来有问题将来安排时间解决嘛，大家又不急着退休 要看公司的背景。
我的责任之一是整改公司的软件架构和开发流程，
如果没有相对合理的开发指引，根本说不上软件开发。
几个人跟着项目转悠，最后弄个半死不活的系统出来，不是我想要的。
老大现在很开心，有一个清清楚楚的系统，老大的老大更开心，因为系统能见人，这样他们才能向客户吹水。
我当初能清楚地看到问题能导致的严重后果，所谓我绝不放过这些细节，否则，最后问题还是回到我身上。
我的坚持是基于我当初清晰的预见，而不是意气用事。
原帖由 yuba 于 3-8-2010 13:55 发表 http://www.freeoz.org/ibbs/images/common/back.gif
他忍了你这么久才够头痛呢
你能坚持到现在也算幸存者了
我现在的做法是大家高兴就好，将来有问题将来安排时间解决嘛，大家又不急着退休 可能和你举的这个例子有关
不hard code这件事属于让历史告诉未来的范畴，是不需要预见能力就应该遵守的
另外就事论事，一个只有一个固定端口的系统即使hard code了、碰到非标准端口了、需要改正了，也不应该需要多长时间
我只是从这个例子中没有看出老大需要头痛的必要，当然用这个事情去教育老大和兄弟是无可厚非的 原帖由 yuba 于 3-8-2010 15:38 发表 http://www.freeoz.org/ibbs/images/common/back.gif
可能和你举的这个例子有关
不hard code这件事属于让历史告诉未来的范畴，是不需要预见能力就应该遵守的
另外就事论事，一个只有一个固定端口的系统即使hard code了、碰到非标准端口了、需要改正了，也不应该需 ...
你就不考虑重新编译，然后把编译好的程序发到现场的成本？不考虑针对不同环境的版本升级时候可能出现的问题？
无论如何，把类似端口这样明显属于环境变量的东西hard code都是不应该的，我觉得楼主做得很好啊 :lol 不需要太长时间和不需要时间是两个完全不同质的东西。
一个完全没有经过测试和端口改变，可以毁掉整个系统而你完全来不及做任何反应，对吧？
而有的应用现场，并不是想改就敢改的。
另一个背景问题是，我当初要拦下来的，不是一个问题，而是一系列问题，
比如老大期望在一台服务器上有且只有一个系统在跑，我坚持在同一个系统上，必须能理论上跑无限个系统。
老大期望尽量耗内存，不用担心，我坚持所有内存必须算清算楚。
老大期望一开始就关注并只关注系统运行速度，我坚持一开始关注并只关注系统稳定性。
这些坚持都建立在多年的产品经验和运维经验上，并不是一个简单的hardcode问题
原帖由 yuba 于 3-8-2010 15:38 发表 http://www.freeoz.org/ibbs/images/common/back.gif
可能和你举的这个例子有关
不hard code这件事属于让历史告诉未来的范畴，是不需要预见能力就应该遵守的
另外就事论事，一个只有一个固定端口的系统即使hard code了、碰到非标准端口了、需要改正了，也不应该需 ... 原帖由 key 于 3-8-2010 16:20 发表 http://freeoz.org/ibbs/images/common/back.gif
另一个背景问题是，我当初要拦下来的，不是一个问题，而是一系列问题
所以我说“和你举的例子有关”，“就事论事”
如果你期待每个读者都能从hard code这件事联想到你的那一系列问题，算我没说 但我觉得，如果有人从“该软件只会运行在某个指定端口”而要求全面hardcode这个端口，
最终会遇到一些不容易预见的麻烦。作为一个有经验的开发人员，应该从一开始就劝阻这种不智的假设。
原帖由 yuba 于 3-8-2010 16:33 发表 http://www.freeoz.org/ibbs/images/common/back.gif
所以我说“和你举的例子有关”，“就事论事”
如果你期待每个读者都能从hard code这件事联想到你的那一系列问题，算我没说 我看成hardcore了;P
除了toy级别的程序，hard code都不应该，除非有十足的理由。 理由充足到比如，C/C++里，用0这个hard code而不用NULL. 原帖由 woodheadz 于 3-8-2010 15:59 发表 http://freeoz.org/ibbs/images/common/back.gif
无论如何，把类似端口这样明显属于环境变量的东西hard code都是不应该的，我觉得楼主做得很好啊
什么态度？！你竟然把楼主根据多年产品开发和运维经验的基础上提出的预见，当做只是禁止了一个“明显”的错误行为？
我帮你改改：没有多年经验，根本不会意识到把类似端口这样属于环境变量的东西hard code是不应该的
呵呵，开个玩笑 很同意。
其实hardcode端口最让人头痛的事应该是开发过程中的测试。这种不智的设想会让你难以有效地进行各种测试。
这里不单单是一个hardcode问题，我想说的是涉及到一系列没有必要的前提假设，我上面已经提到一部分。
这些东西对整个开发和运维都会带来很负面的影响。比如严重的内存浪费，可以让你在任何一台非目标主机上无法运行该软件，
包括你自己的开发机，而一台服务器只跑一个实例，也会让你必须启动多台机器才能进行一次简单的组装测试。
经验可以帮我们预见整个SDLC过程中可能遇到的各种问题，而对一些决定做出判断，
缺少经验，往往会看某些东西根本没法有问题，另一些东西可能有问题，但不致命。
原帖由 woodheadz 于 3-8-2010 15:59 发表 http://www.freeoz.org/ibbs/images/common/back.gif
你就不考虑重新编译，然后把编译好的程序发到现场的成本？不考虑针对不同环境的版本升级时候可能出现的问题？
无论如何，把类似端口这样明显属于环境变量的东西hard code都是不应该的，我觉得楼主做得很好啊 :l ... 原帖由 key 于 3-8-2010 16:39 发表 http://freeoz.org/ibbs/images/common/back.gif
但我觉得，如果有人从“该软件只会运行在某个指定端口”而要求全面hardcode这个端口，
最终会遇到一些不容易预见的麻烦。
假设这个端口就是4321，不改
系统里一共出现xx次，就写xx个“4321”，根本不用什么预见，这本身就是不好的 原帖由 yuba 于 3-8-2010 16:44 发表 http://www.freeoz.org/ibbs/images/common/back.gif
什么态度？！你竟然把楼主根据多年产品开发和运维经验的基础上提出的预见，当做只是禁止了一个“明显”的错误行为？
我帮你改改：没有多年经验，根本不会意识到把类似端口这样属于环境变量的东西hard code是不 ...
明显错误也好，高难度错误也好，只要改正了就是好事。 你又何必这么严酷？ :lol :lol “不应该”有轻重之分。我入职于一个新公司里，如果没有十足的把握，我不会轻易强调一件事。
hardcode一个端口在很多人看来是不应该的，但如果改写public static final int PORT = XXXXX;估计就没有太多人反对了。
事实上我要阻止的是包括这种定义。
public static final int DEFAULT_PORT = XXXX;
与
public static final int PORT = XXXX;
是有很本质的区别的。事实上我做的事比这个还多一步。当然，吹毛求庇的事就不说了。
原帖由 yuba 于 3-8-2010 16:44 发表 http://www.freeoz.org/ibbs/images/common/back.gif
什么态度？！你竟然把楼主根据多年产品开发和运维经验的基础上提出的预见，当做只是禁止了一个“明显”的错误行为？
我帮你改改：没有多年经验，根本不会意识到把类似端口这样属于环境变量的东西hard code是不 ... 其实你和我的见解区别很大。你可能以为，我要做的是用常量定义来代替直接写值。
事实上我要做的是从一开始就不主张这种假设，而不是某个写程序的方式。这就是你的意见和我的意见不同之处。
原帖由 yuba 于 3-8-2010 16:53 发表 http://www.freeoz.org/ibbs/images/common/back.gif
假设这个端口就是4321，不改
系统里一共出现xx次，就写xx个“4321”，根本不用什么预见，这本身就是不好的 原帖由 key 于 3-8-2010 16:58 发表 http://freeoz.org/ibbs/images/common/back.gif
事实上我做的事比这个还多一步。
我深信
但是你只是轻描淡写了一个hard code的故事，就期望我们也心有戚戚，太为难大家了 是我错了，我应该扬扬洒洒五万字，把前因后果写清楚。;P :lol
原帖由 yuba 于 3-8-2010 17:05 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我深信
但是你只是轻描淡写了一个hard code的故事，就期望我们也心有戚戚，太为难大家了 原帖由 key 于 3-8-2010 17:01 发表 http://freeoz.org/ibbs/images/common/back.gif
其实你和我的见解区别很大。你可能以为，我要做的是用常量定义来代替直接写值。
事实上我要做的是从一开始就不主张这种假设，而不是某个写程序的方式。这就是你的意见和我的意见不同之处。
常量先，大道不远矣；常量化是可定制的前提
从一个满是hard code的系统，优化成可配置的系统，常量化的工作量远大于定义和读取配置文件的工作量，不hard code的意义也正在于此
你从要求大家从一个不hard code的例子，联想到其他一系列尽在不言中的高标准要求，进化到了对什么是hard code的概念的扩大化
为了表示我也有预见性，我声明，我只从一楼，已经看到了一个软件开发理论与实际完美结合的典范
呵呵，又开了一个玩笑 原帖由 key 于 3-8-2010 17:07 发表 http://freeoz.org/ibbs/images/common/back.gifu
是我错了，我应该扬扬洒洒五万字，把前因后果写清楚。;P :lol
我没有这个意思。写5个字传达5个字的意思，写5w字传达5w字的意思
写了5个字，读者没有领会到5w字的深意，不要奇怪就好啦 原帖由 key 于 3-8-2010 16:58 发表 http://freeoz.org/ibbs/images/common/back.gif
public static final int DEFAULT_PORT = XXXX;
与
public static final int PORT = XXXX;
是有很本质的区别的。
说点儿具体的，你是用的配置文件吧？
如果是，配置文件里面是怎么定义端口的？DEFAULT_PORT还是PORT，还是both？ 我在看你们争论呢，
我一直都是hardcode，我写的东西不用发布，独此一家，我自己明白就好，给你的永远是个installer
都写那么清楚了，公司就敢开我了，现在我是权威，让key来都不行，绕死你:lol :lol :lol 记性真是不好，除了一个installer，还有一个除了我，神仙也不明白的reg
哈哈哈 这个要看运气。如果你算一下，把你的整套东西铲掉重来都花不了太多时间，你就没信心这样做了。
事实上我已经多次向多个老板证明，铲掉重来可能是最好的系统维护方法。
原帖由 准备买悉尼公寓 于 5-8-2010 23:32 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我在看你们争论呢，
我一直都是hardcode，我写的东西不用发布，独此一家，我自己明白就好，给你的永远是个installer
都写那么清楚了，公司就敢开我了，现在我是权威，让key来都不行，绕死你:lol :lol :lol 利用find, grep, ctags和一些refactor手段，基本上很难有整不明白的程序。
目前看得最让我头痛的一套代码是NetBeans Platform的源代码，
是一群程序高手故意写得不让人看来导致代码难以阅读的。
至于烂代码，最大的特点是流水帐，只要不怕恶心，一边做refactor，一边看，难度并不大。
原帖由 准备买悉尼公寓 于 5-8-2010 23:33 发表 http://www.freeoz.org/ibbs/images/common/back.gif
记性真是不好，除了一个installer，还有一个除了我，神仙也不明白的reg
哈哈哈 呵呵，咱做的不是纯软件的，代码只是其中一部分而已
你永远不会知道这行程序里面为什么要写个H0001，因为这个是往硬件的寄存器里面写的，如果你没有看过这个芯片的手册的话~~
整个铲掉重来，那不如继续雇着我，这个我有信心:lol :lol
因为硬件也是我干的，处理器都是我选的，SCH是我画的，PCB是我布的，为什么选这个，我不告诉老板:loveliness: 我还想说的是，我喜欢做产品，不断地做新东西，不断的卖产品，而不想自己跟进后期维护。
如果你把自己绑在一个产品上，你可以认为你把这个产品绑死了，但同时你也被这个产品绑死了。
我把自己做的软件产品尽量放给别人来用和维护，这样我就有足够的时间和空间来做自己的事。
到目前为止，自从产品beta version之后，我就基本上没有理过，都是同事在做。
我在搞其他东西，已经搞了有一个多月了吧。老大也不理我在搞什么。
我的目标是弄下一代系统，之后整个开发团队就可以退出产品线，完全交付其他组的人来维护和使用。
我不担心老板开我，除非他和钱过不去。
原帖由 准备买悉尼公寓 于 5-8-2010 23:32 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我在看你们争论呢，
我一直都是hardcode，我写的东西不用发布，独此一家，我自己明白就好，给你的永远是个installer
都写那么清楚了，公司就敢开我了，现在我是权威，让key来都不行，绕死你:lol :lol :lol 硬件有硬件的特点，或者这样做在硬件开发领域行得通。
原帖由 准备买悉尼公寓 于 5-8-2010 23:45 发表 http://www.freeoz.org/ibbs/images/common/back.gif
呵呵，咱做的不是纯软件的，代码只是其中一部分而已
你永远不会知道这行程序里面为什么要写个H0001，因为这个是往硬件的寄存器里面写的，如果你没有看过这个芯片的手册的话~~
整个铲掉重来，那不如继续雇着我， ... 我还想说的是，我喜欢在家呆着，不断的玩老婆，不断的打孩子，而不想开车去公司上班。;P
如果我不把自己绑在一个产品上，我可以认为我还能干别的，但同时我干的不踏实。
我自己做的软件和硬件产品都由我自己维护，同样我就有更大的时间和空间来做自己的事。
到目前为止，自从产品发布了之后，经过大约20次升级，我基本上每次只要干一天，就能混上一个月。
我不想搞其他东西，已经有5年多了。老板也不理我在干什么。
我的目标是天天在家睡觉，之后还正常拿钱，完全不操心工作的事情。
我不担心老板开我，除非他和钱过不去。
上一个类似产品寿命40多年了，还在用，我这个，至少也得30年吧:lol :lol :lol :lol 睡了，明儿再玩~:Q :Q 这也是一种生活方式，在乎自己怎样选择。
我很多年前也曾想过类似的问题。当时几乎所有的同事大致上就这样干活，这样过日子，
最关键的地方，老板很欣赏他们。相对地，老板见到我基本上都觉得恶心，因为老板提出来的东西，
我几乎90%以上说“不对”。所以我的日子过得极不得意。
有一年，老板疯了，因为他可能因为产品问题要面临投资失败，
就把我拖出来赌一把。我拉了一队人做了两个月，之后的半年里，产品成功的卖出，把全公司的亏损
全部赚回来，然后以几倍的收益大赚特赚。到底赚了多少，我不关心，总之之后整整两年内公司的销售都很开心。
不过不到一年，老板又开始看着我觉得恶心，因为我成天无所事事，N套产品在外面跑，我都不需要理会，
而我提出的产品计划老板又没兴趣，我提出用类似的方式整改全公司的产品，他也没兴趣。
最后我的团队队员一个个的走了，我也走了。直到现在，这个产品还继续帮他赚钱，不知道他还记不记得我。
或者你会说，产品在继续赚钱就没事啦。但赚一百万是赚，赚一千万也是赚，一个能赚一千万的产品最后只有
一百万的收益就是失败。
现在，我在这里，我又是同样的方式做事。有一天我和主要的投资股东开玩笑说，我们这个产品，说不定
会全世界到处卖，数以百计、千计地卖license，他说，有可能吗？别开玩笑了。很快他就知道这是不是一个玩笑了。
原帖由 准备买悉尼公寓 于 6-8-2010 00:07 发表 http://www.freeoz.org/ibbs/images/common/back.gif
我还想说的是，我喜欢在家呆着，不断的玩老婆，不断的打孩子，而不想开车去公司上班。;P
如果我不把自己绑在一个产品上，我可以认为我还能干别的，但同时我干的不踏实。
我自己做的软件和硬件产品都由我自己维护， ...