Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 120
Просто брать людей, которые работают на результат. Возможно, для этого не придется ничего кодировать.
Феерический бред не имеющий никакого отношения к языку.
Я не хотел приводить конкретных примеров проблем, с которыми сталкивался. Я рассчитывал, что каждый сможет увидеть свои собственные камни, которые следует обойти. Кто-то излишне использует шаблоны только потому, что это умеет. Кто-то не может без применения паттернов решить задачу, которая без них делается существенно проще. Если у вас нет таких проблем, то расскажите как вы их решили. Каких успехов добились. Какой продукт разрабатывали? Уверен, что это интересно не мне одному.
То что кто-то чрезмерно использует шаблоны — это не вина языка!
Все ваши проблемы не имеют отношения к языку — это проблемы людей.
Для того чтобы это осознать, настоятельно рекомендую к прочтению
труд Страуструпа «Дизайн и эволюция языка С++»
Эта книга дает полное представление, почему язык выглядит именно так а не иначе,
и как в нем появлялись те или иные возможности.
А на фразу «Кто-то излишне использует шаблоны только потому, что это умеет.»
можно легко дать контр аргумент «Кто-то излишне боится шаблонов только потому, что это не умеет.»
Все ваши проблемы не имеют отношения к языку — это проблемы людей.
Для того чтобы это осознать, настоятельно рекомендую к прочтению
труд Страуструпа «Дизайн и эволюция языка С++»
Эта книга дает полное представление, почему язык выглядит именно так а не иначе,
и как в нем появлялись те или иные возможности.
А на фразу «Кто-то излишне использует шаблоны только потому, что это умеет.»
можно легко дать контр аргумент «Кто-то излишне боится шаблонов только потому, что это не умеет.»
Все проблемы идут от людей. Язык формализован, а люди — нет. С этим никто не спорит.
Но речь не шла о том, чтобы совсем отказаться от шаблонов. Пример, который я упомянул вскользь касался того, что если я умею писать шаблоны, то это не значит, что их нужно использовать везде. Не имеет смысла делать шаблонный класс, который будет использован в проекте один раз и никогда больше не понадобится. А 99% функциональности и универсальности «на будущее» как показывает практика не используется никогда. Это лишь удорожает процесс разработки и вместо получения продукта на выходе «правильная » (в кавычках) архитектура, для доработки которой требуются ещё средства.
Но речь не шла о том, чтобы совсем отказаться от шаблонов. Пример, который я упомянул вскользь касался того, что если я умею писать шаблоны, то это не значит, что их нужно использовать везде. Не имеет смысла делать шаблонный класс, который будет использован в проекте один раз и никогда больше не понадобится. А 99% функциональности и универсальности «на будущее» как показывает практика не используется никогда. Это лишь удорожает процесс разработки и вместо получения продукта на выходе «правильная » (в кавычках) архитектура, для доработки которой требуются ещё средства.
Проблема в том, что понятие «правильно» для каждого своё, и всё упирается в психологию. Как бы ни хотелось, единственно верного ответа, или понимания не существует. Поэтому я думаю, что демократии в разработке не место, нужна диктатура :) Каждый может высказать предложения, но важные решения принимает специально назначенный для этого человек. Его достоинства должны заключаться не в том, что он цитирует по памяти труды классиков, а в том, что он трезво оценивает последствия принятых решений. Другими словами, чтобы управлять командой талантливых артистов (от слова «art» — искусство) нужен скромный работяга.
Вот! Все проблемы от людей, так причем же здесь С++, который вы так усиленно хаете.
Нет ни одной строчки о том, что C++ плохой. Для меня это лучший язык) Смысл статьи в поиске компромисса для командной разработки большого проекта. Для минимизации количества ошибок и улучшения сопровождаемости кода должны быть введены разумные ограничения в рамках этого проекта. Попытка все сделать идеально и универсально лишь усложняет код и вносит ошибки. Заставляет разработчика тратить на задачу больше времени чем нужно. А если он ответственный — меньше спать.
Заметил, что вы много пишете о QT. Мы для кроссплатформенности также стали её использовать. Но, простите, QT Creator по сравнению с MSVC настолько сырая IDE. До сих пор после того как заберешь из репозитория часть изменений, которые относятся к нескольким библиотекам в одном проекте, он упорно не понимает, что нужно пересобрать их все и в результате после линковки не работающая программа. Требуется обязательно пересобрать все дерево. А когда оно собирается 15 минут, это очень напрягает. Но тем не менее создатели QT молодцы. Они стремятся сделать идеальный продукт. Это видно. Но они выпускают версии, в которых постепенно появляются улучшения. Если попытаться сделать это сразу — ничего не выйдет.
Обнадеживает, что Qt и Creator выходят очень часто. За этот год ЕМНИП уже 3 или 4 релиза. В отличие от той же студии. Да, пока он отстает конечно, но я думаю это дело времени
Даже страшно представить, что Вы разрабатываете, что у вас полная пересборка занимает 15 минут, у меня Qt из сорсов весь собирается за 25.
Да и кто вам запрещет на Windows продолжать использовать MSVC?
Коли куплены ицензии — пользуйтесь на здоровье Visual Studio Add-in вам в помощь
Да и кто вам запрещет на Windows продолжать использовать MSVC?
Коли куплены ицензии — пользуйтесь на здоровье Visual Studio Add-in вам в помощь
Ну привет. Похоже, вы про INCLUDEPATH и DEPENDPATH в файле qmake-проекта не слышали. Ну дык документацию читать надо, раз уж используете тулзу :) Все отлично он пересобирает, но для этого просто надо указать пути по которым могут лежать изменяющиеся файлы, у меня DEPENDPATH обычно совпадает с INCLUDEPATH. Таким образом, при создании мейк-файлов будут просканированы депенденси конкретных файлов от конкретных хидеров и в дальнейшем при каждой сборке мейк будет проверять данные файлы на наличие изменений.
Более чем слышали. В Linux этот функционал работает хорошо. А в Windows все равно переодически возникают такие вещи. Даже когда выполняешь для всего проекта «CleanAll» он все равно собирает с ошибками. Требуется зайти в папку со всеми объектниками, удалить её и пересобрать заново.
Тогда сорри, под виндой я по-старинке MSVC собираю :) Ибо таки отладчик в разы удобнее. Зафайлите им багу что ли. Вообще надо сравнить мейкфайлы результирующие, там два варианта — или они ошибаются в путях, или в определении факта изменения конкретного файла. Скорее всего там первое и какая-нибудь беда со слешами.
Мы точно также переходили на Qt Creator в расчете на то, что будем делать автоматически solution для студии и отлаживаться там (не хотелось сопровождать несколько проектных файлов для разных IDE). В итоге оказалось, что он не может нормально помещать туда различные user defined build steps (NASM/YASM).
Так что работа и отладка теперь в QtCreator'е. Правда если где-то «падает» — запускаем отладчик от MSVC.
Так что работа и отладка теперь в QtCreator'е. Правда если где-то «падает» — запускаем отладчик от MSVC.
Все очень просто. Code review. Не понравился код — reopen задачи и пусть переделывает.
Это сложный путь. Так как тратится время. А оно является очень ценным. Необходимо предупредить, а не заставить переделать. Да и психологически такому разработчику несмотря на то, что он не прав, будет сложно так постоянно работать.
Мне не жалко время на отсмотр кода, благо у нас для этого есть специальные инструменты. Более того, я часто трачу время на рефакторинг и своего и чужого кода, и не считаю это время потерянным.
Психологической проблемы тоже нет. Более того, разработчик даже сам хочет, чтобы я посмотрел его код :)
Психологической проблемы тоже нет. Более того, разработчик даже сам хочет, чтобы я посмотрел его код :)
Речь не о потере времени на отсмотр кода. Речь о потере времени на написание кода, который нужно будет переделать. Вы уже потратили время разработчика. А я говорю, что лучше заранее предупредить такую ситуацию, чтобы не пришлось переписывать.
Да, лучше. Но Вы же сами сказали, что идеального не бывает. Поэтому и приходится иногда переписывать код, и рефракторить. Да, и время больше тратиться не на переписывание кода, а на лазанье в интеренете и пустые споры… :)
Думаю, что споры не могут быть пустыми. Если не удается прийти к общему мнению, то для кого-то из команды процесс разработки может перестать доставлять радость и превратится в рутину. Если это происходит постоянно, то вряд ли команда долго продержится.
Очень даже могут. Более того, если не будет «авторитета», то они могут продолжаться очень долго.
Если кому то программирование не доставляет радость, а обычная рутина, ему стоит задуматься о смене деятельности. Работа должна доставлять радость. Именно поэтому я навряд ли пойду программистом баз данных или web-а, и буду продолжать работать там где мне интересно, пусть и за меньшие деньги.
Если кому то программирование не доставляет радость, а обычная рутина, ему стоит задуматься о смене деятельности. Работа должна доставлять радость. Именно поэтому я навряд ли пойду программистом баз данных или web-а, и буду продолжать работать там где мне интересно, пусть и за меньшие деньги.
>Кто-то не может без применения паттернов решить задачу, которая без них делается существенно проще.
Может делается она и проще, но будет ли проще в поддержке? Одно из назначение (или следствие?) паттернов как раз облегчение поддержки кода, прежде всего новым человеком в проекте.
Может делается она и проще, но будет ли проще в поддержке? Одно из назначение (или следствие?) паттернов как раз облегчение поддержки кода, прежде всего новым человеком в проекте.
Я вообще понял, что затронул весьма и весьма спорную тему. И трудно выделить некую четкую грань за которую переступать нельзя. Слишком много переменных состояния по которым следует производить оптимизацию. Использовать паттерны или нет? Я считаю, что не стоит, если задача решается без них куда понятнее и в результате получается простое и очевидное решение. Это как те же шаблоны. Их очень удобно использовать, но они сложнее в разработке. Тут важно понимать какие цели преследуются. Я говорю, что цель должна быть одна — готовый продукт в разумные сроки. Можно как Джекки Чан красиво прыгать и полчаса пытаться победить врага, а можно как (не побоюсь его здесь упомянуть) Чак Норрис — с одного удара. Во втором случае цель достигнута быстрее.
Мало того, красивая и правильная архитектура на то и правильная, что она логичная и понятная, а сложные запутанные места запрятаны глубоко и изолированны в хорошо отлаживаемые модули.
Искусство разработки не состоит в том, чтобы получить идеальную разработку за неограниченное время и неограниченный бюджет. Поэтому правильная с коммерческой точки зрения архитектура не всегда соответствует представлениям разработчиков. Все должно быть красиво, логично и понятно в любом случае.
Я отношусь к программированию как к прежде всего искусству, а уже во вторую очередь как к бизнесу. Требования бизнеса слишком часто идут вразрез с красотой, и вообще, нет такого преступления, на которое бы не пошел капитал ради получения дополнительной выгоды.
У бизнеса есть одно важно требование, которое глупо не учитывать — требование завершить разработку и выдать готовый продукт. С идеалистическим подходом этого либо никогда не произойдет, либо процесс затянется настолько надолго, что результат просто не будет нужен. В IT-области все развивается огромными темпами. Нет времени на промедление и оттачивание того, что принципиально и качественно не влияет на конечный результат.
Элементарный пример правильной и неправильной архитектуры:
Но, зато, вот хорошая:
В таком случае я за плохую.
goto — плохая архитектура. Но, зато, вот хорошая:
do{
if(...)
break;
return true;
}
while(1);
return false;
В таком случае я за плохую.
Полярность «правильно» — «неправильно» дерется с полярностью «хорошо» — «плохо» и «нравится» — «не нравится». Когда понимаешь, что делать «правильно» — это «плохо», но при этом «нравится», а делать «неправильно» — «это хорошо», но «не нравится» — хочется сменить род деятельности )
...while(0); скорее
Лично я — за второй вариант с циклом. Да, излишне, но goto (кажется уже говорил это в теме о goto) нарушает логику блоков. Жаль, что в новом стандарте не сделали изменений этой опасной конструкции.
Лично я — за второй вариант с циклом. Да, излишне, но goto (кажется уже говорил это в теме о goto) нарушает логику блоков. Жаль, что в новом стандарте не сделали изменений этой опасной конструкции.
по-моему ваш пример вырождается в
return !(...);Имеется ввиду, что там может быть много условий, каждое из которых может не выполнится и тогда следует «чистить» память после цикла. А если все прошло, то return true;
Очень популярная и «правильная» конструкция. Но как мне кажется менее очевидная, и простая чем goto.
Очень популярная и «правильная» конструкция. Но как мне кажется менее очевидная, и простая чем goto.
почему бы не выделить эти условия в отдельную функцию, проверять результат и, при необходимости, чистить?
А если условий 10. На каждом условии происходит выделение памяти. И вот на 5 условии что-то не срабатывает. Требуется очистить не только то, что касается 5го условия, но и предыдущие 4. Можно это решить без goto как минимум двумя способами (кроме приведенного выше):
1. Обрабатывать исключения (если они используются) и производить очистку в той же функции со всеми условиями. Это как минимум наглядно.
2. Создать отдельный класс, который будет хранить все данные и в случае не успеха в том же деструкторе чистить за собой все. Это уже не так наглядно и требует больше кода, но безопасно.
1. Обрабатывать исключения (если они используются) и производить очистку в той же функции со всеми условиями. Это как минимум наглядно.
2. Создать отдельный класс, который будет хранить все данные и в случае не успеха в том же деструкторе чистить за собой все. Это уже не так наглядно и требует больше кода, но безопасно.
Это не архитектура вообще
Вы серьёзно считаете второй вариант хорошей архитектурой?
Читаем внимательно. Это пример того, что считается хорошей архитектурой. Но мне не нравится этот «хороший» вариант.
Кем считается?
Вот очень хорошая статья: habrahabr.ru/blogs/cpp/114211/
Там в качестве примеров приводится «как надо» и автор также не соглашается с тем, что от goto следует полностью отказаться в таких случаях.
Там в качестве примеров приводится «как надо» и автор также не соглашается с тем, что от goto следует полностью отказаться в таких случаях.
Мой рецепт — «Метод маленьких шажков». Хотя почему мой, Microsoft тоже так работает. И другие тоже.
«Каждое задача на изменение должна быть заметна и приводить к реальным результатам в обозримые сроки». То есть отдельные программисты должны получать задачи на неделю (максимум), после чего делается ребилд системы. Если задачи розданы согласовано, то проект не соберется и остальные не смогут идти дальше.
«Каждое задача на изменение должна быть заметна и приводить к реальным результатам в обозримые сроки». То есть отдельные программисты должны получать задачи на неделю (максимум), после чего делается ребилд системы. Если задачи розданы согласовано, то проект не соберется и остальные не смогут идти дальше.
Метод очень правильный. Задача от забора и до обеда. Только его проблема в полном исключении творчества. А в таком виде очень непросто привлечь на работу талантливых разработчиков, которые смогут давать результат качественно превосходящий ожидания. С другой стороны снижены риски уходов в сторону. Хочется найти некую золотую середину.
Это два характерных подхода. Один — «это бизнес, ребята». Есть бюджет, есть сроки, есть задачи. Творчество в очень ограниченных порциях. Типично: «Мне почти стыдно было это коммитить, но это работает».
Другой подход — «это памятник Нам» — типично: «лучше сдать чуть позже, но написать так, чтоб всё ващще!».
Как показала практика — пока работает, в код никто не смотрит. Работает, и ладно. Но второй подход добавлят удовольствия разработчикам, и седых волос менеджерам ))) Чем искать золотую середину — можно попробовать чередовать задачи. Возможно ли в рамках одного проекта жестко настаивать в одних решениях, а другие отдавать на откуп разработчикам?
Другой подход — «это памятник Нам» — типично: «лучше сдать чуть позже, но написать так, чтоб всё ващще!».
Как показала практика — пока работает, в код никто не смотрит. Работает, и ладно. Но второй подход добавлят удовольствия разработчикам, и седых волос менеджерам ))) Чем искать золотую середину — можно попробовать чередовать задачи. Возможно ли в рамках одного проекта жестко настаивать в одних решениях, а другие отдавать на откуп разработчикам?
Лично я против того, что «стыдно коммитить». Код должен быть прост, понятен и делать самую главную вещь — работать. Только зачем тратить большую часть времени на сверх быстрое рисование кнопки в диалоговом окошке, когда можно взять стандартную реализацию из того же QT и решать задачу настоящей проблемной области. Пример утрированный, но смысл такой.
Полностью согласен. Насчет «стыдно» коммитить — я не имел в виду случаи, когда коммитится явный брак. Я про то, что задача бывает решена «в лоб» и «не элегантно». К сожалению, на элегантность иногда не хватает времени. Я только об этом. Как уже написали ниже — это борьба с перфекционизмом.
Я тоже полностью согласен, но есть основная проблема в том, что когда погружаешься в задачу, то увлекаешься и начинаешь решать самый общий случай. Очень трудно себя остановить.
Скажем если надо достать 5-й элемент листа, то вместо того чтобы ПРОСТО его достать часто ловлю себя на том, что хочется написать функцию, которая будет доставать N-й, и попросить у нее 5-й. А уж как иногда хочется написать программу, которая будет писать программы за тебя… ууу… =)
В общем человек есть человек.
Скажем если надо достать 5-й элемент листа, то вместо того чтобы ПРОСТО его достать часто ловлю себя на том, что хочется написать функцию, которая будет доставать N-й, и попросить у нее 5-й. А уж как иногда хочется написать программу, которая будет писать программы за тебя… ууу… =)
В общем человек есть человек.
*sigh*… Вот эта библиотека называется «Qt». «QT» — это QuickTime.
Ни одного упоминания на первой странице Google о QuickTime по запросу «QT». Но вы правы. Пишется именно так как вы написали выше.
Ну, справедливости ради — десятым номером оно всё-таки идёт.
Нет-нет, я не говорил об «отмене творчества». Подразумевается, что разработчик должен научиться четко описывать набор шагов, которые собирается сделать (даже в рамках написания одной «гениальной» функции). И так, чтобы шаги были измеримы по времени и приносили видимый результат.
Например, «элементарная» задача может выглядеть так:
«Нужно изменить наименование переменной х100500 и откомментировать все строки, где она используется».
И обязательно нужно сделать замену по всему коду, не отвлекаясь, а то иногда вводишь переменную, а затем мысль «растекается по древу» и вот — код уже не собирается.
Например, «элементарная» задача может выглядеть так:
«Нужно изменить наименование переменной х100500 и откомментировать все строки, где она используется».
И обязательно нужно сделать замену по всему коду, не отвлекаясь, а то иногда вводишь переменную, а затем мысль «растекается по древу» и вот — код уже не собирается.
Цитата из статьи: «Я не могу совершенно точно назвать причину происходящего с точки зрения психологии или здравого смысла.»В статье идет ре
Замените в тексте C++ на Java — и ни хрена не изменится. Теперь замените Java на Python. Чёрт, опять ни хрена не изменилось! Теперь замените Python на Perl… да что ж это такое, опять ни хрена не изменилось!
Да это же идеальная статья: она абсолютно инвариантна относительно языка! %)
Да это же идеальная статья: она абсолютно инвариантна относительно языка! %)
Можно заменить хоть на проектирование межпланетных ракет, хоть на разработку вакцины от гриппа.
На вакцины — это вряд ли. Потому что людям приходится работать с тем, что есть, а не с тем, как сделать идеально, потому что у них просто нет того уровня контроля, который есть у программистов. И аппаратных инженеров контроля над ситуацией больше, но всё равно не столько же, сколько у программиста.
Вакцину можно до бесконечности тестировать на мышах, обезьянах, добровольцах, пытаться избавиться от какого-нибудь мелкого побочного эффекта, вроде диареи. А можно сказать «стоп, нормально и так» и выкатить на рынок.
«Всю жизнь он преподавал как снимать кино, и за все это время снял пару фильмов «не для всех». Искусство. Среди своих он, возможно, добился почтения. Но для меня, как человека далекого от «профессионального» кино его слова о том насколько ужасен и вульгарен «Аватар» и его создатель Кэмерон звучали, мягко говоря, смешно.»
у меня другое мнение. «там где пьет толпа, источники отравлены». просто для вас программирование инженерная дисциплина а для кого-то искусство)
хотя некоторые говорят что время убивать драконов прошло я в это не особенно верю)
у меня другое мнение. «там где пьет толпа, источники отравлены». просто для вас программирование инженерная дисциплина а для кого-то искусство)
хотя некоторые говорят что время убивать драконов прошло я в это не особенно верю)
Тогда нужно признать, что это искусство. Как кино не для всех. Которое не приносит деньги. И заниматься им самостоятельно как хобби. И это правильно. Так делаю я и так делают здравомыслящие люди в свободное время. Но часто бывает перекос. Как у того режиссера, который с одной стороны кричит как плох Кэмерон, с другой стороны требует финансирования государства. А почему нельзя снять кассовый фильм, а потом фильм для себя? Вполне нормально в рабочем процессе наличие вещей, которые не нравятся, но их нужно делать.
«Я считаю, что не надо делать плохо, надо делать хорошо. И ещё, вот, С++.»
(с) краткое содержание статьи
(с) краткое содержание статьи
Мне понравилось высказывание одного известного гитариста. Сначала, когда вы только учитесь играть у вас будут плохо получаться простые композиции. Потом вы улучшите свои навыки и у вас будут получаться плохо сложные композиции. Наберитесь терпения и вы станете профессионалом — у вас будут виртуозно получаться простые композиции.
я описывал как раз второй этап. Так как к третьему люди уже понимают, что красота не в сложности, а в простоте.
А по поводу ширпотреба. Мне нравились в детстве мультфильмы Диснея. И Аватар сделан очень здорово. У всех свое мнение относительно того, что является искусством. Для меня это IPhone. Успешный массовый продукт. А для кого-то искусство мобильная OS, которую этот кто-то пилит уже 10 лет, пытаясь сделать ее идеальной, но так и не доделывает, тихо ненавидя Джобса за его «ширпотреб».
я описывал как раз второй этап. Так как к третьему люди уже понимают, что красота не в сложности, а в простоте.
А по поводу ширпотреба. Мне нравились в детстве мультфильмы Диснея. И Аватар сделан очень здорово. У всех свое мнение относительно того, что является искусством. Для меня это IPhone. Успешный массовый продукт. А для кого-то искусство мобильная OS, которую этот кто-то пилит уже 10 лет, пытаясь сделать ее идеальной, но так и не доделывает, тихо ненавидя Джобса за его «ширпотреб».
>> У всех свое мнение относительно того, что является искусством. Для меня это IPhone.
Так вот чтобы он был успешно-массовым его долго полировали тряпочкой в т.ч. те самые инженеры «изобретатели велосипедов» от которых вы нос воротите.
Если тот самый xml парсер или ещё какая шняга создаёт ощутимую задержку и портит експириенс, нужно написать тот, который будет в «3 раза быстрее».
Так вот чтобы он был успешно-массовым его долго полировали тряпочкой в т.ч. те самые инженеры «изобретатели велосипедов» от которых вы нос воротите.
Если тот самый xml парсер или ещё какая шняга создаёт ощутимую задержку и портит експириенс, нужно написать тот, который будет в «3 раза быстрее».
Вы считаете IPhone идеальным? В версии 4 можно найти предостаточно проблемных мест, а в предыдущих — ещё больше. Это пример классного продукта, который закончили и выпустили. Его можно назвать лучшим, но он не идеален. Иначе к чему версия 5 и постоянные обновления предыдущих прошивок.
>> Вы считаете IPhone идеальным?
Где я это написал? Идеальный или нет, но вы фразой про айфон перечеркнули весь смысл своего опуса. С точки зрения разработки iPhone это плод изнурительной «велосипедной» работы, а не франкенштейн из фришных библиотек на железе «с полки».
Где я это написал? Идеальный или нет, но вы фразой про айфон перечеркнули весь смысл своего опуса. С точки зрения разработки iPhone это плод изнурительной «велосипедной» работы, а не франкенштейн из фришных библиотек на железе «с полки».
«Франкенштейн из фришных библиотек на железе с полки». Никогда не предлагал такого подхода и таких оценок. И своей фразой я нисколько не перечеркнул смысл статьи. Попробуйте открыть на первом или последнем IPad Google Maps в браузере. На устройстве, которое создано по большей части для доступа к WEBу многие сайты полноценно не работают. Его не сделали идеальным. Не самым важным функционалом пренебрегли (MMS на первых IPhone) и сделали все правильно. Концентрировались на важном.
Например, для того чтобы заработать больше денег?
Чтобы выдать продукт. С какой целью на свет он появляется не тема данной статьи. И если говорить о деньгах, то нет разницы в качестве жизни если у тебя есть миллиард долларов или десять миллиардов. Джобс продал Pixar за 8. Деньги у него были. Это делалось не ради них. Можно сказать ради спортивного интереса. Это потрясающая задача суметь поднять компанию за 10 лет с самого низа на самый верх. Она сама по себе интересна без всяких денег.
>>У всех свое мнение относительно того, что является искусством. Для меня это IPhone
Почему его до сих пор не выставили в Третьяковке!!?? Безобразие!
Почему его до сих пор не выставили в Третьяковке!!?? Безобразие!
Программирование это скорее профессия, чем искусство, и его цель создать продукт, кто бы спорил.
Нужно построить процесс разработки удобно для командной работы, несомненно.
Для этого предлагается набрать команду «средних» программистов, и пусть они пишут «простой» код, понятный всем в команде, читай, самому «среднему». Полностью не согласен!
Это, просто, не работает (проверено на личном опыте, сам был когда-то «средним»). В какой-то момент, этот «простой» код коллапсирует под собственной тяжестью, внести изменение в проект становится с каждым разом всё сложнее и вызывает всё больше ошибок.
Так уж вышло, что именно сейчас мне приходится доводить до ума такой «простой» проект. Если бы не это, и писать бы не стал, а так — задело.
Пара примеров «простоты».
Вместо того чтобы написать «сложный» шаблон функции, «проще» скопировать её 20 раз (серьёзно).
Вместо того, чтобы использовать «сложные» умные указатели, или хотя бы шаблон класса для хранения указателя, используется структурка, хранящая номер типа и DWORD под указатель, и чтобы получить сам указатель нужно проверить эту структурку на валидность (что объект не удалён), проверить тип и вручную привести к указателю нужного типа. И эти три «простых» действия делаются не в десятке мест, и даже не в сотне, а более чем в трёх тысячах мест. И нет никакой уверенности, что везде правильно.
Сравнение с работой художников тоже не продходит. Если художник напортачил, то его 30 секунд можно просто вырезать или перерисовать. Если напортачил программист, его решение может жить в проекте годами (работает же), заставлять писать такой же «простой» код и делать кучу ошибок.
По-настоящему простой код — это тот, который просто сопровождать, использование которого минимизирует ошибки (умный укзатаель против обычного, контейнер против C-массива и т.д.). Внутри код может быть достаточно сложным, если это позволяет сделать его использование простым и надёжным.
В качестве примера, в другом проекте reflection сделан с помощью внешнего кодогенератора (примерно как в Qt). Сложно — да, но добавление нового поля данных в класс происходит в одном месте — в объявлении класса, и что-то забыть или перепутать просто невозможно. Это я называю простым кодом.
Нужно построить процесс разработки удобно для командной работы, несомненно.
Для этого предлагается набрать команду «средних» программистов, и пусть они пишут «простой» код, понятный всем в команде, читай, самому «среднему». Полностью не согласен!
Это, просто, не работает (проверено на личном опыте, сам был когда-то «средним»). В какой-то момент, этот «простой» код коллапсирует под собственной тяжестью, внести изменение в проект становится с каждым разом всё сложнее и вызывает всё больше ошибок.
Так уж вышло, что именно сейчас мне приходится доводить до ума такой «простой» проект. Если бы не это, и писать бы не стал, а так — задело.
Пара примеров «простоты».
Вместо того чтобы написать «сложный» шаблон функции, «проще» скопировать её 20 раз (серьёзно).
Вместо того, чтобы использовать «сложные» умные указатели, или хотя бы шаблон класса для хранения указателя, используется структурка, хранящая номер типа и DWORD под указатель, и чтобы получить сам указатель нужно проверить эту структурку на валидность (что объект не удалён), проверить тип и вручную привести к указателю нужного типа. И эти три «простых» действия делаются не в десятке мест, и даже не в сотне, а более чем в трёх тысячах мест. И нет никакой уверенности, что везде правильно.
Сравнение с работой художников тоже не продходит. Если художник напортачил, то его 30 секунд можно просто вырезать или перерисовать. Если напортачил программист, его решение может жить в проекте годами (работает же), заставлять писать такой же «простой» код и делать кучу ошибок.
По-настоящему простой код — это тот, который просто сопровождать, использование которого минимизирует ошибки (умный укзатаель против обычного, контейнер против C-массива и т.д.). Внутри код может быть достаточно сложным, если это позволяет сделать его использование простым и надёжным.
В качестве примера, в другом проекте reflection сделан с помощью внешнего кодогенератора (примерно как в Qt). Сложно — да, но добавление нового поля данных в класс происходит в одном месте — в объявлении класса, и что-то забыть или перепутать просто невозможно. Это я называю простым кодом.
Очень правильный комментарий. Но вы привели пример не простоты, а полного не умения писать. Я же говорил о том, что не стоит писать шаблон, если он используется в проекте один раз с одним типом данных (проект известен, поэтому это так). А вы пишите о том, чтобы не использовать шаблон там где это действительно нужно.
По поводу умных указателей. В вашем примере они действительно очень нужны. И такой код я бы не стал называть средним.
И с вашим примером проекта reflection я согласен. Это именно то, что я и называю простым кодом. К сложному я отношу десять уровней абстракции, в каждый из которых требуется внести изменение, чтобы добавить одну переменную.
По поводу умных указателей. В вашем примере они действительно очень нужны. И такой код я бы не стал называть средним.
И с вашим примером проекта reflection я согласен. Это именно то, что я и называю простым кодом. К сложному я отношу десять уровней абстракции, в каждый из которых требуется внести изменение, чтобы добавить одну переменную.
Не очень понятно, как из стремления получить красивый кода может получится 10 уровней подобных абстракций… Это как раз бывает из стремления сделать не красиво, а «правильно», по книжке. Когда у человек страшиться того, что недостаточно крут, и выражает это в переусложнении кода. То есть, это вообще не перфекционизм, а проявление комплекса неполноценности, который Си++ вызывает с лёгкостью уровнем своей навороченности и сложности. Вот. То есть, проблема действительно в Си++ или вот Haskell.
Кармак вот, например, до сих пор из принципа KISS пишет свои движки на чистом Си… Хотя, вроде, Tech5 сделан на Си++, надо будет посмотреть, почему.
Кармак вот, например, до сих пор из принципа KISS пишет свои движки на чистом Си… Хотя, вроде, Tech5 сделан на Си++, надо будет посмотреть, почему.
Спасибо за развернутый ответ и за конструктивную дискуссию.
>>Внутри код может быть достаточно сложным, если это позволяет сделать его использование простым и надёжным.
Вот тут-то и кроется настоящее искусство, в этих «внтури сложных» но простых внешне и не требующих регулярной доработки кусках кода.
Вот тут-то и кроется настоящее искусство, в этих «внтури сложных» но простых внешне и не требующих регулярной доработки кусках кода.
Конечно, использовать готовый код экономически выгоднее, чем писать свой. А «красивость» кода становится крайне важна, как только над проектом начинает работать больше одного человека.
Но. Хранить настройки программы в XML — маразм. И использовать тяжелые, громоздкие, с неудобным интерфейсом, overbloated and overengineered Open-source библиотеки для его парсинга тоже не лучшее решение.
Прежде чем вешать всех собак на программиста, стоило бы разобраться сначала с тем, кто ему ставит такие задачи.
Но. Хранить настройки программы в XML — маразм. И использовать тяжелые, громоздкие, с неудобным интерфейсом, overbloated and overengineered Open-source библиотеки для его парсинга тоже не лучшее решение.
Прежде чем вешать всех собак на программиста, стоило бы разобраться сначала с тем, кто ему ставит такие задачи.
Вы вырываете проблему из контекста. Она состоит в том, что скоростное чтение настроек программы ни разу не важная задача, если при этом сама программа так и не написана. А по поводу способа хранения это уже теологический вопрос. Есть XML, есть JSON, есть INI-файлы. Можете свой бинарный формат разработать. На тот момент нужен был XML и не нужно было тянуть за собой Qt для решения этой задачи. TinyXML замечательно подходил. Тем более это то, что легко меняется на следующем этапе разработки и прямо не влияет на функционирование приложения.
Отвечу здесь, чтобы не захламлять оффтопом основное обсуждение. Если пользуетесь TinyXML, то попробуйте PugiXML от нашего соотечественника — он реально быстрее, и тоже открытый.
>>Хранить настройки программы в XML — маразм
поясните
поясните
1) слишком мощный формат для такой простой задачи
2) требует подключения монструозной неуклюжей бибилиотеки с неудобным интерфейсом только чтобы прочитать несчастные несколько настроек.
2) требует подключения монструозной неуклюжей бибилиотеки с неудобным интерфейсом только чтобы прочитать несчастные несколько настроек.
Вы не знаете задачу. Вы не знаете что должно храниться в настройках и где это будет лежать. Какие приложения и на каких языках будут эти настройки использовать. Поэтому вы не можете делать подобных выводов.
Сейчас работаю над проектом, в котором в настоящий момент 387 настроек, организованных в иерархическом дереве.
И все таки Аватар — вульгарный ширпотреб. I'm just saying.
Вульгарный ширпотреб — это масло масленное, кстати :) А вообще, чему это противоречит? Ну ширпотреб, но сделано то хорошо, со вкусом и высокими технологиями. Как-нить там Моцарт тоже был ширпотребом в своё время — на всех тусовках играли.
Вивальди — еще более вульгарный ширпотреб, где его только не встретишь. От этого его музыка не перестала быть произведение искусства.
Согласен, сопровождение С++ дорогое удовольствие, очень многие компании пытаются переписать по возможности такие модули на более «высокие» языки, типа С# или Java, которые более дешевы в производстве и сопровождении, так сказать.
Но пока есть С++ у меня есть работа, и мне кажется хватит еще моим внукам :)
Но пока есть С++ у меня есть работа, и мне кажется хватит еще моим внукам :)
Что-то я не понял, за что минуса?
Потрудитесь объяснить.
Потрудитесь объяснить.
А некоторые компании (по странному стечению обстоятельств) матерясь переписывают некоторые модули с «более высокой» Java на «ужасный» C++, ибо «высокая» Java банально не тянет.
Может всё-таки сойдёмся на том, что каждому языку — своя ниша, а не будем мериться частными случаями неверного выбора инструмента для решения той или иной задачи?
Может всё-таки сойдёмся на том, что каждому языку — своя ниша, а не будем мериться частными случаями неверного выбора инструмента для решения той или иной задачи?
А где в моем комментарии вы прочитали, что я утверждаю обратное?
У С++ замечательное прошлое, настоящее, и я уверен не менее прекрасное будущее, уже только потому, что кода написанного на С/С++ просто немерено, и нет никакого смысла его переписывать, если он и так работает.
Без С++ вам не обойтись если вы пишите:
+операционную систему
+драйверы или системные модули
+системы критичные ко времени выполнения или ресурсам
+игры ААА класса
+для экзотических платформ (тут у вас просто выбора нет)
НО если вы пишите клиент-серверное бизнес систему, от С++ вам лучше держаться подальше, дороже выйдет, а преимуществ по сути никаких.
У С++ замечательное прошлое, настоящее, и я уверен не менее прекрасное будущее, уже только потому, что кода написанного на С/С++ просто немерено, и нет никакого смысла его переписывать, если он и так работает.
Без С++ вам не обойтись если вы пишите:
+операционную систему
+драйверы или системные модули
+системы критичные ко времени выполнения или ресурсам
+игры ААА класса
+для экзотических платформ (тут у вас просто выбора нет)
НО если вы пишите клиент-серверное бизнес систему, от С++ вам лучше держаться подальше, дороже выйдет, а преимуществ по сути никаких.
>>НО если вы пишите клиент-серверное бизнес систему, от С++ вам лучше держаться подальше, дороже выйдет
Вы меня прям расстроили сейчас. Именно этим и занимаемся, преимущества видим в производительности и кроссплатформенности (Qt).
Вы меня прям расстроили сейчас. Именно этим и занимаемся, преимущества видим в производительности и кроссплатформенности (Qt).
Но все таки QT это C++, как пример достаточно глянуть на количество классов «умных ссылок».
Что бы работать с ними надо найти квалифицированных программистов.
В то время чтобы писать на том же C# достаточно одно хорошего программиста + ревизию кода.
Еще у QT есть некоторые проблемы с развертыванием (dll hell никто не отменял).
Хотя в целом библиотека хорошая.
Что бы работать с ними надо найти квалифицированных программистов.
В то время чтобы писать на том же C# достаточно одно хорошего программиста + ревизию кода.
Еще у QT есть некоторые проблемы с развертыванием (dll hell никто не отменял).
Хотя в целом библиотека хорошая.
«Верить в свои ощущения. » Это плохая фраза для процесса разработки программного обеспечения. Производства, если хотите. Такие вещи должны быть сведены к минимуму. А ощущения следует слушать на этапе принятия решения виде: «А нужна ли кому-то такая программа?» А дальше должен идти совершенно четкий процесс, который приближает к результату.
>А знаете ли вы, что среди художников эти мультфильмы считаются чем-то вроде ширпотреба. Мол, они не являются искусством. Потому, что в свое время Дисней разработал сильно упрощенную и формализованную технику производства таких мультфильмов. Именно это позволило создавать полнометражные ленты над которыми трудились сотни разных художников и не вызвать у зрителя вопросы почему в разных эпизодах герои отличаются.
Вашу проблему решить очень просто. Сотни индусов напишут Вам «равномерно ширпотребный» код. Никто Вам больше не скажет «почему части Вашей прогаммы отличаются — одна глючит, а другая нет». Ваша программа будет равномерно дерьмовой — не придерёшься.
Вашу проблему решить очень просто. Сотни индусов напишут Вам «равномерно ширпотребный» код. Никто Вам больше не скажет «почему части Вашей прогаммы отличаются — одна глючит, а другая нет». Ваша программа будет равномерно дерьмовой — не придерёшься.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С++: как не сделать кино не для всех