第97章 文字输出者福音 (第2/7页)

一杯茶一包烟，一行代码改一天。

    别说一行代码改一天了，有时候三四行代码十多号人改上一个月也是常有的事情。

    倒不是说程序猿消极怠工，问题是在别人写的shi一样的代码里debug着实有亿点困难。

    玩不利索指针还胡乱放。

    备注什么的更是没有。

    没备注的情况还好点，最怕遇到堪比老中医的鬼画符的那种火星备注。

    真就一个人的备注十个人猜。

    为啥不找来写代码那个人问问？

    笑死，早就离职了。

    最关键的是改代码时不仅要忍受shi山一样的代码。

    还要面对同行无意之间造成的掣肘。

    别的行业林灰说不好，但程序猿行业并不适用于人多力量大。

    至少不完全适用于人多力量大。

    人力和时间并不呈现线性关系的。

    大量人员并不能缩短软件的开发进度。

    一窝蜂的作业方式非但无助于软件生产，反而会制造麻烦，产生出更差的软件。

    向进度落后的项目追加人力，只会使进度更加落后。

    因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。

    当有N个人必须在这群人之中进行沟通时（无阶级关系），当N增加，其输出M将抵消其效益，甚至倒退。

    事实上认为人力能换取时间这种观念本身就是极其错误的。

    别的行业可能是1 1＞＞2

    但计算机行业很可能出现1 1＜0的怪现象。

    这件事最直接的启发是关于未来团队的构建。

    关于要不要组团队？肯定要组