我想我已经非常擅长编程的基础知识(适用于各种语言).我可以写一个*好的**代码行.我可以写一个好方法.我可以写一堂好课.我可以写一组很好的课程.我可以写出好的小型或中型应用程序.
但是,我不知道如何构建一个好的大型应用程序.特别是在涉及多种技术并且更多可能与时间有关的情况下.假设一个带有大型Web前端的项目,一个连接到其他集成后端的大型服务器后端,最后是一个庞大而复杂的数据库.哦,我参与了其中的一些应用程序,我可以构建一个我确定的.然而,我不太确定它是否有资格作为"好".
因此,我的问题是参考书籍或其他良好的阅读来源,在那里我可以学习如何为一般大型项目分发和组织代码和数据.例如,我是想要非常严格地对事物进行分层,还是要将其封装为独立单元.我是否想要尝试将大部分逻辑保留在同一个池中,或者它应该只是分布,因为在添加我添加的任何功能时它似乎最合乎逻辑.
我已经看到很多关于这些问题的一般原则(例如没有意大利面条代码,肉丸代码......),并阅读了一些讨论此事的优秀文章,但我从来没有遇到过能引导我具体实践知识的来源.我意识到问题的难点,所以我很高兴听到其他人发现的帮助他们寻求这些知识的读物.
一如既往,感谢您的回复.
****鉴于"好"代码定义的辩论性质,在这种情况下,术语"好"将不会被定义(它意味着你认为它应该是什么意思).
j_random_hac.. 28
作为程序员,我们喜欢相信自己是聪明人,所以很难承认某些东西太大而且太复杂,甚至不能同时考虑所有问题.但对于一个大型软件项目来说,这是真的,你越早认识到你有限的大脑容量并开始想出简化问题的方法,你就会越好.
另一个要实现的主要事情是,您将花费大部分时间来更改现有代码.构建初始代码库只是蜜月期 - 你需要设计你的代码时考虑到这个想法,6个月之后你会坐在它前面尝试解决一些问题而不知道这个特定模块是如何工作的,甚至虽然你自己写了.
所以,我们能做些什么？
最小化代码中不相关部分之间的耦合.代码将随着时间的推移以您无法预料的方式发生变化 - 与不熟悉的产品,需求变化相结合会出现显示问题 - 这些问题将导致波动的变化.如果已建立稳定的接口并对其进行编码,则可以在实现中进行所需的任何更改,而不会影响使用该接口的代码.您需要花费时间和精力开发经得起时间考验的接口 - 如果接口也需要改变,那么您将回到正方形.
建立可用于回归测试的自动化测试.是的,预先做了很多工作.但是,如果您能够进行更改,运行测试并确定它仍然可以正常运行,而且没有那种担心如果您对源代码控制进行最新更改,一切都会失败的感觉,它将会得到回报.
摆脱棘手的东西. 我偶尔会看到一些聪明的C++模板技巧并想一想,"哇!这就是我的代码所需要的!" 但事实是,代码变得易读和容易理解的减少往往不值得增加通用性.如果你像我这样,其自然倾向是试图解决一般的方式尽可能的每一个问题,你需要学会克制它,直到你真正跨越来需要对于通用的解决方案.如果出现这种需要,你可能不得不重写一些代码 - 这没什么大不了的.
作为程序员,我们喜欢相信自己是聪明人,所以很难承认某些东西太大而且太复杂,甚至不能同时考虑所有问题.但对于一个大型软件项目来说,这是真的,你越早认识到你有限的大脑容量并开始想出简化问题的方法,你就会越好.
另一个要实现的主要事情是,您将花费大部分时间来更改现有代码.构建初始代码库只是蜜月期 - 你需要设计你的代码时考虑到这个想法,6个月之后你会坐在它前面尝试解决一些问题而不知道这个特定模块是如何工作的,甚至虽然你自己写了.
所以,我们能做些什么？
最小化代码中不相关部分之间的耦合.代码将随着时间的推移以您无法预料的方式发生变化 - 与不熟悉的产品,需求变化相结合会出现显示问题 - 这些问题将导致波动的变化.如果已建立稳定的接口并对其进行编码,则可以在实现中进行所需的任何更改,而不会影响使用该接口的代码.您需要花费时间和精力开发经得起时间考验的接口 - 如果接口也需要改变,那么您将回到正方形.
建立可用于回归测试的自动化测试.是的,预先做了很多工作.但是,如果您能够进行更改,运行测试并确定它仍然可以正常运行,而且没有那种担心如果您对源代码控制进行最新更改,一切都会失败的感觉,它将会得到回报.
摆脱棘手的东西. 我偶尔会看到一些聪明的C++模板技巧并想一想,"哇!这就是我的代码所需要的!" 但事实是,代码变得易读和容易理解的减少往往不值得增加通用性.如果你像我这样,其自然倾向是试图解决一般的方式尽可能的每一个问题,你需要学会克制它,直到你真正跨越来需要对于通用的解决方案.如果出现这种需要,你可能不得不重写一些代码 - 这没什么大不了的.
借用tvanfosson:
从一个小应用程序开始,每当有人想要添加新功能时说"是".
这是我们用来指导编码标准和方法的书:
大规模C++软件设计
自从它首次在众所周知的卫生巾背面绘制以来,我正在开发的程序已经开发了近10年.而且这个项目今天仍然很强劲.它还不完美,并且仍然存在循环依赖的问题,并且一些类接口不是很干净,但是大多数类都不是这样,程序有效并且我们的用户很高兴.
正如许多其他人之前所做的那样,我还建议由Steve McConnell执行代码完成和软件评估.我特别喜欢他用"增长"软件而不是构建或构建软件的比喻.这种查看软件的方式更适合于具有较长生命周期的东西.
正如我在其他地方提到的,大型应用程序不仅更大,它们也不同.这么多,我们谈论的是小型和大型的编程.当您进行大规模编程时,问题的性质及其解决方案会发生重大的质的转变.这条线非常模糊,有许多具体问题可能会迫使你越过那条线.
其中一些问题包括:
大小(例如一个根本不适合单个硬盘的数据库)
复杂性(从一体化应用程序到多个子系统)
并发性(从0到数千/数百万的并发用户)
可用性(从9%的正常运行时间到99.999%的正常运行时间)
可靠性(从每日故障到MTBF几年)
速度(响应时间从小时到毫秒)
产品化(从您的宠物项目到可销售的商品)
等等
怎么处理这一切？学习并使用所有有价值的技术,并学习评估哪些是有价值的 - 这需要一段时间,而且没有快速的答案.
然而,有一种技术容易,明显,并且适合所有人:分而治之.隔离每个主要功能,每个子系统,每个外部依赖,以便您的主系统仅在其外边缘接触它们.当你可以通过在很短的时间内调整一个瘦接口来改变每一个,那么你已经完成了一些事情.这将带你走很长的路.
最好的祝愿.
京公网安备 11010802040832号 | 京ICP备19059560号-6 