项目中的乱七八糟

     有人可能觉得项目都是应该有条有序,有甘特图、计划表、子模块优先级、程序可维护性等。

      但其实很多时候并不如意,我们的产品很多时候有各种不一样的意外:客户临时反馈的重大bug、程序性能瓶颈、程序业务逻辑错误,从而导致整个项目得返工;其实说白了,就是无用功。如果一个项目在前期做好了业务逻辑和数据结构等安排就可以省去了很多考虑的时间(比如powerbuilder、rational rose)

 

对于架构设计,我更加推荐使用freemind和dia,这两个工具比较快捷,虽然功能不一定强大。

 

      工具不一定是重要的,只要做出来可以让大家协同就好了(這個非常重要,否则就是你一个人,再厉害都是一个人,很多产品特点都挖掘不出来的),切合我公司那块儿的情况来说,暂时比较团结地采用同一款IDE、同一个数据库工具、同一个版本的PD、甚至是同一个版本的版本管理器。

 

      这样对团队做产品是有好处的,因为哪個人到另一个人的电脑都得心应手,交流业务一点都没有缝隙。

      好吧,来说点不好的,公司做产品的时候考虑更多的是收益,而收益来自于最大的协同效果,如果大家采用一样的环境对公司是很有利的,但对于个人不一定,因为他可能会想更新知识,不想停滞不前,不用看了,如果你看到这里表示你也是一个想不断更新自己知识的人。

      所以很多时候我们会采用2套工作环境(至于怎么搭建多个工作环境我就不多阐述,很多方法)

      后面我想来说一下,测试的活儿,這個一直被认为是最苦闷的活儿。

 

      其实我很是佩服公司里的测试达人,6個开发人员,1個测试人员,还要写文档,还要给客户解释( - -|| 想想我都觉得可怕)

      当然有激情地话也行,只是被磨了几年之后还会不会犹如当初那么热血沸腾就不知道了,现在他基本每天都需要加班,每个周末有时还要陪开发人员加班。

     

       这样子的压力太大了,导致其实整个团队都没什么精神。其实工作效率很低,还不如不加班的强。假若你本来是秒针,一加班,事儿本来也就是几秒的事情,当压力一大,你就不想走那么快了,成了分针…。对于加班這個想法是没有人想的,但是很多时候会是开发人员自己情不自禁地加班,這個我就不多加评论了,毕竟任务多,工作量大嘛。

       至于每周的活动,我个人感觉对于开发人员尤其重要,人不是机器,不是每天都能产出高质量代码,既然如此,为什么不让他們放松一下呢,这样能有更大的收益。先声明,我的意思并不是说让公司出钱,只是,如果公司内部能发起活动是很好的。这就要看公司了,初期不一定有这么好的情况,逐渐地需要考虑到员工心理素质问题。

       给我8000块一个月,活儿多,生活没有规律,苦不堪言,人肯定走。但是如果你能拿到4000块一个月,但是工作比较有热情,公司很有气氛,这样我觉得会有很多人愿意留下。好吧,在此引用某人的话:“够花就好了,反正都是一样活着。”项目管理当中很大的一个项目就是人员管理,而人员管理需要最基本的就是满足“生理上的要求”,而多余的只會是自己可以拿到多少零花钱而已。

       好吧,说了挺多废话,抱歉,這個不是干货,请勿收录。谢谢!~

      

转载于:https://www.cnblogs.com/jianjungki/archive/2012/08/14/2638754.html

<think>好的,我现在需要帮助用户解决在Visual Studio 2022空项目中运行C代码的问题。根据用户之前的提问,他已经尝试过调整代码但遇到了编译错误,比如scanf的安全警告和链接错误。我需要参考提供的引用信息,找到合适的解决方法。 首先,引用[3]提到在VS2019中处理类似问题时,可以通过添加预处理指令来禁用安全警告,比如使用`#define _CRT_SECURE_NO_WARNINGS`。这可能适用于VS2022,因为两者都是较新的Visual Studio版本,处理方式类似。所以用户需要在代码开头加上这个宏定义,或者使用`#pragma warning(disable:4996)`来禁用特定警告。 其次,用户提到的空项目问题。在Visual Studio的空项目中,默认不会链接标准库的一些函数,导致链接错误,比如`_main`未定义或者标准函数找不到。引用[3]中的代码片段示例显示了如何在VS中配置代码片段,可能需要确保项目设置正确。可能需要检查项目的属性,确认使用的是C++还是C编译器。如果用户是编写C代码,可能需要将文件扩展名改为.c,并确保项目设置为C语言项目,这样编译器会正确识别。 另外,引用[4]提到不同编译器的内存布局差异,但这里的问题可能更多是项目配置问题。例如,空项目可能没有包含必要的运行时库或入口点设置。用户需要确认在项目属性中,子系统设置为控制台,这样生成的程序会有正确的入口点main函数,避免链接错误。 还有,用户可能没有包含必要的头文件,比如stdio.h,导致函数声明缺失。需要检查代码中是否包含了所有必要的头文件,特别是使用输入输出函数时。 最后,可能需要调整代码中的函数使用方式,比如使用scanf_s代替scanf,或者在项目属性中关闭SDL检查,以允许使用不安全的函数。但更推荐使用安全函数或添加宏定义来避免警告。 总结下来,步骤可能包括:添加宏定义禁用警告、确保文件扩展名为.c、设置正确的子系统、包含必要头文件、处理入口点main函数。需要一步步指导用户进行这些调整,确保代码能在空项目中正确编译运行。</think>### 调整C代码以适应Visual Studio 2022空项目的步骤 #### 1. **禁用安全警告** Visual Studio默认禁用部分C标准库函数(如`scanf`),需在代码开头添加宏定义: ```c #define _CRT_SECURE_NO_WARNINGS #include <stdio.h> ``` 或通过项目属性禁用警告:`属性 → C/C++ → 预处理器 → 预处理器定义 → 添加_CRT_SECURE_NO_WARNINGS`[^3]。 #### 2. **确保文件扩展名为`.c`** VS2022根据文件后缀选择编译器: - 将代码文件重命名为`.c`(例如`main.c`) - 右键文件 → 属性 → 配置属性 → 高级 → 编译为C代码[^3]。 #### 3. **设置控制台子系统** 空项目默认未指定入口函数,需手动配置: - 项目属性 → 链接器 → 系统 → 子系统 → 选择`控制台 (/SUBSYSTEM:CONSOLE)` - 确保入口点为`main`函数[^4]。 #### 4. **添加必要头文件函数** 示例代码框架: ```c #define _CRT_SECURE_NO_WARNINGS #include <stdio.h> int main() { int num; printf("输入整数:"); scanf("%d", &num); printf("结果:%d", num); return 0; } ``` #### 5. **处理编译器差异** - 若需兼容GCC语法(如`#include <bits/stdc++.h>`),需手动引入标准库头文件[^3] - 避免使用`getch()`等非标准函数,改用`getchar()`替代。 #### 6. **验证项目配置** | 配置项 | 正确值 | |-----------------|--------------------------| | 文件扩展名 | `.c` | | 子系统 | 控制台 | | 编译模式 | C语言(非C++) | | 运行时库 | 多线程调试 (/MTd) |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值