Здравствуйте, -Cheese-, Вы писали:
C>В качестве технологии скорее всего будет .Net, поэтому если есть книги с упором на это, то хорошо (хотя в принципе это должна быть общая теория).
сразу начинать проектировать сложно, лучше потратить время на чтение литературы, и обдумывать прочитанное в контексте проекта.
Мартин Фаулер, "Архитектура корпоративных программных приложений".
Гамма "Приемы объектно-ориентированного программирования. Паттерны проектирования".
Мартин Фаулер "Рефакторинг. Улучшение существующего кода". Скачать программный продукт NUnit и попробовать его в деле.
Непосредственно по дотнеут лучше читать Джеффри Рихтер "Программирование на платформе Microsoft.NET FRAMEWORK"
Чарльз Петцольд Программирование для Microsoft WINDOWS на С#
Здравствуйте, -Cheese-, Вы писали:
I>>Мартин Фаулер, "Архитектура корпоративных программных приложений". C>Пришёл с обеда с этой книгой... значится с неё и начнём
Из это же серии вот еще эта книжка
Здравствуйте, Thanatos, Вы писали:
C>>>>Предстоит разработка достаточно крупной системы. Опыта такого нет. C>>>>Посоветуйте плиз хорошие книги по разработке, проектированию сложных систем.
T>>>Лучше уж и не начинанать... C>>Почему? Всё когда-то делается в первый раз.
T>Оно-то делается, но первый блин чаще всего комом. T>Не лучше ли найти нанять опытного архитектора?
Здравствуйте, -Cheese-, Вы писали:
A>>судя по вопросам, тебе нужно покодить пару лет. A>>а потом уже прыгать в тимлиды или архитекторы C>Re[3]: Сложная система. Книги.
Всем привет.
Предстоит разработка достаточно крупной системы. Опыта такого нет.
Посоветуйте плиз хорошие книги по разработке, проектированию сложных систем.
Будет множество модулей, постоянно чё-то будет дописываться, добавляться и т.д. Чтоб не запутаться во всём этом, чтоб оно между собой ещё нормально взаимодействовало, можно было расширять и чтоб оно не падало
В качестве технологии скорее всего будет .Net, поэтому если есть книги с упором на это, то хорошо (хотя в принципе это должна быть общая теория).
Здравствуйте, -Cheese-, Вы писали:
C>Всем привет. C>Предстоит разработка достаточно крупной системы. Опыта такого нет. C>Посоветуйте плиз хорошие книги по разработке, проектированию сложных систем. C>Будет множество модулей, постоянно чё-то будет дописываться, добавляться и т.д. Чтоб не запутаться во всём этом, чтоб оно между собой ещё нормально взаимодействовало, можно было расширять и чтоб оно не падало C>В качестве технологии скорее всего будет .Net, поэтому если есть книги с упором на это, то хорошо (хотя в принципе это должна быть общая теория).
Эдвард Йордан
«Смертельный марш»
Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах
Шутка
В принципе, если цель только поучиться за бабки заказчика, то нормальный подход — почитать умных книжек и в бой. Но в книжках пишут далеко не все и не так, как случается в жизни. Так что, если цель сделать работающую систему, то лучше привлечь людей умеющих организовывать процесс разработки и имеющих опыт создания сложных систем. Посмотрев что и как делают они, можно начинать делать самому.
Да... забыл сказать
Так как разработчиков будет несколько, то киньте плиз ещё полезные книжки для организации работы в комманде.
Интересует такие вещи как сохранение кода, складывание в одно место актуальных исходников.... и т.д..
Здравствуйте, -Cheese-, Вы писали:
C>Предстоит разработка достаточно крупной системы. Опыта такого нет. C>Посоветуйте плиз хорошие книги по разработке, проектированию сложных систем.
Лучше уж и не начинанать...
Лучший дар, который мы получили от природы и который лишает нас всякого права жаловаться – это возможность сбежать. /М.Монтень/
Здравствуйте, Thanatos, Вы писали:
T>Здравствуйте, -Cheese-, Вы писали:
C>>Предстоит разработка достаточно крупной системы. Опыта такого нет. C>>Посоветуйте плиз хорошие книги по разработке, проектированию сложных систем.
T>Лучше уж и не начинанать...
Почему? Всё когда-то делается в первый раз.
Хочется не наступать на грабли, на которые уже наступили другие...
Здравствуйте, -Cheese-, Вы писали:
C>>>Предстоит разработка достаточно крупной системы. Опыта такого нет. C>>>Посоветуйте плиз хорошие книги по разработке, проектированию сложных систем.
T>>Лучше уж и не начинанать... C>Почему? Всё когда-то делается в первый раз.
Оно-то делается, но первый блин чаще всего комом.
Не лучше ли найти нанять опытного архитектора?
Лучший дар, который мы получили от природы и который лишает нас всякого права жаловаться – это возможность сбежать. /М.Монтень/
Здравствуйте, ingenero, Вы писали:
I>сразу начинать проектировать сложно, лучше потратить время на чтение литературы, и обдумывать прочитанное в контексте проекта.
сразу кодить и не будем — сначала читать
I>Мартин Фаулер, "Архитектура корпоративных программных приложений".
Пришёл с обеда с этой книгой... значится с неё и начнём
I>Гамма "Приемы объектно-ориентированного программирования. Паттерны проектирования". I>Мартин Фаулер "Рефакторинг. Улучшение существующего кода". Скачать программный продукт NUnit и попробовать его в деле.
I>Непосредственно по дотнеут лучше читать Джеффри Рихтер "Программирование на платформе Microsoft.NET FRAMEWORK" I>Чарльз Петцольд Программирование для Microsoft WINDOWS на С#
I>Удачи Это начало ооочень длинного пути
Спасибо.
и если "Архитектура корпоративных программных приложений" — это замечательно для понимания какими абстракциями проектировать вне зависимости от прикладной области, то вот из "Reusable Object Models" можно брать готовые *прикладные* решения.
-Cheese- пишет: > > Предстоит разработка достаточно крупной системы. Опыта такого нет. > Посоветуйте плиз хорошие книги по разработке, проектированию сложных систем. > Будет множество модулей, постоянно чё-то будет дописываться, добавляться > и т.д. Чтоб не запутаться во всём этом, чтоб оно между собой ещё > нормально взаимодействовало, можно было расширять и чтоб оно не падало
А вообще, как практический совет, книги оные читать для лучшего
засыпания .
А разрабатывать систему исходя из простого правила: все модули системы
должны быть минимально зависимы и иметь максимально простой интерфейс. В
общем правило, эффективно используемое очень давно "разделяй и властвуй."
Да и еще не пытаться предугадать будущее.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
(c) из подписи Anatolix-а
Лучший дар, который мы получили от природы и который лишает нас всякого права жаловаться – это возможность сбежать. /М.Монтень/
Здравствуйте, -Cheese-, Вы писали:
C>Да... забыл сказать C>Так как разработчиков будет несколько, то киньте плиз ещё полезные книжки для организации работы в комманде. C>Интересует такие вещи как сохранение кода, складывание в одно место актуальных исходников.... и т.д..
Если вы задаете такие вопросы, то вам действительно лучше не начинать заниматься этим проектом... Правильный совет дали — нанять толковых людей.
Но видимо вам это не подходит. Интересно почему?
Здравствуйте, vb-develop, Вы писали:
VD>Если вы задаете такие вопросы, то вам действительно лучше не начинать заниматься этим проектом... Правильный совет дали — нанять толковых людей. VD>Но видимо вам это не подходит. Интересно почему?
А что? Толковыми архитекторами сразу рождаются? Вы прямо так в штыки всё воспринимаете....
Просто до этого момента работал один над своими проектами... и не могу сказать, что всё было плохо.
К тому же понятие "Сложная система" относительно.
Хотя бы относительно вашего и моего понимания. Может по вашим меркам это просто крошечное приложеньицичье
Thanatos пишет: > > Разделяй, говоришь... > > Любая проблема дизайна может быть решена введением дополнительного > абстрактного слоя, за исключением проблемы слишком большого количества > дополнительных абстрактных слоев
Ну ладно, тогда добавлю еще одно правило, пожалуй ключевое, ЛЕНЬ.
Здравствуйте, -Cheese-, Вы писали:
C>К тому же понятие "Сложная система" относительно. C>Хотя бы относительно вашего и моего понимания. Может по вашим меркам это просто крошечное приложеньицичье
Почему-то засела в голове фраза из к/ф "Москва слезам не верит":
"Трудно научиться управлять тремя, а после трёх кол-во значения уже не имеет"
C>Так как разработчиков будет несколько, то киньте плиз ещё полезные книжки для организации работы в комманде. C>Интересует такие вещи как сохранение кода, складывание в одно место актуальных исходников.... и т.д..
судя по вопросам, тебе нужно покодить пару лет.
а потом уже прыгать в тимлиды или архитекторы
C>В качестве технологии скорее всего будет .Net, поэтому если есть книги с упором на это, то хорошо (хотя в принципе это должна быть общая теория).
без практики это все равно что учиться готовить не имея плиты и продуктов под рукой.
ну разве что прочитать все книжки из серии "подготовка к экзамену MCSD", проделать все упражнения,
и сдать экзамены (не по брейндампам!)
Здравствуйте, Awaken, Вы писали:
A>судя по вопросам, тебе нужно покодить пару лет. A>а потом уже прыгать в тимлиды или архитекторы Re[3]: Сложная система. Книги.
Здравствуйте, vitalyk, Вы писали: >Кроме того, обычно именно эти вещи "постигаются" опытным путем (т.е. работой в составе команды разработчиков), а не чтением книжек.
А как этот опыт получить?
И если нету и не предвидится команды разработчиков никакой другой, кроме предполагаемой?
Чем плох такой метод обучения, как бросание в "горячую точку"?
Т.е. из книжек вообще ничего научиться нельзя?
P.s.: ПО для атомной станции я писать не собираюсь
C>А как этот опыт получить? C>И если нету и не предвидится команды разработчиков никакой другой, кроме предполагаемой? C>Чем плох такой метод обучения, как бросание в "горячую точку"?
тебе стоит поработать в опытной команде. для прогресса в карьере иногда стоит сменить место работы
Здравствуйте, -Cheese-, Вы писали: C>А как этот опыт получить?
На форумах задаются узконаправленные вопросы и в соответствующих теме форума.
Реакция на на просьбы "научите меня всему обо всём" на любом форуме будет предопределёна.
Помимо того, что Вы свалили в одну кучу вопросы из разных направлений (а не тем),
как "Getting Starting", "System Administration", "Project management", etc.,
ни один из них вообще-то не имеет отношение к этому форуму "О Работе"
(который я понимаю, как форум об отношениях работник-работодатель или заказчик-исполнитель)
Здравствуйте, Awaken, Вы писали:
C>>А как этот опыт получить? C>>И если нету и не предвидится команды разработчиков никакой другой, кроме предполагаемой? C>>Чем плох такой метод обучения, как бросание в "горячую точку"?
A>тебе стоит поработать в опытной команде. для прогресса в карьере иногда стоит сменить место работы
+1
Работая над проектами в одиночку, никогда не узнаешь, что такое работа в команде, и точно не сможешь организовать (во всяком случае первый блин будет комом). Хотя, работа над проектам в одиночку конечно не повредит.
Здравствуйте, Геннадий Ванин, Вы писали:
ГВ>как "Getting Starting"
Любое движение в сторону от того, что делал раньше, можно рассматривать как "Getting Starting"....
ГВ>"System Administration",
это где такое я просил....
ГВ>"Project management", etc.,
тут согласен
ГВ>ни один из них вообще-то не имеет отношение к этому форуму "О Работе" ГВ>(который я понимаю, как форум об отношениях работник-работодатель или заказчик-исполнитель)
какой выриант выбрали бы вы?
Здравствуйте, -Cheese-, Вы писали:
ГВ>>"System Administration", C>это где такое я просил....
Не хочется всё перечитывать, но была просьба поделиться о складывании исходников,
контроле версий (?)
Техобеспечение работы в проекте, как то:
— файл-серверы
— серверы контроля версий
— bugzilla
— wiki
— инсталляции, конфигурации
— сервера
— др
делегируются сисадминам.
Раз Вы возжелали .NET,
которое я могу только горячо восприветствовать,
то всё довольно централизированно обеспечивается
MS Visual Studio .NET Team Edition
C>какой выриант выбрали бы вы?
Для корпоративных (конфиденциальных) блогов и форумов,
мануалов, обменов опытом (трюками) кодирования,
тел и Email списков, чтобы отделы могли посмотреть,
чем заняты коллеги (планы, намерения), фотографий с корпоративных попоек
Чтобы не рассылать анекдоты по внутрикорпоративному Email
VD>+1 VD>Работая над проектами в одиночку, никогда не узнаешь, что такое работа в команде, и точно не сможешь организовать (во всяком случае первый блин будет комом). Хотя, работа над проектам в одиночку конечно не повредит.
тут есть плюсы и минусы.
работать в одиночку легче когда уже есть опыт командной работы.
иначе бывает что прививаются плохие привычки (связанные с тем что "код весь мой", поэтому необходимости
писать его так чтобы и другие могли сопровождать, как-бы не видно)
Это начало ооочень длинного пути 
Автор(ы): Грегор Хоп, Бобби Вульф
Кроме того, обычно именно эти вещи "постигаются" опытным путем (т.е. работой в составе команды разработчиков), а не чтением книжек.
