d**********6
发帖数: 4434 | 1 我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
以把我招过去。
到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
server的程序。现在在这基础上开始功能扩展。
问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
完要先停止service，compile，copy，restart service……debug改一个小错误都要几
分钟，实在太累人了。以前用Groovy/Grails+InteliJ的时候，直接点击debug按钮就启
动一个temporary的local server，上面改动什么东西都可以auto-compile，几秒钟以
后就能测试了。
C#能做到吗，不行的话可咋整啊？ |
N********n
发帖数: 8363 | 2 这个东西有得有失。Managed code需要COMPILE所以花时间，但是经过
STATIC TYPE COMPILE后能查出很多低级错误，花这点时间值得。 |
z*******3
发帖数: 13709 | 3 看了看，觉得还是xcode/apple好
也觉得还是java好，几分钟调试一次，这种搞法，开发太慢了 |
z*******3
发帖数: 13709 | 4 人家招你进去，应该是指望你带给他们一些东西
比如groovy那些，为啥不直接告诉他们你以前是怎么搞的？
然后演示一遍给他们看？c#语法要换成groovy并不难 |
g*****g
发帖数: 34805 | 5 就算Java也有JRebel存在，C#太落伍了。 |
n*w
发帖数: 3393 | 6 不能在local上test run吗？按一下f5等几秒。
看到在server马上要出来下一版本不用自己编译，源文件放上去roslyn会自动处理。
VS
【在 d**********6 的大作中提到】
: 我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
: 问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
: 新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
: 以把我招过去。
: 到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
: server的程序。现在在这基础上开始功能扩展。
: 问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
: 写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
: 后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
: 完要先停止service，compile，copy，restart service……debug改一个小错误都要几
|
N********n
发帖数: 8363 | 7
VS自带IIS模拟，只要不是复杂的系统在VS理F5就可以调试了。不用ATTACH
IIS之后再DEBUG。
【在 n*w 的大作中提到】
: 不能在local上test run吗？按一下f5等几秒。
: 看到在server马上要出来下一版本不用自己编译，源文件放上去roslyn会自动处理。
:
: VS
|
x**n
发帖数: 461 | 8 Debug的时候用I is express，直接在local机器上运行。visual studio 的debugger自
动就attach了。修改code再编译就几秒钟的事。在ide的集成上，idea虽然很不错，
visual studio还是更强大 |
w*******7
发帖数: 188 | 9 在dev local machine 也可以装IIS,可以直接debug. Remote debug是远端sever上没有
VS,然后attach process.
我们都是在local 编译,调试基本没有问题,才会push到QA或production sever,有问题
remote debug.
VS应该是最好用的IDE,软软正在推跨平台的VS,如果真能打通所有OS,也是码农们的福气
. |
b*****o
发帖数: 284 | 10 在local上run IIS很简单啊，每次有新的改动在VS上按一下F6，然后到browser上按一
下F5就可以看到刷新的page。要是想到server上test也是简单。按ALT+;+P就可以把你
这个page publish到server上，然后上browser上F5一下就可以了。这些都不需要
session重来。要是整个publish到server上，publish要花点时间的。 |
|
|
d**********6
发帖数: 4434 | 11 这个不大可能会实现了。这家公司已经深深的跟MS家绑定了，所有的东西从OS，app，
service以及员工的skill set全是MS家的
前面有网友说的也对，有得有失。我自己用的经验，InteliJ的compile和debug时间很
快，但edit的响应速度就很慢，要scroll到某一行可能需要等十几秒，一样让人很抓狂。
我相信MS家是有办法解决这个开发效率的问题的，只不过我不熟悉怎么搞。
【在 z*******3 的大作中提到】
: 人家招你进去，应该是指望你带给他们一些东西
: 比如groovy那些，为啥不直接告诉他们你以前是怎么搞的？
: 然后演示一遍给他们看？c#语法要换成groovy并不难
|
d**********6
发帖数: 4434 | 12 好像是一个通用的service，好几个组的人都用它，可能会挺复杂。
目前看来我们不负责这个service的开发和修改，只需要调用
【在 N********n 的大作中提到】
:
: VS自带IIS模拟，只要不是复杂的系统在VS理F5就可以调试了。不用ATTACH
: IIS之后再DEBUG。
|
p*a
发帖数: 592 | 13 感觉你们公司的人太弱。这明明是本地就可以用iis express debug的，和visual
studio是无缝整合的。另外就算不用visual studio publish，写个power shell
script把编译和部署自动化也就几分钟的事。
VS
【在 d**********6 的大作中提到】
: 我以前做和一段时间的Groovy/Grails开发，用InteliJ的IDE。虽然常有IDE反应超慢的
: 问题一度让我很讨厌，但最近到了新公司以后，发现这根本都是小问题。
: 新公司一直做的是VC，已经有十几年，一直是desktop程序。最近向cloud方面发展，所
: 以把我招过去。
: 到了新的组，开发的时候发现问题来了。小组基本都是C#跳过来的人，已经做好了一个
: server的程序。现在在这基础上开始功能扩展。
: 问题是，我发现这个开发效率实在太低。这个组用C#做server的流程是这样的，先用VS
: 写好code，compile好，然后把dll copy出来放到IIS的目录下，然后启动service，然
: 后测试。如果有问题需要debug，就要attach到process，然后debug，发现有错误修改
: 完要先停止service，compile，copy，restart service……debug改一个小错误都要几
|
k**n
发帖数: 3989 | 14 是楼主快猛糙习惯了，从不适应其他SDLC吧。
不管java，c#都要build然后deploy,
现在连node.js都用上build了。
简单的说，
首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
然后你checkin TFS 或其他的source control， 然后continue Integration自动build
与deploy到服务器上。
服务器应该有dev,qa,uat ，Prod等，
你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
稍正规点的软件公司都这样的。 |
d**********6
发帖数: 4434 | 15 应该是因为我们组的人不负责开发那部分，所以不大懂，不过谢谢指点
【在 p*a 的大作中提到】
: 感觉你们公司的人太弱。这明明是本地就可以用iis express debug的，和visual
: studio是无缝整合的。另外就算不用visual studio publish，写个power shell
: script把编译和部署自动化也就几分钟的事。
:
: VS
|
d******e
发帖数: 2265 | 16 一般语言开发都有watch, deploy。 IIS应该也有。github上找找。
没有自己写个也应该很快。
【在 d**********6 的大作中提到】
: 应该是因为我们组的人不负责开发那部分，所以不大懂，不过谢谢指点
|
n******n
发帖数: 12088 | 17 这么慢的响应速度，可以扔掉了。
狂。
【在 d**********6 的大作中提到】
: 这个不大可能会实现了。这家公司已经深深的跟MS家绑定了，所有的东西从OS，app，
: service以及员工的skill set全是MS家的
: 前面有网友说的也对，有得有失。我自己用的经验，InteliJ的compile和debug时间很
: 快，但edit的响应速度就很慢，要scroll到某一行可能需要等十几秒，一样让人很抓狂。
: 我相信MS家是有办法解决这个开发效率的问题的，只不过我不熟悉怎么搞。
|
c*********e
发帖数: 16335 | 18 我门公司没有qa,用jenkins来管理c# project,真心没有publish来得直接方便。
build
【在 k**n 的大作中提到】
: 是楼主快猛糙习惯了，从不适应其他SDLC吧。
: 不管java，c#都要build然后deploy,
: 现在连node.js都用上build了。
: 简单的说，
: 首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
: 然后你checkin TFS 或其他的source control， 然后continue Integration自动build
: 与deploy到服务器上。
: 服务器应该有dev,qa,uat ，Prod等，
: 你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
: 稍正规点的软件公司都这样的。
|
d**********6
发帖数: 4434 | 19 你说的这套正正是我们公司的模式
我困惑的是api的development，他们怎么完成在本机fix bug。因为我们组在用他们的
sln的时候是要attach才能debug的。不过我的担心可能多余，他们只是可能是他们没有
传授我们怎么做而已。
build
【在 k**n 的大作中提到】
: 是楼主快猛糙习惯了，从不适应其他SDLC吧。
: 不管java，c#都要build然后deploy,
: 现在连node.js都用上build了。
: 简单的说，
: 首先，你用vs在本机fix bug。。如用上TDD，mstest就能把大部分bug搞定，
: 然后你checkin TFS 或其他的source control， 然后continue Integration自动build
: 与deploy到服务器上。
: 服务器应该有dev,qa,uat ，Prod等，
: 你上QA后，所以测试由专门QAtester来完成。每个bug会记录在系统发给你修改。
: 稍正规点的软件公司都这样的。
|
k**n
发帖数: 3989 | 20 你的api好像是WCF吧。
在VS里就能运行啊。
如果是不同sln，
开两个VS， 一个client,一个API，同时debug。
【在 d**********6 的大作中提到】
: 你说的这套正正是我们公司的模式
: 我困惑的是api的development，他们怎么完成在本机fix bug。因为我们组在用他们的
: sln的时候是要attach才能debug的。不过我的担心可能多余，他们只是可能是他们没有
: 传授我们怎么做而已。
:
: build
|
