我没有任何正式的计算机科学资格,而是在网络繁荣的时代我自学了经典的ASP,并设法让自己找到了工作,我的职业生涯从那里发展起来.我很自信,而且我认为,ASP 3中的程序员非常好,但正如其他人所观察到的那样,经典ASP的一个问题是它在隐藏http的细节方面做得非常好,所以你可以成为一个非常有能力的人程序员基于对您正在使用的技术的相对较差的理解.
当我最初改为.NET时,我把它视为经典ASP,将独立应用程序作为单独的网站开发只是因为我当时不知道更好.我在这一点上移动了工作,并在接下来的几年中在一个站点上工作,该站点的架构严重依赖于自定义对象:换句话说,我获得了很多使用.NET作为使用相当旧的中间层开发工具的经验 - 按照经常用于教授OO的经典"汽车"类示例的方式设计OO设计方法.将程序分解为功能块,并以此为基础构建类和方法.虽然我们使用敏捷方法来管理工作,但整个设置是经典的客户端/服务器.这适合我和我逐渐掌握.NET并开始以更应用的方式使用它,我开始看到技术中固有的功能以及它为什么比旧的ASP 3好得多.
在我最近的工作中,我发现自己突然陷入了两个相当年轻,技术娴熟,前卫的程序员的深处.他们已经建立了一个网站架构,它根据很多我不熟悉的东西进行建模,实际上我在理解方面遇到了很多麻烦.该应用程序构建在具有多租户的云计算模型上,并且该架构使用大量接口,工厂等进行松散耦合.他们也使用nHibernate.我加入后不久,这两个人离开了,我现在应该是一个系统的高级开发人员,他的技术和架构我真的不懂,而且我也没有人提问.
除了你,互联网.
坦率地说,我觉得自己已经被深深地投入了,我正在下沉.我不确定这是不是因为我缺乏理解这些东西的教育背景,如果我对现代计算不够数学(我的数学从来都不是很好 - 我的设计方法通常是简单调试,直到它工作,然后重构,直到它看起来整洁),或者我是否只是被简单地呈现出过于激进的性质.但找出它的唯一方法就是尝试学习它.
那么有人可以提出一些好的开始吗？好书,教程或博客？我发现很多互联网资料只是假设我没有的理解水平.
非常感谢您的建议.帮助一个中年人,陷入泥浆开发者再次获得热情!
请!
坐在沙滩上 - 准备
列出你不理解的一切.在最后阶段,此列表应为您的清单.清除你的想法 - 让自己重新开始,"忘记"你已经了解的有关你的架构的所有令人困惑的细节.挖掘原始建筑师创建的每个文档.获取项目中使用的每种技术的文档.做咖啡.
浮动 - 管理复杂性
要浮动,您需要管理复杂性.如果你没有正确处理复杂性,那么当你完全没有需要的时候,你会深入细节,而你却不知道如何以及在何处停下来,沉入水底并淹死.
"我的设计方法通常只是调试直到它工作,然后重构,直到它看起来整洁"
我想我曾经和你一样.我从头开始开发解决方案,一次添加一个解决方案,最终在我的头脑中包含一个复杂的结构.我没有计划架构,我没有单独的设计和实现,我只是编码,调试,重构.它的工作原理是:由于复杂性增长缓慢,我可以毫不费力地理解出现的架构.
当"继承"其他人计划的复杂架构时,这种方法还不够好; 你不能一次吞下整个结构 - 因为有太多的细节,你不能随意吞下一点点 - 因为你不会理解它们彼此之间的关系,你永远不会看到全局.
软件是复杂性管理的难题.有很大的部分,有时也被称为"子系统",它构成了大局.它们中的每一个都由较小的部件组成,而较小的部件又由较小的部件组成.当你看代码时,你看到的只是最微小的部分.所以暂时忘记代码本身,至少在你看到所有更大的部分之前.
游泳 - 绘制建筑
迈向浮动的第一步是看大件.要做到这一点,你需要地图.最大的部分地图是最高级别的架构.如果原建筑师没有留下这样的地图,你必须自己创建它.就像无法从山谷内部映射区域一样,您无法从低级细节映射您的架构.你需要站在山顶,才能看到所有山谷,山丘和小径的360度全景.您需要从顶部映射您的架构.
拥有此顶级地图后,您应该获得构成它的零件的地图 - 就像您创建整个区域的非详细地图一样,然后创建单独的子区域详细地图.地图应该描述不同的子系统.至少,它应该描述每个子系统的职责,它的外部接口,以及它与其他子系统的交互方式.
潜水 - 管理细节
潜水中有这样的原则,即由于压力的变化,你不应该在深度之间移动太快.这个原则成立了.当您从处理一个子系统转向处理其内部子系统时,请确保您只是进入下一级别的复杂性/抽象.让你的头脑一次处理一层.
单独的概念,模式,接口和实现.nHibernate是一种对象关系映射(ORM)解决方案.因此,在处理nHibernate本身的细节之前,您需要确保了解ORM的一般概念及其在世界中的位置.工厂是一种设计模式,因此在您处理工厂之前,您应该了解什么是设计模式以及它们的作用.
技术的兴衰,但概念仍然存在.一旦你了解了概念,在架构层面上,这些概念是如何表现的并不重要.
您的体系结构松散耦合这一事实实际上是一件好事,因为这意味着您可以理解一个子系统的角色,而无需了解其他子系统.您的架构使用接口这一事实也很好 - 这意味着您可以了解元素如何相互交互,而无需了解它们如何在内部工作.
滑水 - 获取蒸馏知识
我认为有一本书是"必读的":史蒂夫麦康奈尔编写的代码.它改变了我的职业生涯.
我希望这篇文章能够以某种方式帮助你,而不是完全浪费你的时间.
以下是一些建议,绝不是一个完整的操作方法或一体化答案;
在你的工作日里腾出时间来了解新的东西.在您的工作日中度过这段时间,因为这是您工作的一部分.这不是你应该只在晚上或周末做的事情.如果你想花一些时间学习它,那么就去吧,但不要忘记学习是你工作的一部分,不要忘记你必须隐藏你在家里的无知或那个不知道一切对你的职业生涯是致命的.由您来平衡学习时间和工作时间.
拿一些大纸和一盒彩色铅笔(如果你愿意,可以选择MS Visio).开始绘制两种类型的图表:
除了答案中已列出的许多优秀资源以及可能要列出的资源之外,还有一些不同的建议 - 使用StackOverflow.
你似乎能够写出非常深思熟虑,可读性和敢于说出好的问题.
因此,只要某个特定的架构选择/模式或一段代码没有任何意义,请随意将其转换为SO问题(显然最好在自己重新研究之后).
另外,关于你的观点:数学:
就软件工程而言,大多数时候你真正需要的唯一数学是:
"离散数学" - 集,图,树等......以及它们对数据结构和算法的实际应用
有限的代数技能集涉及分析后者的O(n)复杂性
理想情况下,直观地掌握统计数据/概率 - 作为一名通用软件工程师,您并不总是必须能够进行高级计算,但感觉"这更可能会影响我的情况,因为它可能会发生时间影响大小"通常是设计选择的良好指导.
然而,有一件事对于一个优秀的软件工程师来说是非常宝贵的,这通常是"擅长数学"的人与"不擅长数学"的区别 - 虽然严格来说并不是数学相关的 - 是看模式的能力.
如果你"不擅长数学"的原因是你缺乏这种模式遵守能力,那么你将处于极大的劣势.这是一种技能/能力,你必须训练自己高于所有其他人才能在建筑系统中取得成功,恕我直言.