읽 기 노트 - 소프트웨어 공학 의 큰 진흙 공

소프트웨어 공학 의 커 다란 진흙 덩어리
(원문 주소: http://www.laputan.org/mud/
큰 진흙 공의 정의: A  BIG BALL OF MUD  is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.
글 에서 작 가 는 소프트웨어 구축 과 건축 을 비교 해서 나 는 매우 합 리 적 이 라 고 생각한다.소프트웨어 구조 사 는 건축 디자이너 에 대응 하여 전체적인 계획 을 세우 고 '건축 도면' 을 설계 해 야 한다.개발 자 는 시공 자 와 대응 하여 구체 적 인 구축 작업 을 한다.
저 자 는 무엇이 추악 한 시스템 을 구축 하기 위해 좋 은 프로그래머 를 구동 하 는가?뒤에서 도 답 을 내 놓 았 다.

　　Time

　　                 ，           ，        deadline

　　Cost

　　      Architecture is expensive, especially when a new domain is being explored.         。 

　　Experience

　　          “discover and develop new abstractions”,             。（domain experience architectural experience     。）

　　Skill

　　          、                    

　　Visibility

 　　                ：                       ，                    。

　　Complexity

　　                          ；the software is ugly because the problem is ugly, or at least not well understood.

　　Change

　　         ，              。

　　Scale

　　      ，            ，          

　　        ·     ："good ideas don't always scale."

　　Scale           ，  ，  ，         。

　　      ，               http://www.folklore.org/StoryView.py?project=Macintosh&story=Creative_Think.txt

　　      ：    ，       ，            。

　　（ ：  · Alan Kay Smalltalk      ，  "The best way to predict the future is to invent it."               。）

개인 능력 에 한계 가 있 기 때문에 다음은 몇 단락 의 글 을 발췌 하면 필 기 를 조금 하 는 셈 이다.

　　1.The time and money to chase perfection are seldom available, nor should they be. To survive, we must do what it takes to get our software working and out the door on time. Indeed, if a team completes a project with time to spare, today’s managers are likely to take that as a sign to provide less time and money or fewer people the next time around.

　　         ，      。                ，            、           。             ，       ，                  ！

　　2.focus first on features and functionality, then focus on architecture and performance.

　　3.BIG BALL OF MUD might be thought of as an anti-pattern, since our intention is to show how passivity in the face of forces that undermine architecture can lead to a quagmire. However, its undeniable popularity leads to the inexorable conclusion that it is a pattern in its own right. It is certainly a pervasive, recurring solution to the problem of producing a working system in the context of software development. It would seem to be the path of least resistance when one confronts the sorts of forces discussed above. Only by understanding the logic of its appeal can we channel or counteract the forces that lead to a BIG BALL OF MUD.

　　4.One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.

　　          “   ”   

　　5.Indeed, reviews and pair programming provide programmers with something their work would not otherwise have: an audience. Sunlight, it is said is a powerful disinfectant. Pair-practices add an element of performance to programming. An immediate audience of one's peers provides immediate incentives to programmers to keep their code clear and comprehensible, as well as functional.

　　    -    ，           ，                      ，           。  ，                      。        ，           ，                 ，        ，         ，                 ，                。                ，                 。

　　6.An additional benefit of pairing is that accumulated wisdom and best practices can be rapidly disseminated throughout an organization through successive pairings. This is, incidentally, the same benefit that sexual reproduction brought to the genome.

　　       ：     

 　　7.There are three ways to deal with BIG BALLS OF MUD. The first is to keep the system healthy. Conscientiously alternating periods of EXPANSION with periods ofCONSOLIDATION, refactoring and repair can maintain, and even enhance a system's structure as it evolves. The second is to throw the system away and start over. TheRECONSTRUCTION pattern explores this drastic, but frequently necessary alternative. The third is to simply surrender to entropy, and wallow in the mire.

　　          ：1        ，    、  ，        ；    3      ，       。

　　8.Master plans are often rigid, misguided and out of date. Users’ needs change with time.

 　　9.Successful software attracts a wider audience, which can, in turn, place a broader range of requirements on it. These new requirements can run against the grain of the original design. Nonetheless, they can frequently be addressed, but at the cost of cutting across the grain of existing architectural assumptions.

　　         。                            。

　　             。              ，   ，        ，        。                 ，              ？      ，                    。

 　　10.Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system.

　　      ，     ，         

 　　11.Microsoft mandates that a DAILY BUILD of each product be performed at the end of each working day……Indeed, this approach, and keeping the last working version around, are nearly universal practices among successful maintenance programmers.

　　12.If you can’t make a mess go away, at least you can hide it.

(뒤에 만화, 화풍 이 특이 한데.. 아 쉽게 도 못 알 아 봤 어 요)