Агентом не пользовался, проблем не было. Bay Area, dice/monster/linkein, хватало.
Алсо, по рассказам переехавших с Восточного побережья знакомых сложилось ощущение, что в Bay Area попроще.
Просто мнение, цифр не будет.
> к примеру Белорусские аутсорсеры, эксплуатирующие студенческий труд
Факты в студию, или не было.
Из личного опыта — студенты максимум составляют 30-40% от кодерского контингента, и берут их нечасто, ибо проблемы будут, а толк — как повезет.
Возможно, что-то существенно изменилось?
В целом (для случайного читателя в первую очередь), рекомендую ознакомиться с developers.google.com/closure/compiler/docs/api-tutorial3#dangers
И исходить из того, что сторонние библиотеки наверерняка про это даже и не думали. Так что если closure, то и его библиотеки, со всеми вытекающими.
Кстати, каким образом приведенный пример кореллирует с исходной посылкой про «качество кода», я не разобрался. Но не суть.
С исходной посылкой я в целом согласен — Closure Compiler с advanced режимом использовать без developers.google.com/closure/compiler/docs/js-for-compiler по меньшей мере неразумно.
Он делает много чего, удаляет код, раскрывает функции, вставляет значения констант, передвигает код в выводе — много на что выдаются предупреждения, но — из опыта — кто ж их читает?
Но справедливости ради отмечу, что приведенный пример минифицируется корректно и работает, если заменить «props» на props.
Также ломается если:
obj[«props»] = { abc: 42 };
Но в этом случае работает:
obj.props = { abc: 42 };
Еще, разумеется будет ломаться в более хитрых случаях, например, если имя свойство задавать через переменную, или вывод функции, или прототипы, или (миллион случаев сюда).
a. Взялись за Closure — так уж бы и code.google.com/p/closure-stylesheets/ посмотрели для CSS.
б. Closure c advanced компиляцией дает выигрыш в размере в ~20%. Минус (ли?) — (псевдо)строгая, (псевдо)статическая типизация комментариями.
Неприятно, но верно. Удручает, когда так вот лицом прям тыкают.
Мораль — чтоб не сгнить совсем, пиши в стол. Делай что-то свое и для себя. И чтоб обязательно было по кайфу, иначе смысла нет.
Эм, есть такая басня, не басня, притча, не притча про «знать, где ударить». Гуглится. Рекомендую.
SLOC — не показатель, особенно если дело касается интеграции со сторонними библиотеками/протоколами, работы с большим спектром устройств, отладки в поисках трудновоспроизводимых багов, мультипоточности, борьбы с утечками памяти, рефакторинга ключевых функций/классов,…
Ничего серьезного, правда? Это если не говорить про архитектуру и процессы, там все очень спорно.
Я обычно на подобные заявления предлагаю попробовать попереводить и почитать переводные стихи, и сравнить количество затраченных усилий и, собственно, объем результата. Просто из любопытства.
По-видимому, это вовсе и не WAT.
По-видимому, так и должно быть, и понятно, и удобно, и быстро, и все только радуются когда используют в своих проектах эту особенность интерпритатора.
Ага.
Имхо, критичное отношение — краеугольный камень разумности вообще. А юмор — это одно из его проявлений. Но это, в общем-то, не суть.
> Как у вас организован рефакторинг
По умолчанию, каждое изменение кода содержит максимум рефакторинга, в пределах разумного. Т.е. поменять отступы, убить не нужные переменные, т.п.
Крупный рефакторинг обычно привязывают к существенному изменению функционала — новая фича хороший повод чтобы вместо вставки костылей переписать кусок кода.
Вообще, имхо выделять время на рефакторинг или как-то это целенаправлено просто не оправданно. Да, бывает нужно, но это уже следствие, а не причина.
Чисто не там, где убирают, а там, где не мусорят.
Прям хоть счас бери и пиши игру, используя ее как сценарий.
Алсо, по рассказам переехавших с Восточного побережья знакомых сложилось ощущение, что в Bay Area попроще.
Просто мнение, цифр не будет.
Уж если взялись уж.
история успеха же.
Так-то!
Пример: Бердымухамедов, Гурбангулы Мяликгулыевич
род. Бердымухамедов, Гурбангулы Мяликгулыевича
Если убрать запятую:
род. Бердымухамедова Гурбангулы Мяликгулыевича
Делите, вычитайте, но плз, не переводите в рубли.
Факты в студию, или не было.
Из личного опыта — студенты максимум составляют 30-40% от кодерского контингента, и берут их нечасто, ибо проблемы будут, а толк — как повезет.
Возможно, что-то существенно изменилось?
developers.google.com/closure/compiler/docs/api-tutorial3#propnames
В целом (для случайного читателя в первую очередь), рекомендую ознакомиться с
developers.google.com/closure/compiler/docs/api-tutorial3#dangers
И исходить из того, что сторонние библиотеки наверерняка про это даже и не думали. Так что если closure, то и его библиотеки, со всеми вытекающими.
Кстати, каким образом приведенный пример кореллирует с исходной посылкой про «качество кода», я не разобрался. Но не суть.
С исходной посылкой я в целом согласен — Closure Compiler с advanced режимом использовать без developers.google.com/closure/compiler/docs/js-for-compiler по меньшей мере неразумно.
Он делает много чего, удаляет код, раскрывает функции, вставляет значения констант, передвигает код в выводе — много на что выдаются предупреждения, но — из опыта — кто ж их читает?
Но справедливости ради отмечу, что приведенный пример минифицируется корректно и работает, если заменить «props» на props.
Также ломается если:
obj[«props»] = { abc: 42 };
Но в этом случае работает:
obj.props = { abc: 42 };
Еще, разумеется будет ломаться в более хитрых случаях, например, если имя свойство задавать через переменную, или вывод функции, или прототипы, или (миллион случаев сюда).
Если на сайте (а еще более смешно — в андроид приложении) просят ввести email и пароль — сразу же доосвидания. Ну разве что очень надо.
Особенно лень с всякими форумами и новостными сайтами — иной раз поднимается рука написать комментарий, но как дойдешь до капчи — да ну его нафиг…
> ReferenceError: obj is not defined
Возможно, имелось ввиду это?
// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// ==/ClosureCompiler==
function test() {
var obj = {
props: { test: 123 }
};
return obj;
}
console.log(test().props.test)
Что прекрасно сжимается в следующее:
console.log(123);
б. Closure c advanced компиляцией дает выигрыш в размере в ~20%. Минус (ли?) — (псевдо)строгая, (псевдо)статическая типизация комментариями.
Мораль — чтоб не сгнить совсем, пиши в стол. Делай что-то свое и для себя. И чтоб обязательно было по кайфу, иначе смысла нет.
SLOC — не показатель, особенно если дело касается интеграции со сторонними библиотеками/протоколами, работы с большим спектром устройств, отладки в поисках трудновоспроизводимых багов, мультипоточности, борьбы с утечками памяти, рефакторинга ключевых функций/классов,…
Ничего серьезного, правда? Это если не говорить про архитектуру и процессы, там все очень спорно.
Я обычно на подобные заявления предлагаю попробовать попереводить и почитать переводные стихи, и сравнить количество затраченных усилий и, собственно, объем результата. Просто из любопытства.
По-видимому, так и должно быть, и понятно, и удобно, и быстро, и все только радуются когда используют в своих проектах эту особенность интерпритатора.
Ага.
Имхо, критичное отношение — краеугольный камень разумности вообще. А юмор — это одно из его проявлений. Но это, в общем-то, не суть.
По умолчанию, каждое изменение кода содержит максимум рефакторинга, в пределах разумного. Т.е. поменять отступы, убить не нужные переменные, т.п.
Крупный рефакторинг обычно привязывают к существенному изменению функционала — новая фича хороший повод чтобы вместо вставки костылей переписать кусок кода.
Вообще, имхо выделять время на рефакторинг или как-то это целенаправлено просто не оправданно. Да, бывает нужно, но это уже следствие, а не причина.
Чисто не там, где убирают, а там, где не мусорят.