Как профессионально пишутся большие проекты?

[dixlofos]

Когда я только начинал, я думал что самое главное - это знание языка. Вот прошел год с момента моего старта, язык я знаю пускай не на 100%, но вполне сносно, написал с десяток программ и сотню программулинок =).
Когда писал последнюю свою, на данный момент времени, программу то столкнулся с некоторыми проблемами.. саму программу я написал и она работает, но если понадобиться добавить функционала, который сильно отличается от того что заложено архитектурой, то могут возникнуть сильные проблемы, тк автономность работы большинства частей программы практически равна нулю, и дерни одно - рухнет все остальное =)
И вот я спрашиваю как пишутся большие проекты? С чего начинают? Рисуют ли что-то на бумаге, или пишут с ходу только опираясь на опыт?

[riden]

Главное не знание языка (знание языка - это как бы нулевой уровень программиста), а уровень развития абстрактного мышления. Сначало ты можешь запрограммировать любую частную вещь, тогда ты программист. Когда ты можешь переходить к программированию более общих вещей, охватывающих несколько частностей, ты - уже более качественный программист.

[dixlofos]

да это-то понятно, вопрос-то не в этом

[Psycho Tiger]

Вам везёт. Пишу больше 5 лет и вообще нихрена не знаю.

[Bgg]

Вам везёт. Пишу больше 5 лет и вообще нихрена не знаю.

И ты все 5 лет работаешь один?

Я так понимаю вопрос в том как работают несколько flash программистов над одним проектом. Flash программист + серверный + аниматоры/иллюстраторы думаю и так понятно.

[VVall]

Проекты проектируются, программы пишутся.

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

[Котяра]

Для этого и придумали ООП.
Большие проекты я начинаю с разработки в XMind`e или на листочке архитектуры проекта.
Каждую часть стараюсь делать как можно более независимой и инкапсулированной. Сходу продумать архитектуру сложно, особенно если полные требования неизвестны и поэтому лучше проявить излишнюю расширяемость.(лучше перебдеть чем недобдеть)
Модули общаются между собой либо событиями либо по описанному интерфейсу - прямых вызовов стараюсь избегать.
Кроме архитектуры - важны конвенции кодирования и контроль версий.
Я придерживаюсь стандартных конвенций и использую svn.
И ещё - я очень ленивый и перед тем как что-нибудь писать, ищу: а не написано ли это до меня.

[Bgg]

Котяра, а как распределяется работа между программистами? Есть архитектор который пишет основу и он же распределяет работу по написанию модулей? Я не очень понимаю как можно распределить работу равномерно, т.к. все модули могут быть по сложности разные, к тому же пока не написана основа с интерфейсами для модулей, то приступать к написанию тех самых модулей, бессмысленно.

[wvxvw]

Если под большими понимается "энтерпрайз", то смотрите в сторону Ant, Maven, юнит-тестов, автоматического тестирования, всяческую теорию о том, как строятся приложения в этой сфере. Чесно говоря, я не знаю, что именно стоит почитать по этому поводу т.как энтерпрайз сектор во флеше не особо развит... наверняка стоит искать что-то по Java / C# - связаной теории...

[dixlofos]

а UML кто-нить использует?
я книгу счас читаю про него, точнее и про него тоже, стоит ли? Или это все лишняя формализация процесса?

[Котяра]

Котяра, а как распределяется работа между программистами? Есть архитектор который пишет основу и он же распределяет работу по написанию модулей? Я не очень понимаю как можно распределить работу равномерно, т.к. все модули могут быть по сложности разные, к тому же пока не написана основа с интерфейсами для модулей, то приступать к написанию тех самых модулей, бессмысленно.
По разному. В идеале архитектор должен быть - он же часто тимлид комманды.
вопросы распределения и подсчёта сложности - очень не простые вопросы - понимание приходит только с опытом, да и то почти всегда сложность задач будет недооценена в 1.5 раза (даже с учётом, что сложность задач будет недооценена в 1.5 раза)
Модульность как раз и позволяет работать контентщикам (второстепенным и/или внешним программистам) до того пока не сделана основная часть. Продумать архитектуру надо до начала работ, конечно, но это на самом деле не такая уж сложная вещь для опытных программистов - архитектуры они выбирают часто из своего опыта и предпочтений - никаких особых вычислений и просчётов не ведётся при этом.
А вообще способы организации работ хорошо описаны у Макконнелла в Совершенном коде (http://www.ozon.ru/context/detail/id/3159814/), частично у Фаулера в Рефакторинге (http://www.ozon.ru/context/detail/id/1308678/) и много про это написано в Мифическом человеко-месяце (http://www.ozon.ru/context/detail/id/83760/). Также советую книжку "Как пасти Котов (http://www.ozon.ru/context/detail/id/2409500/)"

[Tails]

dixlofos
Если заказчик просит о внесений ранее не огаворенных изменений, тогда - поставте перед ним вопрос об увеличений стоимости и времени проекта. никаких проблем.

[Bgg]

Котяра, спасибо за книги. Начальство уже какой раз пытается сэкономить время и деньги, подсунув мне программиста в "помощь", рассчитывая на то, что если программиста два, то результат будет получен в два раза быстрее :confused:

[Котяра]

Котяра, спасибо за книги. Начальство уже какой раз пытается сэкономить время и деньги, подсунув мне программиста в "помощь", рассчитывая на то, что если программиста два, то результат будет получен в два раза быстрее :confused:
Ну на самом деле они частично правы. Конечно нужно сделать поправку на задачи. Мне 80% времени приходиться делать повторяющиеся, низко квалифицированные действия, которые я с удовольствием бы делегировал другим программистам. Прирост конечно не 2 раза, т.к. нужно будет затратить время на согласование, но всё же есть.
Другое дело, что 2 программиста не сделают в 2 раза быстрее одну задачу, которая сложно поддаётся разбиению.

[Psycho Tiger]

И ты все 5 лет работаешь один?
Нет, не один конечно. Но не всегда квалификация коллег радует.

По теме: если программистов двое, то я бы разбил всё это дело на MVC и отдал написание вьюшек менее квалифицированному программисту. Вьюшки вьюшками, в контроллере ошибка куда опаснее. Где то 10% времени, конечно, уйдет на согласование - но когда два флешера в команде это лучшее решение, я считаю. Конечно, MVC частность, можно перейти и в MVP и вообще просто рассмотреть это дело как просто back-end (опытному) и front-end (менее опытному) с соответствующими ухищрениями, но я думаю, мысль понятна.