Comments 133
«Большинство индийских софтверных компаний имеют в штате малоквалифицированных программистов.» — этот тезис частично относится и к российским аутсорсерам.
К сожалению замечаю, что люди, работающие в компании несколько лет даже не знают основ технологий, с которыми постоянно работают. Ну как можно путать жизненный цикл страницы asp.net на сервере и клиенте, когда работаешь с этим 2 года?
Ещё часто попадается:
Ведь гораздо проще
и так пишет программист со стажем работы 3 года!!! Это называется — я получаю зарплату.
К сожалению замечаю, что люди, работающие в компании несколько лет даже не знают основ технологий, с которыми постоянно работают. Ну как можно путать жизненный цикл страницы asp.net на сервере и клиенте, когда работаешь с этим 2 года?
Ещё часто попадается:
if ( a == b ) return true; else return falseВедь гораздо проще
return a==b;и так пишет программист со стажем работы 3 года!!! Это называется — я получаю зарплату.
Мой опыт PHP, JS кодинга около 7 лет, но написал бы тоже первый вариант, а не return a==b;.
Невозможно каждую мелочь сделать рациональной. Но нужно к этому стремиться. Не у всех мозги работают одинакого и в одном направлении, к тому же программист может невысыпаться, кодить с температурой, его могут отвлекать в конце-концов.
Как показывает практика — хорошо, когда программист, хотя бы работает. Большинство же большую часть рабочего дня страдают непонятно чем. Отсюда задержки в сроках.
Невозможно каждую мелочь сделать рациональной. Но нужно к этому стремиться. Не у всех мозги работают одинакого и в одном направлении, к тому же программист может невысыпаться, кодить с температурой, его могут отвлекать в конце-концов.
Как показывает практика — хорошо, когда программист, хотя бы работает. Большинство же большую часть рабочего дня страдают непонятно чем. Отсюда задержки в сроках.
Нет, уважаемый, Вы не правы.
От программиста который «хотя бы работает» или постоянно не высыпается и кодит с температурой гораздо больше вреда чем пользы.
А если программист большую часть дня страдает непонятно чем, то нужен ли такой программист вобще в компании?
От программиста который «хотя бы работает» или постоянно не высыпается и кодит с температурой гораздо больше вреда чем пользы.
А если программист большую часть дня страдает непонятно чем, то нужен ли такой программист вобще в компании?
Вы не правильно поняли мою точку зрения.
Я сказал, что человек МОЖЕТ не высыпаться, болеть и т.п. Я не говорил, что он всегда такой. Имелось ввиду, что мелкие ошибки МОЖЕТ совершать даже очень опытный человек. И что нет ничего идеального.
Насчёт программистов, которые «хотя бы работают» это скорее горькая правда понятая с годами, а не пример для подражания. Даже люди, которым прилично платят зачастую используют для работы только четверь своего рабочего дня. Все остальное время сидят на Хабре, Башорге или ещё чем-то занимаются. С этим надо бороться, стимулируя сотрудника или если это не приносит успехов — заменой сотрудника.
Я сказал, что человек МОЖЕТ не высыпаться, болеть и т.п. Я не говорил, что он всегда такой. Имелось ввиду, что мелкие ошибки МОЖЕТ совершать даже очень опытный человек. И что нет ничего идеального.
Насчёт программистов, которые «хотя бы работают» это скорее горькая правда понятая с годами, а не пример для подражания. Даже люди, которым прилично платят зачастую используют для работы только четверь своего рабочего дня. Все остальное время сидят на Хабре, Башорге или ещё чем-то занимаются. С этим надо бороться, стимулируя сотрудника или если это не приносит успехов — заменой сотрудника.
мне кажется, что выражения подобные
return a==b;
должны «отскакивать от зубов» у программиста со стажем, ибо написание правильного, красивого и простого (для чтения другими и самим через n лет) кода должно быть прямо пропорциональным как годам работы, так и количеству прочтенных хороших книг по программирования. Потом это все остается «в крови», и не возникает различных идиотских ситуаций
return a==b;
должны «отскакивать от зубов» у программиста со стажем, ибо написание правильного, красивого и простого (для чтения другими и самим через n лет) кода должно быть прямо пропорциональным как годам работы, так и количеству прочтенных хороших книг по программирования. Потом это все остается «в крови», и не возникает различных идиотских ситуаций
Программист со стажем как раз таки уже давно должен успокоиться на счет того КАК красивее написать ту или иную строчку кода.
Все это мелочи, гораздо важнее суть того ЧТО написано.
От красиво написанной глупости пользы мало :)
Все это мелочи, гораздо важнее суть того ЧТО написано.
От красиво написанной глупости пользы мало :)
а вы можете представить программиста который может воплотить дизайн любой сложности но не способен ( или не любит ) писать красивый по стилю код?
красиво написанная глупость — это как раз if ( a == b ) return true; else return false;
код должен быть лаконичным
код должен быть лаконичным
Код никому ничего не должен ;)
По-моему, велико благо, что одну и туже задачу можно решить по-разному. Каждый выберет как ему удобно.
По-моему, велико благо, что одну и туже задачу можно решить по-разному. Каждый выберет как ему удобно.
вот и индусы могут одну и ту же задачу решать по-разному. а потом получаешь проект после самых «специалистов» и диву даешься :)
Языки программирования высокого уровня были придуманы для того, чтобы они были понятны людям, а не машинам. Люди разные. Для кого-то очевиден один вариант решения, для кого-то другой. Если язык позволяет использовать оба решения одной и тоже задачи, то это прекрасно. Еще раз повторюсь, потому что языки программирования придуманы для удобства людей, а для людей совершенно естественно думать по разному!
я не вижу ничего красивого.
return a==b; — это красивее, спору нет, но в контексте всей программы этот код может быть глупым и лишним :)
return a==b; — это красивее, спору нет, но в контексте всей программы этот код может быть глупым и лишним :)
Пишу на всяком уже около 10 лет. Серьезно пишу 4 года. НИ ЗА ЧТО не написал бы первый вариант. Это не рационализация.
Это устойчивая конструкция, точно так же, как для цикла с предусловием использутся
Это устойчивая конструкция, точно так же, как для цикла с предусловием использутся
for а не мешанина из while и if. Хороший программист, имхо, должен использовать второй вариант просто на автомате.
Вот уж точно не показатель, я бы предпочел видеть первый вариант, потому как он более читабелен. Ну и во-вторых, зачем жертвовать читабельностью кода, если компилятор оптимизирует подобные мелочи за вас?
А такие конструкции, как
do
{
if (! cond)
break;
}
while (false);
Используется Apple повсеместно, так что по таким вещам о качестве кода не судят.
Касательно не знания технологий с которыми работаешь… Это не удивительно, если человек то и делает, что фиксит баги, то его уровня, отладчика и гугля наверняка хватает, чтобы решать все необходимые вопросы.
А такие конструкции, как
do
{
if (! cond)
break;
}
while (false);
Используется Apple повсеместно, так что по таким вещам о качестве кода не судят.
Касательно не знания технологий с которыми работаешь… Это не удивительно, если человек то и делает, что фиксит баги, то его уровня, отладчика и гугля наверняка хватает, чтобы решать все необходимые вопросы.
Насчет читабельности можно поспорить.
>Используется Apple повсеместно, так что по таким вещам о качестве кода не судят.
Пруфлинк в студию! А if ( a == b ) return true; else return false; не разу не читабильнее.
Пруфлинк в студию! А if ( a == b ) return true; else return false; не разу не читабильнее.
Это вам не читабильнее, по себе людей не судят :)
Пруфлинк? Я что ли это сам придумал, или вас обманывать стану. Вот если хотите:
www.opensource.apple.com/darwinsource/10.5.4/AppleIntel8255x-18.0.80/i82557.cpp
www.opensource.apple.com/darwinsource/10.5.4/AppleRTL8139Ethernet-141/RTL8139.cpp
Метод start, для просмотра нужна бесплатная регистрация на Apple ADC :)
Пруфлинк? Я что ли это сам придумал, или вас обманывать стану. Вот если хотите:
www.opensource.apple.com/darwinsource/10.5.4/AppleIntel8255x-18.0.80/i82557.cpp
www.opensource.apple.com/darwinsource/10.5.4/AppleRTL8139Ethernet-141/RTL8139.cpp
Метод start, для просмотра нужна бесплатная регистрация на Apple ADC :)
IMHO, более читабелен код вида return (a == b)
Как в известном мультике, это код на «раз-два» а с if… else на «раз-два-три-четыре»
Как в известном мультике, это код на «раз-два» а с if… else на «раз-два-три-четыре»
хороший программист работает мало — но в цель
это называется всё вокруг колхозное всё вокруг моё.
совковый подход. Буду я работать не буду (эффективность и отдача), я всё равно получу своё бабло. Создал видимость и дали денег.
совковый подход. Буду я работать не буду (эффективность и отдача), я всё равно получу своё бабло. Создал видимость и дали денег.
Именно.
Подожди, а сколько за это платят? You american bastards are paying me twenty dollars a week?
среднестатистически. :)
хочешь вырваться из круговой поруки — становись профи. имхо.
а так, заказчику надо что бы делалось, для галочки где то, исполнителю надо, для того что заказчик мозг не имел. Так и получается — для галочки. Вроде работает, а как оно работает — а какая разница то? :).
Не командный принцип на результат, конкретно на зарабатывание имени и денег, а просто, что бы получить свою, обозначенную, зп.
Получается в итоге страдает заказчик, от качества выполненных работ. Да, он потом и не обратится в эту компанию, но время ушло, ушли деньги, и возможно погорел проект из за чьего то разгильдяйства. Сопсно заказчик страдает и от своего разгильдяйства, если доверил работу разработчикам с заведомо низким выходным потенциалом.
думаю что это долгая тема для обсуждений :), в любом случае не надо кидаться в крайности, но и вместе с тем понимать, что за качество надо платить.
хочешь вырваться из круговой поруки — становись профи. имхо.
а так, заказчику надо что бы делалось, для галочки где то, исполнителю надо, для того что заказчик мозг не имел. Так и получается — для галочки. Вроде работает, а как оно работает — а какая разница то? :).
Не командный принцип на результат, конкретно на зарабатывание имени и денег, а просто, что бы получить свою, обозначенную, зп.
Получается в итоге страдает заказчик, от качества выполненных работ. Да, он потом и не обратится в эту компанию, но время ушло, ушли деньги, и возможно погорел проект из за чьего то разгильдяйства. Сопсно заказчик страдает и от своего разгильдяйства, если доверил работу разработчикам с заведомо низким выходным потенциалом.
думаю что это долгая тема для обсуждений :), в любом случае не надо кидаться в крайности, но и вместе с тем понимать, что за качество надо платить.
Не думаю, что в индийских аутсорсерских конторах особо есть где развернуться желающему поработать на результат и на имя. Тот чел может оплату за количество символов кода получает, потому и нагородил мусора:)
воот :), оттуда и ноги лезут. мне надо набить 1к символов я получу миску каши. 0.5к символов можно остаться и без миски.
Вспоминается анек про самую большую худ.книгу.
сел иван царевич на кобылу и поскакал (1стр)
ыц ыц ыц ыц ( на пару тыс страниц)
и прискакал (последня стр)
:))
Вспоминается анек про самую большую худ.книгу.
сел иван царевич на кобылу и поскакал (1стр)
ыц ыц ыц ыц ( на пару тыс страниц)
и прискакал (последня стр)
:))
При чём здесь имя. Тут речь о навыках.
Если бы они только программили… По всей видимости, именно индусы составляют техническую документацию Micro$oft, которую мы после них переводим. Чего стоит вот этот перл:
Enter the domain, account name, and password for the Reporting Services service account specified for Reporting Services.
И перевод в лучших традициях албанского неизвестным фрилансером:
Введите домен, имя учетной записи и пароль учетной записи службы служб отчетов, заданной для служб отчетов.
Enter the domain, account name, and password for the Reporting Services service account specified for Reporting Services.
И перевод в лучших традициях албанского неизвестным фрилансером:
Введите домен, имя учетной записи и пароль учетной записи службы служб отчетов, заданной для служб отчетов.
Да, 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 изнутри, сравнивая новые версии со старыми, вместо умильной радости от продвинутых возможностей складывается ощущения, что майкрософт всех опять глубоко натянула.
Впрочем положительные моменты тоже есть. Сам факт, что с дополнительными насадками фреймворки становятся опенсорсом, да ещё и с мощной системой исследования архитектуры, говорит о многом. Отныне можно писать код учитывая все малейшие особенности реализации, чёрного ящика больше нет.
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 изнутри, сравнивая новые версии со старыми, вместо умильной радости от продвинутых возможностей складывается ощущения, что майкрософт всех опять глубоко натянула.
Впрочем положительные моменты тоже есть. Сам факт, что с дополнительными насадками фреймворки становятся опенсорсом, да ещё и с мощной системой исследования архитектуры, говорит о многом. Отныне можно писать код учитывая все малейшие особенности реализации, чёрного ящика больше нет.
У меня тоже большой опыт… но я не с первого раза понял конструкцию, так как никогда её не использовал.
«if ( a == b ) return true; else return false»…
По-русски это так ( предположим, что а и б равны )
Если Тру то Тру иначе Фолс… мне кажется… глупым…
Грубыми ошибками я считаю не правильное проектирование БД и архитектуру приложение, что в следствии порождает огромное количество кода, ошибок и трудность понимания.
«if ( a == b ) return true; else return false»…
По-русски это так ( предположим, что а и б равны )
Если Тру то Тру иначе Фолс… мне кажется… глупым…
Грубыми ошибками я считаю не правильное проектирование БД и архитектуру приложение, что в следствии порождает огромное количество кода, ошибок и трудность понимания.
Я пишу на С++ года 1,5-2 и если чесно тоже написал бы первый вариант чтобы решить задачу (!!!), это если нужно РЕШИТЬ! Но уверен, если б проэкт делался от души, я б просматривал каждую строчку кода очень скрупулёзно, и возможно бамнул код до 2го варианта. Так что — если вопрос стоит в том что задачу нужно просто решить — ответ очевиден. А проэкт от души, тогда естественно получите максимум отдачи от программиста
Ой ли… точно ли стали бы вкладывать душу? скрупулёзно просматривать каждую строчку?
Вот если честно положить руку на сердце?
Кроме того, есть ещё поняти лёгкости восприятия кода.
Судя по постам, многие бы воспользовались второй констукцией (и я в их числе), так не значит ли это, что код, записанный в виде if ( a == b ) return true; else return false; для многих более понятен, и в случае аутсорсинга как раз было бы лучше если бы программист написал так, а не return (a==b);?
Кроме того, учитывая предыдущую мысль в части лёгкости восприятия кода, нужно учитывать ещё что компилятор, возможно, обе строки кода скомпилирует примерно к одному виду, так что в первом случае мы получим понятный текст программы, во втором более гиковый (но менее «читаемый»), а в результате программа будет работать одинаково на уровне кода.
ИМХО!
Вот если честно положить руку на сердце?
Кроме того, есть ещё поняти лёгкости восприятия кода.
Судя по постам, многие бы воспользовались второй констукцией (и я в их числе), так не значит ли это, что код, записанный в виде if ( a == b ) return true; else return false; для многих более понятен, и в случае аутсорсинга как раз было бы лучше если бы программист написал так, а не return (a==b);?
Кроме того, учитывая предыдущую мысль в части лёгкости восприятия кода, нужно учитывать ещё что компилятор, возможно, обе строки кода скомпилирует примерно к одному виду, так что в первом случае мы получим понятный текст программы, во втором более гиковый (но менее «читаемый»), а в результате программа будет работать одинаково на уровне кода.
ИМХО!
с чего это он менее «читаемый»?
return equal(istream_iterator(ifstream(file1)), istream_iterator(), istream_iterator(ifstream(file2)));
вот такой код я бы еще назвал слегка неудобно читаемым… а вот return a==b это как раз легкочитаемо.
return equal(istream_iterator(ifstream(file1)), istream_iterator(), istream_iterator(ifstream(file2)));
вот такой код я бы еще назвал слегка неудобно читаемым… а вот return a==b это как раз легкочитаемо.
Это было абсолютное ИМХО!
Сам я не программист. Занимаюсь этим исключительно как хобби, ну и по работе, если нужно какой-нить процесс автоматизировать — не гнушаюсь что-нить написать.
И вот для человека моего уровня, ок, корректнее сказать для меня, исключительно для меня, код
return (a==b); менее понятен.
Скорее всего «читаемость» кода зависит от уровня программиста и количества прочитанных умных книжек.
Вот у меня уровень никакой, и первую конструкцию я понял слёту, на осознание второй конструкции мне потребовалось секунд 15 (это вроде и не много, но всё равно, пришлось задуматься) :)
Про конструкцию, которая упоминается ниже «[true, false][a <=> b]» я вообще молчу, ибо специфики языка не знаю.
Но, кстати, сейчас, по работе, нам одна известная компания пишет программный продукт (на базе некой платформы). Языка, на котором пишется бизнес логикая я не знаю (это помись PL/SQL с какими-то присадками), но, тем не менее, код прочитать могу, и в некоторых случаях даже помочь разработчику, сообщив о тех или иных ошибках в когде.
Сообственно, к чему я, для меня, если код будет построен на конструкциях «[true, false][a <=> b]» или return (a==b) мне будет его тяжелее читать (как минимум, придётся чаще зависать или обращаться к разработчику, уточняя а что данный код означает).
Соответственно, если согласны, что «читаемость» кода связана с уровнем знаний, приведу ещё один аргумент.
В комментах описывалась ситуация, в которой была группа разработчиков в которой пару человек были сильными, остальные послабже, соответственно, возможно сильные программисты спокойно причитаю «качественный» код, но вот со слабыми, возможно, возникнут сложности, элементарно из-за незнаний хитрых специфических конструкций языка, и конструкция вида «Если а равно б вернуть Истина, в противном случае — Ложь» для непродвинутых программистов, которые, тем не менее присутствуют во многих командах разработки, будет более понятной и адекватной.
Так если когд не обязательно попадёт к сильным программистам, стоит ли изголяться?
Сам я не программист. Занимаюсь этим исключительно как хобби, ну и по работе, если нужно какой-нить процесс автоматизировать — не гнушаюсь что-нить написать.
И вот для человека моего уровня, ок, корректнее сказать для меня, исключительно для меня, код
return (a==b); менее понятен.
Скорее всего «читаемость» кода зависит от уровня программиста и количества прочитанных умных книжек.
Вот у меня уровень никакой, и первую конструкцию я понял слёту, на осознание второй конструкции мне потребовалось секунд 15 (это вроде и не много, но всё равно, пришлось задуматься) :)
Про конструкцию, которая упоминается ниже «[true, false][a <=> b]» я вообще молчу, ибо специфики языка не знаю.
Но, кстати, сейчас, по работе, нам одна известная компания пишет программный продукт (на базе некой платформы). Языка, на котором пишется бизнес логикая я не знаю (это помись PL/SQL с какими-то присадками), но, тем не менее, код прочитать могу, и в некоторых случаях даже помочь разработчику, сообщив о тех или иных ошибках в когде.
Сообственно, к чему я, для меня, если код будет построен на конструкциях «[true, false][a <=> b]» или return (a==b) мне будет его тяжелее читать (как минимум, придётся чаще зависать или обращаться к разработчику, уточняя а что данный код означает).
Соответственно, если согласны, что «читаемость» кода связана с уровнем знаний, приведу ещё один аргумент.
В комментах описывалась ситуация, в которой была группа разработчиков в которой пару человек были сильными, остальные послабже, соответственно, возможно сильные программисты спокойно причитаю «качественный» код, но вот со слабыми, возможно, возникнут сложности, элементарно из-за незнаний хитрых специфических конструкций языка, и конструкция вида «Если а равно б вернуть Истина, в противном случае — Ложь» для непродвинутых программистов, которые, тем не менее присутствуют во многих командах разработки, будет более понятной и адекватной.
Так если когд не обязательно попадёт к сильным программистам, стоит ли изголяться?
Да вы правы в том что кому-то этот код будет понять сложнее. Но как вы думаете что правильнее — подтолкнуть кого-то учится или заставить других деградировать?
я на практике в реальной жизни встречал подобную ситуацию доведенную до абсурда — начальство заставляло всех сотрудников ( считавшихся профессиональными программистами ) писать очень примитивный код как раз по подобным соображениям. А когда из всех возможностей языка вам оставляют узкую нишу и когда из всех ваших знаний вы можете применять лишь 20% потому что остальное кто-то может не понять… это очень печально.
я на практике в реальной жизни встречал подобную ситуацию доведенную до абсурда — начальство заставляло всех сотрудников ( считавшихся профессиональными программистами ) писать очень примитивный код как раз по подобным соображениям. А когда из всех возможностей языка вам оставляют узкую нишу и когда из всех ваших знаний вы можете применять лишь 20% потому что остальное кто-то может не понять… это очень печально.
Просматривал бы — это абсолютно точно. Почему это вас так удивило?
А вот нашёл бы или нет — второй вопрос. Но в данном случае — думаю что нашёл бы!=)
А вот нашёл бы или нет — второй вопрос. Но в данном случае — думаю что нашёл бы!=)
3om6ak, только не принимайте на свой счёт!
Хотел написать про то что мне не понятно что такое делать код от души и всё такое, но предлагаю не разводить полемики, я только хочу уточнить, в чём великий позитив конструкции вида
return (a==b);
над конструкцией вида (записал в php-шной интерпритации):
if($a == $b){
return true;
}else{
return false;
}
?
Хотел написать про то что мне не понятно что такое делать код от души и всё такое, но предлагаю не разводить полемики, я только хочу уточнить, в чём великий позитив конструкции вида
return (a==b);
над конструкцией вида (записал в php-шной интерпритации):
if($a == $b){
return true;
}else{
return false;
}
?
Великий позитив в том, что вы не пишите лишнего кода!
в данном примере… это абсолютно не нужный кусок кода… вот и всё… если вам нравится программная тавтология пишите свой быдлокод дальше нормальный программист который дружит с головой не будет писать лишнего кода. Извините что так грубо… но это реально бред.
давайте еще так сделаем
if ( a.toString == «true» && a === true && a != false a.toString !=«false» )
{
return TRUE;
}else{
return false;
}
в данном примере… это абсолютно не нужный кусок кода… вот и всё… если вам нравится программная тавтология пишите свой быдлокод дальше нормальный программист который дружит с головой не будет писать лишнего кода. Извините что так грубо… но это реально бред.
давайте еще так сделаем
if ( a.toString == «true» && a === true && a != false a.toString !=«false» )
{
return TRUE;
}else{
return false;
}
пишите на ассемблере, чтобы даже лишней конструкции при декомпилировании не выскочило… вылизывайте и наслаждайтесь своим творением.
Давайте ещё конструкции вспоминать типа return a==b? true: false; ???
А давайте ещё половыми органами помериемся? только от длинны члена вероятность беременности не уменьшается.
Знать что такие конструкции есть — надо. Но кому что использовать — дело субьективное.
Мне, например, приведенную мной конструкцию использовать нравится. Ну и что?
И опыта мне не занимать.
Перестаньте уже мерится членами. Знать надо, а что использовать — выбирайте сами. Не такое как у Вас представление о используемых конструкциях — не значит что Вы читаете код менее опытного программиста и знающего меньше Вас.
кстати, читал не мало исходников (на том же PHP), где часто используют конструкцию for($i=0;$i<count($a);$i++){} совершенно не напрягаясь что в данной конструкции функция count() используется каждый шаг цикла. Зато все умеют НЕ использовать лишние символы. Говорят о чистоте кода. А потом матюгаются, когда при выходе новой игры им надо апгрейд делать или что у них какая-то программа тормозит. Научитесь уже наконец писать for($i=0; $i<$as=count($a); $i++){}
Ато впечатление такое: «У вас процессор простаивает??? НЕ ДАДИМ ЕМУ ПРОСТАИВАТЬ БЕЗ ДЕЛА! Пустой цикл — наше будующее! Save the clock!».
Развели тут спор о том как лучше написать слово «хуй» — с большой буквы или нет.
Давайте ещё конструкции вспоминать типа return a==b? true: false; ???
А давайте ещё половыми органами помериемся? только от длинны члена вероятность беременности не уменьшается.
Знать что такие конструкции есть — надо. Но кому что использовать — дело субьективное.
Мне, например, приведенную мной конструкцию использовать нравится. Ну и что?
И опыта мне не занимать.
Перестаньте уже мерится членами. Знать надо, а что использовать — выбирайте сами. Не такое как у Вас представление о используемых конструкциях — не значит что Вы читаете код менее опытного программиста и знающего меньше Вас.
кстати, читал не мало исходников (на том же PHP), где часто используют конструкцию for($i=0;$i<count($a);$i++){} совершенно не напрягаясь что в данной конструкции функция count() используется каждый шаг цикла. Зато все умеют НЕ использовать лишние символы. Говорят о чистоте кода. А потом матюгаются, когда при выходе новой игры им надо апгрейд делать или что у них какая-то программа тормозит. Научитесь уже наконец писать for($i=0; $i<$as=count($a); $i++){}
Ато впечатление такое: «У вас процессор простаивает??? НЕ ДАДИМ ЕМУ ПРОСТАИВАТЬ БЕЗ ДЕЛА! Пустой цикл — наше будующее! Save the clock!».
Развели тут спор о том как лучше написать слово «хуй» — с большой буквы или нет.
Код стал бы понятней для домохозяйки?
Так это не её дело — код используется программистами и меня от первого варианта воротит.
Так это не её дело — код используется программистами и меня от первого варианта воротит.
Так как я выражал моё мнение, то код был понятнее для меня.
Я не домохозяйка, но и не великий программист.
Великих программистов, кстати, наверное не так много в отношении к общей массе людей, которые занимаются написанием кода.
Вообще как писал тут daemoni, «программирование в промышленном масштабе — давно не исскуство, а скорее индустрия». Я с ним полностью согласен, жаль не могу пока голосовать, обязательно бы отдал голос за его коммент.
Я не домохозяйка, но и не великий программист.
Великих программистов, кстати, наверное не так много в отношении к общей массе людей, которые занимаются написанием кода.
Вообще как писал тут daemoni, «программирование в промышленном масштабе — давно не исскуство, а скорее индустрия». Я с ним полностью согласен, жаль не могу пока голосовать, обязательно бы отдал голос за его коммент.
> в случае аутсорсинга как раз было бы лучше если бы программист написал так, а не return (a==b);
Вы рекомендовали использовать такой код при аутсорсинге.
Использовать быдлокод в аутсорсинге!
Посмотрите парой строк ниже, думаю так еще понятнее:
habrahabr.ru/blogs/pm/36976/#comment_864767
habrahabr.ru/blogs/pm/36976/#comment_865523
Изучайте языки программирования, развивайтесь.
Очень скоро сами поймете.
Вы рекомендовали использовать такой код при аутсорсинге.
Использовать быдлокод в аутсорсинге!
Посмотрите парой строк ниже, думаю так еще понятнее:
habrahabr.ru/blogs/pm/36976/#comment_864767
habrahabr.ru/blogs/pm/36976/#comment_865523
Изучайте языки программирования, развивайтесь.
Очень скоро сами поймете.
у перовго варианта есть преимущество — если вдруг вам понадобиться добавить что нибудь в блок if во внутрь, а не просто вернуть значение.
это не аргумент.
в этом случае всегда можно переписать код.
Улучшенный вариант:
bool isEqual( one, another )
{
return one == another;
}
bool valueTrue()
{
return True;
}
bool valueFalse()
{
return False;
}
if( isEqual( a, b ) )
{
return valueTrue();
}
else
{
return valueFalse();
}
Если вдруг изменится операция сравнения, а также значения истины и лжи. ;-)
Улучшенный вариант:
bool isEqual( one, another )
{
return one == another;
}
bool valueTrue()
{
return True;
}
bool valueFalse()
{
return False;
}
if( isEqual( a, b ) )
{
return valueTrue();
}
else
{
return valueFalse();
}
Если вдруг изменится операция сравнения, а также значения истины и лжи. ;-)
вообще иногда у подобного кода в динамических языках иногда есть цель.
общая мысль такая: «a or b» не всегда boolean.
общая мысль такая: «a or b» не всегда boolean.
Я бы вот так написал:
a == b? true: false;
в Си по-моему можно сделать так:
a == b ?: false;
Но самую крутую проверку я недавно встретил в Ruby:
[true, false][a <=> b]
a == b? true: false;
в Си по-моему можно сделать так:
a == b ?: false;
Но самую крутую проверку я недавно встретил в Ruby:
[true, false][a <=> b]
Приведенный вами пример кода не показателен. Я бы еще заключил все return'ы в операторные скобки, а над ними еще по комментарию написал, потому что знаю, что потом с этим кодом буду разбираться я сам, либо кто-то другой. И не факт, что этот самый «кто-то другой» будет обладать огромным опытом и силой джедая. Код надо писать так, чтобы он работал, и чтобы люди, которым потом придется его дополнять, вспомнили предыдущих разработчиков с благодарностью.
А вот такой код:
(http://bash.org.ru/quote/66390) — это действительно тихий ужас. Человек-обфускатор.
А вот такой код:
if (b.ToString().length < 5){...}
(http://bash.org.ru/quote/66390) — это действительно тихий ужас. Человек-обфускатор.
В смысле, что длина «True» <5, в отличие от «False»?:) Я рыдалъ…
В иделе код должен сам комментировать себя.
Я понимаю, что новым людям бывает сложно понять и разобраться в новом проекте. Но согласитесь, если все будут писать так (возьмём мой пример):
— if ( a == b ) return true; else return false;
— не будут использовать паттернов;
— будут постоянно изобретать свои колёса и велосипеды;
— не будут стремиться к новым знаниям в своих областях программирования.
Что получится в итоге? Я думаю многие согласятся, что программирование — это своего рода искусство. Искусство писать красиво, компактно, понятно. Если люди будут делать как им проще и совершать те вещи, которые я перечислил (естественно это не все тезисы, а что пришло в голову), мы получим говнокод. Это будет обычный банальный говнокод, который есть везде и всюду. Никаким искусством не пахнет.
Я не считаю себя джедаем в этом деле, но я хочу стремиться к прекрасному, хочу писать красиво и просто. И для этого нужны знания, нужно расти, познавать, изучать. Люди, которые этого не понимают — обычные кодеры.
Я понимаю, что новым людям бывает сложно понять и разобраться в новом проекте. Но согласитесь, если все будут писать так (возьмём мой пример):
— if ( a == b ) return true; else return false;
— не будут использовать паттернов;
— будут постоянно изобретать свои колёса и велосипеды;
— не будут стремиться к новым знаниям в своих областях программирования.
Что получится в итоге? Я думаю многие согласятся, что программирование — это своего рода искусство. Искусство писать красиво, компактно, понятно. Если люди будут делать как им проще и совершать те вещи, которые я перечислил (естественно это не все тезисы, а что пришло в голову), мы получим говнокод. Это будет обычный банальный говнокод, который есть везде и всюду. Никаким искусством не пахнет.
Я не считаю себя джедаем в этом деле, но я хочу стремиться к прекрасному, хочу писать красиво и просто. И для этого нужны знания, нужно расти, познавать, изучать. Люди, которые этого не понимают — обычные кодеры.
Вы намешали в кучу понятия из разных категорий, так нельзя (кто же конструкции языка мешает с паттернами). Конечно, если вообще лентяйничать и ничему не учиться — то начнется процесс деградации.
А программирование в промышленном масштабе — давно не исскуство, а скорее индустрия.
А программирование в промышленном масштабе — давно не исскуство, а скорее индустрия.
«Мой код комментирует себя сам» — стандартная отмазка людей, не желающих упрощать жизнь тем, кто будет код поддерживать. Насчет «искусства» — спорный момент. Почитайте lxr.linux.no/linux/Documentation/CodingStyle, например.
В идеале код документирует себя сам — это не отмазка, а реальность, к сожалению редкая. Если разработчик понятно называет методы и переменные, не запутывает логики, — код читается легко и просто. Возможно для этого потребуется что-нибудь почитать и усвоить. Например (C# 3.0) код, использующий лямбда выражения, сначала выглядит сложным и непонятным, в дальнейшем все становится хорошо.
Согсен!
Первый опыт работы получил в команде, работавшей с лозунгом «код должен быть понятен для студента».
Код был ужасен, его уровень перерос спустя пару месяцев.
Первый опыт работы получил в команде, работавшей с лозунгом «код должен быть понятен для студента».
Код был ужасен, его уровень перерос спустя пару месяцев.
Опыт программирования шесть лет.
Первый вариант — мой выбор, потому что это не рационализация, а экономия букв. Зато жертвуется наглядность кода и читабельность.
Первый вариант — мой выбор, потому что это не рационализация, а экономия букв. Зато жертвуется наглядность кода и читабельность.
UFO just landed and posted this here
Пишу 3 года. Задумался как бы я написал. Наверное, если бы писал в начале рабочего дня, то написал бы второй вариант, если в конце, то первый) Читать в чужом коде приятнее первый.
через полгода у тебя стало не 1 условие, а 4ре
Более того делать return a == b;
а где-то еще в функции return c > a;
не менее глупо чем
накапливай все в результат и возвращай в одном месте.
Более того делать return a == b;
а где-то еще в функции return c > a;
не менее глупо чем
if ( a == b ) return true; else return false;накапливай все в результат и возвращай в одном месте.
return $result;
Я за первый вариант, токо немного переписанный.
if ( a == b ) {
return true;
} else {
return false;
}
потому как данный вариант _гораздо_ удобнее в плане расширяемости, теперь в любую ветку можно дабавить новую строку не трогая остальные.
if ( a == b ) {
return true;
} else {
return false;
}
потому как данный вариант _гораздо_ удобнее в плане расширяемости, теперь в любую ветку можно дабавить новую строку не трогая остальные.
А вас что, по рукам бьют, когда вы что-то трогаете? :)
Это всё сродни преждевременной оптимизации. Зачем писать в пять раз больше кода просто так? Потому что, может быть, понадобиться расширять? и при этом будет лень написать эти самые дополнительные четыре строчки? А если не понадобиться? А если понадобиться дополнительно сделать что-нибудь в цикле в ветках? Давайте вставим пустые циклы в код. Это ведь гораздо удобнее в плане расширяемости. Теперь можно легко добавить в любйю ветку тело цикла, не трогая остальное. И, ещё, вызов пустых методов надо добавить. Это ещё более удобно в плате расширяемости :). Ещё можно вписать в ветки кучу кода для запуска спутника на Луну. И закомментировать его. Если потом понадобиться, можно легко его раскомментировать, не торогая остального :).
Это всё сродни преждевременной оптимизации. Зачем писать в пять раз больше кода просто так? Потому что, может быть, понадобиться расширять? и при этом будет лень написать эти самые дополнительные четыре строчки? А если не понадобиться? А если понадобиться дополнительно сделать что-нибудь в цикле в ветках? Давайте вставим пустые циклы в код. Это ведь гораздо удобнее в плане расширяемости. Теперь можно легко добавить в любйю ветку тело цикла, не трогая остальное. И, ещё, вызов пустых методов надо добавить. Это ещё более удобно в плате расширяемости :). Ещё можно вписать в ветки кучу кода для запуска спутника на Луну. И закомментировать его. Если потом понадобиться, можно легко его раскомментировать, не торогая остального :).
В последнее время даже на родине появляется большое количество аутсорсинговых компаний, в них берут только что закончивших ВУЗ студентов, которым платят гроши. А основные заказчики — Европа, США, Австралия. О каком качестве кода можно говорить?
частично вы правы. но в регионах (по крайней мере у нас) аутсорсинговые компания платят в 1,5-2 раза болье, чем местные. потому туда идут лучшие, а не худшие и даже не средние, и компаний есть выбор
Все зависит от того какие продукты выполняет эти аутсорсинговые компании. К примеру компания американская и делает качественно, но работники у неё в России, платит она им хорошо так как нужны лучшие. ибо и берет за свои продукты очень много.
Я работаю в крупной международной компании в питерском офисе. Заказчики — авторитетные зарубежные компании (США, Германия, Англия).
Мой первый проект был с коммерческой точки зрения успешным, с точки зрения кода нет. Почему?
Команда состояла из 20-30 человек, из них 2-3 уровня Senior, 4 человека уровня Intermediate, остальные Junior. Нас продавали как высококачественных специалистов, способных качественно и в срок разработать ПО. Естественно проект стоил для заказчика больших денег. Что касается оплаты труда, даже по средним питерским зарплатам они были ниже, платили хорошо только senior'ам, остальные довольствовались малым.
Качество кода и реализации проекта в целом до бета версии было просто ужасным. Исходя из состава команды можно сделать соотв. выводы. Только к концу проекта люди набрались опыта и знаний (к сожалению не все), что немного отразилось на продукте. Видимо ставка руководства на то, что небольшое количество специалистов способны поддержать на достойном уровне качество кода среди большой команды низкоквалифицированных разработчиков не оправдалось.
Естественно мои ожидания от работы в солидной компании были другими. Я считал, все пишут правильно, хорошо, приятно смотреть на код, поощрают повышение знаний и т.д. Первый проект показал как идут дела в компании. На других проектах ситуация местами получше, но людей, пишущих через простите жопу хватает. Причём, как я упомянул в первом комментарии, они работают давно и получают хорошие деньги. Выводы можете сделать сами.
Мой первый проект был с коммерческой точки зрения успешным, с точки зрения кода нет. Почему?
Команда состояла из 20-30 человек, из них 2-3 уровня Senior, 4 человека уровня Intermediate, остальные Junior. Нас продавали как высококачественных специалистов, способных качественно и в срок разработать ПО. Естественно проект стоил для заказчика больших денег. Что касается оплаты труда, даже по средним питерским зарплатам они были ниже, платили хорошо только senior'ам, остальные довольствовались малым.
Качество кода и реализации проекта в целом до бета версии было просто ужасным. Исходя из состава команды можно сделать соотв. выводы. Только к концу проекта люди набрались опыта и знаний (к сожалению не все), что немного отразилось на продукте. Видимо ставка руководства на то, что небольшое количество специалистов способны поддержать на достойном уровне качество кода среди большой команды низкоквалифицированных разработчиков не оправдалось.
Естественно мои ожидания от работы в солидной компании были другими. Я считал, все пишут правильно, хорошо, приятно смотреть на код, поощрают повышение знаний и т.д. Первый проект показал как идут дела в компании. На других проектах ситуация местами получше, но людей, пишущих через простите жопу хватает. Причём, как я упомянул в первом комментарии, они работают давно и получают хорошие деньги. Выводы можете сделать сами.
В крупных компаниях вообще зачастую всем все пофигу…
Сам начинал студентом в компании с персоналом порядка 200 человек. Сбежал оттуда через 9 месяцев. Причина банальна — временами по нескольку дней нечего было делать!
Крупные компании зачастую берут количеством, а не качеством, поэтому набирают на работу избыточное количество работников, а менеджеры вследствие своей низкой квалификации неспособны вовремя загружать их работой. А вынужденное безделье очень сильно снижает мотивацию работника.
Сам начинал студентом в компании с персоналом порядка 200 человек. Сбежал оттуда через 9 месяцев. Причина банальна — временами по нескольку дней нечего было делать!
Крупные компании зачастую берут количеством, а не качеством, поэтому набирают на работу избыточное количество работников, а менеджеры вследствие своей низкой квалификации неспособны вовремя загружать их работой. А вынужденное безделье очень сильно снижает мотивацию работника.
прям как про меня :)
у меня в последнее время складывается впечатление, что, к сожалению, так обстоят дела в подавляющем большинстве российский компаний мелкого и среднего масштаба.
у меня в последнее время складывается впечатление, что, к сожалению, так обстоят дела в подавляющем большинстве российский компаний мелкого и среднего масштаба.
UFO just landed and posted this here
Можете ли вы привести ссылку на источник?
кто может подтвердить факт того, что большинство американских (читай и всех остальных) программистов высококвалифицированны, заботятся о качестве и «вкладывают душу в продукт» за высокую плату?
мне кажется все зависит от конкретной команды и организации.
мне кажется все зависит от конкретной команды и организации.
UFO just landed and posted this here
>«Какой выход? Не пользуйтесь аутсорсингом.»
Не надо быть таким категоричным.
Аутсорсингом пользоваться можно, но при этом надо грамотно выбирать компанию или фрилансера. Т.е. с хорошими отзывами, с хорошим портфолио. Плюс на основе разговора по ICQ/Skype можно дать приблизительную оценку навыкам программиста.
И не надо забывать про контроль. Если вы сами являетесь специалистом, то неплохо бы поглядывать в код по походу разработки и делать соответствующие замечания исполнителю. Главное не пускать на самотек.
Не надо быть таким категоричным.
Аутсорсингом пользоваться можно, но при этом надо грамотно выбирать компанию или фрилансера. Т.е. с хорошими отзывами, с хорошим портфолио. Плюс на основе разговора по ICQ/Skype можно дать приблизительную оценку навыкам программиста.
И не надо забывать про контроль. Если вы сами являетесь специалистом, то неплохо бы поглядывать в код по походу разработки и делать соответствующие замечания исполнителю. Главное не пускать на самотек.
Всё зависит от профессионализма команды.
И serzhb хорошо заметил — надо не пускать проект на самотек.
Работа любого менеджера — это контроль. Если на первом этапе вам предоставят «грязный» код — вы можете отказаться от услуг, причем без опалты. Главное внести этот пункт в договор.
Но…
Я бы больше обрашал внимание НЕ НА
Такой стиль тоже правильный :) Любой инженер так может написать. Главное для инженера целостность проекта и гибкость (архитектура) а еще и логическая «понятливость» кода.
Надо обращать внимание на архитектуру построения проекта, его гибкость и расширяемость, когда заказываете аутсорс.
А «перлы» кода, один квалифицированный инженер-«рефакторильщик» поправит довольно быстро, что кстати очень сейчас распространено.
Компания аутсорсер — плучает заказ — отдает его индусам, следит за архитектурой, получает проект, а потом один инженер быстро рефакторит индуский код для заказчика «свыше», скорость выполнения кстати от этого не страдает.
И serzhb хорошо заметил — надо не пускать проект на самотек.
Работа любого менеджера — это контроль. Если на первом этапе вам предоставят «грязный» код — вы можете отказаться от услуг, причем без опалты. Главное внести этот пункт в договор.
Но…
Я бы больше обрашал внимание НЕ НА
if ( a == b ) return true; else return false
Ведь гораздо проще
return a==b; Такой стиль тоже правильный :) Любой инженер так может написать. Главное для инженера целостность проекта и гибкость (архитектура) а еще и логическая «понятливость» кода.
Надо обращать внимание на архитектуру построения проекта, его гибкость и расширяемость, когда заказываете аутсорс.
А «перлы» кода, один квалифицированный инженер-«рефакторильщик» поправит довольно быстро, что кстати очень сейчас распространено.
Компания аутсорсер — плучает заказ — отдает его индусам, следит за архитектурой, получает проект, а потом один инженер быстро рефакторит индуский код для заказчика «свыше», скорость выполнения кстати от этого не страдает.
«Такой стиль тоже правильный :) „
Стиль
Если да то возращаем да, иначе возращаем нет… это правильный стиль?
Стиль
Если да то возращаем да, иначе возращаем нет… это правильный стиль?
На самом деле в ретурн можно запихнуть часто код всего метода :) Это же не будет нагляднее. Я вот считаю, что как раз 90% программистов, которые начинали на Си\Си++ напишут второй вариант( return a==b;), и как раз их надо переучивать на первый, единственное еще и скобки{} групповые добавить. Читать первый вариант другим программист будет намного проще, причина даже не в этом примитивном условии, а в том, что человек который напишет такой ретурн, в другом методе засунет туда намного более сложную конструкцию, просто он мыслит так. Если ты пишешь только для себя — вопросов нет, если в команде, при этом туда люди пришли с разной школы(я не про уровень говорю), то код, который пишется по второму принципу будет читаться намного тяжелее
тяжелее?
я в шоке… извините но если вы не знаете, что $a === $b это логическая операция то это ваша проблема, когда я вижу return $a === $b; я сразу понимаю, что тут либо TRUE либо FALSE и мне для этого не нужен не понятно откуда взятый IF и ELSE.
Тут не предлогают запихивать все подряд… в RETURN положили ЛОГИЧЕСКОЕ ВЫРАЖЕНИЕ… да это везде нормальные программисты используют… откуда вы???????????????????
я в шоке… извините но если вы не знаете, что $a === $b это логическая операция то это ваша проблема, когда я вижу return $a === $b; я сразу понимаю, что тут либо TRUE либо FALSE и мне для этого не нужен не понятно откуда взятый IF и ELSE.
Тут не предлогают запихивать все подряд… в RETURN положили ЛОГИЧЕСКОЕ ВЫРАЖЕНИЕ… да это везде нормальные программисты используют… откуда вы???????????????????
Вы меня не поняли, этот пример тривиален(и искусственный), конечно это понятно всем.
Но минус такого подхода в том, что люди в ретурн начинают заносить сложные выражения, как логические, так и с вычислениями, лучше в правилах сразу оговорить, что в ретурне не должно быть выражений, чем потом будут встречаться нечетабельные методы.
Но минус такого подхода в том, что люди в ретурн начинают заносить сложные выражения, как логические, так и с вычислениями, лучше в правилах сразу оговорить, что в ретурне не должно быть выражений, чем потом будут встречаться нечетабельные методы.
Еще хорошо помогают инструменты статического анализа исходников + аудит. Даже хороший программист может не закрыть за собой поток после работы; а что могут вытворять китайские студенты — это вообще ужас.
Когда кривой код находится автоматически, то, во-первых, видно, кто как пишет. Во-вторых, после некоторой раскачки, код приводится в порядок, и появляется дополнительный опыт. Правда, требуется желание тим лида все это организовать.
Когда кривой код находится автоматически, то, во-первых, видно, кто как пишет. Во-вторых, после некоторой раскачки, код приводится в порядок, и появляется дополнительный опыт. Правда, требуется желание тим лида все это организовать.
да, интересно конечно, как они сами это изнутри видят!
Интересно…
Товарищ пишет, что коренной индиец и советует не пользоваться аутсорсингом. Что-то тут не так.
Ну не может же он ратовать за то, чтобы его оставили без работы? Следовательно, этот индиец умотал в штаты и работает в местной конторе. Тогда это тенденциозный пост, направленный на принижение роли аутсорсеров на своей Родине дабы получать их проекты.
Вопрос: а будет ли коренной индиец в США работать лучше, чем в Бангалоре???
Но ситуацию описал на 100% верно. У меня на проекте в связке порядка 10 индусов. Только один из них вменяемый. Остальные — школьники.
Товарищ пишет, что коренной индиец и советует не пользоваться аутсорсингом. Что-то тут не так.
Ну не может же он ратовать за то, чтобы его оставили без работы? Следовательно, этот индиец умотал в штаты и работает в местной конторе. Тогда это тенденциозный пост, направленный на принижение роли аутсорсеров на своей Родине дабы получать их проекты.
Вопрос: а будет ли коренной индиец в США работать лучше, чем в Бангалоре???
Но ситуацию описал на 100% верно. У меня на проекте в связке порядка 10 индусов. Только один из них вменяемый. Остальные — школьники.
приведенный пример кода не слишком страшный, зацените вот это:
if (res.toString().length == 5) {...} //проверка переменной на false!!!
if (res.toString().length == 5) {...} //проверка переменной на false!!!
Все течет, все изменяется…
Я думаю что если в статье заменить слово «индийский» на «российский» или «украинский», то не надо будет ни одного тезиса менять или даже редактировать :) Мне пришлось довольно много поработать в аутсорсах и во всех проектах, было так — два три человека застрельщики грамотные, остальные джуниоры. Причем принцип — набирай всегда тех, кто лучше тебя, инаре рискуешь оказаться среди идиотов — работает на 100%. Во всех аутсорсерах можно выделить несколько поколений разработчиков (по уровню квалификации) и при этом уровень новых поколений падает просто катастрофически — если посидел джуниором на проекте с полгодика, то на следующий проект уже сеньёр.
Когда только начинал самое хлебное место это были банки, потом стали аутсорсеры, сейчас народ растекается по иностранным представительствам. Что будет дальше посмотрим, но то что в отрасль приходит народ со все меньшей квалификацией это прискорбный факт.
Я думаю что если в статье заменить слово «индийский» на «российский» или «украинский», то не надо будет ни одного тезиса менять или даже редактировать :) Мне пришлось довольно много поработать в аутсорсах и во всех проектах, было так — два три человека застрельщики грамотные, остальные джуниоры. Причем принцип — набирай всегда тех, кто лучше тебя, инаре рискуешь оказаться среди идиотов — работает на 100%. Во всех аутсорсерах можно выделить несколько поколений разработчиков (по уровню квалификации) и при этом уровень новых поколений падает просто катастрофически — если посидел джуниором на проекте с полгодика, то на следующий проект уже сеньёр.
Когда только начинал самое хлебное место это были банки, потом стали аутсорсеры, сейчас народ растекается по иностранным представительствам. Что будет дальше посмотрим, но то что в отрасль приходит народ со все меньшей квалификацией это прискорбный факт.
Тут проблема курицы и яйца по-моему. Низкоквалифицированные индусы предлагают свой труд, и чтобы как-то выиграть рынок — предлагают весьма задешево. Приходит проект. делают как могут, получают свои грОши. Приходит еще проект, тоже задешево. Тоже делают — за тем ведь и подались в программеры. Так проходят годы. Стимула улучшать свои навыки, как это видно из статьи, нет — работа неприбыльная, спецов хороших опять-таки нет, никто не научит толком. Во всем мире слава о них ходит именно такая, какую сами создали: дешевые «джамшуты», с примитивом справятся, дорого не возьмут. На этом же основании никто не станет платить больше — мол, а за что, резонный вопрос? Из такого заколдованного круга не вырваться никогда, если только не отказаться от идеи зарабатывать так деньги, и заработать в конце концов репутацию (момент, присутствующий в начале жизни многих веб-студий, кстати). То есть убрать деньги из списка мотивации на некоторое время. Это возможно при поддержке правительсва, к примеру, или крупных инвесторов, заинтересованных в крайне долгосрочных вложениях. Очевидная мораль истории — деньги из воздуха не заработаешь, какое-то время придется работать на совесть и голодным.
Кстати, Zimbra — это случаем не индийская компания?
Кстати, Zimbra — это случаем не индийская компания?
В букмарки, мемориз и еа печать!
Пригодится для дискуссий о качестве индийского кода.
Пригодится для дискуссий о качестве индийского кода.
Хотелось бы написать об одном случае, который поведал мне недавно коллега по работе.
От крупного клиента им достался проект на доработку. Нужно было расширить функционал и оптимизировать работу. Проект изначально делали индусы. Там был очень интересный класс для тестирования одного бизнес компонента. Он содержал порядка 12 тысяч строк и с десяток тестов. Что делали индусы: написали 1 тест, всё остальные — копипаст с изменением нескольких параметров, т.е. термином «выделение метода» даже не пахло, тупой копипаст. После рефакторинга класс стал весить 600 строчек.
От крупного клиента им достался проект на доработку. Нужно было расширить функционал и оптимизировать работу. Проект изначально делали индусы. Там был очень интересный класс для тестирования одного бизнес компонента. Он содержал порядка 12 тысяч строк и с десяток тестов. Что делали индусы: написали 1 тест, всё остальные — копипаст с изменением нескольких параметров, т.е. термином «выделение метода» даже не пахло, тупой копипаст. После рефакторинга класс стал весить 600 строчек.
А можно ссылку на оригинал??
Версия: а вдруг этот пост написал не индус — программист «высокоразвитой» страны, у которого индусы отбирают хлеб?
Важен не код, а результат. Вон Билл Гейтс на глючных виндах сумел получить выгоду, хотя ошибок (не дыр, а именно ошибок) там было предостаточно.
И любой бизнес-процесс можно оценивать только с точки зрение получения выгоды. Если стоимость написания красивого, читаемого, рационального, эффективного кода, выше, чем прибыль, получаемая от этих качеств, то вкладываться в них не имеет смысла.
Если же предполагается использовать код, как основу для дальнейших разработок, удобство работы с ним оценивается уже экономией человеко-часов по дальнейшей работе с кодом и тоже сравнивается с получаемой от этого прибылью. Иной раз выгоднее написать код заново, чем тратить время на доработку. Это касается и больших проектов.
Поэтому стоит пользоваться аутсорсингом или не стоит — дело конкретного случая. Просто если пользуешься, то будь готов к тому, что справедливо описано в этой статье.
Спасибо.
И любой бизнес-процесс можно оценивать только с точки зрение получения выгоды. Если стоимость написания красивого, читаемого, рационального, эффективного кода, выше, чем прибыль, получаемая от этих качеств, то вкладываться в них не имеет смысла.
Если же предполагается использовать код, как основу для дальнейших разработок, удобство работы с ним оценивается уже экономией человеко-часов по дальнейшей работе с кодом и тоже сравнивается с получаемой от этого прибылью. Иной раз выгоднее написать код заново, чем тратить время на доработку. Это касается и больших проектов.
Поэтому стоит пользоваться аутсорсингом или не стоит — дело конкретного случая. Просто если пользуешься, то будь готов к тому, что справедливо описано в этой статье.
Спасибо.
по поводу оутсорса очень хорошо написано в книге у Спольски «Лучшие примеры разработки ПО»
Как шутят, сертификаты нужны для того, чтобы индусы могли себе найти работу.
Я, сейчас, нахожусь в качестве вот такого вот индуса… — Участвую в проэкте на ASP.Net/C#, а так как до этого с даной платформой не работал совсем — не знаю почти ничего :)
Большинство проблем — незнание специфических приемов или встроенного функционала (хотя, уже больше времени провожу в мануалах, нежели в изобретении собственных велосипедов/самокатов/колеса/палки-копалки)…
Большинство проблем — незнание специфических приемов или встроенного функционала (хотя, уже больше времени провожу в мануалах, нежели в изобретении собственных велосипедов/самокатов/колеса/палки-копалки)…
С точки зрения рынка подобные советы бессмысленны. В данном случае те люди которые продают ПО уже двадцать лет наверняка лучше разбираются что им делать с себестоимостью, качеством, прибылью, сопровождением и т д чем даже пусть и очень замечательный и честный индийский программист.
Относительно спора if vs return
Я начинающий программист, это моё хобби, поэтому много читаю книг. Так вот примеров первой конструкции я нигде не встречал. И даже не обладая многолетним опытом программирования могу сказать что return для меня более естественная и привычная конструкция и уж тем более читаемая и безошибочная.
Относительно спора if vs return
Я начинающий программист, это моё хобби, поэтому много читаю книг. Так вот примеров первой конструкции я нигде не встречал. И даже не обладая многолетним опытом программирования могу сказать что return для меня более естественная и привычная конструкция и уж тем более читаемая и безошибочная.
Обожаю комментарии вида: «я пишу вот уже три дня и всегда испольщую первый вариант, ведь он гораздо читабельнее...» Мне это напоминает: «я вожу машину уже три дня и всегда залажу в машину через багажное отделение, ведь даже ежу понятно что эта дверь самая большая, а значит и удобная...»
Не надо показывать свою серость и нежелание нормально освоить язык. Не знали что так можно, так мотаем на ус и делаем в последствии правильно. А не заставляем людей, которым возможно придется работать с этим кодом, пробираться в дебрях вашего оператороблудия.
Не надо показывать свою серость и нежелание нормально освоить язык. Не знали что так можно, так мотаем на ус и делаем в последствии правильно. А не заставляем людей, которым возможно придется работать с этим кодом, пробираться в дебрях вашего оператороблудия.
Sign up to leave a comment.
Почему не стоит пользоваться аутсорсингом в странах с дешевой рабочей силой