G>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
Есть конкретный индусский проект на C#, который надо срочно реанимировать. Ты предлагаешь научиться понимать мысль автора и достраивать систему в рамках его концепций. Давай рассмотрим твое предложение на конкретных примерах.
1) Есть объект. У объекта есть поле IsEmpty типа int. Если IsEmpty == 0 — то объект пустой; если IsEmpty == 1, то объект непустой.
2) Есть метод. void DoSomething(int val). Я придумал тут только название метода; название и состав параметров сохранено оригинальным. Дак вот, этот метод выполняет три совершенно разных действия и то, что именно он будет делать зависит от значения параметра val. Если val == 0, то выполняется первое действие; если val == 1 — второе; а при val == 2 — третье. Естественно, никаких коментариев, документации и т.д. нет. В коде использование метода выглядит так: DoSomething(0); DoSomething(1); DoSomething(2) и т.д.
3) Есть метод GetUserInformation. Этот метод, в зависимости от параметров, либо возвращает информацию о пользователе, либо апдейтит её и возвращает null.
4) Про исключения в этом проекте я уже когда-то писал здесь
Дак вот, ты действительно предлагаешь развивать систему в рамках этих "концепций"?
P.S.: этот проект после "евроремонта" таки удачно ушел в продакшен и теперь от него воняет не так сильно, как сначала. Более того, он даже начал работать!
Здравствуйте, prVovik, Вы писали:
V>Дак вот, ты действительно предлагаешь развивать систему в рамках этих "концепций"?
Вопрос, наверное, насколько сильно развивать. Во-вторых, мне кажется, это скорее не концепции, а культура кодирования (вполне может быть, что некие общие принципы продуманы хорошо, но потом это дело зажило, обросло полипами и завитками и прочее).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: чужой плохой код
От:
Аноним
Дата:
21.11.07 14:46
Оценка:
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Здравствуйте, Аноним, Вы писали: А>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Всем спасибо, что откликнулись, но проблема отпала сама собой: мне этим на старой работе хорошо...
Потому продолжаем в рамках общего развития...
NW>1) В чем заключается необходимость рефакторинга?
большая связность библиотек, запутанность кода, отсутствие саппорта, другие проблемы NW>2) Где те кто этот код писал?
недоступны за давностью лет... многим либам больше 10 лет NW>3) Объем кода?
более 50 мегабайт, библиотек так же больше 50... количество строк я не знаю... NW>4) Его сложность и требования к надежности?
сложность различная, требования наверное к разным либам разные NW>5) Насколько страшный код?
различной страшности... встречается ужасный код с названиями функций на непонятных языках NW>6) Язык\среда разработки?
студия 2005, С++ NW>7) Сколько человек будет работать над этим? Ваша должность там?
2-3, девелопер, тимлид
Re[2]: чужой плохой код
От:
Аноним
Дата:
21.11.07 14:56
Оценка:
Здравствуйте, Gregory Liokumovich, Вы писали:
А>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода? GL>Затея рисковая: GL>если все нормально — то и проблем не будет, а вот если все запущено — то работа превратится в ад, при этом Вас легко могут сделать стрелочником.
GL>Я бы выяснил следующее: GL>1) в доступе ли автор кода
некоторые частей. В основном нет GL>2) есть ли спецификация (если есть — надо посмотреть) и не разъехалась ли она с реальностью
почти нет. GL>3) есть ли автоматизированные тесты, что они покрывают (если есть — надо их смотреть)
почти нет GL>4) есть ли тестеры, которые ее тестили
тестеры, которые тестили некоторые части этого кода. Да и то в составе другой программы GL>5) как код собирается сейчас (может легко оказаться, что программа собиралась на одной машине с супер специфичным окружением, которая давно умерла)
без руля. Должен собираться GL>Четкие ответы на эти вопросы — хороший признак. Невразумительные — плохой.
ответы четкие... только мне не помогают
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
А>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
G>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
Тут это... Меру надо знать
Потому что твой вопрос звучит как
— Меня тут зовут лазить в затопленные канализационные коллекторы, стоит за это браться?
— А ты хочешь научиться лазить по лестницам или нет?
Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду.
У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
Для того, чтоб научиться лазить по лестницам, необязательно проделывать это в течении нескольких месяцев в затопленных коллекторах.
Если, конечно, нет острого желания сделать разгребание дерьма своей основной профессией.
Если есть — тогда, конечно, другое дело, "надо брать", и потом большими буквами в резюме писать: "Работаю исключительно с legacy-кодом, от которого все ваши программисты шарахаются" — оторвут с руками, ассенизаторы всем нужны.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, IT, Вы писали:
IT>>Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности. E>Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией.
Наверное, потому, что в основном новые фичи — это пристегивание нового кода "сбоку", что с очень небольшой вероятностью может сломать уже существующую функциональность — а это обычно всех очень даже устраивает.
При этом вся существующая помойка кода оказывается нетронутой.
А "переписывание всего на Юникод" — это именно переписывание всего, а не просто добавление фичи.
Хотя, конечно, кто как назовет.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
V>Есть конкретный индусский проект на C#, который надо срочно реанимировать. Ты предлагаешь научиться понимать мысль автора и достраивать систему в рамках его концепций. Давай рассмотрим твое предложение на конкретных примерах.
Индусский проект != произвольный чужой проект.
V>Дак вот, ты действительно предлагаешь развивать систему в рамках этих "концепций"?
Херовый стиль кодирования != концепции.
V>P.S.: этот проект после "евроремонта" таки удачно ушел в продакшен и теперь от него воняет не так сильно, как сначала. Более того, он даже начал работать!
Ты все таки не выбросил его, и не переписал его с нуля, а заставил его работать серией переделок. Этого не надо уметь делать? Это не есть отдельный навык? На это разве не требуется более высокая квалификация, чем просто выкинуть этот код, и написать собственный кусок дерьма?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, Аноним, Вы писали:
А>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>>>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
G>>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
J>Тут это... Меру надо знать
J>Потому что твой вопрос звучит как J>- Меня тут зовут лазить в затопленные канализационные коллекторы, стоит за это браться? J>- А ты хочешь научиться лазить по лестницам или нет?
Вопрос автора: А>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
При чем тут "канализации"? Я ничего подобного не вижу — обычная характеристика кода, который имеет возраст и писался большим количеством людей. ВСЕ большие проекты с возрастом выглядят примерно так.
J>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду.
Я в посте автора не видел ничего про малограмотных кодеров. Более того,
1) Малограмотные кодеры не смогут написать большую работоспособную систему в любом случае. Это миф.
2) Твой собственный код будет казаться помойкой другому "малограмотному кодеру", не умеющему работать с чужим кодом. На мой взгляд, такая позиция — симптом неумения работать с чужим кодом, не более того.
J>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были.
Здравствуйте, Gaperton, Вы писали:
G>Вопрос автора: А>>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
Сабж автора: "чужой _плохой_ код".
G>При чем тут "канализации"? Я ничего подобного не вижу — обычная характеристика кода, который имеет возраст и писался большим количеством людей. ВСЕ большие проекты с возрастом выглядят примерно так.
Дьявол — в деталях, в данном случае — в слове "примерно".
Если ты один и тот же проект отдашь лет на пять квалифицированным программистам и индусокодерам с плохим менеджером над ними — "примерно" по прошествии этих пяти лет будет _очень_ разным.
J>>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду.
G>Я в посте автора не видел ничего про малограмотных кодеров. Более того, G>1) Малограмотные кодеры не смогут написать большую работоспособную систему в любом случае. Это миф.
Зато малограмотные кодеры отлично могут поддерживать изначально вменяемый продукт и за несколько лет превратить его в помойку.
Очень, кстати, распространенная практика: сначала хорошие программеры пишут ядро, а потом остаются одни индусы.
G>2) Твой собственный код будет казаться помойкой другому "малограмотному кодеру", не умеющему работать с чужим кодом. На мой взгляд, такая позиция — симптом неумения работать с чужим кодом, не более того.
Я не очень понимаю, как нежелание работать с плохим кодом связано со способностью работать с чужим кодом, в том числе и с плохим. Это во-первых.
А во-вторых, я не очень понимаю, зачем для того, чтобы научиться работать с чужим кодом, надо обязательно садиться на саппорт древнего проекта, когда практический любой проект, в котором разработчиков больше одного, предполагает эту самую работу с чужим кодом.
J>>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
G>У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были.
Ну я очень рад за тебя и твоих программистов
У меня вот были (и есть) и примеры, которые я описал, и о которых ты говоришь.
Здравствуйте, Gaperton, Вы писали:
G>Индусский проект != произвольный чужой проект. G>Херовый стиль кодирования != концепции.
зато "Индусский проект" + "Херовый стиль кодирования" = отвращение к работе и мысли о самоубийстве.
V>>P.S.: этот проект после "евроремонта" таки удачно ушел в продакшен и теперь от него воняет не так сильно, как сначала. Более того, он даже начал работать!
G>Ты все таки не выбросил его, и не переписал его с нуля, а заставил его работать серией переделок. Этого не надо уметь делать? Это не есть отдельный навык?
Это, вообще-то, базовый навык.
Если этого навыка нет — такому вообще в программизме не место.
G>На это разве не требуется более высокая квалификация, чем просто выкинуть этот код, и написать собственный кусок дерьма?
Нет, не требуется, ибо это базовый навык.
Посадить на поддержку можно любого индуса, и он copy-paste-ом пофиксит тебе любые баги, и все будет приемлемо работать и тебя во всех отношениях удовлетворит, пока ты в код не заглянешь.
А вот если ты посадишь этого же индуса наваять новый проект с нуля, т.е. сформулировать и отранжировать требования, спроектировать и закодить, причем так, чтобы обеспечить высокий уровень поддерживаемости — вот на это нужна очень высокая квалификация.
Здравствуйте, jazzer, Вы писали:
G>>Вопрос автора: А>>>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
J>Сабж автора: "чужой _плохой_ код".
G>>При чем тут "канализации"? Я ничего подобного не вижу — обычная характеристика кода, который имеет возраст и писался большим количеством людей. ВСЕ большие проекты с возрастом выглядят примерно так.
J>Дьявол — в деталях, в данном случае — в слове "примерно". J>Если ты один и тот же проект отдашь лет на пять квалифицированным программистам и индусокодерам с плохим менеджером над ними — "примерно" по прошествии этих пяти лет будет _очень_ разным.
Я не заметил в посте автора упоминания индусокодеров, извини. Знаешь, почему? Потому, что его там нет. Все, чего там нет — ты додумал сам. Спорить с этим я не буду.
G>>У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были. J>Ну я очень рад за тебя и твоих программистов J>У меня вот были (и есть) и примеры, которые я описал, и о которых ты говоришь.
Здравствуйте, jazzer, Вы писали:
J>А вот если ты посадишь этого же индуса наваять новый проект с нуля, т.е. сформулировать и отранжировать требования, спроектировать и закодить, причем так, чтобы обеспечить высокий уровень поддерживаемости — вот на это нужна очень высокая квалификация.
Не согласен. Да, чтобы написать с нуля — нужна высокая квалификация.
А чтобы отрефакторить готовое — еще выше. Тебе же надо делать все тоже самое, что и в первом случае, но с учетом ограничений, которые на тебя наложила предыдущая реализация — гораздо более ювелирная работа.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, jazzer, Вы писали:
J>>А вот если ты посадишь этого же индуса наваять новый проект с нуля, т.е. сформулировать и отранжировать требования, спроектировать и закодить, причем так, чтобы обеспечить высокий уровень поддерживаемости — вот на это нужна очень высокая квалификация.
DAS> Не согласен. Да, чтобы написать с нуля — нужна высокая квалификация. DAS> А чтобы отрефакторить готовое — еще выше. Тебе же надо делать все тоже самое, что и в первом случае, но с учетом ограничений, которые на тебя наложила предыдущая реализация — гораздо более ювелирная работа.
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Рефакторинг это процесс перехода из одного состояния в другое без изменения внешнего поведения. Прям в определении все пункты:
1) "из одного состояния" — оцени старое значить. возми метрики (профайлы, оцени по смеллам, возми тулзы)
2) "новое состояние" — пойми что ты хочешь, прибрось будущую систему, оцени её
3) "без изменения внешнего" — обложись тестами. два вариант либо всё — но это сказка, либо места хирургического вмешательства.
4) примени безопасную технику рефакторинга.
п.4 — для реинженеринга (не путать рефакторинг крупных вещей называется реинженеринг)
Нюансы:
1. Косвенно сужу, что система слишком связанная (раз не было тестов) — это хреново
2. Реинженеринг это целый waterfall, он должен аккуратно планироваться и выполнятся
3. Если у вас команда первым делом нужно привести порядок в головах разработчиков
4. Нужно разработать внутрикомандное взаимодействие и выработка общей стратегии
5. Жри слона по частям.
А лучше позвать спецов, которые помогут вам провести это
Например меня.
Здравствуйте, Gaperton, Вы писали:
J>>Сабж автора: "чужой _плохой_ код".
G>Я не заметил в посте автора упоминания индусокодеров, извини. Знаешь, почему? Потому, что его там нет. Все, чего там нет — ты додумал сам. Спорить с этим я не буду.
там было упоминание плохого кода.
плохой код у нас обычно производится индусокодерами (независимо от национальности, потому что в моей команде по крайней мере один этнический индус — очень толковый парень) или как хочешь их обзови
Ты тоже додумал сам, что там есть концепции и прочая, а там может оказаться 20 мегабайт тупого копи-пейста.
G>>>У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были. J>>Ну я очень рад за тебя и твоих программистов J>>У меня вот были (и есть) и примеры, которые я описал, и о которых ты говоришь. G>Сочувствую.
Наверное, в этом и разница.
Тебе, видимо, сплошь попадались проекты, в которых насквозь была архитектура и концепции, и там действительно можно было чему-то научиться, а мне зачастую — маленькое-маленькое ядро, в котором действительно есть концепции и дизайн, а вокруг — гора тупейшего копипейста и кода в стиле java+basic=c++, естественно, никак не комментированного (как со стороны кода, так и со стороны задач, которые должны этим кодов исполняться) и с недоступными разработчиками. И те пафосые слова, которые ты говорил ("понять мысль и концепцию автора и следовать им" и т.д.) в реальности выливается в то, что ты убиваешь добрую неделю на то, чтобы осознать, что _никакой_ концепции и _никаких_ мыслей в голове автора не было вообще, было только желание сделать тяп-ляп и пойти пить пиво.
И процесс этот выглядит обычно так: ага, тут, наверное, автор просто скопипейстил эту девятистраничную функцию и поменял в ней а на б, а тут другой автор скопипейстил из второй и поменял б на в и г на д (надо бы следовать замыслу автора, т.е. заняться тем же копи-пейстом, да?) и в результате мы имеем полтора десятка функций, которые, вроде бы, делают одно и то же, но результаты все выдают разные, и ты понятия не имеешь, которая же из них работает правильно, потому что когда от юзера приходил баг-репорт, правилась только одна из этих функций (потому что именно она зовется из того места, на которое напоролся юзер) или вообще отпочковывалась еще одна, потому что исходная зовется еще из кучи мест — не дай бог ведь сломаешь, поэтому в коде появляется скопипейсченная функция специально для кнопки А, которую нажал юзер, а для всех остальных мест — остается старая функция, но ты-то об этом не знаешь и думаешь, что запрос от юзера был изменить поведение именно кнопки А, и что _все_ функции работают правильно, просто вот в этом месте нужно исключение.
Я думаю, ни один человек в здравом уме добровольно за копание в горе мусора в течение нескольких лет не возьмется и другому советовать пойти поплавать в подобном водоеме не будет, разве что кровному врагу.
Тем более делать это такими пафосными словами, что это, мол, единственный путь научиться работать с чужим кодом.
J>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду. J>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
Не факт, что это плохо. "Вкус к хорошему коду", во-первых, субъективен, во-вторых, следование ему тратит время ужасным образом.
J>Если есть — тогда, конечно, другое дело, "надо брать", и потом большими буквами в резюме писать: "Работаю исключительно с legacy-кодом, от которого все ваши программисты шарахаются" — оторвут с руками, ассенизаторы всем нужны.
Ага. Ремонт чего-то в канализации — дело востребованное, реальное, оплачиваемое, а вот маниловские мечты о прекрасном коде — не всегда.
Кстати, это не обязательно legacy код. Legacy — это то, что подлежит переделке, но очень осторожной, ибо оно работает. Старый код — не обязательно legacy, там далеко не все нуждается в переделке.
MSS>Кстати, это не обязательно legacy код. Legacy — это то, что подлежит переделке, но очень осторожной, ибо оно работает. Старый код — не обязательно legacy, там далеко не все нуждается в переделке.
Макс, а как тебе такое определение легаси кода.
Легаси код — это код написанный (может и недавно) предыдущей командой, из которой почти никого не осталось
DM>Легаси код — это код написанный (может и недавно) предыдущей командой, из которой почти никого не осталось
Определить в общем можно как угодно, но для меня слово legacy стоит где-то рядом со словом obsolete. То, что будет подвергаться тотальной переделке в обозримом будущем.
Если код не планируется весь глубоко рефакторить — то зачем его называть legacy?
Здравствуйте, Maxim S. Shatskih, Вы писали:
J>>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду. J>>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
MSS>Не факт, что это плохо. "Вкус к хорошему коду", во-первых, субъективен, во-вторых, следование ему тратит время ужасным образом.
Вообще говоря, это неверно. Точнее, про написание ничего не могу сказать, хотя тоже есть подозрение, а вот исправление "хорошего кода" занимает заметно меньше времени, чем "плохого".
NW>>5) Насколько страшный код? А>различной страшности... встречается ужасный код с названиями функций на непонятных языках NW>>6) Язык\среда разработки? А>студия 2005, С++ NW>>7) Сколько человек будет работать над этим? Ваша должность там? А>2-3, девелопер, тимлид
Знаешь, почему? Потому, что его там нет. Все, чего там нет — ты додумал сам. Спорить с этим я не буду.
