Почему не стоит пользоваться аутсорсингом в странах с дешевой рабочей силой

Нет, уважаемый, Вы не правы.

От программиста который «хотя бы работает» или постоянно не высыпается и кодит с температурой гораздо больше вреда чем пользы.

А если программист большую часть дня страдает непонятно чем, то нужен ли такой программист вобще в компании?

Пишу на всяком уже около 10 лет. Серьезно пишу 4 года. НИ ЗА ЧТО не написал бы первый вариант. Это не рационализация.
Это устойчивая конструкция, точно так же, как для цикла с предусловием использутся for а не мешанина из while и if. Хороший программист, имхо, должен использовать второй вариант просто на автомате.

хороший программист работает мало — но в цель

Именно.

Подожди, а сколько за это платят? You american bastards are paying me twenty dollars a week?

Да, MSDN это нечто. Возьмём конкретный пример — BindingNavigator Members (VS 2005).
ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.NETDEVFX.v20.en/CPref17/html/T_System_Windows_Forms_BindingNavigator_Members.htm

Понаписано куча всякой муры, члены от Control, ToolStrip и так далее, хотя в реале это наследуется даже без переопределения. Причём вся документация в таком вот дурацком стиле, свалили всё в одно место, как будь-то им платили за тупую генерацию. Связи с интерфейсами не показаны, ничего по группам не распределено

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

Да здравствует китайский код

private void OnMoveFirst(object sender, EventArgs e)
{
if (this.Validate() && (this.bindingSource != null))
{
this.bindingSource.MoveFirst();
this.RefreshItemsInternal();
}
}

private void OnMoveLast(object sender, EventArgs e)
{
if (this.Validate() && (this.bindingSource != null))
{
this.bindingSource.MoveLast();
this.RefreshItemsInternal();
}
}

private void OnMoveNext(object sender, EventArgs e)
{
if (this.Validate() && (this.bindingSource != null))
{
this.bindingSource.MoveNext();
this.RefreshItemsInternal();
}
}

private void OnMovePrevious(object sender, EventArgs e)
{
if (this.Validate() && (this.bindingSource != null))
{
this.bindingSource.MovePrevious();
this.RefreshItemsInternal();
}
}

Майкрософт любит копипасту и это далеко не самое страшное их преступление. Вот почитайте топик как люди восхищаются новыми возможностями от майкрософт — habrahabr.ru/blogs/net/36601/, оценки говорят сами за себя.

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

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

Это просто непонимание структуры языка. Непонимание, что положительное условие и есть true. Спроси этого индуса, сколько будет 2х2=4 — и он вообще зависнет в сансаре.

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

Кроме того, есть ещё поняти лёгкости восприятия кода.
Судя по постам, многие бы воспользовались второй констукцией (и я в их числе), так не значит ли это, что код, записанный в виде if ( a == b ) return true; else return false; для многих более понятен, и в случае аутсорсинга как раз было бы лучше если бы программист написал так, а не return (a==b);?

Кроме того, учитывая предыдущую мысль в части лёгкости восприятия кода, нужно учитывать ещё что компилятор, возможно, обе строки кода скомпилирует примерно к одному виду, так что в первом случае мы получим понятный текст программы, во втором более гиковый (но менее «читаемый»), а в результате программа будет работать одинаково на уровне кода.
ИМХО!

в этом случае всегда можно переписать код.

Улучшенный вариант:

bool isEqual( one, another )
{
return one == another;
}

bool valueTrue()
{
return True;
}

bool valueFalse()
{
return False;
}

if( isEqual( a, b ) )
{
return valueTrue();
}
else
{
return valueFalse();
}

Если вдруг изменится операция сравнения, а также значения истины и лжи. ;-)

в C# как я писал это делается просто
return a == b;
Признаться, выражение из Ruby режет глаза.

А как читается конструкция на руби?
Массив и элемент под индексом a<=>b?

Хм… а лисповый вариант с (eq a b) не катит? :)

В смысле, что длина «True» <5, в отличие от «False»?:) Я рыдалъ…

В иделе код должен сам комментировать себя.
Я понимаю, что новым людям бывает сложно понять и разобраться в новом проекте. Но согласитесь, если все будут писать так (возьмём мой пример):
— if ( a == b ) return true; else return false;
— не будут использовать паттернов;
— будут постоянно изобретать свои колёса и велосипеды;
— не будут стремиться к новым знаниям в своих областях программирования.
Что получится в итоге? Я думаю многие согласятся, что программирование — это своего рода искусство. Искусство писать красиво, компактно, понятно. Если люди будут делать как им проще и совершать те вещи, которые я перечислил (естественно это не все тезисы, а что пришло в голову), мы получим говнокод. Это будет обычный банальный говнокод, который есть везде и всюду. Никаким искусством не пахнет.
Я не считаю себя джедаем в этом деле, но я хочу стремиться к прекрасному, хочу писать красиво и просто. И для этого нужны знания, нужно расти, познавать, изучать. Люди, которые этого не понимают — обычные кодеры.

Опыт программирования 15 лет, второй вариант — единственный разумный, потому как

return a == b; // если нужно просто удостовериться в идентичности значений

return a == b? foo(): bar() // если нужно сделать нечто по условию

А вас что, по рукам бьют, когда вы что-то трогаете? :)
Это всё сродни преждевременной оптимизации. Зачем писать в пять раз больше кода просто так? Потому что, может быть, понадобиться расширять? и при этом будет лень написать эти самые дополнительные четыре строчки? А если не понадобиться? А если понадобиться дополнительно сделать что-нибудь в цикле в ветках? Давайте вставим пустые циклы в код. Это ведь гораздо удобнее в плане расширяемости. Теперь можно легко добавить в любйю ветку тело цикла, не трогая остальное. И, ещё, вызов пустых методов надо добавить. Это ещё более удобно в плате расширяемости :). Ещё можно вписать в ветки кучу кода для запуска спутника на Луну. И закомментировать его. Если потом понадобиться, можно легко его раскомментировать, не торогая остального :).

Явление временное. В Питере и Москве аутсорсинг когда-то рос бурными темпами, что положительно сказывалось на заработной плате. Сейчас ситуация приближается к описанной в блоге индуса. Тоже было и с «анклавами» в Белоруссии и Украине.

Я работаю в крупной международной компании в питерском офисе. Заказчики — авторитетные зарубежные компании (США, Германия, Англия).
 
Мой первый проект был с коммерческой точки зрения успешным, с точки зрения кода нет. Почему?
Команда состояла из 20-30 человек, из них 2-3 уровня Senior, 4 человека уровня Intermediate, остальные Junior. Нас продавали как высококачественных специалистов, способных качественно и в срок разработать ПО. Естественно проект стоил для заказчика больших денег. Что касается оплаты труда, даже по средним питерским зарплатам они были ниже, платили хорошо только senior'ам, остальные довольствовались малым.
 
Качество кода и реализации проекта в целом до бета версии было просто ужасным. Исходя из состава команды можно сделать соотв. выводы. Только к концу проекта люди набрались опыта и знаний (к сожалению не все), что немного отразилось на продукте. Видимо ставка руководства на то, что небольшое количество специалистов способны поддержать на достойном уровне качество кода среди большой команды низкоквалифицированных разработчиков не оправдалось.
 
Естественно мои ожидания от работы в солидной компании были другими. Я считал, все пишут правильно, хорошо, приятно смотреть на код, поощрают повышение знаний и т.д. Первый проект показал как идут дела в компании. На других проектах ситуация местами получше, но людей, пишущих через простите жопу хватает. Причём, как я упомянул в первом комментарии, они работают давно и получают хорошие деньги. Выводы можете сделать сами.

Точняк! :) Спасибо! )

как вы все это заметили? :)

присмотрелся — забавно :)

коричневая майка = 2 раза ку! :)

На самом деле в ретурн можно запихнуть часто код всего метода :) Это же не будет нагляднее. Я вот считаю, что как раз 90% программистов, которые начинали на Си\Си++ напишут второй вариант( return a==b;), и как раз их надо переучивать на первый, единственное еще и скобки{} групповые добавить. Читать первый вариант другим программист будет намного проще, причина даже не в этом примитивном условии, а в том, что человек который напишет такой ретурн, в другом методе засунет туда намного более сложную конструкцию, просто он мыслит так. Если ты пишешь только для себя — вопросов нет, если в команде, при этом туда люди пришли с разной школы(я не про уровень говорю), то код, который пишется по второму принципу будет читаться намного тяжелее

Если бы ему было больно за свою страну он бы не писал: «Не отдавайте проекты на аутсорсинг». Он бы написал: «Господа односельчане-программисты! Учите матчасть, а то белый господин скоро денег платить не будет!»

Судя по названию, молдаване какие-то:)

Мне сказал коллега, который с этим имеет дело. Я вроде так и написал если вы не поняли.