多产品代码架构

对于多产品代码来说如何,对于不同产品相同属性不同参数如何简单code

举个例子:

其实很简单,比如说你们班有很多小伙伴,如何设置信息呢,用到了struct

struct STUDENT_S{
    string     name;
    int  age;
	bool sex;
	string addr;
	...
};
struct STUDENT_S g_student_param[] = {
   {“Li Lei”,     12, true,  "beijing"},
   {"Han Meimei", 11, false, "wuhan"},
}

  用这种简单列举的方式就可以用一套代码,一劳永逸,如果再添加其他人的话,直接再起一行就可以了,哈哈

原文地址:https://www.cnblogs.com/r-yan/p/12576474.html

时间: 2024-10-14 12:22:02

多产品代码架构的相关文章

单元测试代码比产品代码还要多?

[图一] 是单元测试代码? [图二] 是产品代码? 显而易见的是, 单元测试代码比产品代码还要多, 这合理吗? 当然合理! 产品代码虽然是只有短短的几行; 处理订阅者订阅赛马的消息? 但, 却会衍生出许多不同的使用者场景; 如: 没有订阅者订阅, 只有单一或多个订阅者, 某个订阅者重复订阅, 某个订阅者取消订阅-..等等? 单元测试, 根据这些不同的使用者场景, 分别有相对应的单元测试代码 (测试用例) ?  所以, 单元测试代码自然会比产品代码还要多? 但, 这样的付出 (投资) 绝对是值得的

【原创】互联网产品的架构评估——可用性、可靠性、可维护性、安全性

架构指标 子项 描述 策略 致命阶段 备注 可用性 ISO 9241-11 定义:产品在特定使用环境下为特定用户用于特定用途时所具有的有效性.效率和用户主观满意度.产品是否容易上手,用户能否完成任务,效率如何,以及这过程中用户的主观感受可好,是从用户的角度来看产品的质量.可用性好意味着产品质量高,是企业的核心竞争力. 尽量让系统和功能相匹配.尽量简洁而自然. 做好异常预防和异常处理.提供相关帮助文档.及时获取有价值的反馈 有效性 功能可用,出错少 严格的功能测试,降低bug率 初期 效率 系统反

SOA: UBER工程代码架构的拓展和演变SERVICE-ORIENTED ARCHITECTURE: SCALING THE UBER ENGINEERING CODEBASE AS WE GROW

像很多初创型公司一样,Uber的架构一开始也是一整块的,或者说是整体的.不可分割的,服务端部署在一个城市,对外整体上是单个节点.这个也迎合了当时服务范围和功能选项有限的业务场景.可执行代码部署在单个节点,对于这种场景下,可以说是简洁.易管理的,而且直接上来说,满足了我们的业务需求:简单的连接司机和乘客,出账单,支付.在这种"小而美"的场景下,将Uber的这些简单的业务逻辑放在一起,也是很有道理.很有实际操作性.很有性价比的:).但是,当我们的业务迅速拓展到多个城市,并且产品也不再那么单

Android bluetooth介绍(二): android 蓝牙代码架构及其uart 到rfcomm流程

关键词:蓝牙blueZ  UART  HCI_UART H4  HCI  L2CAP RFCOMM  版本:基于android4.2之前版本 bluez内核:linux/linux3.08系统:android/android4.1.3.4作者:xubin341719(欢迎转载,请注明作者,请尊重版权谢谢)欢迎指正错误,共同学习.共同进步!!一.Android Bluetooth Architecture蓝牙代码架构部分(google 官方蓝牙框架) Android的蓝牙系统,自下而上包括以下一些

产品代码的建议标准

怎样的代码才能作为产品代码提交到代码库中,使系统能够持续健康地成长? 第一级: 无语法错误,编译通过, 能够启动应用: 消除警告与错误: 第二级: 简洁清爽的排版,合理的命名, 一致的风格, 适宜必要的注释: 第三级: 能够处理正常情况下的功能实现,保证正常情况下的逻辑正确: 第四级: 能够处理不合法输入,给出错误提示:能够处理可能出现的错误和异常,输出容易排错的日志: 第五级: 使用相互协作良好的短小方法: 消除一个方法中含有大段逻辑的情形: 第六级: 编写的代码有比较完善的单元测试用例:对错

编码艺术-代码架构的思考

一.前言 从入职到现在已有一年.想想现在与当初自己的期望虽有遗憾但也还是有所进步.我个人对自己的认知是敢于尝试与实践新的技术与新的理论,说大胆也不为过.因此工作中写的代码或多或少也被诟病.被批评.被质疑.但我觉得若人人都循规蹈矩.人人都不去尝试,那么谈何创新.谈何进步呢?终究是需要人去做那一颗划破静夜的流星. 二.背景 最近在对项目的SDK进行升级改造.考虑到要兼容之前用户的调用习惯,所以改造是需要很多讲究的,也引发了对代码架构的思考.在大多数时候我们在完成一个需求的时候,大部分人都是努力去完成

社交产品后端架构设计

本篇文章会向读者展示几个架构设计的关键点,使一个社交应用能够成为真正的下一代社交产品.以下几个属性将会影响到架构的设计: a)可用性 b)可扩展性 c)性能和灵活性可扩展 目标 a)确保用户的内容数据能够很方便的被其他用户发现和获取. b)确保内容推送是相关的,不仅在语义上,也是从用户设备的角度. c)确保实时更新生成.推送和分析. d)尽可能地节省用户的资源. e)不论服务器负载变化如何,用户体验应保持不变. f)确保应用整体上是安全的 总之,我们要处理一个相当大的挑战,我们必须处理不断扩大的

“百变”Redis带你见识不同场景下的产品技术架构

摘要: 2018飞天技术汇24期-云数据库Redis产品发布会,由阿里云数据库技术组技术专家王欢.怀听.梁盼分别带来以"Redis全球多活产品"."Redis混合存储产品"."Redis多线程性能增强版"为题的演讲,本文对Redis进行了简单的介绍,进而针对不同的应用场景研制出不同的产品,并对不同产品分别进行了详细地介绍.2018飞天技术汇24期-云数据库Redis产品发布会,由阿里云数据库技术组技术专家王欢.怀听.梁盼分别带来以"Re

大数据系统数据采集产品的架构分析

任何完整的大数据平台,一般包括以下的几个过程: 数据采集 数据存储 数据处理 数据展现(可视化,报表和监控) 其中,数据采集是所有数据系统必不可少的,随着大数据越来越被重视,数据采集的挑战也变的尤为突出.这其中包括: 数据源多种多样 数据量大,变化快 如何保证数据采集的可靠性的性能 如何避免重复数据 如何保证数据的质量 我们今天就来看看当前可用的一些数据采集的产品,重点关注一些它们是如何做到高可靠,高性能和高扩展. Apache Flume Flume 是Apache旗下,开源,高可靠,高扩展,