Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не все так просто... PD>Он не рвач и не обманщик, нет. Но он исходит из того, что считается нормой в его среде. А в ней , увы, не считается нормой (и дискуссия это прекрасно подтверждает) провести иссследование и найти максимально возможные характеристики ПО, которое собираемся делать. Скорее наоборот.
Прочитал ветку, откуда такой вывод, не понял. Может, у шароварщиков, особенно тех, у кого продажи высокие, спросим, следят ли они за рынком (и успехами конкурентов)? "Максимально возможные характеристики" можно найти только при неограниченном бюджете и за бесконечное время. А у нас пока модель несколько иная: вменяемый заказчик договаривается с вменяемым исполнителем. Именно первый проводит исследование рынка с целью найти лучшее. И именно поэтому многие исполнители выбрасывают на рынок не доведенные до ума продукты с единственной целью опередить конкурента. Это, правда, ситуация на рынке коробочных продуктов. В случае, когда софт разрабатывается для конкретного заказчика, определяющими становятся требования именно этого заказчика. И с его точки зрения важнейшим фактором становится бюджет, уложиться в который исполнителю — искусство.
PD>В самом деле, почему это исполнитель должен объяснять заказчику, что это можно было бы сделать намного лучше , если исполнитель знает, что все остальные делают отнюдь не лучше. Ведь заказчик все равно платить будет — идти ему некуда, у других то же самое. Террор среды.
"Это можно было бы сделать лучше" — так обычно говорят, когда видят у потенциального заказчика продукт, выполненный конкурентом. Вменяемый заказчик на подобное ведется крайне редко. И попутно спрошу: у твоих конкурентов действительно то же самое?
PD>Вот если работы станет на порядок меньше, и образуются армии безработных программистов, вот тогда да, те, кто умеют лучше делать, будут из кожи вон лезть, чтобы доказать заказчику, что они это лучше сделают, и что именно лучше.
И при этом останутся в рамках.
PD>Выставит заказчик проект — а ему и объяснят, что и вот это можно лучше сделать, и вот это, а вот это надо совсем иначе делать и будет намного лучше. Иначе они работу не получат. А заполучив ее — будут еще и по ходу работы думать, как еще лучше сделать. Но до этого далеко.
Заказчика интересует результат. На дополнительные затраты с целью улучшения исполнителем тех или иных функций софта заказчик пойдет только если будет убежден в их целесообразности: либо он увеличит доходы, либо существенно сократит расходы. На последнее почему-то обращают внимание реже. Исполнитель, разумеется. в любом случае не должен писать чего-то такого:
String s = new Integer("21").toString(); // Видел в реальном проекте...
Отсутствие подобных перлов как раз и означает, что исполнитель пытается сделать свою работу как можно лучше.
Топик более чем странный. Но я, кажется, понял, почему он все еще так взволнованно "дышит". По-моему, здесь схлестнулся довольно абстрактный академический подход с грубым практическим.
Любое техническое устройство, будь то программа, самолет или танк, — это всегда компромисс. Каждый отдельный элемент не проектируется как идеальный. Это обычно невозможно, и практики к этому не стремятся. Главное — чтобы взлетел. Нормальный программер обычно знает, где у него в программе косяки, что хорошо бы подделать, если когда-нибудь дойдут руки (т.е хватит ресурсов). Приоритетно рассверливаются только важные "бутылочные гёрлышки".
Я выше писал о конкуренции. Она может и подхлестывать оптимизацию, и тормозить. Например, приходится добавлять в софт всякие конъюнкрунные свистелки-перделки в ущерб понятно чему.
Здравствуйте, fmiracle, Вы писали:
F>Нет. Я могу делать проект для себя (для обучения или из любви к искусству, неважно), и выставлять ему свой собственный набор требований, которые он должен удовлетворять, и по ним оценивать качество — хорошо у меня получилось или нет.
Оценивать самого себя — это слишком предвзято. Любой критерий будет неточен. Хотя, лично я гениален по самое небалуйся. Все что я делаю — очень качественно. Никто так не умеет делать качественно, как я.
Здравствуйте, GlebZ, Вы писали:
F>>Нет. Я могу делать проект для себя (для обучения или из любви к искусству, неважно), и выставлять ему свой собственный набор требований, которые он должен удовлетворять, и по ним оценивать качество — хорошо у меня получилось или нет. GZ>Оценивать самого себя — это слишком предвзято.
Если проект делается для себя (а я писал именно так), то это как раз самая правильная оценка.
GZ>Хотя, лично я гениален по самое небалуйся. Все что я делаю — очень качественно. Никто так не умеет делать качественно, как я.
Тебе хорошо. А я почти всегда вижу в своих продуктах что можно улучшить. Далеко не всегда находятся ресурсы для этого, правда.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Визуально время на все про все — пара секунд.
При этом время на написание кода — максимум полчаса, а скорее даже столько же, сколько при использовании штатного сериалайзера. А уж если учесть сколько времени потом потратить пришлось на дебаг и разбор полетов "почему так медленно"...
Так что в данном конкретном случае оптимизация нужна и полезна. Другое дело, когда с профайлером миллисекунды неделю выжимают.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что-то здесь не то. Хоть сколько меня убеждайте — а не то. Есть некие внутренние критерии качества. Должны быть. Если это сделано халтурно, то хоть 33 раза пусть этот продукт удовлетворяет всем требованиям, а халтура есть халтура.
Скажем так. Есть критерии, которые определяются исходя из текущего опыта. Скажем, исходя из своего опыта — я предпочитаю обработку данных делать как можно ближе к данным. Например, если мы говорим про данные которые храняться в SQL Server — то я постараюсь сделать максимально возможную подготовку данных в запросе, который обрабатывается на сервере и на клиент передать минимальный кусочек информации.
Т.е. естественно что на начальный дизайн решений, выбор средств и подходов мой текущий опыт будет одним из решающих факторов. Однако при этом я постоянно готов пересмотреть задачу с нуля. Поднявшись на уровень абстракций где нет никаких очевидных вещей. Где нет стандартных подходов к обработке данных или ожидаемого времени сериализации данных в файл. И очень важно держать эту базой как можно более чистой и незашоренной мусором вроде "Вывод данных в файл размером в 150 Мб , если данные уже готовы и находятся в ОП, должен производиться за несколько секунд.".
Это если говорить об общем подходе к анализу проблем. Но особенно опасно пускать на самый верхний уровень абстракций любые утверждения относительно производительности программ. Эти утверждения очень сильно зависят от контекста использования, типа данных, с которыми работает приложение, и множества других факторов.
Люди, которые способны подняться на верхний уровень абстракций способны придумать youtube, потому что они не боятся пускать по сети тонны трафика (в отличии от людей, которые навсегда для себя решили, что html страница должна быть как можно более худой — и это аксиома). Люди с верхнего уровня способны построить кластерную real-time систему на .Net, потому что для них "а ведь в .Net есть garbage collector" — не является конечным аргументом.
Поэтому с вами тут и спорят, что вы не хотите признать, что даже для ваших задач верхний уровень абстракций не имеет права содержать никаких утверждений про производительность. Более того, пугает что ваших студентов вы явно учите тому же самому.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что-то здесь не то. Хоть сколько меня убеждайте — а не то. Есть некие внутренние критерии качества. Должны быть. Если это сделано халтурно, то хоть 33 раза пусть этот продукт удовлетворяет всем требованиям, а халтура есть халтура.
Давно хотел спросить: а как ты выбираешь софт для себя? По каким критериям? Какой компилятор ты считаешь качественным, а какой — нет, ну и т. д.
Здравствуйте, GlebZ, Вы писали:
GZ>Pavel — большая ошибка считать что программирование — это цель. Наша цель — добавленная стоимость. Программирование — всего лишь средство. Если программирование станет целью, то на рынке мало кто этот продукт купит. Во-первых вероятнее всего он не выйдет в ожидаемые пользователем сроки. Во-вторых, его стоимость (а стоимость программного продукта это прежде всего стоимость человеческого труда туда вложенного) будет завышена. Программа и так стоит весьма недешева, ты же предлагаешь сомнительными плюсами увеличить ее стоимость. Боюсь конечный пользователь такого не одобрит, а главное тупо не купит.
Все верно. Не возразишь.
Но давай тогда признаем следующий неприятный факт. Мы делаем не тот продукт, который могли бы делать. Мы не делаем продукт, которому в плане его внутреннего качества нельзя бросить никакого упрека. Мы скорее как те древнеримские рабы, которым все равно, хорошо они делают свое дело или нет, лишь бы хозяин был доволен, кормил и плеткой не бил.
Плетки и корм разве что сейчас другие...
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Что-то здесь не то. Хоть сколько меня убеждайте — а не то. Есть некие внутренние критерии качества. Должны быть. Если это сделано халтурно, то хоть 33 раза пусть этот продукт удовлетворяет всем требованиям, а халтура есть халтура. 0>Любые критерии определяются кем-то, а не существуют сами по себе. То, о чем ты говоришь, это критерий, который для себя определил инженер. Это инженерная эстетика, профессиональная честь — называй как хочешь. Это очень хорошо, когда у людей есть такое чувство. Но оно неизбежно вступает в конфликт с бизнес-реалиями, где хорошо то, что приносит деньги.
Увы, ты прав. Но очень уж неприятно видеть, как эти бизнес-реалии ведут к тому, что профессиональная честь уступает место халтуре, да еще находятся люди, готовые эту халтуру оправдывать не тем, что, мол, такова жизнь (это еще куда не шло), а "глубокими" соображениями о том, что мол, так и должно быть с неких высших позиций. Мне больно видет превращение моей любимой профессии в халтуру.
Здравствуйте, Геннадий Васильев, Вы писали:
PD>>Что-то здесь не то. Хоть сколько меня убеждайте — а не то. Есть некие внутренние критерии качества. Должны быть. Если это сделано халтурно, то хоть 33 раза пусть этот продукт удовлетворяет всем требованиям, а халтура есть халтура.
ГВ>Что значит "внутренние"? Внутри чего?
Внутреннее устройство программы. Использованы ли лучшие для этой задачи алгоритмы/структуры данных или первые попавшиеся.
Внутренняя структура программы. Является ли она ясной и логичной, наиболее подходящей для этой задачи или же сделано абы как.
Потребности в ресурсах (время, память и т.д.) Минимальны ли они (в разумном смысле) или же как бог на душу положит.
Отмечу, что все вышеприведенное пользователь вряд ли увидит. Это только тот увидит, кому исходники доступны. А увидев, или восхитится, или же, наоборот, скажет в адрес автора (может, не вслух) пару "лестных" фраз.
Вот тебе пример из моей ранней молодости. Был я тогда аспирантом, и был у меня студент, которому я дал задание написать программу (химические расчеты). Он ее написал, она нормально работала. Я посмотрел код и увидел там транспонирование матрицы, вполне вытекающее из алгоритма расчета. Для размещения транспонированной матрицы он завел новую матрицу того же размера. Между тем исходная матрица больше не требовалась, что могло быть элементарно определено из алгоритма. На скорость это не влияло, на память — довольно серьезно, но не так уж существенно. С точки зрения лишних трудозатрат — практически ноль (код транспонирования матрицы на месте ничуть не сложнее кода транспонирования в другую матрицу)
Я ему высказал все, что я о таком программировании думаю. Полагаю, он эту выволочку надолго запомнил.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот тебе пример из моей ранней молодости. Был я тогда аспирантом, и был у меня студент, которому я дал задание написать программу (химические расчеты). Он ее написал, она нормально работала. Я посмотрел код и увидел там транспонирование матрицы, вполне вытекающее из алгоритма расчета. Для размещения транспонированной матрицы он завел новую матрицу того же размера. Между тем исходная матрица больше не требовалась, что могло быть элементарно определено из алгоритма. На скорость это не влияло, на память — довольно серьезно, но не так уж существенно. С точки зрения лишних трудозатрат — практически ноль (код транспонирования матрицы на месте ничуть не сложнее кода транспонирования в другую матрицу)
PD>Я ему высказал все, что я о таком программировании думаю. Полагаю, он эту выволочку надолго запомнил.
PD>Я был неправ ?
Зависит от того, было ли требование о памяти в ТЗ и от того, на кого студент учился и в каком виде была выволочка.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Все верно. Не возразишь.
PD>Но давай тогда признаем следующий неприятный факт. Мы делаем не тот продукт, который могли бы делать.
Да
PD>Мы не делаем продукт, которому в плане его внутреннего качества нельзя бросить никакого упрека.
Да.
PD>Мы скорее как те древнеримские рабы, которым все равно, хорошо они делают свое дело или нет, лишь бы хозяин был доволен, кормил и плеткой не бил.
Вывод не понятен.
С тем же успехом мы как те инженеры, которые в годы войны разрабатывали танки для армии, чтобы защищать страну. И — инженерно — делали прекрасные разработки. Но при этом они не были идеальны, это очевидно, т.к. танки 43го года были совершеннее чем танки 42го, а танки 44го — совершеннее, чем 43го. Собственно, идеал до сих пор не достигнут, и все время появляются улучшения.
Почему инженеры выпускали в 42м году танк, хотя могли бы поработать еще пару лет и сделать лучше? Ты можешь считать что это потому, что над ними стояли надсмотрщики из НКВД, а я лично буду считать, что они делали так потому, что понимали — тот танк в том состоянии, какой он есть, нужен армии прямо сейчас и он гораздо полезнее, чем гипотетически гораздо лучший, но через 2 года.
Еще можно считать, что мы как те инженеры, которые выпускали паровозы, чтобы можно было решать практические задачи транспортировки, а не пытались разработать сразу электрический локомотив, который гораздо эффективнее, мощнее и удобнее.
Собственно, правильный вывод совсем другой и его уже много раз озвучивали — программирование — это инженерная дисциплина, а не точная наука.
В точной науке можно окончательно доказать закон или теорему и успокоиться.
В инженерных же дисциплинах нет идеала — в них всегда ищут компромиссы и пытаются уложиться в ограниченные ресурсы. И удачное (не идеальное, такого нет) инженерное решение — это наилучший компромисс между плюсами и минусами (всеми, включая и цену и качество) для всех возможных вариантов использования данного решения.
Здравствуйте, fmiracle, Вы писали:
F>Замечательно. А теперь, пожалуйста, продемонстрируй такую же простую сериализацию/десериализацию Dictionary<int, object>?
Еще раз могу посоветовать — читай исходные постинги внимательно. Там речь шла о Dictionat из int и double, и проблема была у автора в неприемлемом времени именно для этого случая. Я показал, что для этой задачи есть решение с записью в файл и чтением из него за пару секунд. Я нигде не заявлял, что это решение годится на все случаи жизни.
F>Можно даже всего лишь что-то типа Dictionary<int, MyClass>. Разумеется (не надо говорить, что это очевидно, я и так знаю), у MyClass могут быть наследники.
Самое забавное, что все это давным-давно есть. Сериализация — не изобретение дотнета, она еще в MFC была (и есть). И именно в MFC сериализуют граф классов, являющихся наследниками от CObject (впрочем, и не наследников тоже можно), в том числе и вот такой класс
template< class KEY, class ARG_KEY, class VALUE, class ARG_VALUE >class CMap : public CObject
который, как ты понимаешь, есть тот же Dictionary
Ну и не-темплейтных классов там немало. Например — CMapStringToOb Class и CMapWordToOb (последний — примерно то, что ты хочешь, только вот не int, а short — древняя библиотека, увы.
И сериализуют этот мэп просто вот так
m_map.Serialize(ar);
Я сейчас пример для исходной задачи сделал, любопытно было посмотреть, сколько строк получится и сколько времени займет
Строки
// в описании класса CMyDocument
CMap<int,int,int,int> m_map;
// в OnInitDocument
// For best performance, the hash table size should be a prime number. To minimize collisions, the size should be roughly 20 percent larger than the largest anticipated data set.
m_map.InitHashTable(3100000); for(int i = 0; i < 3000000; i++)
m_map.SetAt(i,i);
// в Serialize
if (ar.IsStoring())
{
// TODO: add storing code here
m_map.Serialize(ar);
}
Все. Итого 4 строчки. Намного сложнее, чем на дотнете ? Без всяких так SerializationCallback...
Скорость (визуально) на моей машине — примерно 3-4 сек.
Просто , видишь ли, это писалось тогда, когда еще умели писать эффективный код.
Здравствуйте, Privalov, Вы писали:
P>Прочитал ветку, откуда такой вывод, не понял. Может, у шароварщиков, особенно тех, у кого продажи высокие, спросим, следят ли они за рынком (и успехами конкурентов)? "Максимально возможные характеристики" можно найти только при неограниченном бюджете и за бесконечное время.
Или при том же бюджете и за то же время, но при этом имея хорошую квалификацию, зная все, что положенно знать, умея делать как следует, а не абы как и главное — сначала думая, как бы это лучше сделать, а потом уж делая.
>А у нас пока модель несколько иная: вменяемый заказчик договаривается с вменяемым исполнителем. Именно первый проводит исследование рынка с целью найти лучшее. И именно поэтому многие исполнители выбрасывают на рынок не доведенные до ума продукты с единственной целью опередить конкурента. Это, правда, ситуация на рынке коробочных продуктов. В случае, когда софт разрабатывается для конкретного заказчика, определяющими становятся требования именно этого заказчика. И с его точки зрения важнейшим фактором становится бюджет, уложиться в который исполнителю — искусство.
Все равно не понимаю. Вот автор решил употребить сериализацию, а надо бы банально вывести в файл. Я на написание этого кода по выводу в файл ручным способом потратил 15 минут, при том, что я в дотнете дилетант. Ну и где, спрашивается, я не уложился в этот бюджет ? А у автора этот вывод требует 2 минуты, и не потребуй десериализация 20 минут, так бы и оставил (приемлемо...)
P>"Это можно было бы сделать лучше" — так обычно говорят, когда видят у потенциального заказчика продукт, выполненный конкурентом. Вменяемый заказчик на подобное ведется крайне редко. И попутно спрошу: у твоих конкурентов действительно то же самое?
У меня нет конкурентов
P>Заказчика интересует результат. На дополнительные затраты с целью улучшения исполнителем тех или иных функций софта заказчик пойдет только если будет убежден в их целесообразности: либо он увеличит доходы, либо существенно сократит расходы.
А все же с этой сериализацией Dictionary — так и оставить или нет ?
>Исполнитель, разумеется. в любом случае не должен писать чего-то такого: P>
P> String s = new Integer("21").toString(); // Видел в реальном проекте...
P>
P>Отсутствие подобных перлов как раз и означает, что исполнитель пытается сделать свою работу как можно лучше.
Извини.
Отсутствие подобных перлов ровно ничего не означает.
А вот наличие подобных перлов означает просто одно — автора надо обратно в школу отправить, а не допускать его к профессиональной работе.
А вот тот факт, что такие перлы могут вообще обсуждаться в плане разговора о качестве — говорит о том, что, похоже, наша профессия, став массовой, превратилась в поле деятельности непрофессионалов. Потому что профессионалы такое обсуждать вообще не могут. Это за гранью профессиональной работы. Это все равно что в техническом вузе обсуждать неумение студента решать линейное уравнения с одной переменной и делать вывод — вот пока он в этом ошибки допускает, он еще не качественный, скажем, конструктор, а как только научится решать его без ошибок — все, готов качественный специалист.
Не прав. И причину твоей неправоты ты сам же и указал — "На скорость это не влияло, на память — довольно серьезно, но не так уж существенно". То есть, принятое студентом решение не влияло сколько-нибудь существенно на работу программы, требование же минимизации используемой памяти не формулировалось вообще, не так ли? Значит, все требования, предъявленные к программе на этапе разработки, были выполнены; и не выполненных требований не было. А вот ты — сам придумал себе проблему на ровном месте, да еще и бедному студенту устроил выволочку ни за что.
Здравствуйте, Кэр, Вы писали:
Кэр>Т.е. естественно что на начальный дизайн решений, выбор средств и подходов мой текущий опыт будет одним из решающих факторов. Однако при этом я постоянно готов пересмотреть задачу с нуля. Поднявшись на уровень абстракций где нет никаких очевидных вещей. Где нет стандартных подходов к обработке данных или ожидаемого времени сериализации данных в файл. И очень важно держать эту базой как можно более чистой и незашоренной мусором вроде "Вывод данных в файл размером в 150 Мб , если данные уже готовы и находятся в ОП, должен производиться за несколько секунд.".
Хорошая мысль. Но мне не совсем понятно, почему одно другому противоречит.
Хочешь подниматься к вершинам абстракций — на здоровье. Нет там стандартных подходов — и не надо. Но нет там и сериализации, коли уж туда поднялись. Это же вершины, там вообще высокими понятиями оперируют. "Вывод данных куда-то в каком-то формате" — вот это годится. А сериализация — это не горные вершины, а так, СреднеРусская возвышенность
Так что на высотах абстракций можно , конечно, себя деталями не утруждать, и про время этого вывода не думать. Но на этих высоких абстракциях программу не напишешь. Раньше или позже с горных высот придется спуститься к средствам языка программирования, ОС и т.д. К чисто техническим элементам. И вот тут, если все же выяснится, что объем данных 150 Мб, данные готовы и вывод надо вести в файл — почему нельзя принять как требование, чтобы это делалось за пару секунд, коли аппаратура это позволяет ?
Кэр>Это если говорить об общем подходе к анализу проблем. Но особенно опасно пускать на самый верхний уровень абстракций любые утверждения относительно производительности программ. Эти утверждения очень сильно зависят от контекста использования, типа данных, с которыми работает приложение, и множества других факторов.
И не надо их на верхний уровень пускать.
Кэр>Поэтому с вами тут и спорят, что вы не хотите признать, что даже для ваших задач верхний уровень абстракций не имеет права содержать никаких утверждений про производительность.
Признаю, признаю, я же уже сказал. На верхнем уровне — признаю. Только потом, когда с верхнего уровня спуститесь и выяснится, что <см. выше> — потрудитесь за 2 секунды, пожалуйста. А не выполнится то, что <см. выше> — тогда скажите, что у вас получилось, может, я вам еще пару секунд и добавлю
>Более того, пугает что ваших студентов вы явно учите тому же самому.
Не пугайтесь. Учить их писать неэффективно желающих найдется немало, увы.
P>Давно хотел спросить: а как ты выбираешь софт для себя? По каким критериям?
1. Должен удовлетворять функциональным требованиям. Проще говоря, если не делает все то, что мне надо — значит, как минимум, ограниченно годен.
2. Наилучшее быстродействие и наименьшая память.
3. Дизайн и юзабилити.
Приоритеты по убывающей.
>Какой компилятор ты считаешь качественным, а какой — нет, ну и т. д.
Я в основном с VS работаю, с С++. Как компилятор — очень даже ничего, ну а если уж надо оптимизировать донельзя — есть IGC, он в студию элементарно встраивается. Что касается IDE — с тоской вспоминаю VS 6.0. Вот это было действительно качественно сделано, студия та просто летала. А сейчас чем больше xx в 20xx, тем все медленее и медленнее...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Увы, ты прав. Но очень уж неприятно видеть, как эти бизнес-реалии ведут к тому, что профессиональная честь уступает место халтуре, да еще находятся люди, готовые эту халтуру оправдывать не тем, что, мол, такова жизнь (это еще куда не шло), а "глубокими" соображениями о том, что мол, так и должно быть с неких высших позиций. Мне больно видет превращение моей любимой профессии в халтуру.
Я бы не сказал, что есть массовое превращение в халтуру. Эффективные алгоритмы это одна сторона дела. Есть и другие, где профессионализм разработчиков и потребности бизнеса находят друг друга. Например — проектирование архитектуры программы. Прошаренный бизнес уже понял, что хотя пользователю плевать на правильно внутреннее устройство программы, качественно спроектированный и написанный продукт выгоден самому бизнесу, поскольку его сопровождение и развитие проще и дешевле. Есть, правда, и непрошаренный бизнес. На моей прошлой работе директор департамента разработки один раз додумался до явного запрета рефакторинга (дескать, мы тут деньгу зашибаем, а не а красивый код пишем). Я, кстати, уволился оттуда примерно в то же время из-за сопутствующих маразмов. Зато в там, где я сейчас работаю (как минимум в некоторых командах), качеству кода и дизайна придается значение, что радует.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Не прав. И причину твоей неправоты ты сам же и указал — "На скорость это не влияло, на память — довольно серьезно, но не так уж существенно". То есть, принятое студентом решение не влияло сколько-нибудь существенно на работу программы, требование же минимизации используемой памяти не формулировалось вообще, не так ли?
Да, все верно.
>Значит, все требования, предъявленные к программе на этапе разработки, были выполнены; и не выполненных требований не было.
Совершенно верно.
>А вот ты — сам придумал себе проблему на ровном месте, да еще и бедному студенту устроил выволочку ни за что.
То есть я должен был ему это спустить и не обращать внимание на это ? Пусть и дальше так же пишет!
Допустим.
Но тогда он мне с полным основанием в следующий раз скажет — ПЛ, вы же прошлый раз видели у меня такой же код и слова не сказали. Ну я и сейчас то же самое написал, да более того, оттуда и взял. И раз это код был хорош тогда, значит и сейчас верно. Но сейчас у меня это в память не помещается (задача другая). А раз так — значит, эту задачу при такой памяти решать невозможно...
Но теперь у меня к тебе вопрос. А почему, собственно, я должен был это пропустить? Да, удовлетворяет ТЗ и т.д. Но написано халтурно, не споришь ? И затраты на то, чтобы написать как следует — мизерные, если не нулевые. Я бы понял, если бы речь шла о полной переделке всей структуры проекта, а то ведь мелочь, но позволит сэкономить половину памяти. Почему же я должен был промолчать ?
Вменяемый заказчик на подобное ведется крайне редко. И попутно спрошу: у твоих конкурентов действительно то же самое? 
