把什么放入架构设计

25 条评论

• 「代码必须开源」多余么…… 开源跟不开源完全两个写法吧，不开源我可以用很多脏手段，想想怎么合理的背一些技术债务，省掉跟我的用例没关系的工作。

• 多余，必然会做的事情不必写进架构。就像一天要吃三顿饭，没人天天提醒自己这么做，并且有的时候忙忘了吃两顿也影响不大。
• 泰坦回复小清新09-16

  感觉不一样，不开源意味着可以用公司内部的、不开源的库，工具链等东西，但如果开源，依赖的第三方库要考虑内部外部。另外开不开源，开源选择的license也会影响到本软件可用的第三方库种类

• 赞同柱哥关于高层设计和原始需求作为底层设计依据的逻辑链和理由。
  但是，具体到关于你们讨论的那个“开源”的要求，我觉着还是得明确吧。我的理由是～开源这个需求，第一，涉及到的代码开放；第二，涉及到设计相应的开源的协议规则。这些如果仅仅承载在原始的需求，并不利于底层的设计分解。

• 我觉得两种思路的分歧主要在于，下层设计考虑约束时，是只需要考虑上层设计列好的约束，还是要同时考虑上层约束以及原始约束。
  如果下层设计要考虑原始约束，就得跟上层设计一样再从原始需求里分析一遍，做了重复的事情。
  如果高层设计只是部分的约束，那"每层设备应该把本层增加的约束和之前的约束的无损转化全部交给下一层"这逻辑就不是必要的。
• 分歧在于，下层设计是上层设计生成的，还是说把下层设计看成独立的设计，只是需要满足上层设计的约束。

• 分层结构下，如果上层不全部cover约束条件的话，下层在只对它上一层负责的情况下，会不会漏掉一些东西，到实际开发代码的时候发现还有没考虑到的地方
• 上层就是要漏掉一些东西的，这样下层才好填空[大笑]

• 知乎用户09-16

  就具体案例，主要是看开源这个约束是否较大影响未来架构的演化。如果开源是为了让其它厂商加入并增强生态，那这个约束就应该是重要的顶层设计。如果开源并不主要为了生态，那么就可以不放架构设计。

• 「已注销」 (作者) 09-16

  ChangeLog：补充关于“开源”这个具象的信息，回答前面很多人想讨论的问题。

• 补充后重新看了一下，发现自己没有完全带入作者的情景，因为自己这边「是不是要开源」还在讨论，不算是「必然会做的事情」……

• 以及「讨论区不少人关心这个问题的具象，而不是我讨论的抽象」确实是这样……

• 知乎用户09-20

  每篇文章必看， 另外请问怎么能成为一个做这种工作的程序员？我一直在写后端，对软件工程很感兴趣，也一直在思考。 我在头条和挺大的外企都待过，但没见过有你这种职位，去思考，讨论这些问题。 观察我的leader leader的leader也都只是在做需求，需求评审也是看看手头能做什么，怎么做到。 根本没有方法论，连基础的抽象能力都没有
• 「已注销」 (作者) 回复知乎用户09-20

  我理解大型软件开发都需要这样的岗位吧。

• 知乎用户09-28

  看的有点晕。

  每层抽象当然有自己的约束，有些是被上层约束的，有些是专门为了约束下层的，还有些和其他层无关，只服务自己的，但是这些都是为了解决这一层面向的问题。

  所以重点是开源是服务于哪一层的，其他层如果不知道这个约束是否也能完整工作。

• 李奇10-08

  啥情况? 发一个gitee链接？怎么找?
• yszg回复李奇10-08

  请问下gitte是什么的呀[捂脸]还能像知乎一样看到答主的文章吗
• 李奇回复yszg10-09

  一个git仓库，版本管理，写作很友好。读者阅读起来也方便，看了一下，应该还可以评论，讨论，挺好。

• 请问迁移的新地址是多少啊？

• 知乎用户11-07

  Kenneth-Lee-2012

• 李江12-09

  这篇文章找不到了能否分享一个链接