作者dream1124 (全新开始)
看板Soft_Job
标题Re: [请益] 新创刚起步的一些开发疑问
时间Thu Apr 26 03:33:57 2018
※ 引述《wandallin (万大林)》之铭言：
虽然你同事提的是有利後续长期维护程式码的事务和规则，
但是从大局来看... 你们才刚上线还要再补功能，同时商业模式又还不确定....
也就是说现有运作模式再大修的机会不小，
因此 1,3,4,5,6,7 点有可能做了以後没多久就变无意义...是否值得令人疑惑。
再从实务来看，你们用的是实现逻辑的速度快，但 bug 相对复杂难追踪的 js，
这种情况下若没有新的功能需求，那程式架构没严重问题就不该去动，
免得改完架构是好懂好维护了，却有地方不小心改坏掉，越改越不稳定....
这样你跟老板都会不好向负责的对象交待。
再加上你们没有人会写测试，每次改完都要一一手动检验成果，很难快速与完整，
这使你们相对不容易检查出前面那些问题，专案因此曝露在失控的风险中。
最起码等到有人先引进测试的做法，系统运作逻辑也稳定下来後才适合去落实其他原则。
整体而言，目前的状况你觉得烦...我觉得合情合理，没什麽问题啊~
是我的话也会叫他们先指出那些想重构的地方并记在 issue tracker 上，
待时机成熟时再来搞这些东西~
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.169.230.235
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1524684839.A.874.html
※ 编辑: dream1124 (118.169.230.235), 04/26/2018 03:45:03
1F：推 expup: 我想说的都被你说了 04/26 04:17
2F：→ deray: 超级劣币 04/26 08:30
3F：推 Masakiad: 「1,3,4,5,6,7 点有可能做了以後没多久就变无意义」我 04/26 08:44
4F：→ Masakiad: 反对这样的看法，依照我待过新创的经验是；现在不弄照 04/26 08:44
5F：→ Masakiad: 正常发展速度一子dirty code就照成一堆模组依赖了。只要 04/26 08:44
6F：→ Masakiad: 疯狂的加入新功能，又不早早写测试，就算压着不做那些 04/26 08:44
7F：→ Masakiad: 事，系统也不会多稳，既然如此不如趁有心早点做好上述 04/26 08:44
8F：→ Masakiad: 那几点。 04/26 08:44
9F：推 vi000246: 同一楼上 一开始架构弄好 以後赶专案能欠的技术债coda 04/26 08:50
10F：→ vi000246: 也会比较多 04/26 08:51
11F：→ jackblack: 现在不做以後真的会做吗 04/26 09:01
12F：推 WangDaMing: 建议你心态改变下 04/26 09:49
回楼上几位
其实我不否定开始开发前的架构很重要，我也讨厌公司不解决很可怕的程式码。
我自己就曾经在前公司系统转换架构时，在规划时期卡了公司两周来规划与实现好维护的架构。
只是我认为他们现在商业模式不确定，老板也还在找顾客，
实在不是大改架构使系统稳定度冒上一定风险的好时机，
最起码也等客户有着落了，确定这是对方要的东西再以此现状为基础重构。
另外，前面提的想法只是大方向反对「单纯为了重构」而去大改程式，
以及要先准备好自动化测试办法之後再重构，总而言之不是坚决反对一切重构行为。
事实上最後提到先监定出要重构的部分就是为了让团队可以未来新增功能时，
若发现会调整到重构目标就可以一并修正。
另外…若近期比较有空，而且怕以後忙到没空改的话，那也可以先在其他分支
微调较不影响大局的地方，然後再伺机套用
13F：推 jack0204: 很多人被赶的时程压到超紧绷，这样的确没时间做就放弃 04/26 09:51
14F：→ jack0204: 写测试，但照经验来看紧绷不会是一时的，所以未来没机会 04/26 09:51
15F：→ jack0204: 去改，就整个放弃测试了 04/26 09:52
16F：→ t64141: 有两句很经典的话，先求有再求好，以及东西没坏就不要改才 04/26 09:54
17F：→ t64141: 不会改坏，第一句出现在前期，第二句用在後期，结果造就了 04/26 09:54
18F：→ t64141: 很多负债累累的系统 04/26 09:54
19F：→ Masakiad: 还有一句话「程式写的不好又怎麽会写的快」 04/26 10:16
20F：→ Masakiad: 但我想能真正经历的才懂吧 04/26 10:17
※ 编辑: dream1124 (118.169.230.235), 04/26/2018 12:01:32
21F：推 lovdkkkk: 1. 可做, 反正不太花时间, 只是也没什麽立即明显的功效 04/26 13:46
22F：→ lovdkkkk: 3. 可以先都不管, 以後想修再修 04/26 13:46
23F：→ lovdkkkk: 4. 必需做, 但是范围要挑过, 程度也要有节制, 04/26 13:47
24F：→ lovdkkkk: 记 tracker 後再加个步骤 - 讨论要不要做, 排时程 04/26 13:47
25F：→ lovdkkkk: 不能全放生往後延 04/26 13:47
26F：→ lovdkkkk: 5. 同 3, 可以规范新的怎麽写, 旧的全改就再说 04/26 13:47
27F：→ lovdkkkk: 6. 可以考虑排专人负责看 tracker 补 test case, 04/26 13:48
28F：→ lovdkkkk: 顺 开发-建置-测试-发布 的流程 初期不一定要全员参与 04/26 13:48
29F：→ lovdkkkk: 7. 用个工具做就好, 没有白费不白费的问题 @@ 04/26 13:49
30F：推 senjor: 其实这是白箱的剧情，多写测试多做重构就可以一起做的很快 04/27 10:43
31F：→ senjor: 但是要能够多写测试多做重构的前提就是要你写的够快。 04/27 10:44
32F：→ viper9709: 推这篇 04/27 23:11
33F：推 CCben: 推! 新创还没开始赚钱就要做重构?! 你同事平常接票不多吧 04/30 00:13