¿Cuánto debo dividir mi código en métodos / funciones separados más pequeños? A pesar de que ese fragmento de código solo se puede usar una vez y, como sabemos, siempre es posible que cada fragmento de código se pueda cambiar / editar en el futuro.

Solo usted puede responder esto para su aplicación. Por lo general, cuanto mejor factoriza su código, más resistente es a los cambios. Además, cuando habla específicamente de iOS, una aplicación bien pensada es más fácil de hacer universal y más fácil de usar también en Mac. Además, quién sabe lo que depara el futuro: tal vez podría usar el mismo código iOS bien factorizado al escribir aplicaciones para algo como un AppleTV o Apple Watch.

La regla general típica que sigo es: escribir algo la primera vez. Si necesito cambiar o reutilizar eso más tarde, es posible que deba extraerlo en su propio método. O tal vez hay una mejor manera de abstraer lo que está tratando de hacer en una clase separada. Una ventaja adicional: ir a ese paso adicional significa que probablemente pueda escribir algunas pruebas unitarias a su alrededor, ya que ahora es probable que funcione de forma aislada.

Por lo tanto, diría que paso mucho tiempo refactorizando mientras codifico. Escribe un poco, ponlo a trabajar, luego refactoriza un poco.

Hay dos razones principales para dividir el código en métodos más pequeños: reutilización y legibilidad. Si está satisfecho, el código es lo suficientemente reutilizable, entonces debería preguntarse si es legible.

Una función legible hace bien una cosa, debería ser fácil de mantener en su cabeza y debería ser posible describir lo que hace en una o dos oraciones.
Filosofía Unix
¿Qué hace que un buen código sea bueno?

Las funciones IMO en lenguajes OO (c #, java) rara vez deben exceder las 50 líneas, y en lenguajes funcionales mucho más cortos, digamos 10 líneas. Mis estándares de codificación dicen “enviar funciones de más de 50 líneas para su revisión”
¿La mejor regla para el tamaño máximo de la función?

Realmente no debería tener que cortar el código existente: en primer lugar, nunca debería haberse alargado.
LAS DIVISORAS SE PUEDEN AGREGAR MÁS FÁCILMENTE QUE LAS EMBARCACIONES SE PUEDEN DIVIDIR

Divídalo en funciones de responsabilidad única para que sea más fácil de leer y depurar. Nunca se sabe lo que sucederá en el futuro. Hay todo tipo de código bruto que decía ‘nunca lo cambiaremos, por lo que está bien que sea un truco’ y luego, años más tarde, necesita hacer un cambio y es difícil depurar y comprender lo que está sucediendo.

Bueno, yo diría que acabo de leer el siguiente libro:
Código limpio: Un manual de artesanía de software ágil: Robert C. Martin: 0000132350882: Amazon.com: Libros