M_T>UML диаграммы действительно не нужны, но я бы предпочел видеть рабочий, понятный, протестированный, и легко поддерживаемый код а не кусок не понятно чего.

Все и сразу?

Да вы батенька фантазер.

M_T>Качество кода это один из важнейших факторов в оценки кода. Давно известно что собственно разработка эта самая дешевая часть она берет не больше 30% ресурсов которые тратятся на проект в течение жизни проекта после этого идет поддержка которая занимает уже 70% ресурсов а иногда и больше. Чем качественнее будет код, тем дешевле его будет поддерживать, тем дешевле будет конечная цена проекта.

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

Так что в предлагаемом вами варианте речь идет скорее не о том чтобы заработать больше, а о том чтобы не заработать вовсе.

M_T>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.

M_T>

M_T>picture.Width((r+1)*2);
M_T>picture.Height((r+1)*2);
M_T>Map.SetOffset(r);
M_T>for(i=1; i<Picture.Width(); i++)
M_T>    for(j=1; j<Picture.Height(); j++) 
M_T>        if(My_Bitmap.PixelIsBlack(i,j))
M_T>                  Map.SetTileVisability(j,i,2)
M_T>

Ну вот и 3 версия "правильного кода".

А что следующий программист скажет?)

Здравствуйте, Apostate, Вы писали:

M_T>>UML диаграммы действительно не нужны, но я бы предпочел видеть рабочий, понятный, протестированный, и легко поддерживаемый код а не кусок не понятно чего.

A>Все и сразу?

A>Да вы батенька фантазер.

Я не фантазер, все дело в правильной методологии есть методологии тяжелые и медленные где нужно писать кучу документации продумывать досконально дизайн рисовать диаграммы. А есть быстрые где дизайн минимальный и большая часть времени это собственно кодированье но кодированье правильное
которое дает тот результат, о котором я написал.

A>Ну да, но еще также очень хорошо известно что на рынке остаются в основном те продукты которые успели в приемлемые сроки выпустить первые работоспособные версии. А вовсе не те у которых поддержка дешевле.
A>Так что в предлагаемом вами варианте речь идет скорее не о том чтобы заработать больше, а о том чтобы не заработать вовсе.

Ну давайте посмотрим на Нетскеип к примеру им был произведен революционный продукт не имеющий аналогов.
Который занимал 80-90 процентов рынка.И где он сейчас ? Он не смог конкурировать с МС в основном из-за того
что код его был написан в стиле приведенным выше. Добавка новой функциональности или починка багов занимала
столько времени что продукт не смог оставаться конкурентно способным. В конце пришлось его просто выкинуть
и писать все заново но поезд уже ушел.

M_T>>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.

M_T>>

M_T>>picture.Width((r+1)*2);
M_T>>picture.Height((r+1)*2);
M_T>>Map.SetOffset(r);
M_T>>for(i=1; i<Picture.Width(); i++)
M_T>>    for(j=1; j<Picture.Height(); j++) 
M_T>>        if(My_Bitmap.PixelIsBlack(i,j))
M_T>>                  Map.SetTileVisability(j,i,2)
M_T>>

A>Ну вот и 3 версия "правильного кода".

A>А что следующий программист скажет?)

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

M_T>Я не фантазер, все дело в правильной методологии есть методологии тяжелые и медленные где нужно писать кучу документации продумывать досконально дизайн рисовать диаграммы. А есть быстрые где дизайн минимальный и большая часть времени это собственно кодированье но кодированье правильное
M_T>которое дает тот результат, о котором я написал.

А что за методологии?

M_T>Ну давайте посмотрим на Нетскеип к примеру им был произведен революционный продукт не имеющий аналогов.
M_T>Который занимал 80-90 процентов рынка.И где он сейчас ? Он не смог конкурировать с МС в основном из-за того
M_T>что код его был написан в стиле приведенным выше. Добавка новой функциональности или починка багов занимала
M_T>столько времени что продукт не смог оставаться конкурентно способным. В конце пришлось его просто выкинуть
M_T>и писать все заново но поезд уже ушел.

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

M_T>>>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.

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

Ну именно то что он бесконечный. Поэтому качество кода это вопрос стадии поддержка кода — в масштабе жизни проекта бесконечна. А не стадии его создания — конечная. Ошибка это пытатся засунуть бесконечное в конечное — пускай пишут как получается, после исправим если понадобится, по-моему это в некотором роде один из постулатов XP.

Здравствуйте, Apostate, Вы писали:

M_T>>Я не фантазер, все дело в правильной методологии есть методологии тяжелые и медленные где нужно писать кучу документации продумывать досконально дизайн рисовать диаграммы. А есть быстрые где дизайн минимальный и большая часть времени это собственно кодированье но кодированье правильное
M_T>>которое дает тот результат, о котором я написал.

A>А что за методологии?

Самая популярная XP о который вы уже сказали, но о которой помойму знаете крайне мало.

A>Ну я ж говорю как правило.

У вас не правельное правило.

A>Все можно преодолеть, вопрос сколько это будет стоить. Например, надо быть монополистом в этом классе операционных систем, плюс отдавать свой продукт бесплатно.

Нетскеип в конечно счете проиграл по функциональносте. До тех пор пока он был функциональнее IE ему удавалось держать сильные позиции не смотря на все ухешрения отдела маркетинга МС.

M_T>>>>Вообще если следовать заветам Рефакторинга то код, в конечном счете, будет выглядеть примерно вот так.

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

A>Ну именно то что он бесконечный. Поэтому качество кода это вопрос стадии поддержка кода — в масштабе жизни проекта бесконечна. А не стадии его создания — конечная.

Бесконечность начинаеться с нуля тоесть с того времени когда написали первую строчку кода.
XP пытаеться как можно быстрее превести проект к стадии подержки кода.

A> Ошибка это пытатся засунуть бесконечное в конечное — пускай пишут как получается, после исправим если понадобится, по-моему это в некотором роде один из постулатов XP.

В некотором роде действительно да, только не в том роде как вы написали а в том как я написал.
Цикл написания кода в ХП это Тестированье->Кодированье->Рефакторинг.

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

M_T>Самая популярная XP о который вы уже сказали, но о которой помойму знаете крайне мало.

Да нет.

M_T>У вас не правельное правило.

Правильное.

M_T>Нетскеип в конечно счете проиграл по функциональносте. До тех пор пока он был функциональнее IE ему удавалось держать сильные позиции не смотря на все ухешрения отдела маркетинга МС.

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

M_T>В некотором роде действительно да, только не в том роде как вы написали

это перл!

M_T> а в том как я написал.

-) а я раньше

Здравствуйте, Apostate, Вы писали:

A>Да нет.

Помойму все-таки да

M_T>>Нетскеип в конечно счете проиграл по функциональносте. До тех пор пока он был функциональнее IE ему удавалось держать сильные позиции не смотря на все ухешрения отдела маркетинга МС.

A>Ну-ну. Не буду спорить просто не соглашусь с тем какой именно фактор был первичным, определяющим, важным. Я считаю, если бы не 'ухешрения' что выше, об этой новой функциональности массовый пользователь даже не узнал, а узнал бы то не стал бы ее юзать. Опять же повторюсь что уверен на 100% и именно поэтому спорить не буду .

Я в свое время был убежденым нетскейпшиком но с определеного момента IE просто стал луче и удобнее и я стал пользоваться им.


M_T>> а в том как я написал.

A>-) а я раньше

Вы описали совершено неверное понимание принципов ХП.

M_T>Я в свое время был убежденым нетскейпшиком но с определеного момента IE просто стал луче и удобнее и я стал пользоваться им.

Это ты. А я говорил о массовом пользователе.

M_T>Вы описали совершено неверное понимание принципов ХП.

У тебя либо педантизм либо неумение воспринимать те же мысли но другими словами — я почти тоже самое сказал что ты потом ниже. Опять же спорить не буду, потому что смысла спорить кто что сказал или не сказал вообще нет.

Вот по существу пожалуйста. Вернусь к начальной твоей реплике.

M_T>Если предшественник не думал а том как он сможет вставить еще одну кнопку в интерфейс без смертельных мучений то он дебил.

Если он разрабатывал MFC то да, а вот если писал прикладную программу у которой должно быть 2 кнопки и думал а что если завтра нужно будет поставить третью, а что для этого нужно , а не исправить ли мне сейчас на этот случай архитектуру и т.п. — то это как минимум уже не XP. С этим согласен?

Здравствуйте, Apostate, Вы писали:

M_T>>Я в свое время был убежденым нетскейпшиком но с определеного момента IE просто стал луче и удобнее и я стал пользоваться им.

A>Это ты. А я говорил о массовом пользователе.

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


A>Вот по существу пожалуйста. Вернусь к начальной твоей реплике.

M_T>>Если предшественник не думал а том как он сможет вставить еще одну кнопку в интерфейс без смертельных мучений то он дебил.

A>Если он разрабатывал MFC то да, а вот если писал прикладную программу у которой должно быть 2 кнопки и думал а что если завтра нужно будет поставить третью, а что для этого нужно , а не исправить ли мне сейчас на этот случай архитектуру и т.п. — то это как минимум уже не XP. С этим согласен?

ХП против введения абстрактной архитектуры но целиком за улучшение сушествуешего кода при том за непрерывное если у вас есть одна кнопка то вполне можно хранить все ее значения в обычных переменных но с понятными названиями и обрабатывать ее события в глобальной функции если же понадобилось две или больше кнопок то нужно не копи пайстеть и добовлять цифирки на конец названий а нужно вводить простенький класс Button посколько это стало необходимостью.

M_T>>>Если предшественник не думал а том как он сможет вставить еще одну кнопку в интерфейс без смертельных мучений то он дебил.

A>>Если он разрабатывал MFC то да, а вот если писал прикладную программу у которой должно быть 2 кнопки и думал а что если завтра нужно будет поставить третью, а что для этого нужно , а не исправить ли мне сейчас на этот случай архитектуру и т.п. — то это как минимум уже не XP. С этим согласен?

M_T>ХП против введения абстрактной архитектуры но целиком за улучшение сушествуешего кода при том за непрерывное

Поправки следующие — улучшение существующего кода только когда либо есть новый план релиза и там стоит чтобы было 3 кнопки — так захотел пользователь, либо когда задача сделать так чтобы в любой момент мы могли добавить 3-ю кнопку — маркетологи (ну или интуиция разработчика) говорит что клиент в любую минуту может этого захотеть. Никакого непрерывного совершенствования ради совершенствования, ради каких-то абстрактных целей. Если в задании жестко 2 кнопки и никаких подвижок что там с какого-то бока может появится третья — запрет на любые совершенствования кода, архитектуры в этом направлении — работает? — не трогай!.

M_T>если у вас есть одна кнопка то вполне можно хранить все ее значения в обычных переменных но с понятными названиями и обрабатывать ее события в глобальной функции если же понадобилось две или больше кнопок то нужно не копи пайстеть и добовлять цифирки на конец названий а нужно вводить простенький класс Button посколько это стало необходимостью.

Сомнительно. Можно привести 1000 аргументов за и не меньше против. И называется такой трюк стилем, а о стилях не спорят.

Единственно c чем могу спорить — с амбициозностью что наш стиль это супер стиль, а кто так не делает дебилы, а кто делает не_дебилы. Есть 1000 примеров успешных программистов не делающих так как ты написал и 1000 неуспешных делающих, как впрочем и наоборот. It depends. И зависит от того делают ли они свою работу — тратят свое время, нужд компании/клиента или ради_чего_то_другого, абстрактной цели совершенствования кода, например.

Например вот так. А вдруг когда нибудь в messagebox понадобится сразу 10 кнопок — "Повторить" "Повторять всегда" "Делай как в прошлый раз" "Ничего не знаю, сделай по умолчанию" "Вообще ничего не знаю, делай все по умолчанию" "Аборт" "Игнорировать" "Игнорировать Все" "Детали" "Помощь" — круто, возьму ка я и откажусь от стандартного messagebox, напишу свой похожий на стандартный но который в любой момент можно будет исправить на нечто на подобное, и вставлю его в текущий код.

Здравствуйте, Apostate, Вы писали:

A>Поправки следующие — улучшение существующего кода только когда либо есть новый план релиза и там стоит чтобы было 3 кнопки — так захотел пользователь, либо когда задача сделать так чтобы в любой момент мы могли добавить 3-ю кнопку — маркетологи (ну или интуиция разработчика) говорит что клиент в любую минуту может этого захотеть. Никакого непрерывного совершенствования ради совершенствования, ради каких-то абстрактных целей. Если в задании жестко 2 кнопки и никаких подвижок что там с какого-то бока может появится третья — запрет на любые совершенствования кода, архитектуры в этом направлении — работает? — не трогай!.

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

A>Сомнительно. Можно привести 1000 аргументов за и не меньше против. И называется такой трюк стилем, а о стилях не спорят.

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

A>Единственно c чем могу спорить — с амбициозностью что наш стиль это супер стиль, а кто так не делает дебилы, а кто делает не_дебилы. Есть 1000 примеров успешных программистов не делающих так как ты написал и 1000 неуспешных делающих, как впрочем и наоборот. It depends. И зависит от того делают ли они свою работу — тратят свое время, нужд компании/клиента или ради_чего_то_другого, абстрактной цели совершенствования кода, например.

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

M_T>Мне не понятно почему вы воспринимаете совершенствование кода как введение дополнительной абстрактной функциональности, я говорю всеволиш про рефакторинг, тоесть как написано на обложке про "улучшение дизайна существующего кода". Рефакторинг это одна из неотемлимых практик ХП такая же как парное программирование и разработка "тестами вперед".

ты ничего не понимаешь в конфу,
нет это ты
не ты
ну сейчас я докажу тебе что ты ошибаешься
да давай посмотрим

тия-кия-куя-х.я-зуя-кирдык-бдымс два трупа

Вообщем, темное это дело XP, тонкости формулировок разнятся от книжки к книжке, а все дело именно в этих тонкостях .

В моем понимании XP (теперь надеюсь понятно к чему такие оговорки?), рефакторинг это инструментдоведения программы до удовлетворения тестов. Его никогда не делают просто так. Тесты тоже не придумывают с потолка. Т.е. "улучшение дизайна существующего кода" только в рамках теста типа "сделайте так чтобы завтра мы могли быстро добавить функциональность такого-то и такого рода" — а не просто дали мальчику код и сказали "как нибудь усовершенствуй его". И это имхо ОСНОВЫ XP в этом его кардинальное отличие.


M_T>Конечно нету непрерывного совершенствованья одного и того же куска кода, поскольку есть конечное количеств улучшений.

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

M_T>Но до тех пор пока кто-то работает с кодом идет совершенствованье того или иного куска.

По определению работа с кодом это его совершенствование. Хотя я бы все-таки говорил о модификации кода.

M_T>Рефакторинг не имеет смысла только в случае если код написан по принципу написать и забыть но такого кода очень мало, большинство же кода требуется изменять, поскольку требованья меняются.

Это классика. А XP написать и, зная что потом будешь поддерживать, не сделать ничегочтобы код удовлетворял тестам которых еще нет, и лишь быть готовым психологически к любым новым требованиям в том числе и забыть про проект.

M_T>Я не очень понимаю с чем вы спорите , вам не нравятся классы ?

Мне нравятся, но я знаю людей которым не нравятся и я не согласен с теми кто говорит что они работать не умеет.

M_T>Мне честно говоря было бы интересно послушать два три аргумента в пользу дублирования кода.

Послушать? Ну-ну). Хорошо послушайте.

В пределах n-часов жизни копи-паст код удобнейсоздания функции

1. Скорость написания
— копи-паст и все
— не нужно придумывать название функции, далеко не такой простой вопрос как может показатся, не нужно описывать параметры функции, определятся с их составом, опять же придумывать их названия, типы, допустимые и не допустимые значения ,выносить все это из места употребления в соотвествующий cpp-файл, а объявление в h. файл

2. Модификация во время написания. Например, хочется чтобы все было также но в цикле проверялось еще и это условие
— копи-паст приписываешь в пастнутый код новое проверка_доп_условия и все
— как вариант не надо в функции вводить дополнительный параметр (проверять_доп_условие) и параметр(значение_доп_условия), исправлять код в фукнции более сложным образом (если проверять_доп_условию то проверить_дополнительное_условие), синхронизировать изменения в объявлении функции (h. файл cpp. файл), и главное как минимум задуматься о том что изменения в функции не скажутся на работе других уже написанных и отлаженных участков кода, которые ее вызывают
— или как другой вариант не нужно создавать для этого еще одну функцию делающую то же но с проверкой этого_доп_условия, при том что это собственно то же дублирование кода)

3. Не надо много запоминать — так случилось что мозг человек не может нормально держать в голове больше 5-7 понятий, тот же индефикатор функции и ее параметры, нужно не только придумать но еще и запомнить и держать в голове

Вся эта работа и неудобства для того чтобы сделать код которым когда-нибудь потом было бы удобно пользоватся и бывает очень обидно когда через полчаса понимаешь что этот код надо вообще убрать и написать по другому и функция эта вообще оказывается не нужна.

Поэтому вариант работы " написать код как получится а потом выделить в нем дублирующиеся участки" я считаю во многом рациональным, и тех кто им пользуется вовсе не закидывают тухлыми помидорами, как это сделал открыватель этого топика.

Здравствуйте, limax, Вы писали:

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

2. Лично я сильно привык к DUnit (аналог JUnit для Delphi), во всяком случае при рефакторинге таких программ тесты бывают, имхо, полезны. Даже при условии, что наша контора ХР не использует.

P. S. А венгерскую нотацию я не переношу. Имхо, если о типе переменной можно узнать только из приставки, то нужно срочно что-то менять!

Здравствуйте, limax, Вы писали:

[skip skip skip]

Вот читаю я такие темы и думаю, как мне однажды повезло. Год назад в институте попросили переделать прогу, которая была написана под ДОС, под Винды. Ну как там было все красиво написано. Единственное, только оформление кода я переделал под себя. А так все было понятно, кое-где были комментарии. Я брал целыми кусками и вставлял в свою версию проги. Короче, красота. Автору проги надо

Здравствуйте, limax, Вы писали:

L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?

Скажи ему, что недавно натолкнулся на прикольную статью
http://www.xprogramming.ru/Articles/CodeSmells.html
и поделись ссылкой

Здравствуйте, Аноним, Вы писали:

<флейм поскипан без прочтения — что-то вы тут развели демагогию>

А>Поэтому вариант работы " написать код как получится а потом выделить в нем дублирующиеся участки" я считаю во многом рациональным, и тех кто им пользуется вовсе не закидывают тухлыми помидорами, как это сделал открыватель этого топика.

Если бы! Предшественник открывателя этого топика даже не пытался "выделить в нем дублирующиеся участки" и не планировал делать это в будущем — да уже и не смог бы. Он просто в очередной раз жал Copy/Paste.

Здравствуйте, limax, Вы писали:

L>Здравствуйте, Аноним, Вы писали:

L><флейм поскипан без прочтения — что-то вы тут развели демагогию>

А>>Поэтому вариант работы " написать код как получится а потом выделить в нем дублирующиеся участки" я считаю во многом рациональным, и тех кто им пользуется вовсе не закидывают тухлыми помидорами, как это сделал открыватель этого топика.

L>Если бы! Предшественник открывателя этого топика даже не пытался "выделить в нем дублирующиеся участки" и не планировал делать это в будущем — да уже и не смог бы. Он просто в очередной раз жал Copy/Paste.

Не знаю, не знаю... Может он быть, он считал что пока и так нормально, а когда понадобится легко можно сделать, работа не сложная. Ну воот открывателю топика и понадобилось — пускай делает.

И кое-какие функции там уже есть — draw_sprite . Как раз тот случай когда можно с уверенностью заранее сказать, еще не приступив к написанию кода, что такая функция будет нужна в нем не раз и не два.

Здравствуйте, limax, Вы писали:

L>Теперь вопрос: что мне передать тому программисту при встрече, ежели такая когда-нибудь состоится?

Готов поспорить на стакан красного и огурец, что этот программер юзал allegro для графики. Если так то тебе еще повезло, она понятная и глюков там не много, да и программу можно компилять и отлаживать в VC6.0, 7.0, 7.1
За это его можно оставить в живых.

Здравствуйте, limax, Вы писали:

L>Достался мне в наследство от предыдущего программера код игры. И не просто код, а КОД, т.к. программер этот работает в компании SOT.
Очень забавный юмористический рассказ.
Прямо готовое пособие как не надо писать код.
Прямо нарушение всех правил оформления проектирования и так далее.
Передать ему, что он стал героем нового анекдота.
Только я вот не верю, что такой чел существует.
Причин несколько.
Передали вам код...
При таком его состоянии я бы его выкинул, а не передавал, передали на что, на сопровождение?
ТАКОЕ не сопровождают.
При том стиле, в котором это написано, ничто большое работать не будет.
Значит, это мелкая софтина, а ее проще переписать, чем исправить.
Она якобы работает, значит, он дописал ее до конца, писал наверное долго.
За это время любой разумный человек его бы десять раз уволил еще на первом же промежуточном этапе.
Выводов несколько, либо он ее не написал, либо она не работает,
либо что-то не то с управлением развития проектов в конторе
как следствие контора такая не может существовать долго — должна была развалиться.

Из чего делаем вывод все это юмористический литературный этюд.

F>Из чего делаем вывод все это юмористический литературный этюд.



Эээ, ты теоретик, да?

Или по жизни очень везло?

Здравствуйте, Apostate, Вы писали:

F>>Из чего делаем вывод все это юмористический литературный этюд.

A>

A>Эээ, ты теоретик, да?
Угадал по образованию теоретик физик

A>Или по жизни очень везло?
Да таких горбаг как описанно я не видал.
Эпизоды мне знакомы, но чтобы все вместе...