Здравствуйте, Аноним.

Часто работадатель это просто чиновник. Дело в конторе идет плохо, программный комплекс развивается медлено.Два-три программиста которые его ведут обещают, что к седующей недели (месяцу) новая версия программы будет выпущена.Через месяц-год выясняется, что программеры в запарке. Функционер приходит в ярость (законо!). Главный программер излагает начальству необходимость найма работника. Дальше схема простая — На чем написан проект? — На С. Пишем заявку, включаем туда все модные темы и пошло поехало ... Кнут то, что Дональд в корзину. Все!

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

А>Обижаешь. Я занимаюсь именно промышленной разработкой. И здесь как раз лабание никому не нужно. А уж о том, что бы слабать побыстрее и речи быть не может. Любой код проходит многоктратную проверку и тестирование. Ты себе представляешь атомную электростанцию, где код лабают чем быстрее, тем лучше? Я вот нет. Я конечно не на станции, но стандарты по надежности у нас тоже очень и очень высоки.

Так у вас там совсем другие требования, т.е. абсолютно. Наверняка и другие сроки и другие тулзы и другая технологии разработки и соответсвенно другого уровня надёжность. Но не надо равнять. Если бы весть софт делался как для атомных станций, то мы бы сейчас только-только начинали осваивать MS-DOS Хотя он наверняка был бы очень надёжный.

IT>>Молодцы, что ещё можно сказать. Думаю, что у вас с вашей уникальной технологией просто нет другого выбора. А если бы был, то вы бы брали тех у кого резюме более подходящее, а не тех кто заявляет про знание Кнута (что, кстати, гораздо сложнее проверить в отведённые на интервью время).

А>Я к тому, что отсюда видно, что это не так уж и надо.

Я же и говорю — именно вам не так уж и надо.

А>Утрировал конечно. Ты считаешь, что человек работающий 10 лет обязательно автоматически узнает все подводные камни? Я так думаю, что он узнает только от человека зависит, многие могут и не узнать.

Я так не считаю, но ты слишком обобщаешь. По твоему получается раз ты знаешь MFC и ATL, то ты автоматически не знаешь пузырьковую сортировку

А>Я к тому клоню, что все эти MFC, .NET и прочие ATL вещи приходящие и логичнее былобы проверяить эээ более базовые знания чтоли. Вот захочу я, к примеру, работу сменить, и что мне теперь дорога на win32 закрыта типа не справлюсь? MFC не освою? Я так вот не думаю

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

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

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

А>>Обижаешь. Я занимаюсь именно промышленной разработкой. И здесь как раз лабание никому не нужно. А уж о том, что бы слабать побыстрее и речи быть не может. Любой код проходит многоктратную проверку и тестирование. Ты себе представляешь атомную электростанцию, где код лабают чем быстрее, тем лучше? Я вот нет. Я конечно не на станции, но стандарты по надежности у нас тоже очень и очень высоки.

IT>Так у вас там совсем другие требования, т.е. абсолютно. Наверняка и другие сроки и другие тулзы и другая технологии разработки и соответсвенно другого уровня надёжность. Но не надо равнять. Если бы весть софт делался как для атомных станций, то мы бы сейчас только-только начинали осваивать MS-DOS Хотя он наверняка был бы очень надёжный.

Как так другие? Мы же говорим о промышленном программировании, не так ли? Да, я программирую не атомную станцию, но неужели вы готовы мирится, что программа управления полетом зависнет когда ваш самолет пойдет на посадку? Или телефонная станция, не соединит в самый нужный момент? А управление техпроцессом не предприятии? Список я думаю легко продолжить. Я, честно говоря, даже затрудняюсь найти место где надежность программ не на первом месте. Вопрос, я думаю очень интересный, может стоит это обсудить в отдельном топике? О, так сказать, технологическом цикле и стандартах?

Кстати, о тулзах ты погорячился, отвратительные, совершенно отвратительные, с VS и рядом не лежали.

А>>Утрировал конечно. Ты считаешь, что человек работающий 10 лет обязательно автоматически узнает все подводные камни? Я так думаю, что он узнает только от человека зависит, многие могут и не узнать.

IT>Я так не считаю, но ты слишком обобщаешь. По твоему получается раз ты знаешь MFC и ATL, то ты автоматически не знаешь пузырьковую сортировку

Случайно, я так не считаю конечно.

А>>Я к тому клоню, что все эти MFC, .NET и прочие ATL вещи приходящие и логичнее былобы проверяить эээ более базовые знания чтоли. Вот захочу я, к примеру, работу сменить, и что мне теперь дорога на win32 закрыта типа не справлюсь? MFC не освою? Я так вот не думаю

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

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

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

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

A>>Ведь вроде "все верно", а падает

А>IMHO, если все понятно а падает, программа спроектирована неверно.

Ну почему же не верно? Есть класс, который реализует 2 интерфейса.
Для проектирования дело обычное? Да!
Создаем объект класса, используем его только в одной роли. Опять для проектирования обычное дело.
Поиспользовали в этой роли, удаляем. Нормально? Да!
Все падает!

Проблема тут не в проектировании, а в знании ЯП. Знаешь C++ — сразу поймешь в чем дело, не знаешь — потратишь много времени. Будешь много тратить времени на разрешение мелких технических проблем — значит твое КПД маленькое. Выгоднее нанять не тебя, а того, кто уже наступал на эти грабли, тот у кого выше КПД.

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

А>>>Обижаешь. Я занимаюсь именно промышленной разработкой...

IT>>Так у вас там совсем другие требования, т.е. абсолютно. Наверняка и другие сроки и другие тулзы и другая технологии разработки и соответсвенно другого уровня надёжность. Но не надо равнять. Если бы весть софт делался как для атомных станций, то мы бы сейчас только-только начинали осваивать MS-DOS Хотя он наверняка был бы очень надёжный.

А>Как так другие? Мы же говорим о промышленном программировании, не так ли?

Всё таки мне кажется что ты путаешь промышленную разработку ПО с разработкой ПО для промышленности

А>Да, я программирую не атомную станцию, но неужели вы готовы мирится, что программа управления полетом зависнет когда ваш самолет пойдет на посадку?

Скорее всего главный конструктор сядет.

А>Или телефонная станция, не соединит в самый нужный момент?

911 потом по судам затаскает.

А>А управление техпроцессом не предприятии?

Остановка линии может обойтись миллионобаксовыми убытками.

А>Список я думаю легко продолжить. Я, честно говоря, даже затрудняюсь найти место где надежность программ не на первом месте.

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

А>Вопрос, я думаю очень интересный, может стоит это обсудить в отдельном топике? О, так сказать, технологическом цикле и стандартах?

Можно.

А>Кстати, о тулзах ты погорячился, отвратительные, совершенно отвратительные, с VS и рядом не лежали.

Я же не говорил что они у вас классные, я говорил что другие. А то что вы там из г-на, извиняюсь за выражение, пули лепите, так это я и не сомневаюсь. В твоём случае консерватизм вполне оправдан и лозунг "Лучшее враг хорошего" вполне уместен.

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

Так зачем тогда кодеров набирать?

А>Но так ведь не возмут, даже до собеседования не дойдет. Изначально не возьмут, если не напишу что у меня там три года MFC. Вот вам и тема "откуда привирание в резюме" и привру, поди проверь исходники ме запрещено специальной подпиской показывать. Обидно, что ко мне изначально отнесуться как к лоху, не знающему базовых вещей.

Нужно не обижаться, а книжки в зубы и учиться.

А>А гарантий нет ни у кого, нельзя на основании собеседования гарантировать, что человек подойдет и справится. См."откуда привирание в резюме".

Это так.

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

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

A>>>Ведь вроде "все верно", а падает

А>>IMHO, если все понятно а падает, программа спроектирована неверно.

A>Ну почему же не верно? Есть класс, который реализует 2 интерфейса.
A>Для проектирования дело обычное? Да!

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

A>Создаем объект класса, используем его только в одной роли. Опять для проектирования обычное дело.
A>Поиспользовали в этой роли, удаляем. Нормально? Да!
A>Все падает!

Ээээ.... Я как бы счел пример неудачным и говорил в неприменимости именно к нему, поскольку совершенно не узрел там как ты говоришь тонкостей. Ткни меня носом где там место не описанное в стандарте? Ты меня неправильно понял, я говорил о человеке, который не имеет опыта в работе с некторой технологией, тем не менее имя опыт в других, а вовсе не об идиоте ленящемся прочитать ладно бы стандарт, FAQ по предмету, отыскиваемый в гугле за 30 сек. Вот например:

020. Соответствие конструкторов и деструкторов
> Q: Что за чехарда с конструкторами? Деструкторы явно вызываются чаще...

A: (Arkady Belousov) — 23.02.97

А на это существует неписанное Правило Большой четвёрки (блин, что за
манера — создавать сложности, а потом придумывать пути их обхода): если ты
сам не озаботишься о дефолтном конструкторе, конструкторе копирования,
операторе присваивания и виртуальном деструкторе, то либо Старший Брат
озаботит тебя этим по умолчанию (первые три), либо через указатель будет
дестроиться некорректно (четвёртый).


A>Проблема тут не в проектировании, а в знании ЯП. Знаешь C++ — сразу поймешь в чем дело, не знаешь — потратишь много времени. Будешь много тратить времени на разрешение мелких технических проблем — значит твое КПД маленькое. Выгоднее нанять не тебя, а того, кто уже наступал на эти грабли, тот у кого выше КПД.

А если не поймешь возмешь стандарт и прочитаешь необходимую главу, другую. В данном случае о производных классах вроде нет под рукой. Если ты все еще настаиваешь на времени ну скажем 15 минут вместе с неторопливым чтением. Ты считаешь это серьезным препядствием? Где тут нужен невероятный опыт?

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


IT>Всё таки мне кажется что ты путаешь промышленную разработку ПО с разработкой ПО для промышленности

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

IT>Скорее всего главный конструктор сядет.

Да фиг бы с конструктором, я бы наверно молился, что бы самому сесть

IT>Остановка линии может обойтись миллионобаксовыми убытками.

А ошибка в бухгалтерской программе может раззорить предприятие? Ась?

А>>Список я думаю легко продолжить. Я, честно говоря, даже затрудняюсь найти место где надежность программ не на первом месте.

IT>Вопрос не в самой надёжность, а в степени надёжности и соответственно в стоимости разработки. Я очень сомневаюсь, что программы которые считают вашу бухгалтерию такой же степени надёжности как те, которые управляют реактором

Но неужели вся армия прогарммистов с РСДН лепит только бухгалтерские программы? Неверю.

А>>Кстати, о тулзах ты погорячился, отвратительные, совершенно отвратительные, с VS и рядом не лежали.

IT>Я же не говорил что они у вас классные, я говорил что другие. А то что вы там из г-на, извиняюсь за выражение, пули лепите, так это я и не сомневаюсь. В твоём случае консерватизм вполне оправдан и лозунг "Лучшее враг хорошего" вполне уместен.

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

IT>Так зачем тогда кодеров набирать?

Эээ.. а кто тут говорил про кодеров? Высокоскильный кодер это вообще мощная фраза. Так что работать я, пожалуй, смог бы и сразу, а знания по MFC поддтянуть.

А>>Но так ведь не возмут, даже до собеседования не дойдет. Изначально не возьмут, если не напишу что у меня там три года MFC. Вот вам и тема "откуда привирание в резюме" и привру, поди проверь исходники ме запрещено специальной подпиской показывать. Обидно, что ко мне изначально отнесуться как к лоху, не знающему базовых вещей.

IT>Нужно не обижаться, а книжки в зубы и учиться.

Это то ясен перец, иначе и привирание не поможет. Я про то что не напишешь в резюме, и хоть ты сто книг прочитай, никто и разговаривать не начнет.

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

IT>>Всё таки мне кажется что ты путаешь промышленную разработку ПО с разработкой ПО для промышленности

А>Ааа эээ тогда поясни разницу? Пожалуйста. Я как то слабо себе представляю высокотехнологичное написание курсовой. Только чур бухгалтерия это тоже предприятие, не для себя же ты ее пишешь.

Бухгалтерия — это предприятие, но это не производство, это обслуга, которая часто мнит себя важнее самого производства

IT>>Остановка линии может обойтись миллионобаксовыми убытками.

А>А ошибка в бухгалтерской программе может раззорить предприятие? Ась?

Не может. Разорить может тупой глав. бух, но не программа, которая напечатает на бумаге неправильные цифры. Неправильные цифры выискиваются, корректируются, пересчитываются и т.п. Физически такая программа ничем не управляет, соответственно ничего не может разрушить. В Интернете ежесекундно случаются мириады глюков, но никто от них ещё не умирал. Если же ты сделаешь ошибку, то умереть может даже страшно подумать сколько народу. Именно в связи с этим к твоим программам и предъявляются такие требования.

Странно, что я вообще тебе всё это объясняю. Если ты действительно работаешь там где говоришь, то тебе всё это должно быть гораздо лучше известно

А>Но неужели вся армия прогарммистов с РСДН лепит только бухгалтерские программы? Неверю.

Посмотри что-то было в голосованиях.

IT>>Так зачем тогда кодеров набирать?

А>Эээ.. а кто тут говорил про кодеров? Высокоскильный кодер это вообще мощная фраза.

А чё? Мне вообще слово 'кодер' нравиться. Сам люблю покодить страшное дело как

А>Так что работать я, пожалуй, смог бы и сразу, а знания по MFC поддтянуть.

А что бы ты делал поначалу, если тебе нужно писать именно на MFC?

А>Это то ясен перец, иначе и привирание не поможет. Я про то что не напишешь в резюме, и хоть ты сто книг прочитай, никто и разговаривать не начнет.

И что тут плохого? И кто в этом виноват?

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

А>>А ошибка в бухгалтерской программе может раззорить предприятие? Ась?

IT>Не может. Разорить может тупой глав. бух, но не программа, которая напечатает на бумаге неправильные цифры. Неправильные цифры выискиваются, корректируются, пересчитываются и т.п. Физически такая программа ничем не управляет, соответственно ничего не может разрушить. В Интернете ежесекундно случаются мириады глюков, но никто от них ещё не

Разве? А не слыхал ли ты о случаях кражи денег из за дыры в программе? Я вот слыхал и это только о тех, кого поймали, всмысле такие вещи особо не афишируются.
Я думаю, ты все-таки путаешь естественные ошибки (ну сложно составить тестовые случаи на все случаи, особенно для таких систем как windows), с халатностью когда на тестирование вообще забивают, типа мы не атомной станции, подумаешь упадет. Вот взять к примеру, ээээ янус, вот есть для него тест-план? Сомневаюсь, потому, что я смотрел b1 b3 и изменилась функциональность.

IT>Странно, что я вообще тебе всё это объясняю. Если ты действительно работаешь там где говоришь, то тебе всё это должно быть гораздо лучше известно

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

А>>Так что работать я, пожалуй, смог бы и сразу, а знания по MFC поддтянуть.

IT>А что бы ты делал поначалу, если тебе нужно писать именно на MFC?

Занимался бы проработкой поставленной задачи. Что значит писать на МFC? Писать надо что-то. Не открываешь же ты новый проект и сразу давай лепить формочку и кнопки, а зачем потом разберемся.

А>>Это то ясен перец, иначе и привирание не поможет. Я про то что не напишешь в резюме, и хоть ты сто книг прочитай, никто и разговаривать не начнет.

IT>И что тут плохого? И кто в этом виноват?

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

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

А>IMHO, если все понятно а падает, программа спроектирована неверно. Для консультаций должен быть специалист по языку, а код должен читатся как книга. Вся языковая эквилибристика должна быть исключена. Даже самы тупой из присутствующих на code review должен код понимать не напрягаясь. Это все мое HO конечно.

Ежели все понятно и падает, то ошибка в кодировании и ничего больше.
Не надо делать из проектирования панацею. Носятся все с ним как с писанной торбой, млин.

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

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

Я так и не понял — ты собираешься MFC с ATL-ом учить или нет ?
А насчет плохо — это кому как. По моему все нормально.

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

> В Интернете ежесекундно случаются мириады глюков, но никто от них ещё не умирал.

Согласен. Кроме того даже если ты где-нибудь видишь баг это не всегда значит что его надо фиксить. Классический пример вот отсюда:
http://www.joelonsoftware.com/articles/fog0000000014.html

As a software developer, fixing bugs is a good thing. Right? Isn't it always a good thing?

No!

Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.

These things are hard, but not impossible, to measure. Let me give you an example. Suppose you operate a peanut-butter-and-jelly sandwich factory. Your factory produces 100,000 sandwiches a day. Recently, due to the introduction of some new flavors (garlic peanut butter with spicy Habanero jam), demand for your product has gone through the roof. The factory is operating full-out at 100,000 sandwiches, but the demand is probably closer to 200,000. You just can't make any more. And each sandwich earns you a profit of 15 cents. So you're losing $15,000 a day in potential earnings because you don't have enough capacity.

Building a new factory would cost way too much. You don't have the capital, and you're afraid that spicy/garlicky sandwiches are just a fad which will pass, anyway. But you're still losing that $15,000 a day.

It's a good thing you hired Jason. Jason is a fourteen year old programmer who hacked into the computers that run the factory, and believes that he has come up with a way to speed up the assembly line by a factor of 2. Something about overclocking that he heard on slashdot. And it seemed to work in a test run.

There's only one thing stopping you from rolling it out. There's a teeny tiny wee little bug that causes a sandwich to be mushed once an hour or so. Jason wants to fix the wee bug. He thinks he can fix it in three days. Do you let him fix it, or do you roll out the software in its bug-addled state?

Rolling out the software three days later will cost you $45,000 in lost profits. And it will save you, um, the cost of raw materials for 72 sandwiches. (In either case Jason will get the bug fixed three days later). Well, I don't know how much sandwiches cost on your planet, but here on Earth, they're a lot less than $625.

Здравствуйте, Anatolix,

A>Согласен. Кроме того даже если ты где-нибудь видишь баг это не всегда значит что его надо фиксить. Классический пример вот отсюда:
A>http://www.joelonsoftware.com/articles/fog0000000014.html

На самом деле ещё проще. Пока баг не мешает работать, его не надо фиксить. Потому, если пользователь доволен, что имеет, то зачем причёсывать код?
"Good enough software", и ничего более.

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

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

Воруют из-за дыр в программах, воруют из-за дыр в заборах. Какая разница? Вор есть вор, какими бы средствами он не пользовался. И при чём тут это вообще?

А>Я думаю, ты все-таки путаешь естественные ошибки (ну сложно составить тестовые случаи на все случаи, особенно для таких систем как windows), с халатностью когда на тестирование вообще забивают, типа мы не атомной станции, подумаешь упадет.

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

А>Вот взять к примеру, ээээ янус, вот есть для него тест-план? Сомневаюсь, потому, что я смотрел b1 b3 и изменилась функциональность.

Ты не сравнивай. За янус никто не платит, народ развлекается, учит .NET. Баги исправляются либо после наезда, либо если уж самого припекло. Я, кстати, янусом не пользуюсь именно из-за его багистости А попытки наехать на разработчиков обычно заканчиваются чем то типа — ну возми и сам исправь

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

А как заказчик узнает что в твоём объекте баги?

IT>>А что бы ты делал поначалу, если тебе нужно писать именно на MFC?

А>Занимался бы проработкой поставленной задачи. Что значит писать на МFC? Писать надо что-то. Не открываешь же ты новый проект и сразу давай лепить формочку и кнопки, а зачем потом разберемся.

Какой проработкой. Мы же договорились, что без MFC и ATL тебя берут как юниора, всё что надо проработать проработают и без тебя архитекторы

IT>>И что тут плохого? И кто в этом виноват?

А>Плохо то, что заставляют писать всякую чушь в резюме ставя во главу технологии, о которых через пять лет никто и не вспомнит.

Честно говоря, такое отношение к технологиям меня настораживает. Очень сильно попахивает шапкозакидательством. Типа мы крутые, нам любые технологии по плечу. Если по твоему на MFC нужно 2 недели, то вот эту неделю мы с тобой протрепались, и за это время ты запросто мог бы выучить половину MFC. Ещё неделя и ты всё знаешь. Т.е. какие тогда для тебя могут быть проблемы?

А>Плохо то, что из-за этого сложнее найти работу мне, да и работодателю с моей точки зрения тоже плохо

Боюсь что ты не понял главного, от тебя требуется знание именно технологий.

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

IT>Ты не сравнивай. За янус никто не платит, народ развлекается, учит .NET. Баги исправляются либо после наезда, либо если уж самого припекло. Я, кстати, янусом не пользуюсь именно из-за его багистости А попытки наехать на разработчиков обычно заканчиваются чем то типа — ну возми и сам исправь

То что ты просил давно уже поправлено.

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

IT>Как раз это я и пытаюсь тебе растолковать. Надёжность программ зависит не только от квалификации разработчика (халатность не в счёт, это не разработчик, а раздолбай), но и от тех мер которые предпринимаются для организации процесса разработки, тестирования и устранения багов. В разных случаях эти меры могу быть разнымим и всё зависит от стоимости и сроков.

Да я собсно вкурсе. Я даже считал эту саму надежность. Я просто пытался так робко защитить бухгалтерские программы как вообщем-то тоже нужные и от которых кое-что зависит, и которые не стоит то уж совсем переводить в разряд "а нафиг их тестировать" А ты их вон как не любишь.

IT>Ты не сравнивай. За янус никто не платит, народ развлекается, учит .NET. Баги исправляются либо после наезда, либо если уж самого припекло. Я, кстати, янусом не пользуюсь именно из-за его багистости А попытки наехать на разработчиков обычно заканчиваются чем то типа — ну возми и сам исправь

Странное развлечение писать принципально кривые программы.

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

IT>А как заказчик узнает что в твоём объекте баги?

На основе полевых испытаний, если там не найдут, то они никого и не волнуют пока их не найдут Потом правят конечно, если не смогут доказать что это фича

IT>Какой проработкой. Мы же договорились, что без MFC и ATL тебя берут как юниора, всё что надо проработать проработают и без тебя архитекторы

Проработают что? Мы же не MFC пишем не так ли? Следовательно ест некий алгоритм, так сказать последовательность действий, котрый надо сначала придумать, а уж потом на писать MFC там или нет.
Отсутствме текущих знаний по MFC, ATL или чего там они хотят, не означает, что я не знаком и остальным процессом. Ну ты же сам мне привел аргумент, что из [не]владения MFC не вытекает автоматическое [не]владения пузырьковой сортировкой. А сейчас говоришь обратное, типа раз не знаешь MFC то и вообще не программист.
Может у нас разночтения в технологиях программирования? Вот как у нас
От заказчика пулучают набор требований, требования переводят в описание функциональности (т.е. что надо сделать). B Это спускают разработчикам и тестерам те пишут как будут делать и как будут тестировать. Все это вместе обсасывается и разработчики начинают разрабатывать, а тестеры тестировать. Я разработчик, кто за меня еще что то будет прорабатывать? Поделись как проходит у вас.


IT>Честно говоря, такое отношение к технологиям меня настораживает. Очень сильно попахивает шапкозакидательством. Типа мы крутые, нам любые технологии по плечу. Если по твоему на MFC нужно 2 недели, то вот эту неделю мы с тобой

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

протрепались, и за это время ты запросто мог бы выучить половину MFC. Ещё неделя и ты всё знаешь. Т.е. какие тогда для тебя могут быть проблемы?

А почему ты думаешь, что так не происходит? За то время что мы протрепались, я вполне осилил большую часть С# Троелсона и чать framework sdk. И уж я точно теперь знаю, где что искать по этой теме. И собственно я думаю, что так делают многие. Мне просто интересно быть в курсе.
Проблема в том, что мое знание у меня на лбу не написано, типа он читал пять книг по MFC и три по ATL, запомнил столькото

IT>Боюсь что ты не понял главного, от тебя требуется знание именно технологий.

Это я как раз сразу знал, на это и жалуюсь. Здесь же вроде разговоры за жизнь, не так ли?

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

А>Да я собсно вкурсе. Я даже считал эту саму надежность. Я просто пытался так робко защитить бухгалтерские программы как вообщем-то тоже нужные и от которых кое-что зависит, и которые не стоит то уж совсем переводить в разряд "а нафиг их тестировать" А ты их вон как не любишь.

Разве я сказал что не люблю бухгалтерию? (Но я и не говорю, что я от неё в восторге ) И в разряд "а нафиг их тестировать" я тоже ничего не переводил, не надо нас грузить, можешь перечитать весь топик сначала

Что я говорил, так это то, что от того насколько ты усердно будешь тестировать зависит стоимость всего проекта и сроки. Если главное требование — высокая надёжность, то заказчик именно за это и будет платить, соответственно именно этим всё своё основное время ты и будешь заниматься. Но поверь мне, бывают и другие случаи, и как я уже говорил, если бы все писали программы как для атомных станций, то мы бы сейчас работали на MS DOS.

А>Странное развлечение писать принципально кривые программы.

Каждому своё

IT>>А как заказчик узнает что в твоём объекте баги?

А>На основе полевых испытаний, если там не найдут, то они никого и не волнуют пока их не найдут Потом правят конечно, если не смогут доказать что это фича

Какова стоимость таких испытаний?

IT>>Какой проработкой. Мы же договорились, что без MFC и ATL тебя берут как юниора, всё что надо проработать проработают и без тебя архитекторы

А>Проработают что?

А что ты собирался прорабатывать?

А>Мы же не MFC пишем не так ли?

Но пишем на MFC.

А>Следовательно ест некий алгоритм, так сказать последовательность действий, котрый надо сначала придумать, а уж потом на писать MFC там или нет.

Ты думаешь? А второй алгоритм ты будешь писать на Дельфях или на C#?

А>Отсутствме текущих знаний по MFC, ATL или чего там они хотят, не означает, что я не знаком и остальным процессом. Ну ты же сам мне привел аргумент, что из [не]владения MFC не вытекает автоматическое [не]владения пузырьковой сортировкой. А сейчас говоришь обратное, типа раз не знаешь MFC то и вообще не программист.

Ещё раз медленно. Т_е_б_я б_е_р_у_т н_а р_а_б_о_т_у ч_т_о б_ы т_ы п_и_с_а_л н_а M_F_C, и_м_е_н_н_о з_а э_т_о т_е_б_е б_у_д_у_т п_л_а_т_и_т_ь. Если ты позиционируешь себя как не как юниор и претендуешь на позицию где сам будешь выбирать какую технологию, то вперёд и с песней, но зачем тогда так возмущаться по поводу тех позиций, которые тебя не интересуют.

А>Может у нас разночтения в технологиях программирования? Вот как у нас
А>От заказчика пулучают набор требований, требования переводят в описание функциональности (т.е. что надо сделать). B Это спускают разработчикам и тестерам те пишут как будут делать и как будут тестировать. Все это вместе обсасывается и разработчики начинают разрабатывать, а тестеры тестировать. Я разработчик, кто за меня еще что то будет прорабатывать? Поделись как проходит у вас.

Примерно так же. За исключением того, что у нас тут был жуткий бардак, который как раз и обуславливался тем, что кто что на чём хотел, тот то на том и делал, т.к. считать себя самым умным, вполне нормальная человеческая черта. Сейчас это искореняется всеми доступными средствами, ибо достало. Разработчик сам продумывает детали задачи, но в выборе технологий и принципиальных решений он ограничен. Это уже продумали до него. Если он не согласен, то эта тема всегда открыта для обсуждения и согласования.

IT>>Честно говоря, такое отношение к технологиям меня настораживает. Очень сильно попахивает шапкозакидательством. Типа мы крутые, нам любые технологии по плечу. Если по твоему на MFC нужно 2 недели, то вот эту неделю мы с тобой

А>А с чего бы мне стенать и посыпать голову пеплом? Все что сделали одни люди могут изучить и сломать другие люди.

Кто бы был против.

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

Но это ведь тоже придумали другие, соответственно тебе это под силу. Разве нет? Ну не за две недели, за пару месяцев например.

А>А почему ты думаешь, что так не происходит? За то время что мы протрепались, я вполне осилил большую часть С# Троелсона и чать framework sdk. И уж я точно теперь знаю, где что искать по этой теме.

Молодец.

А>И собственно я думаю, что так делают многие. Мне просто интересно быть в курсе.
А>Проблема в том, что мое знание у меня на лбу не написано, типа он читал пять книг по MFC и три по ATL, запомнил столькото

И ты считаешь, что это проблемы окружающих? Вокруг тебя ходят одни телепаты, блин Должен тебя огорчить, но это твои проблемы.

IT>>Боюсь что ты не понял главного, от тебя требуется знание именно технологий.

А>Это я как раз сразу знал, на это и жалуюсь. Здесь же вроде разговоры за жизнь, не так ли?

Ну да

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

IT>Что я говорил, так это то, что от того насколько ты усердно будешь тестировать зависит стоимость всего проекта и сроки. Если главное требование — высокая надёжность, то заказчик именно за это и будет платить, соответственно именно этим всё своё основное время ты и будешь заниматься. Но поверь мне, бывают и другие случаи, и как я уже говорил, если бы все писали программы как для атомных станций, то мы бы сейчас работали на MS DOS.

А я согласен. Но усердие и размер тест-плана вещи не прямо связаные.
Ну вот смотри:
Допустим серьезное, дорогое тестирование это
дизайнер, предварительное тестирование, предварительное тестирование связанных модулей, официальное тестирование, тестирование связанных модулей, основная функиональность всего, тестирование заказчиком при сдаче. Ошибка на любом этапе откидывает нас на шаг нумер нуль. Пропуски запрещены.
Надо ли такое при тестировании при разработке ну скажем эээ януса? Очевидно нет. Но вот тест-план в обоих случаях может быть одинаковым, если делает одно и тоже. Т.е. есть набор функий, есть набор тестов для этих функций. ИМХО задача программирования, есть задача пройти все тесты. По моему так. Где тут можно, что сэкономить? Работу по другому на закончишь, если конечно не ставил задачу выпустить связный набор глюков. Остануться только ошибки пропущеные тает-планом, но это уж не те ошибки. И это конечно уже опыт и квалификация.

IT>Какова стоимость таких испытаний?

Не отчитываются. Но так вроде всё сдают, начиная от компьютерных классов.

IT>Ты думаешь? А второй алгоритм ты будешь писать на Дельфях или на C#?

С каких пор алгоритмы стали от MFC зависеть? От MFC завист их реализация. Все буду на MFC писать, вот только писать начну не сразу

IT>Ещё раз медленно. Т_е_б_я б_е_р_у_т н_а р_а_б_о_т_у ч_т_о б_ы т_ы п_и_с_а_л н_а M_F_C, и_м_е_н_н_о з_а э_т_о т_е_б_е б_у_д_у_т п_л_а_т_и_т_ь. Если ты позиционируешь себя как не как юниор и претендуешь на позицию где сам будешь выбирать какую технологию, то вперёд и с песней, но зачем тогда так возмущаться по поводу тех позиций, которые тебя не интересуют.

Да что значит п_и_с_а_т_ь? Я же не диктант пишу, в самом деле. У тебя получается, что прям как секретаршу посадили и давай строчи. — У тебя какая производительность? — 300 строк в день, правда такая фигня.

IT>Примерно так же. За исключением того, что у нас тут был жуткий бардак, который как раз и обуславливался тем, что кто что на чём хотел, тот то на том и делал, т.к. считать себя самым умным, вполне нормальная человеческая черта. Сейчас это искореняется всеми доступными средствами, ибо достало. Разработчик сам продумывает детали задачи, но в выборе технологий и принципиальных решений он ограничен. Это уже продумали до него. Если он не согласен, то эта тема всегда открыта для обсуждения и согласования.

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

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

IT>Но это ведь тоже придумали другие, соответственно тебе это под силу. Разве нет? Ну не за две недели, за пару месяцев например.

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

IT>Молодец.

Ну вот, выпросил себе похвалу

А>>Проблема в том, что мое знание у меня на лбу не написано, типа он читал пять книг по MFC и три по ATL, запомнил столькото

IT>И ты считаешь, что это проблемы окружающих? Вокруг тебя ходят одни телепаты, блин Должен тебя огорчить, но это твои проблемы.

Не чуткий ты. Да не телепаты, но это и есть проблема. И приходится писать всякую ерунду в резюме, и такую же ерунду начинают писать в требованиях. Дайте нам человаека 5 лет опыта с C#, зарплата 4000 руб. Как нет? Вчера приходил, но засранец 4100 хотел.

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

А>>А ошибка в бухгалтерской программе может раззорить предприятие? Ась?
IT>Не может. Разорить может тупой глав. бух, но не программа, которая напечатает на бумаге неправильные цифры. Неправильные цифры выискиваются, корректируются, пересчитываются и т.п. Физически такая программа ничем не управляет, соответственно ничего не может разрушить.
IT>Странно, что я вообще тебе всё это объясняю.

Да, да уважаемый IT, странно, очень странно вы представляете себе работу бухгалтерии. Очевидно, что Вы, как и многие программисты, никогда не сталкивались с автоматизацией очень больших объемов бухгалтерской информации. Поэтому Вы совершенно не представляете себе степень ответственности, которую приходится нести в этом случае программисту. В наше бюрократическое время у бухгалтеров совсем нет времени выискивать ошибки. Причем ошибки тонут в потоке информации и накапливаются как снежный ком. В этом случае, именно ошибки в программе могут подвести самого умного бухгалтера, разорить предприятие и создать проблемы лично для Вас. Да и перед вашим носом могут помахать пистолетиком. На кого нарвешься... Очень просто можно не заметить неправильные цифры в больших объемах данных. Посчитать с неправильных цифр неправильные налоги. То есть возможно занизить налоги. А потом придет налоговая через пару лет и предпишет такие штрафы, что мало не покажется. Так что Ваше мнение здесь по поводу бухгалтерских прогрмм — это детский лепет. Извините.

Здравствуйте, Олег Жихарев, Вы писали:

ОЖ>Да, да уважаемый IT, странно, очень странно вы представляете себе работу бухгалтерии. Очевидно, что Вы, как и многие программисты, никогда не сталкивались с автоматизацией очень больших объемов бухгалтерской информации.

Как минимум это нарушение правил форума. Кроме того это просто невежливо.

ОЖ>Поэтому Вы совершенно не представляете себе степень ответственности, которую приходится нести в этом случае программисту.

Я думаю это ты не представляешь.

ОЖ> В наше бюрократическое время у бухгалтеров совсем нет времени выискивать ошибки.

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

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

Перед твоим махали?

ОЖ>На кого нарвешься...

Надо мозгами думать когда на работу устраиваешься, а не органом чувства самосохранения.

ОЖ>Очень просто можно не заметить неправильные цифры в больших объемах данных.

Я тебе больше скажу — я регулярно ошибаюсь, и бухгалтера столь же регулярно ошибаются. Ничего, живой пока.

ОЖ>Посчитать с неправильных цифр неправильные налоги.

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

ОЖ>То есть возможно занизить налоги.

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

ОЖ>А потом придет налоговая через пару лет и предпишет такие штрафы, что мало не покажется.

Гы гы. Наивный. Как будто штрафы зависят от правильности работы софта

ОЖ>Так что Ваше мнение здесь по поводу бухгалтерских прогрмм — это детский лепет. Извините.

Имхо ваше мнение это лепет, только не детский, а непонятно какой. Бред одним словом.

Не пойму к чему все это? Просто чтобы наехать? В любой, даже суперсложной бухгалтерии ответственность несет бухгалтер, а никак не программист. И уж тем более глупо "перед вашим носом махать пистолетиком".