Здравствуйте, 4058, Вы писали:
4>Если говорить про софт под игровые приставки, то тут все просто,
... 4>Сложный это софт или нет, решать тебе, но если будет хоть одна ошибка контракта больше не получишь.
В системах реального времени требования не меньше. Особенно, когда эти системы связаны с опасными производствами или оборонкой.
4>Поэтому скучать с копи-пастом "формо-кодерства", особо не приходится.
Т.е. знакомства с предметной областью, о которой вел речь автор первой статьи, фактически, не было.
4>В данный момент на посл. крупном проекте сложность была обусловлена его инфрастуктурой: 4>крипто-сервера, сервера БД (Oracle, MS SQL, FoxPro, многомерная БД + барахло в виде Documentum и файловые хранилища), 4>несолько серверов прирожений, узкоспециализированное железо, 4>на котором крутится допотопный софт, который прекрасно работает 24/7 и никто не позволит его переписывать. 4>Все это конечно было не просто заставить петь дружным хором. 4>Сложный это софт или нет, решать тебе, но ошибки сведены к минимому.
Довольно обыденная картина информационных систем в крупных банках.
Повторюсь, что твой опыт не является чем-то выдающимся и меня он не впечатляет. Перечисленные тобой выше проекты простыми я не назову, но и запредельной сложности в них не видно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 4058, Вы писали:
ГВ>>А что такое качественный код?
4>Я затрудняюсь ответить на этот вопрос. Можно попытаться привести набор противоречивых критериев, 4>и спорить о них до бесконечности, но в кратце:
4>Качественный код должен:
4>* безошибочно выполнять свою задачу наиболее локаничным образом 4>* рационально использовать ресурс 4>* удобно сопровождаться
4>Все описанные выше критерии, должны на сколько возможно укладываться в поставленные временные рамки 4>(а не как оно бывает дайте нам в 1.5-n раза больше времени и мы вам сделаем всё )
Хочешь, упрощу? Качественный код — это код, удовлетворяющий выдвинутым требованиям. Всё. Вот "рациональное использование ресурсов", "удобство сопровождения" — это всё требования, которые предъявляются к коду. Могут и не предъявляться, кстати, но не суть. Соответственно предъявляемым требованиям можно сформировать систему критериев и т.п. Дальше можно спорить о том, какие требования и когда уместно выдвигать, а какие — нет. Зачастую борцы за что-нибудь перетягивают одеяло требований в ту или иную сторону — то в сторону исключительно "бизнес-требований", игнорируя требования технологического порядка, то обратно — в сторону одних только требований "удобства сопровождения", "соответствия Хорошим Практикам" и т.п. И начинают те и другие биться во имя какой-то имманетной качественности, которой на самом деле не существует. Существует упорядочивание требований по степени важности в текущей ситуации.
Так что выражение "ядро Win 3.x менее качественно, чем ядро NT" не имеет смысла, если у тебя нет bugtracking log по обоим системам. Это разные системы, и появились они вследствие разных требований к конечному продукту. Я уверен, что в рамках своих требований и то и другое ядро приблизительно одинаково качественны (полагаю, что NT даже менее качественна, чем 3.x ), то есть в одинаковой мере им удовлетворяют.
И само собой, MS "переписала" Win 3.x не потому, что она была какой-то изначально некачественной, а потому что поменялись требования к конечному продукту. Win 3.x — оконная надстройка над 16-битной DOS ("оболочка дешёвая, мышами пропахшая"), тогда как NT — уже самостоятельная многозадачная операционная система. Естественно, Win 3.x (и её последователь — 9x), не могли в полной мере вписаться в те требования, под которые создавалась NT (и которые в дальнейшем вполне подошли массовому рынку), поэтому в конечном итоге они обе "сошли со сцены". Но при этом и 3.x, и 9x/Me — вполне качественные продукты в том смысле, что они вполне удовлетворили тем требованиям, под которые их делали.
С другой стороны, слово "качественно" часто употребляется как синоним "мне нравится", или в смысле какого-то абстрактного "хорошо". Но это уж такая тонкая и спекулятивная материя, что лучше совсем обойти её стороной.
С третьей стороны интересно вот что. Культура технической деятельности, это ни что иное, как квинтэссенция некой совокупности требований к продукту и как следствие — к исполнителю. Смекаешь? Только благодаря тому, что мы воспитаны приблизительно в однаковых культурных условиях, мы и можем опускать перечисление всех требований, ограничиваясь термином "качественно".
ГВ>>К скипнутому рассуждению о горе-философе, которой пишет библиотечку "для души". 4>Это долгий розговор вероятно требующий отдельного поста.
Присоединюсь к просьбе eao197: мы тут никуда не торопимся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 4058, Вы писали:
4>Еще раз повторяю, некачественный софт бывает очень дорог в долгосрочной перспективе, 4>поэтому то что съэкономили сегодня, прийдется отдавать в 4-х кратном размере завтра.
"Сегодня" может элементарно не хватить денег на качество. При этом если конкурентов в данной нише нету, то на качестве (в начале) — можно сэкономить: мышки будут давится, плакать, но продолжать кушать кактус; а когда деньги появятся — можно будет кактус превратить (переделать) во вкусный огурчик . Ну а если уже есть аналоги по функционалу и удобству (ничего особо нового не делается) — то несомненно стоит вкладывать ресурсы именно в качество, притом сразу. Ну и про промежуточные варианты забывать не стоит.
Все с детства знают, что то-то то-то невозможно. Но всегда находится "невежда", который этого не знает. Он-то и делает открытие.
Альберт Эйнштейн.
Здравствуйте, Mamut, Вы писали: M>Обычно такие DSLи млм затоены под конкретные задачи или слишком общие, и не подходят для конкретной задачи
Ага. Ну, вот, например, CSS совершенно непригоден для установления displayWidth различным контролам.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, 4058, Вы писали:
4>>Если говорить про софт под игровые приставки, то тут все просто, E>... 4>>Сложный это софт или нет, решать тебе, но если будет хоть одна ошибка контракта больше не получишь.
E>В системах реального времени требования не меньше.
Зачастую RTS достаточно простые, по сравнению с игроделом (даже под портативные консоли).
Например если твоя игра, постоянно дергает UMD-привод приставки PSP,
то заряд быстро кончится, а есть регламентированное время, сколько по времени
игра должна работать до полного разряда батареи.
E>В системах реального времени требования не меньше.
Особенно, когда эти системы связаны с опасными производствами или оборонкой.
Ну да, можно еще до кучи космос приписать, вот только об этих
областях больше разговоров, чем известности, а чего-же там делается на самом деле ...
4>>Поэтому скучать с копи-пастом "формо-кодерства", особо не приходится.
E>Т.е. знакомства с предметной областью, о которой вел речь автор первой статьи, фактически, не было.
О том и речь. Поэтому его доводы, лично мне мало интересны.
E>Повторюсь, что твой опыт не является чем-то выдающимся и меня он не впечатляет. Перечисленные тобой выше проекты простыми я не назову, но и запредельной сложности в них не видно.
Я не считаю свой опыт чем-то выдающимся, просто он есть,
чего нельзя сказать об авторе статьи.
Здравствуйте, Sinclair, Вы писали:
S> M>Обычно такие DSLи млм затоены под конкретные задачи или слишком общие, и не подходят для конкретной задачи
S> Ага. Ну, вот, например, CSS совершенно непригоден для установления displayWidth различным контролам.
Можно расширить мою фразу: "и чаще всего DSL'и не доконца реализованы соответствующими инструментами/платформами"
Здравствуйте, 4058, Вы писали:
4>>>Сложный это софт или нет, решать тебе, но если будет хоть одна ошибка контракта больше не получишь.
E>>В системах реального времени требования не меньше.
4>Зачастую RTS достаточно простые, по сравнению с игроделом (даже под портативные консоли).
4>Например если твоя игра, постоянно дергает UMD-привод приставки PSP, 4>то заряд быстро кончится, а есть регламентированное время, сколько по времени 4>игра должна работать до полного разряда батареи.
Например, если система управления производством не сможет обработать правильно какую-то ситуацию, произойдет выход из строя оборудования (иногда дорогостоящего) и остановка производства.
E>>В системах реального времени требования не меньше. 4>Особенно, когда эти системы связаны с опасными производствами или оборонкой.
4>Ну да, можно еще до кучи космос приписать, вот только об этих 4>областях больше разговоров, чем известности, а чего-же там делается на самом деле ...
С космосом не сталкивался, не знаю, что там происходит. Столкнулся бы, говорил бы и о нем так же.
4>>>Поэтому скучать с копи-пастом "формо-кодерства", особо не приходится.
E>>Т.е. знакомства с предметной областью, о которой вел речь автор первой статьи, фактически, не было.
4>О том и речь. Поэтому его доводы, лично мне мало интересны. 4>Вероятно я не правильно выразился, у меня был опыт работы в его области, у него в моей явно нет.
Ну так вот он, детский сад в действии. Автор статьи говорит прямым текстом:
Но давайте в этой статье попробуем сосредоточиться на неком неувлечённом программисте и той работе, которую он выполняет. Фактически, давайте сузим наши рамки ещё сильнее и поговорим только о разработчиках «скучного» программного обеспечения. Под «скучным» я подразумеваю обработку погрузочно-разгрузочных накладных, учёт использования корпоративного автопарка, создание отчётов о расходах и т.п., и всё это только для внутреннего использования и с огромной кучей требований, специфичных для конкретной компании. Итак, повторюсь, если вы не зарабатываете себе на жизнь «скучным» ПО, тогда эта статья к вам не вполне применима.
Так что автор даже не пытался говорить о всей индустрии в целом. Он говорит о проектах, в которых требования к качеству на порядки ниже, чем в некоторых других областях (включая АСУТП и игрострой). Но автору, не смотря на его очень прозрачные предупреждения, заявляют:
Во первых, автор говорит за читателя чем он занимается.
Во вторых, приводится до безобразия унылый перечень простеньких/однодневных задач,
на основании, которых человек осмеливается "трындеть" о состоянии индустрии в целом.
Тогда как речь специально идет об вполне определенном классе ПО и связанных с этим классом ПО проблемах. И, если не ошибаюсь, количество денег, которые тратятся на разработку именно таких проектов, на порядки больше, чем на игровую индустрию. Так что еще отдельный вопрос, что именно отражает состояние индустрии в целом -- "скучные" проекты или игрострой.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Например, если система управления производством не сможет обработать правильно какую-то ситуацию, произойдет выход из строя оборудования (иногда дорогостоящего) и остановка производства.
СУП полнотью не является RTS, как правило небольшие ее части.
E>Ну так вот он, детский сад в действии. Автор статьи говорит прямым текстом:
[SKIP]
Статья начинается с:
Программирование — это не забава. Это нудное и скучное занятие, и, уж конечно, никакой не подвиг. Чего бы вы там с ним не делали, программирование совершенно точно не будет «секси».
Утверждение, что программирование нудное и скучное занятие, чего бы мы (?) там не делали.
Безусловно, многим из нас, включая меня, нравится писать код. Но должно ли нам это нравиться?
Кому это 'нам'?
"Итак, повторюсь, если вы не зарабатываете себе на жизнь «скучным» ПО, тогда эта статья к вам не вполне
применима."
Не вполне? А может все-таки просто не применима?
P.S. Можно как-нибудь обойтись без лестных выпадов в адрес собеседника, или "уроки Влада" не прошли для тебя даром?
Здравствуйте, 4058, Вы писали:
E>>Например, если система управления производством не сможет обработать правильно какую-то ситуацию, произойдет выход из строя оборудования (иногда дорогостоящего) и остановка производства.
4>СУП полнотью не является RTS, как правило небольшие ее части.
Откуда такая статистика на счет "как правило"?
E>>Ну так вот он, детский сад в действии. Автор статьи говорит прямым текстом:
4>[SKIP] 4>Статья начинается с: 4>
4>Программирование — это не забава. Это нудное и скучное занятие, и, уж конечно, никакой не подвиг. Чего бы вы там с ним не делали, программирование совершенно точно не будет «секси».
4>Утверждение, что программирование нудное и скучное занятие, чего бы мы (?) там не делали.
Я присоединяюсь к автору. Чтобы мы не делали с программированием, оно никогда не будет таким же увлекательным и захватывающим как, например, секс.
4>
Безусловно, многим из нас, включая меня, нравится писать код. Но должно ли нам это нравиться?
4>Кому это 'нам'?
Программистам. Многим программистам нравится программировать. Но должно ли это занятие вообще нравится?
4>
4>"Итак, повторюсь, если вы не зарабатываете себе на жизнь «скучным» ПО, тогда эта статья к вам не вполне
4>применима."
4>Не вполне? А может все-таки просто не применима?
Имхо, уровень "вполне" определяет сам читатель. Тем не менее, некоторые выводы, сделанные в статье, могут быть применимы в очень многих областях программостроения.
4>P.S. Можно как-нибудь обойтись без лестных выпадов в адрес собеседника, или "уроки Влада" не прошли для тебя даром?
Я не сделал еще ни одного выпада. Даже предложение посмотреть в зеркало, с которого начался сеанс эксбиционизма, являлось всего лишь констатацией того факта, что каждый из нас (включая и меня, т.к. зеркало беспристрасно) постоянно оказывается в ситуациях, когда выбор делается не в пользу качества.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я присоединяюсь к автору. Чтобы мы не делали с программированием, оно никогда не будет таким же увлекательным и захватывающим как, например, секс.
Он не пишет про секс, он пишет про "секси". Ы?
E>Программистам. Многим программистам нравится программировать. Но должно ли это занятие вообще нравится?
Это вопрос о том, должен ли человек получать удовольствие от своей работы.
По повозможности должен, другое дело, что в ламерских областях это удается сравнительно редко.
E>... постоянно оказывается в ситуациях, когда выбор делается не в пользу качества.
Не постоянно, я уже устал объяснять что "код на сегодня", пишется для быстренького завоевания определенной
низши (и то это не всегда прокатывает), а затем все равно приходится делать качественно.
Пример: Win3.x — захват, NT — добровольное удержание (т.к. пользователя в захвате долго не продержишь).
Здравствуйте, eao197, Вы писали:
E>Я не сделал еще ни одного выпада. Даже предложение посмотреть в зеркало, с которого начался сеанс эксбиционизма, являлось всего лишь констатацией того факта, что каждый из нас (включая и меня, т.к. зеркало беспристрасно) постоянно оказывается в ситуациях, когда выбор делается не в пользу качества.
ИМХО, в этой ситуации главное не заниматься самообманом и давать хотя бы самому себе отчет о своих действиях и мотивах. Лично я иногда сознательно позволяю себе немного фана в коммерческих проектах, если это не опасно и есть время. Просто иначе сложно себя мотивировать на работу.
Здравствуйте, 4058, Вы писали:
4>Это вопрос о том, должен ли человек получать удовольствие от своей работы.
Очень часто удовольствие идет во вред работе. Это не значит, что надо совсем себя лишать удовольствия, но хотя бы ограничиваться. Это примерно как может ли профессиональный водитель превышать скорость, если он получает удовольствие от быстрой езды? Вообще говоря не должен, но если очень хочется и не опасно, то иногда можно.
Здравствуйте, 4058, Вы писали:
E>>Я присоединяюсь к автору. Чтобы мы не делали с программированием, оно никогда не будет таким же увлекательным и захватывающим как, например, секс.
4>Он не пишет про секс, он пишет про "секси". Ы?
Ну для меня самым "секси" занятием является таки секс. А программирование, в какой-бы ипостаси оно не существовало, к разряду "секси" точно не относятся. Бывают моменты озарения, когда программа работает так, как нужно и от этого получаешь удовольствие. Но это такие редкие случаи, что их можно воспринимать всего лишь как очень приятное дополнение.
E>>Программистам. Многим программистам нравится программировать. Но должно ли это занятие вообще нравится?
4>Это вопрос о том, должен ли человек получать удовольствие от своей работы. 4>По повозможности должен, другое дело, что в ламерских областях это удается сравнительно редко.
Ну вот, опять детсад начинается. Ламерские области, не ламерские. Людей еще можно называть ламерами, хотя это не этично и не тактично. А уж целые области программостроения называть ламерством...
E>>... постоянно оказывается в ситуациях, когда выбор делается не в пользу качества.
4>Не постоянно
Ну это уже, похоже, вопрос веры.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, mrTwister, Вы писали:
E>>Я не сделал еще ни одного выпада. Даже предложение посмотреть в зеркало, с которого начался сеанс эксбиционизма, являлось всего лишь констатацией того факта, что каждый из нас (включая и меня, т.к. зеркало беспристрасно) постоянно оказывается в ситуациях, когда выбор делается не в пользу качества.
T>ИМХО, в этой ситуации главное не заниматься самообманом и давать хотя бы самому себе отчет о своих действиях и мотивах. Лично я иногда сознательно позволяю себе немного фана в коммерческих проектах, если это не опасно и есть время. Просто иначе сложно себя мотивировать на работу.
Вопрос мотивации это вообще такая отдельная область... Люди книги пишут и зарабатывают состояния на обучении других людей мотивировать самих себя. Так что я со своим делитантизмом лучше в эту область вообще вдаваться сейчас не буду.
Расскажу только одну историю, которая очень серьезно изменило мое отношение к работе (именно к работе, т.е. к занятию, за которое платят). Возвращался я из командировки лет шесть назад. Со мной в купе ехал один мужик, который ночью во сне в слух с кем-то ругался, кому-то что-то доказывал, оправдывался. Утром мы с ним разговорились и я спросил, мол, работа так напрягает, что ты во сне разговаривать начал? На что он мне ответил: "Работа, которая не напрягает -- не работа". До сих пор мне кажется, что он был прав.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, 4058, Вы писали:
E>Ну для меня самым "секси" занятием является таки секс. А программирование, в какой-бы ипостаси оно не существовало, к разряду "секси" точно не относятся.
Автор по всей видимости подразумевал нечто вроде удовольствия от программирования.
E>Бывают моменты озарения, когда программа работает так, как нужно и от этого получаешь удовольствие. Но это такие редкие случаи, что их можно воспринимать всего лишь как очень приятное дополнение.
Для тебя приятным дополнением является, когда твоя программа работает "как нужно"?
Или она зачастую работает "как нужно", но тебе это не всегда доставляет удовольствие?
E>Ну вот, опять детсад начинается. Ламерские области, не ламерские. Людей еще можно называть ламерами, хотя это не этично и не тактично. А уж целые области программостроения называть ламерством...
Ну, мнение об области определяет ее "население".
Если в области сосредоточено множество людей низкой квалификации,
без малейшего желания для самосовершенствования (тот самый — ламер),
то область грубо говоря можно считать ламерской.
E>Ну это уже, похоже, вопрос веры.
Здравствуйте, 4058, Вы писали:
E>>Ну для меня самым "секси" занятием является таки секс. А программирование, в какой-бы ипостаси оно не существовало, к разряду "секси" точно не относятся.
4>Автор по всей видимости подразумевал нечто вроде удовольствия от программирования.
Я тоже. Есть куча занятий, которые доставляют гораздо больше удовольствия, чем программирование.
E>>Бывают моменты озарения, когда программа работает так, как нужно и от этого получаешь удовольствие. Но это такие редкие случаи, что их можно воспринимать всего лишь как очень приятное дополнение.
4>Для тебя приятным дополнением является, когда твоя программа работает "как нужно"? 4>Или она зачастую работает "как нужно", но тебе это не всегда доставляет удовольствие?
Да для меня (вальяжно поглаживая лысину) уже давным-давно стало нормой, когда программы работают "как нужно". Какие-то интеллектуальные вызовы, заставляющие напрягаться, когда не знаешь, что именно получится, и сколько сил придется вложить в достижение цели, появляются очень редко. Вот победа от такого вызова действительно приятна. Но это всего лишь дополнение.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
)
