'유결과론'에서 모 90후 프로그래머를 만났다

'유결과론'은 IT회사의 소프트웨어 개발 관리에서 맞습니까? 
유결과론, 특히 단기적인 외부에서만 볼 수 있는'결과'는 기술이 완전히 문외한인 지도자에 대한 게으른 관리 전략이다.
모 90년대 프로그래머는 통계 기능을 실현할 때 이렇게 실현했다.
Class CountPlaceDistrict는 각 항목의 통계를 얻는 총 수량입니다.

CountPlaceDistrict countPlaceDistrict = new CountPlaceDistrict(i+1, placeId,
sysCompany.getStr("comp_name"),
1, getStaffsByCompId(sysCompanys).size(),
getDailyCheckByCompList(sysCompanys).size(),getPlacesPunByCompList(sysCompanys).size(),getStaffsP(sysCompanys).size(),
getCaseInfoByCompList(sysCompanys).size(), getSuspiciousInfoByCompList(sysCompanys).size(),
getBusinessJournalByCompList(sysCompanys).size(), getSecurityPatrolLogByCompList(sysCompanys).size(),
getAlarmPersonByCompList(sysCompanys).size());

그 중에서 getStaffsByCompId, getBusinessJournal ByCompList 등 함수는 다음과 같다.

/**
 *                   
 *
 * @param sysCompanyList
* @return
 */
public List<Staffs> getStaffsByCompId(List<SysCompany> sysCompanyList) {
    List<Staffs> staffsList = new ArrayList<Staffs>();
    for (SysCompany sysCompany : sysCompanyList) {
        List<Staffs> staffs = Staffs.dao.getStaffs(sysCompany.getStr("comp_id"));
        for (Staffs s : staffs) {
            staffsList.add(s);
}
    }
    return staffsList;
}

즉 그는 모든 종사자를 다 읽어내고 리스트에 모두 넣은 뒤 리스트의 사이즈(size)를 확보해 통계 기능을 구현하는 것이다.
전문가는 이곳을 보면 그의 실현 방법의 문제가 어디에 있는지 이미 알고 있다.
만약 시스템이 진정으로 응용되고 종사자의 수가 많아진다면 특히 영업일지(get Business Journal By CompList)의 수가 비교적 많을 것이다. 그의 작법은 비교적 심각한 성능 비용 문제가 있을 수 있다.
그리고 기술을 모르는 사장이 매주 회의를 열어 이야기를 나누고 매주 진도를 재촉하기 때문에 위의 글쓰기는 현재 내부 개발 단계에서 외부에서도 정확한 통계 결과를 얻을 수 있을 것 같아서 90후 프로그래머의 상술한 글쓰기는 묵인되었다.만약 다른 사람이 90후 프로그래머에게 지금 바로 고쳐달라고 한다면 90후 프로그래머는 아직도 의견이 매우 크다. 다른 사람이 그의 노동 성과를 뒤집어엎는다고 해서 다른 사람이 더 많은 일을 하는 것 같다. 
이것이 바로'유결과론'의 폐단의 직관적인 예이다.
부주: 90후 프로그래머에 대한 편견과 견해는 없습니다. 다만 이 프로그래머는 90후 프로그래머이기 때문에'어떤 90후 프로그래머'로 대칭할 뿐입니다.