История изменений

Чтобы делать сверху вниз, нужна команда. В одиночку у тебя скорее всего быстро пропадёт задор, потому что делать «правильно» — рутинно и утомительно.

Ещё из наблюдений, разработка сверху вниз склонна наделить систему мнимой «гибкостью» тогда как в действительности опирается на множество допущений и предположений. В результате небольшое изменение функциональных требований выливается в рефакторинг всего на свете или неописуемые костыли (или и то и другое).

Я предпочитаю, чтобы новые проекты начинались в одно лицо и снизу вверх. В течение жизни проекта, его требования будут уточняться и пересматриваться, будут меняться условия по производительности. Куски кода, не обмазанные надмозговой «архитектурой», проще перепилить и переиспользовать. В конечном счете со временем это плавно перетекает в подход сверху-вниз.

С другой стороны, верно и обратное. Неопытный разработчик снизу вверх напишет так, что проще переписать с нуля. Поэтому ему лучше учиться в команде и ковырять сверху вниз, что скажут.

Чтобы делать сверху вниз, нужна команда. В одиночку у тебя скорее всего быстро пропадёт задор, потому что делать «правильно» — рутинно и утомительно.

Ещё из наблюдений, разработка сверху вниз склонна наделить систему мнимой «гибкостью» тогда как в действительности опирается на множество допущений и предположений. В результате небольшое изменение функциональных требований выливается в рефакторинг всего на свете или неописуемыми костылями (или и то и другое).

Я предпочитаю, чтобы новые проекты начинались в одно лицо и снизу вверх. В течение жизни проекта, его требования будут уточняться и пересматриваться, будут меняться условия по производительности. Куски кода, не обмазанные надмозговой «архитектурой», проще перепилить и переиспользовать. В конечном счете со временем это плавно перетекает в подход сверху-вниз.

С другой стороны, верно и обратное. Неопытный разработчик снизу вверх напишет так, что проще переписать с нуля. Поэтому ему лучше учиться в команде и ковырять сверху вниз, что скажут.