Ben*_*ter
17
首先是通用答案:
- 了解任何给定的工具都不是解决所有问题的灵丹妙药.因此,当您阅读有关MVC或功能编程的内容或有人在喷出LISP将解决您的所有问题时,他们不会.他们可以解决你遇到的一大堆问题,但他们不会全部解决.在许多情况下,除了解决一些问题外,他们还会介绍其他一些问题.
- 了解不同组件/技术/工具的局限性和优势,触手可及,为任何特定问题提供解决方案.根据所有优点和缺点的消失做出决定 - 不要盲目做出决定.
- 为工作选择合适的工具,包括语言,开发,集成技术.
- 谁将维护代码？代码给预期的受众.如果那就是你,不要指望从现在开始的六个月,当你需要提供一个修复程序时,你会记住你今天的思考过程...编写简单的代码并记录你的思考过程.不是"如何" - 代码那样做,而是"为什么".无论你的代码是多么容易阅读,它都无法告诉你为什么这样做.代码注释是为什么,而不是如何.
- 了解您的用户,他们的工作方式,他们对工具的心态,他们的工作是什么,他们对您的软件学习曲线的态度是什么.
- 了解将支持您的应用程序的人/团队的心态 - 这也意味着安装.
- 了解源代码控制的需要并使用它.
- 备份,总是假设并做好最坏的准备,如果你不希望你做到的话.
- 了解如何编写软件规范,技术规范,测试文档和用户文档.
- FAT/SAT/UAT测试和签核程序.
- 设定低于您能够提供的期望,不要向客户承诺Lambourghini并提供Volkswagon Beetle [Bug].更好地承诺甲壳虫[Bug]并提供梅赛德斯.
- 不要过度复杂化任何东西 - 包括架构,编程或其他任何东西.文档应该易于阅读,界面应该易于使用.
现在详细说明:
- 了解您必须先研究问题并了解问题域,然后才能提供任何类型的解决方案,架构或其他方案.
- 了解用户期望交付的内容,交付方式以及交互方式.
- 找到将使用您的解决方案的技术最娴熟的人,如果他们能够理解它,其他人也会.
- 为您的用户和您的金融家设计您的软件.如果你交付给它的人不能/不会使用它,你永远不会听到它的结束 - 即使你的金融家最初满意,他们也会很快回头.
计划失败就是计划失败
您的环境,软件需求,目标受众,网络支持人员,预算和任何其他因素将极大地影响您提供的解决方案.例如,在我编写的环境类型中,我倾向于使用一组有限的工具来交付产品,它们可能会因您的环境而异:
- Web浏览器 - IE/Firefox/Opera/Safari
- 应用程序/文件服务器 - Windows Server,Linux,Unix
- Web服务器 - IIS/Apache
- Web应用程序开发 - ASP.NET/C#/ VB.NET/ASP/PHP/JavaScript/AJAX/MVC
- 控制台应用程序开发 - BAT/C#/ VB.NET [如果BAT文件更简单地完成工作,请不要编写完整的C#应用程序].
- Windows应用程序开发 - C#/ VB.NET
- 数据维护 - C#/ VB.NET/Excel/VBA
- 数据库服务器 - SQL Server,MySQL,Oracle
- 网络/数据/文件集成服务 - MSMQ,BizTalk,SonicMQ,FTP
我可以将这些技术中的一种或多种用于我的解决方案,完全取决于对我的要求.关键是要了解哪些与特定情况相关并且仅使用必要的情况.例如,如果单个用户可以轻松使用命令行实用程序,则不要编写完整的Web应用程序,如果许多用户需要访问无法轻松安装在其计算机上的应用程序,请不要编写Windows应用程序由于用户限制和有限的系统支持人员.不要为那些几乎无法用鼠标浏览窗口的用户编写命令行实用程序,也不要指望Microsoft专家支持基于*nix的系统.
提供的图表和文档,使人们简单的诊断问题,这样,当问题被发现[他们将是],用户/桌边支持可以很容易地缩小问题到系统中的一个特定组成部分.这将使您的生活更轻松,因为他们要么能够自己修复它,要么为您提供足够的信息来快速简单地解决问题.
编辑:回应您对UML的评论,这对于此目的很有用,但您必须再次了解您的目标受众.如果你是一个独立的程序员,正在为一个人员不懂UML的小客户开发系统,你也可以提供一个用简单英语装饰的常规流程图.如果你的目标受众是一个软件咨询公司,其业务是软件开发,那么无论如何,UML都是一个很好的工具 - 特别是对于一些UML工具,你可以让它自动生成你的存根类/方法,让你自动化一些处理.我倾向于为小公司的小团队工作,所以我不像我想的那样使用UML,并且我可能不理解它,但这并不是说如果我被要求我不会不要刷它.它是一个很棒的工具,可以放在你的工具箱中,但不要仅仅为了它而使用它.您在解决方案的设计/架构/开发中使用的所有内容都应该用于客观原因 - 不要盲目地使用/学习它,因为有人说"你应该使用它,因为它很棒".
良好架构的关键是:
- 了解您正在使用的工具
- 了解您应该和不应该使用您的工具用于任何特定目的的原因
- 客观地做出明智的决定,不要以传闻或情感为基础.
最重要的是:
- 用你的常识!如果某些事情听起来不对或感觉不对,请找出原因,最糟糕的情况是你会发现自己错了,并且你已经纠正了一个误解/误解,最好的情况是你节省了很多时间追求错误和基于这种误解的潜在昂贵的选择 - 无论哪种方式你都比你更好.