提几个问题 大家一起来讨论下
1.一款迭代开发2-3年以上的APP怎么样的项目架构才是比较好的呢？
（1）一般现在 小团队开发（1-3人） 新的app 一般都会使用 pod来进行依赖管理第三方库，当然也可以管理本地的库。
这样子 第三方库基本上不需要去太大的搭理，只需要管理好podfile就可以了。
代码里使用mvc也好 mvvm也罢，文件不管怎么分，基本上就2个工程，一个主app工程 一个pod管理的第三方库工程。
（2）但是如果老项目 依然是小团队开发的 历史遗留 可能就没有使用pod了，可能混乱一点的 就只有一个主工程了，第三方库直接下下来拖进去好了，更新么就把文件换掉即可。
但是可能依然只有1 ，2个开发，其实影响并不是很大。
但是如果老项目是5人以上的话，这个影响就可以发生了，这个时候 项目分工 迭代开发 可能就会发生很混乱了。那这种项目有啥好的解决办法呢。
（3）现在大公司 大项目 例如微信 网易新闻等 这种体量很大的app，大部分应该是多工程 多依赖 来进行管理的。抽出和业务依赖非常小的模块作为核心库，就算以后新开发的app也可以用到，这部分核心库 一般都是内部封装 提供,framwork静态库供其他team使用，而且各不同业务的team之间也是代码保密状态 只有api沟通。不同的业务就是不同的SDK，最后一个app就是 多个不同的库 组合在一起 加耦合性高的业务代码进行组合。（以上都是小人之见，个人还没有参与过 10人以上的开发）。
毕竟软件项目都是不断成长的 ，是否在软件体量达到一定量的时候 就需要进行（3）那种模式的重构，还是说 就照着（1）（2）那种方式进行下去，毕竟重构的成本太高，尤其是软件已经有大量用户基础。
PHP中文网2017-04-17 17:30:23
이 문제에는 내가 발언권이 있다고 생각합니다
PS: 중요하기 때문에 한 가지 먼저 언급하겠습니다. 시간을 내어 작성한 코드를 검토해 보세요.
아래에 긴 글을 썼는데, 원본 포스터의 질문에 답변을 하지 못한 것을 발견했습니다:
(1) 맞습니다
(2) 예전 프로젝트의 상황에 따라 다르며, 그럴 수도 있습니다. 또한 코드를 변경하여 구조화합니다. 여러 사람이 협업한다면 명확한 분업과 SDK 작성에 대한 태도가 있어야 합니다
(3) 맞아요 예전에도 그랬어요
(4) 작은 회사라도 2~3명 정도 (3)에 따라 개발하는 것이 가장 좋습니다. 그렇지 않으면 코드 베이스에 본질을 추출하지 않고 1년, 2년, 3년 또는 4년 동안 많은 프로젝트만 있을 수 있습니다
이 멋진 프로젝트를 보면 Sun7400/YYKit을 알게 될 것입니다. 이 멋진 프로젝트는 iOS에서만 작업된 지 1년이 넘었습니다.
제가 처음 맡은 일은 지도 내비게이션 SDK를 개발하는 것이었습니다. 이후 App Store에 작은 앱을 출시하기도 했고, 뉴스 클라이언트, 온라인 쇼핑 플랫폼 등 대규모 프로젝트도 아웃소싱하기도 했습니다. 사실 모두 공통점이 있습니다. . 프로젝트 구조와 관련하여 다음과 같은 제안을 드립니다.
cocospods 또는 기타 타사 코드 도구를 사용하여 필요한 타사 코드를 통합 방식으로 관리합니다. 타사 라이브러리를 추가할 때 발생하는 다양한 링크와 런타임 오류를 고려하면 사용하기 쉽습니다. 몇 년 전만 해도 지금은 정말 유용하다는 생각이 듭니다. 행복
의도적으로 MVC나 MVVC의 이론을 수용하지 마세요. 모든 개발은 低耦合을 기본 표준으로
프로젝트 중 재사용률이 가장 낮은 프로젝트는 ViewController이므로 스토리보드를 사용하여 페이지 레이아웃을 완성하고, ViewController의 UI 코드를 생략한다는 장점이 있습니다. 개정되었으므로 VC 코드를 많이 수정할 필요는 없습니다
가장 재사용 가능한 기능은 URL 인코딩, UI이미지 자르기, MD5 인덱싱 등과 같은 몇 가지 기본 기능입니다. 이러한 기능은 결합도가 매우 낮기 때문에 제외됩니다
다음으로 높은 재사용률은 내비게이션 엔진 경로 계산, Thinning 등과 같은 일부 핵심 알고리즘입니다. 실제로 현재 프로젝트를 수행할 때 직접 조작해야 하는 알고리즘은 거의 없습니다. 있어요, 나와서 캡슐화하세요. VC에 함부로 쓰지 마세요
사용자 정의 컨트롤, 게으르지 말고 Cell을 포함한 캡슐화를 상속받으세요. 간단히 말해서 VC에서 컨트롤을 구축하지 마세요.
VC에서 모든 TableViewDelegate 메소드를 별도로 캡슐화하려고 시도했다면 TableView를 상속하여 자체 DataSource를 만들도록 해보셨나요?
네트워크, CoreData 및 모델은 MagicalRecord과 같은 고급 타사 프레임워크와 자동으로 번들로 제공되는 일부 json->모델 프레임워크
메소드 코드가 20줄을 초과합니다. 분할이 필요한지 고려해보세요
마지막으로 내 프로젝트의 일반적인 구조는 다음과 같습니다
ViewController 디렉터리는 다음과 같이 여러 페이지에 따라 디렉터리로 구분됩니다.
디렉토리 사용자 정의 컨트롤 및 셀 보기
3차 프로젝트의 제3자 코드 직접 가져오기
Func 함수 코드
CoreData 모델 및 데이터베이스 컨트롤러
API 네트워크 인터페이스
분류의 가장 큰 장점 중 하나는 코드를 빠르게 찾을 수 있다는 것이고, 프로젝트 규모가 크더라도 거래가 진행되는 과정을 명확하게 파악할 수 있다는 것입니다.
마지막으로 CoreData를 사용하신다면 꼭 연구해 보시길 권합니다NSFetchedResultsController
제가 패키징한 zsy78191/DEFetchRC입니다
행운을 빕니다
高洛峰2017-04-17 17:30:23
비용 효율성은 프로젝트의 라이프사이클에 따라 달라집니다
프로젝트가 단기적으로 취소되지 않고 계속해서 변경되어야 한다면... 장기적인 고통은 그보다 더 큽니다. 단기적인 고통
리팩토링은 하나의 버전에서 완료할 필요가 없습니다. 이전 코드를 조금씩 해체하고 동작이 변경되지 않도록 테스트를 작성해 보세요.
