Деньги компаниями зарабатываются по разному. Можно сидеть на госзаказе («трубе») и втюхивать разное дерьмо за нереальные деньги. На коммерческом же рынке, как правило, такое не прокатывает, ведь помимо дурного ФЗ-94 есть еще рынок и конкуренция.
И не очень понятно, почему программист должен сам по себе «оптимизировать код на 5%»? Это менеджеры как раз должны сказать: чтобы мы продавали больше, нам надо, чтобы производительность была на xx% выше, чем у такого-то конкурента.
Комментарий на правах feedback-a…
Для такого названия поста слишком несистемно представлена информация, больше похоже на обрывки мыслей. Значительно ценнее опыт применения для решения конкретных задач, желательно с указанием особенностей проекта(ов), «граблей», на которые Вы наступили, и находках (нестандартные варианты использования, например), которые позволили получить синергетический эффект от использования, пусть даже в Вашем конкретном проекте.
Мы у себя, например, два года выстраивали процессы коллективной разработки распределенной команды программистов (два офиса в Москве, один в Дубне). Используем, собственно, описанные Вами инструменты: redmine, svn и др. Думаю, принципиально ничего бы не поменялось, если бы вместо redmine был trac, а вместо svn — git. Само сложное и основное было правильно выстроить процессы. Использование конкретных инструментов — дело вторичное. Если нечего автоматизировать, то можно и кучу денег вбухать в коммерческие инструменты — работа не станет эффективнее.
Делитесь реальным опытом и люди к Вам потянутся!:)
Удачи.
Николай,
я не призываю в каждом случае фанатично ставить пустые ветки ELSE:)
На самом деле, наличие такой ветки больше вписываются в Ваше мировоззрение — все-таки «else {}» — это код, который «говорит сам за себя»;)
Я говорю лишь то, что не вижу ничего зазорного в том, чтобы использовать такую конструкцию, если по смыслу окружения могут закрасться сомнения — вот и все!
p.s. Я реально не вижу смысла в продолжении этой ветки дискуссии, чтобы не превращать обсуждение в балаган, что настойчиво пытаются сделать два товарища далее по тексту:). Предмета для спора просто нет:)
>>Если то, что Вы отметили как "#error" должно препятствовать компиляции — то какой смысл такое писать?
Это может быть субъективно, но сознание более свободно, когда описываешь программу, а не пишешь ее, если Вы меня понимаете:) Это как на доске сначала нарисовать, а потом уже начать делать.
Я не понимаю, почему тесты так упорно противопоставляются комментариям в коде. Одно другому не мешает!
Что касается «избыточной ветки ELSE».
Case1. Программист дочитал до этого ELSE и подумал (как Вы, например) «нафига здесь эта пустую ничего не означающая ветка?» — это мысль на доли секунды, такой риторический вопрос, ответ на который дан в комментарии; код читается дальше с мимолетным ощущением собственной крутости «а я и так все понял бы, без этой тупиковой ветки!»:)
Case2. Программист в поисках ошибки добирается до IF и не видит обработки ветки ELSE. Задумывается, начинает смотреть, а что означает эта другая отсутствующая ветка с точки зрения входных данных, даже находит заботливо подготовленный старшим товарищем unit-тест, запустив который, убеждается, что зря параноил. 5 минут тоже не так много в масштабе вселенной, но… против долей секунды в Case1 — неприлично много.
Имхо,
тесты отвечают на вопрос «оно все еще работает?», а комментарии отвечают на вопрос «почему оно работает?».
Это лишь мое скромное мнение, сформированное за 20 лет программирования:)
Да что уж тут! Давайте запишем в корпоративных стандартах, что в команде программистов должны быть только гении, да чтоб еще и мысли друг друга могли читать через время и расстояние. И действительно, о чем мы тут спорим?:)
С комментариями, опять же по моей практике и по моему скромному мнению, значительно больше шансов, что никто ничего не испортит:)
Ок, я постараюсь в следующих постах дать менее «злые» правила, но сразу предупреждаю, что им будет предшествовать гора определений и вспомогательных утверждений:) Это несколько снижает их практическую применимость в реальных условиях, но раз уж у нас формируется узкий «кружок любителей безопасного многопоточного программирования», то побалуемся теоретическими выкладками:)
Не надо говорить за всех, пожалуйста.
Я, например, вообще предпочитаю сначала написать общую структуру программы в виде комментариев todo, а потом уже реализовывать. Какие-то todo остаются «на потом», конечно.
Кому-то жесть, а кому-то… Согласен, что нужна «золотая середина».
Лично я не вижу ничего плохого прописать явно какую-то пустую или тупиковую ветку алгоритма с комментарием "//do nothing", чтобы потом вспомнить, что там действительно «nothing to do». Естественно, делать так повсеместно не призываю:)
Одно время я параноил и расставлял return без параметров в функциях, которые не должны ничего возвращать. Тем самым я подчеркивал, что функция действительно дописана, а я не просто отвлекся от кода и забыл дописать:). Сейчас от этого отошел, но это и есть — поиск «золотой середины»:)
Вы хотите пройти наш путь, я так полагаю:) На старте исследований у нас тоже была мысль свести все к одному примитиву синхронизации — мы не нашли эквивалентного представления, поэтому строили доказательную базу отдельно для мьютексов и отдельно для сигнальных переменных.
1. Описанный Вами фрагмент системы не содержит ситуаций взаимных блокировок, т.к. то, что Вы ошибочно назвали блокировкой, пройдет, когда планировщик вернется к первому потоку и сделает U3 (дав жизнь потоку 3) и U2 (дав жизнь потоку 2) — именно в таком порядке!
2. Видимо, Вы не очень точно трактуете смысл слова «в самом начале»:) Мьютекс, который является спутником сигнальной переменной, должен быть захвачен перед обращением к разделяемому ресурсу, чтобы гарантировать атомарность доступа. Поэтому вполне правомерен захват L3 сразу перед W3 (ребро между ними и есть то самое обращение к разделяемому ресурсу).
>> Однако в данном конкретном случае, разве это не очевидно?
Предметом обсуждения, имхо, является не данный конкретный случай, все-таки, а общий подход.
Знаете, я иногда на проводимых мной собеседованиях прошу кандидата написать несложную программу за ограниченное время. Задачи, как правило просты и их сложно не решить, но меня интересует, как человек оформит это свое простое решение, понимая, что сразу после того, как оно будет представлено, оно отправится в помойку, а еще и времени мало. Для меня очень показательно, если человек в любом случае аккуратно оформляет код, называет переменные и функции осмысленно и проч.
Также и «в данном конкретном случае». Если не задумываешься об этом на маленьких проектах, то в большие никто не пустит:)
Константы следует выносить на видное место хотя бы ради того, чтобы подчеркнуть, что какая-то цифирь оказалась захардкожена в программу! А в комментарии необходимо указать, почему выбрано именно такое значение, какие значения возможны еще и как программа будет работать при установке этих других значений. Поверьте, это существенно облегчит жизнь Вашим последователям.
И не очень понятно, почему программист должен сам по себе «оптимизировать код на 5%»? Это менеджеры как раз должны сказать: чтобы мы продавали больше, нам надо, чтобы производительность была на xx% выше, чем у такого-то конкурента.
Для такого названия поста слишком несистемно представлена информация, больше похоже на обрывки мыслей. Значительно ценнее опыт применения для решения конкретных задач, желательно с указанием особенностей проекта(ов), «граблей», на которые Вы наступили, и находках (нестандартные варианты использования, например), которые позволили получить синергетический эффект от использования, пусть даже в Вашем конкретном проекте.
Мы у себя, например, два года выстраивали процессы коллективной разработки распределенной команды программистов (два офиса в Москве, один в Дубне). Используем, собственно, описанные Вами инструменты: redmine, svn и др. Думаю, принципиально ничего бы не поменялось, если бы вместо redmine был trac, а вместо svn — git. Само сложное и основное было правильно выстроить процессы. Использование конкретных инструментов — дело вторичное. Если нечего автоматизировать, то можно и кучу денег вбухать в коммерческие инструменты — работа не станет эффективнее.
Делитесь реальным опытом и люди к Вам потянутся!:)
Удачи.
я не призываю в каждом случае фанатично ставить пустые ветки ELSE:)
На самом деле, наличие такой ветки больше вписываются в Ваше мировоззрение — все-таки «else {}» — это код, который «говорит сам за себя»;)
Я говорю лишь то, что не вижу ничего зазорного в том, чтобы использовать такую конструкцию, если по смыслу окружения могут закрасться сомнения — вот и все!
p.s. Я реально не вижу смысла в продолжении этой ветки дискуссии, чтобы не превращать обсуждение в балаган, что настойчиво пытаются сделать два товарища далее по тексту:). Предмета для спора просто нет:)
Это может быть субъективно, но сознание более свободно, когда описываешь программу, а не пишешь ее, если Вы меня понимаете:) Это как на доске сначала нарисовать, а потом уже начать делать.
Критичные TODO можно написать так:
Менее критичные так:
А совсем «на потом» так:
Что касается «избыточной ветки ELSE».
Case1. Программист дочитал до этого ELSE и подумал (как Вы, например) «нафига здесь эта пустую ничего не означающая ветка?» — это мысль на доли секунды, такой риторический вопрос, ответ на который дан в комментарии; код читается дальше с мимолетным ощущением собственной крутости «а я и так все понял бы, без этой тупиковой ветки!»:)
Case2. Программист в поисках ошибки добирается до IF и не видит обработки ветки ELSE. Задумывается, начинает смотреть, а что означает эта другая отсутствующая ветка с точки зрения входных данных, даже находит заботливо подготовленный старшим товарищем unit-тест, запустив который, убеждается, что зря параноил. 5 минут тоже не так много в масштабе вселенной, но… против долей секунды в Case1 — неприлично много.
Имхо,
тесты отвечают на вопрос «оно все еще работает?», а комментарии отвечают на вопрос «почему оно работает?».
Это лишь мое скромное мнение, сформированное за 20 лет программирования:)
С комментариями, опять же по моей практике и по моему скромному мнению, значительно больше шансов, что никто ничего не испортит:)
Я, например, вообще предпочитаю сначала написать общую структуру программы в виде комментариев todo, а потом уже реализовывать. Какие-то todo остаются «на потом», конечно.
Лично я не вижу ничего плохого прописать явно какую-то пустую или тупиковую ветку алгоритма с комментарием "//do nothing", чтобы потом вспомнить, что там действительно «nothing to do». Естественно, делать так повсеместно не призываю:)
Одно время я параноил и расставлял return без параметров в функциях, которые не должны ничего возвращать. Тем самым я подчеркивал, что функция действительно дописана, а я не просто отвлекся от кода и забыл дописать:). Сейчас от этого отошел, но это и есть — поиск «золотой середины»:)
1. Описанный Вами фрагмент системы не содержит ситуаций взаимных блокировок, т.к. то, что Вы ошибочно назвали блокировкой, пройдет, когда планировщик вернется к первому потоку и сделает U3 (дав жизнь потоку 3) и U2 (дав жизнь потоку 2) — именно в таком порядке!
2. Видимо, Вы не очень точно трактуете смысл слова «в самом начале»:) Мьютекс, который является спутником сигнальной переменной, должен быть захвачен перед обращением к разделяемому ресурсу, чтобы гарантировать атомарность доступа. Поэтому вполне правомерен захват L3 сразу перед W3 (ребро между ними и есть то самое обращение к разделяемому ресурсу).
Предметом обсуждения, имхо, является не данный конкретный случай, все-таки, а общий подход.
Знаете, я иногда на проводимых мной собеседованиях прошу кандидата написать несложную программу за ограниченное время. Задачи, как правило просты и их сложно не решить, но меня интересует, как человек оформит это свое простое решение, понимая, что сразу после того, как оно будет представлено, оно отправится в помойку, а еще и времени мало. Для меня очень показательно, если человек в любом случае аккуратно оформляет код, называет переменные и функции осмысленно и проч.
Также и «в данном конкретном случае». Если не задумываешься об этом на маленьких проектах, то в большие никто не пустит:)