История изменений
Исправление slackwarrior, (текущая версия) :
выбираешь цель, дробишь задачу до уровня «так тут уже почти и кодить нечего, всё очевидно», реализуешь на известном тебе ЯП.
Не все задачи можно и нужно дробить в пыль. Эта дичь приводит к потерям времени на скедуляние задач, когда люди не в теме пытаются слишком декомпозировать — в итоге можно устать, объясняя что у компонента нельзя отделить разметку от логики так чтоб девелоперы не толкались локтями, и один компонент должен разрабатывать один человек целиком. Можно делить компоненты на компоненты, но компоненты на разметку и логику делить бессмысленно.
Я не понимаю, например, как и куда применять ООП, чтобы это было полезно и осмысленно. Ну кроме очевидных элементов GUI и каких-нибудь юнитов в играх.
ООП нужно не всегда :) компонентная модель эквивалентна, например, и обходится без развесистого наследования.
Исправление slackwarrior, :
выбираешь цель, дробишь задачу до уровня «так тут уже почти и кодить нечего, всё очевидно», реализуешь на известном тебе ЯП.
Не все задачи можно и нужно дробить в пыль. Эта дичь приводит к потерям времени на скедуляние задач, когда люди не в теме пытаются слишком декомпозировать — в итоге можно устать, объясняя что у компонента нельзя отделить разметку от логики так чтоб девелоперы не толкались локтями, и один компонент должен разрабатывать один человек целиком. Можно делить компоненты на компоненты, но компоненты на разметку и логику делить бессмысленно.
Исходная версия slackwarrior, :
Не все задачи можно и нужно дробить в пыль. Эта дичь приводит к потерям времени на скедуляние задач, когда люди не в теме пытаются слишком декомпозировать — в итоге можно устать, объясняя что у компонента нельзя отделить разметку от логики так чтоб девелоперы не толкались локтями, и один компонент должен разрабатывать один человек целиком. Можно делить компоненты на компоненты, но компоненты на разметку и логику делить бессмысленно.