❶ asp.net 编程有哪些重要的技术要点
高内聚低耦合，代码优化清晰。面向对象的掌握其含义。多态，封装，继承
❷ 与新手分享为什么要学习.NET
为什么微软设计和发布 .NET? 相信大多数人都会认为微软推出 .NET 是为了与 java 正面竞争，不可否认这是原因之一，但是如果你回顾 Windows 下微软技术的发展历史，你就会发现，几经岁月的微软技术已经显得越来越壅肿 , 无论在易用性、开发效率和安全性上都积累了诸多诟病，很多技术都是在需求的驱动下诞生的，都缺乏整体规划，微软迫切地需要对其所有的技术进行一次重构，现在就让我们一起回顾一下微软技术的发展历史，来认识 .NET 技术诞生的必要性：
在 .NET 之前， Windows 平台下的编程技术主要是 Win32 SDK, ASP,COM, DCOM, ADO 等技术，这些技术在后来也有了一个统一的名字叫 Windows DNA ，和 .NET 是一系列技术的集合一样， Windows DNA 是这些一系列技术的统称，为了加快软件开发，微软为 C++ 程序员提供了 VC/MFC 开发工具，为 Basic 程序员 提供了 VB 等，由于语言本身存在的先天差异 ( 例如数据类型不相同，内存管理也不同等等 ) ，微软没有办法做到 VB 和 VC 程序引用同一套类库，所以微软为每一种语言都提供其单独的 Runtime 类库、单独的数据库类，不同的 GUI 构建方式等。由于类库的大部分功能都基本相同，因此，为不同的语言设计和维护不同的类库是一件很没有效率的事情。（后注： .NET 是所有 的 .NET 语言都引用同一套 .NET Framework ）
值得一提的是， Borland 公司的 C++ Builder 与 Delphi 共同使用的是同一套类库，这个类库就是 VCL ，为什么 Borland 做到两个不同的语言引用同一套类库呢？ 因为 Borland 拥有 Pascal, Borland 通过修改编译器来修改 Pascal 语言使得它在数据类型和内存管理方面与 C++ 相拟，使得用这两种语言编译出来的程序能二进制兼容。虽然微软拥有 Basic, 但是 Basic 的先天优势是易学易用，微软无意去修改 Basic 使得 Basic 变得复杂。
微软使用 COM 来解决语言间的组件重用问题，并提出组件编程模型的概念， COM 的基本原理是通过定义一些编程契约，使得按照这些契约编写出来的组件 ( 以 dll/exe 的形式存在 ) 可以跨语言和跨平台地进行重用。
在 COM 推出之前，微软和 Borland 在开发工具的战场上斗得你死我活，而微软凭靠着 OLE 技术赢得了重要的一役胜利，微软在 OLE 的基础上创造了 COM 技术，并大幅地使用 COM 技术来构建 Windows 下的软件组件，其中， ADO 就是一个常用 COM 组件，不同的编程语言都可以调用 ADO 来访问和操 作数据库，因此， ASP 程序员会惊呀地发现，他用 ADO 编写的访问数据库的代码看起来与 VC 程序员访问数据库的代码是如此的相拟。
通过对微软技术历史的分析，可以发现 COM 的产生是一个偶然，当时微软为了对搞 Apple 的文件技术，从而推出 OLE(Object Linking and Embedding ，对象连接与嵌入 ) ， OLE 的目的是让文件可以即时编辑，例如 Word 文档可以嵌到 Excel 中编辑， Excel 表格也可以嵌到 Word 中编辑， OLE 的成功使得微软察觉到跨语言组件重用的重要性，于是微软从 OLE 中抽取出一些重要的特性，并实现了 COM ，然后再用 COM 重写了 OLE 组件，所以可以说， COM 是在缺乏整体规划的情况下设计出来的，加上 OLE 庞大和复杂（当年 Borland 与微软的开发工具大战， Borland 在 OLE 上面吃了大亏），再加上随着需求的不断增加和修补， COM 并不易用，但这并不防止 COM 组件的成功，在 .NET 之前， COM 已经成为 Windows 下重要的组件编程技术，很多重要的组件 ( 如 ADO, ActiveX 组件 ) 等都是基于 COM 技术开发的，当时业界较流行的做法是 VC 程序员编写 COM 组件，然后由 VB 程序员或 ASP 程序员来将 COM 组件组装成提供给最终用户的软件产品， .NET 之前， COM 就是这样很好地解决了多种语言之间的组件重用问题。
以 Win32 SDK, COM 技术基础组成的 Windows DNA 技术经历了整个 90 年代的发展，期间根据市场需求不断的修修补补，已经非常壅肿，且积累了诸多诟病，某些技术过于复杂，开发效率低等，这些问题都成为了设计 .NET 的背景，下面我试图罗列出一些主要需要改进的地方 ( 列个大概，肯定不全，希望大家帮忙补充 ) ：
1) COM 并不支持面向对象的诸多特性，例如不支持接口、继承等，在面向对象流行的今天已显得非常落后，目前大部分的生产力工具都是以面向对象为基础的（例如 UML 建模工具）。
2) 编写 COM 组件对于新手来说比较复杂，必须要遵守一些较为繁琐的规则，安装和部署需要修改注册表，不便于测试和部署。
3) COM 组件基于 exe/dll 的形式存在，而 dll 是 Windows 下重要的组件存在形式，但是 dll 也成了 Windows 下软件不稳定的罪魁祸首，原因 是大部分主要的 dll 都存放在一个统一的目录： Windows/System32 ，当安装一个新软件或者升级软件到新版本时，新的 dll 会覆盖旧的 dll 文件，从而可能会导致现有的软件无法工作或者不稳定，这是大名鼎 鼎 的Dll Hell (Dll 地狱 ).
4) COM 组件虽然可以跨语言进行调用，但是没有办法进行跨语言调试，例如在 VB 中调用 VC 编写的 COM 组件时，这个组件不能在 VB 中调试，造成软件调试困难。
5) 安全性方面，软件没有办法知道自已所引用的组件是否已被非法修改，安全控制也只停留在用户级别的控制上，没有办法做到代码级别上的安全控制，例如没有办法做到限制某个组件只能读取文件内容，但不能将内容写入文件。
随着信息化的需求不断演进，以及 JAVA 的流行，以及云计算等一些概念的提出，微软迫切需要修改自身的技术来适合市场的需求，显然，微软有两种解决方案：
1) 继续对 Windows DNA 的相关技术进行修修补补，在上面增加新功能，改进并修复错误。
2) 重新规划一套新技术，解决现有技术存在的问题。
微软选择了第 2 种方案，即重新规划一套新技术，在微软内部，新技术作为 COM 的更新版本被命名为 COM 2.0 （来源于 <<.NET 本质论 >> 一书），后来才改名为 CLR, 和 Windows DNA 以 COM 技术为基础一样， .NET 以 CLR为基础 ，而 CLR 显然可以看作是经过重构的、新版本的 COM ，只是新版本的 COM 比它的旧版本增强太大从而使 得它应该换个名字。微软用 .NET 这个名字来代替 Windows DNA ，来表示一系列新技术的统称 ( 其实就是一个商标 ) ，至于为什么使用 .NET 这个名字， NET 是网络的意思，微软使用 .NET 这个名字是预见未来将是网络应用、分布式计算的天下，而微软，已经做好了准备。
.NET 设计的首要目标，就是要解决旧技术中的诸多问题，针对上面对旧技术需要改进的一些问题，我们再回头来看看 .NET 是如何改进这些问题的：
1) 引入中间语言技术，程序在编译后产出中间语言而不是机器码，在中间语言这一层直接支持面向对象技术，并定义常用数据类型，最大限度地缩短不同编程语言之间 的差异，使得不同编程语言编写的代码可以无缝集成起来，例如 VB 编写的类可以在 C# 中继承、创建实例等等，这在以前是无法想象的。
2) 引用程序集的概念来解决 dll 地狱问题，安装新程序集不需要修改注册表，部署简单，不同的程序集版本可以同时存在，有趣的是，这个特性使得微软在推 出 .NET 新版本时，不用头痛去考虑旧 .NET 程序的兼容 (.NET 程序员也因为这个原因而对微软抱有不满 ) ，因为 .NET 的新旧类库可以相互共存，因此你的程序可以引用旧版本的 .NET 类库中的一部分，同时还可以引用新版 本 .NET 类库的另一部分，当然，这样的话，最终用户需要同时安装两个版本的 .NET Framework 。
3) 引入 Click One 技术使软件的安装和更新更简便 。
4) 支持代码级的安全控制。
5) 中间语言技术使得跨平台成为可能，目前 MONE 项目已使得 .NET 程序可以运行在 Linux 下，甚至 iPhone 手机上。
总之， .NET 技术是微软技术一次全面的重构，所以要在 Windows 下进行程序开发，学习 .NET 是大势所趋，虽然旧的技术 (COM/MFC 等 ) 还将存活一段时间，但微软保留这些技术更多是为了兼容旧的程序， Windows 下要使用新的技术和新的功能，首选还是 .NET
❸ 学好.net web开发必须要掌握哪些技术
一楼说的太范泛了，具体说，语言上要掌握C#，SQL，javascript,网页制作上，要掌握html,css,silverlight,美工上要掌握photoshop,flash在.net上要掌握的东西就多了，如三层架构与工厂模式，缓存与依赖，全球化与本地化，委托与事件等诸多.net编程技术内涵，还有如页面优化，性能优化等开发者进阶技术等等。
❹ 如何提高.net的编程能力
呵你可以多上CSND 或者说CNBLOGS多看看别人写的代码啊!还有平时有空自个也要多做点项目啊!实践其实还是最重的!在做的过程中发现问题解决问题!嘿我也是学NET的!有空可以到我的网络空间多看看的!里面有写的很多平时遇到的问题还有功能的实现的
❺ 怎样才能提高编程技术
1. 扎实的基础。数据结构、离散数学、编译原理，这些是所有计算机科学的基础，如果不掌握他们，很难写出高水平的程序。学计算机专业的人比学其他专业的人更能写出高质量的软件。程序人人都会写，但当发现写到一定程度很难再提高的时候，就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学OOP，即使再精通OOP，遇到一些基本算法的时候可能也会束手无策。
2. 丰富的想象力。不要拘泥于固定的思维方式，遇到问题的时候要多想几种解决问题的方案，试试别人从没想过的方法。丰富的想象力是建立在丰富的知识的基础上，除计算机以外，多涉猎其他的学科，比如天文、物理、数学等等。另外，多看科幻电影也是一个很好的途径。
3. 最简单的是最好的。这也许是所有科学都遵循的一条准则，如此复杂的质能互换原理在爱因斯坦眼里不过是一个简单得不能再简单的公式：E=mc2。简单的方法更容易被人理解，更容易实现，也更容易维护。遇到问题时要优先考虑最简单的方案，只有简单方案不能满足要求时再考虑复杂的方案。
4. 不钻牛角尖。当你遇到障碍的时候，不妨暂时远离电脑，看看窗外的风景，听听轻音乐，和朋友聊聊天。当遇到难题的时候会去玩游戏，而且是那种极暴力的打斗类游戏，当负责游戏的那部分大脑细胞极度亢奋的时候，负责编程的那部分大脑细胞就得到了充分的休息。当重新开始工作的时候，会发现那些难题现在竟然可以迎刃而解。
5. 对答案的渴求。人类自然科学的发展史就是一个渴求得到答案的过程，即使只能知道答案的一小部分也值得我们去付出。只要坚定信念，一定要找到问题的答案，才会付出精力去探索，即使最后没有得到答案，在过程中你也会学到很多东西。
6. 多与别人交流。三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸出灵感的火花。多上上网，看看别人对同一问题的看法，会有很大的启发。
7. 良好的编程风格。注意养成良好的习惯，代码的缩进编排，变量的命名规则要始终保持一致。大家都知道如何排除代码中错误，却往往忽视了对注释的排错。注释是程序的一个重要组成部分，它可以使代码更容易理解，而如果代码已经清楚地表达了思想，就不必再加注释了，如果注释和代码不一致，那就更加糟糕。
8. 韧性和毅力。这也许是"高手"和一般程序员最大的区别。A good programming is 99% sweat and 1% coffee。高手们并不是天才，他们是在无数个日日夜夜中磨练出来的。成功能给我们带来无比的喜悦，但过程却是无比的枯燥乏味。你不妨做个测试，找个 10000以内的素数表，把它们全都抄下来，然后再检查三遍，如果能够不间断地完成这一工作，你就可以满足这一条。
❻ .net方向的编程 应该怎么学习 多谢指教！
想找个工作的话你的这些书已经够了，但你最好再买本.net的开发实例相关的书，然后再平时多做些拿的出手的软件（或网站）。这样在面试的时候会比较有底气。估计你要学会这些东西大概要半年以上。
现在web软件是软件的发展趋势，因为不用装客户端，不用专门写服务器。所以目前一些中小型IT公司比较倾向于web
❼ 如何提高asp.net编程技术
asp.net自学的话非常难,因为asp.net需要学习的东西很多而且很难,如果你没掌握学习asp.net的方法的话,可能1-2年都只能入门,如果你掌握asp.net的学习的方法的话,半年就能学会asp.net。 …………………………………...
❽ 如何学习网络编程
具体到编程，用java来实现网络编程是很容易的，可以作为网络编程的入门。使用C＋＋和winsock相对复杂一些。
总之看实际需要了。
你好初学网络编程者可以从以下几个步骤开展：
1）下载一个可以互动的学习工具，通过这个与这个工具互动，我们可以及时的学到每个api的结果如果。
对于有c/c++或java基础的朋友通过一两个礼拜的时间就可以上手了，另外个人建议初学者可以学习dive into python。
2）掌握网络编程中会用到的几个基本概念和内涵，比如IP地址，port号，socket等
3）记住和消化网络编程C/S模型，把server和client端编程的常用模式理解和消化
4）花几天时间学习socket api集，api集可以分为下面几大类：创建 socket bind listen accept收发 read/recv/recvfrom write/send/sendto关闭 close shutdown参数 getsockopt/setsockopt地址 gethostbyaddr getaddrbyhost,...在学习这些api时候，可以先关注在函数功能，参数意义上
5）结合python互动平台，实践socket api的用法，比如socket函数怎么使用，bind怎么使用等等。在互动过程中，我们可以变换参数，看看调用结果如何。比如，创建一个tcp socket的语法如下：socket(AF_INET,SOCK_STREAM)创建一个udp socket的语法如下：socket(AF_INET,SOCK_DGRAM)
6）学习socket server端编程实现简单规约比如echo，time等，然后通过cmd中的telnet来测试。
7）学习I/O模型，比如阻塞、非阻塞和反应式（select,poll,WaitForMultipleObject)等
8）学习Richard Stevens的《Unix网络编程》，深入学习其中的api原理以及服务端设计原理，并通过代码编写。
9）下载高性能网络编程框架twisted，笔者强烈推荐，它将使你的网络编程效率提高10倍以上。
10）学习设计模式、操作系统知识比如线程、进程、同步等。
要想真正掌握计算机技术，并在IT行业里干出一番事业来，有所作为，具有一定的编程能力是一个基本条件和要求。打好基础学编程要具备一定的基础，总结之有以下几方面：
（1）数学基础 从计算机发展和应用的历史来看计算机的数学模型和体系结构等都是有数学家提出的，最早的计算机也是为数值计算而设计的。因此，要学好计算机就要有一定的数学基础，出学者有高中水平就差不多了。
（2）逻辑思维能力的培养 学程序设计要有一定的逻辑思维能力，“逻思力”的培养要长时间的实践锻炼。要想成为一名优秀的程序员，最重要的是掌握编程思想。要做到这一点必须在反复的实践、观察、分析、比较、总结中逐渐地积累。因此在学习编程过程中，我们不必等到什么都完全明白了才去动手实践，只要明白了大概，就要敢于自己动手去体验。谁都有第一次。
有些问题只有通过实践后才能明白，也只有实践才能把老师和书上的知识变成自己的，高手都是这样成材的。
❾ 我现在很迷茫，我是学习软件的在从事.net编程但是自己的技术一点也不怎么好，也就不怎么喜欢这个行
工作经验也不是一朝一夕之功。目前做开发人员的着实不少，但能做设计人员的真没几个。我就经常碰到这样的情况，有时候是我自己需要人，有时候是别人找我要人，前提条件就是能顶住一块需求或者有设计思维。目前绝大部分新参加工作的（指的是2年以内的工作经验者）都只是按自己的思维或完全没有设计思维在干活，但市场上奇缺有相当丰富的设计应变能力和需求控制能力的人。这种人员往往都是需要少则五六年工作经验者。
工作有时候也是需要看自己的兴趣发展的，如果自己对该行业完全没兴趣，也没必要把一生中的光阴的几分之几耗费在上面。楼主可以仔细思考一下自己的兴趣所在，然后再设想转行的事情。
❿ net程序员怎么提升自己的技术能力
一、先列三个常见的开发场景：
1、拿到一个模块详细设计文档，大部分程序员的通常做法就是开始搭建界面代码，然后从第一个按钮点击事件或页面Load事件开始写第一行业务代码。写的差不多了，就运行一下，发现哪里不是自己想的那样，就改改，直到改到是自己预想的那样。
2、做完了一个功能模块或几块相关联的功能模块，输入111asd，发现新建正常、保存正常，就提交给测试人员。测试员用测试用数据、测试场景用例来测试，发现有问题，就登记bug。对于严重的影响下一步测试的BUG，测试员就用内部IM通知这个开发人员。对于不影响继续往下测试的BUG，测试员就登记下来，等程序员有空时处理。
3、程序员一般工作不希望大家打扰，所以开发起来就是开发。等手头开发告一段落，就看看BUG库。发现有与自己有关的BUG，就从第一个BUG开始看起。就开始通过IM和测试员掰扯起来（这不是个BUG啊、业务逻辑不是你想的那样啊、我这里不能重现啊、你给的信息描述不清晰啊），于是IM几来几往，甚至跑过去当面交流一番，甚至会拉扯上产品经理一起讨论，更甚者需要项目经理或产品经理发起一个会议来集体讨论一下
这是不是很熟悉呢？这就是大部分程序员开发的三个步骤：写代码、自测、修复BUG。
二、说好的代码设计、代码测试呢？
代码设计？那不是都有开发平台么，已经固化了啊。那不是维护旧功能做完善修改呢么，又不是写新代码，只能在现有代码基础上修改啊，你又不能大幅重构。
代码测试？你丫需求讨论期、产品设计期、设计评审期那么长，都把研发项目时间占光了，就留下2个星期让我们写代码，我们哪里有时间搞那么深的测试。还想让我们搞结对编程？还想让我们搞测试驱动开发？
而且你看测试，什么功能测试、集成测试、性能测试、安全测试、安装部署测试、升级测试、迁移测试、UAT测试，一大堆测试，测试也需要很多时间。
一个项目，需求讨论、产品范围规划与评审、产品设计与设计评审占了一个半月，开发+自测就一个月，测试占了一个半月，这就4个月了啊。
三、为啥程序员写代码总是写写测测？
刚才大家也都看到了，大部分程序员都是从界面代码开始写起，而且写一写，就运行一下看看。为什么会是这种开发方式？
那是因为大部分程序员缺乏在脑子中的整体建模能力。只能做出来一点，真实的感觉一下，然后再往下。
有些是产品经理的上游就有问题，没给出业务流程图（因为产品经理也没做过业务），也没画清楚产品功能操作流程图。
为啥没给出业务流程图？因为产品经理不熟悉业务，另外，产品经理也没有流程建模能力啊。为啥没画清楚产品功能操作流程图啊？因为不会清晰表达流程啊。
很多产品经理、程序员，都缺乏分类、分层、相关、先后能力，更别说总结、洞察能力。
这是基本训练，是一个做事头脑清醒的人必备的技能，这不是一个程序员或产品经理或测试员的特定技能要求。
我经常看书就梳理书的脉络，每看一本就写一篇总结。我过去闲扯淡还梳理过水浒传、红楼梦的人物关系图呢，其实就在事事上训练自己的关联性、层次性、洞察性。
我经常面试一个人时，我会问这样的问题：“你把我刚才说的话复述一遍，另外你再回答一下我为什么会这样？”，其实，我就在看一个人的细心记忆、完整梳理、重现能力，我也在看一个人的梳理、总结、洞察能力。
我个人写代码就喜欢先理解业务流，然后理解数据表关系，然后理解产品功能操作流，大致对功能为何这样设计、功能这样操作会取什么表、插入或更新哪些表，哪些表的状态字段是关键。
然后我写代码的时候，就根据我所理解的业务流、功能操作流、数据输入输出流，定义函数，定义函数的输入与输出。
然后，我会给函数的输入值，赋上一些固定值，跑下来看看能否跑通这几个关联函数，看看还需要怎样的新增函数，或者看看函数的输入输出参数是否满足跑通。
剩下的事，就是我填肉写详细逻辑代码了。
当然，大部分人没我这样的逻辑建模能力。怎么阅读理解也想象不出来，也没法定义函数。毕竟有逻辑建模能力的程序员都很少，100个人里有10个，已经是求爷爷告奶奶好幸运了。
那怎么办呢？
我建议是分离分工配合，这就是现实中没办法的办法。让有逻辑建模能力的人来设计函数框架、来设计工具来设计代码模板，然后让没有逻辑建模能力的人来填肉写详细逻辑代码。
我们可以先从最紧要的模块开始这么做。不紧要的模块，还让它放任自流，让熟练手程序员继续涂抹。
我曾经还让有头脑的程序员做榜样，给大家分享他是怎么规划函数的，怎么做维护性代码的代码结构改善的。但是发现效果并不佳，其他人并没有因此能做代码设计。可能逻辑建模能力是个人的基本素质，是从小到大训练成型的，不是你一个大学已经几年的人能够短时间内可以训练的。
所以啊，还是让能走的人先走，让从最紧要的模块开始这么做。
不必担心这样做后，因为过去一件事被分工（一个做代码框架一个填肉）成两个人做了会降低工作效率。我们很多的工作效率低就是因为半瓶子醋搞出来的，来回反复修改。
真是应了刘德华在电影里说的那句话：说你又不听，听又听不懂，听懂了又不做，做又做不好，做不好还不服气。
四、为什么大部分程序员不做代码测试或白盒测试或单元测试呢？
还是因为没有代码设计。因为没有函数啊。所以，一个按钮功能有多复杂，代码就有多长。我见过2000行的函数，我也见过1000多行的存储过程和视图SQL。怎么做白盒测试啊，这些代码都粘在一起呢，要测，就得从头到尾都得测。
所以啊，先学会设计函数，先写好函数，这就求爷爷告奶奶了。很多开发了5年的熟练手程序员，可能都未必会写函数。
函数的输入输出值就很有讲究。很多人都写死了，随着版本迭代，发现过去定义的函数参数不够用了，于是就新增了一个参数。然后，相关性异常就爆发了，其他关联的地方忘改了，到底哪些有关联，怎么查啊，本系统没有，没准其他系统就调用你了，你根本不知道哪个神经人曾经COPY过你的代码修吧修吧就改成了他的功能呢，而且里面的很多代码他看不懂也不敢删，只要他实现的功能正常了他也不管了。于是，你改了你这个函数，他的系统就莫名出错了。
所以，我一般会定义几个对象来做参数。另外，我也很注重函数的日志、函数的异常保护、异常抛出、异常返回。另外，我也很注重参数输入值的合法性校验。
所以啊，应该开发Leader们先制定函数编写规范最佳实践，输入输出参数怎么定义比较好，函数的返回值如何定义比较好，函数的日志记录应该怎么写比较好，函数的异常保护、异常抛出、异常返回如何写比较好。先教会一般程序员，先从会写函数开始啊。
当然，你光有一份规范，程序员们还是不理解、不实际应用啊。所以，还得Leader们做好典型的代码模板，里面是符合函数规范的代码框架，只有这样，一般程序员们才会照猫画虎适应了函数设计的编程习惯。
所以啊，我专门重新定义了leader的明确职责，其中第一个重要职责就是：负责工具/框架/模板/规范的制定，并且负责推广且普及应用落地。
你不明确定义Leader的这个重要职责，你不对这个职责做明确的KPI考核，谁尿你啊。你以为好的工具/框架/模板/规范是靠人们的热情、自发产生的么？我们还没有那么自觉高尚啊。
五、为什么大部分程序员不写注释啊？
我经常说一句话，千万别多写注释。为啥？
因为我们经常遇到的问题不是没有注释，而是更糟的是，注释和事实代码逻辑是不相符的。这就出现常见问题了：残存下来的设计文档是一个逻辑、注释是一个逻辑说明、真实代码逻辑又是一个，钟表多了，你也不知道正确时间了。
所以啊，产品文档、注释、真实代码，三者总是很难一致同步。我为了几百人研发团队能做到这个同步花了大量心血和办法，但我最终也没解决了这个问题，还把Leader们、总监们、我都搞的精疲力尽。
索性回归到一切一切的本源，代码，就是程序员的唯一产出，是最有效的产出。那么，让代码写的不用注释也能看懂，咱得奔着这个目的走啊。
为啥看不懂，不就是意大利面条式代码么，又长又互相交杂。
OK，我就规定了，每个函数不能超过50行。用这一个简单规定和静态代码检查插件，来逼迫大家尝试着写函数。有的函数属于流程函数，是串起其他函数的，有的函数就是详细实现函数，实现一个且唯一一个明确作用的。
有了流程函数和功能函数，而且每个函数不超过50行，这就比过去容易看懂了。
六、为什么大部分程序员不抽象公共函数啊？
我经常说一句话：千万别抽象公共函数啊。为啥？
因为大部分程序员缺乏抽象洞察能力。特别是有些积极热情有余、爱学习爱看书、半瓶子醋晃悠的二杆子，看了几本UML、重构、设计模式、整洁代码之道，就跃跃欲试了，还真敢给你抽象公共函数了。
一开始，他觉得80%相似，20%不相似，于是在公共函数里面简单写几个if..else做个区隔就可以。没想到，越随着版本迭代，这些功能渐渐越变越不一样了，但是这个代码已经几经人手了，而且这是一个公共函数，谁也不知道牵扯多少，所以谁也不敢大改，发现问题了就加一个if..else判断。
没想到啊没想到，这个本来当初公共的函数，现在变成了系统最大的毒瘤，最复杂的地方，谁也不敢动，除非实在万不得已，手起刀落。
所以，我平时告诫程序员，纯技术的、纯通用的，你们可以尝试搞搞抽象公共函数，对于业务的，你们还是简单粗暴的根据Leader们做的代码模板代码框架，乖乖的复制、修改、填肉吧。
你们啊，先从做模板做代码片段开始吧，咱们放到咱们内部代码片段开源库里，看谁的代码片段被别人复制的多，说明你的代码抽象设计能力越好了。那时候，我就大胆放心让你撒丫子跑了。在没有学会跑之前，给老子乖乖的复制、修改、填肉吧。