В свое время купил алюминиевый HTC Legacy, на момент покупки было одно обновление — вроде Android 2.3, больше апдейтов не было. К тому же через пару месяцев у него сломался тачскрин, пока его чинили феерические 45 дней, его цена в рознице упала примерно на 5000 рублей. Тогда в сервисе мне еще сказали, что в HTC можно вызвать сотрудника на дом, они сами заберут его на ремонт, типа маркетинг, лояльность и все такое. Товарищи, что действительно круто — это когда всем известный корейский бренд-производитель флагманских Android-девайсов починил мой ноутбук (замена шлейфа на монитор) по гарантии за 2 дня, а потом еще позвонили поинтересовались, доволен ли я ремонтом. В целом в HTC разочарован, хотя аппараты у них ничего.
Тут писали про XP и про прочие недостатки решения вроде нюансов безопасности. Стрелка СТ в целом отлично выполняет свою работу практически в любую погоду и ночью. Эквивалентных аналогов я почти не знаю. Мне лично пришло немало писем счастья именно от нее.
Насколько знаю, она не только нарушение скоростного режима фиксирует, но и, например, движение по запрещенной полосе, проезд на красный, пересечение стоп-линии и пр.
По поводу новости у меня весьма смешанные чувства, с одной стороны Стрелка — крутое ИТ-решение, с другой — напрягает и хакеры тоже молодцы :)
При всех своих достоинствах это достаточно тяжеловесное решение, объем генерированных классов (например, Java) довольно громоздкий + либа весом 666667 байт, в малоресурсных системах вроде j2me практически неприменимо несмотря даже на наличие портов.
IMHO, короткий код — не всегда более понятный код. Все зависит от контекста и от архитектуры ПО в целом.
Может пример и не очень удачен, но в perl'е некоторые вещи можно записать весьма лаконичной конструкцией, которую потом хрен разберешь.
Сортировка пузырьком записывается короче и понятнее, чем quicksort, но не стоит использовать первую только из-за этого.
Хороший понятный код — это который можно понять, прочитав пару раз, он зачастую даже в комментариях не нуждается (здесь не хочу раздувать священную войну про комментирование). За свою практику встречал программистов, способных писать так, крайне редко.
Объем не первичен, но безусловно важны такие вещи как форматирование, единые нотации по оформлению кода по всему проекту, единообразие концепций, паттернов, технологий и пр.
Если проект богат функциональностью, то малым числом строк не обойдешься, но зато можно это дело удачно разбить на модули, сделать хорошее API, при необходимости документировать. Как правило, весь проект знать нет особой нужды, но при соблюдении ряда условий освоение и расширение новой функциональности может быть достаточно тривиальным. Поддержка такого состояния в проекте — ответственность тимлидов и ведущих программистов, инструменты вроде ревью кода в помощь.
Тут уже отметили, что это есть в любой приличной IDE.
Считаю моветоном писать в аннотации к классу имя автора (дефолтный авто-шаблон класса, например), потому что практически любой класс в итоге является результатом совместных правок (в команде из трех человек и более) и нужно уже смотреть историю, чтобы выяснить по каждой конкретной строке. По большому счету даже не так важно, кто автор кода, если, например, в нем есть ошибка. Вопрос, как это исправить и не допустить в будущем. Уведомить автора тоже будет не лишним (например, в личной беседе или через ревью).
Также, конечно, важным является наличие единого стандарта оформления кода — по сути, не важно какого, табы или пробелы и пр., суть в том что он должен быть единым для рабочей группы, а может и для департамента в целом. Если нужно — зафиксированным в виде статьи в локальной wiki, чтобы на него делать отсылку.
Общая кодовая база, даже пусть и с изъянами, зато хорошо и подробно знакомая всем участникам и используемая в десятке проектов — это лучше, чем 10 проектов, сделанных по-разному. Причем если это общеизвестные 3rd-party библиотеки вроде guava или apache commons — вообще здорово. Это упрощает вхождение программиста в новый проект, когда он видит знакомый код, совместное владение кодом повышается. Эти вопросы опять же на ответственности тимлида.
Ревью кода — безусловное добро. Даже старшие коллеги делились кодом на ревью и между собой и с коллегами ниже рангом, которые были «в теме».
При этом инициативы вроде использования альтернативного фреймворка (например, spring di в конкретном проекте вместо guice, как везде) могли быть поддержаны при условии взятия ответственности довести начатое до конца и предоставить необходимые консультации и пр.
Я в проф-коммуникации разделяю условно компромисс и консенсус. В моем понимании компромисс — когда обе стороны идут на уступки, в итоге обе недовольны, но решение есть. Консенсус — когда обе стороны приходят к решению, которое обе стороны устраивает. Грань тонкая, консенсус возможен далеко не всегда.
Предложенный в статье способ разделения на «норки» мне знаком и стал результатом непреодолимых споров и изначальной договоренности равенства участников. IMHO, это плохой путь, лучше — вертикальная иерархия, т.е. спорные моменты разрешает тимлид, оценивая плюсы и риски решений (в том числе несогласие одной из сторон), тимлид берет ответственность за решение.
Что касается консенсуса, тут интереснее. Бывает, он возможен в малых командах, когда есть взаимное профессиональное уважение коллег и как правило их высокий уровень. Опять же IMHO, только такие команды способны ценой малого числа участников создать качественные продукты. Т.е. ключевое — это авторитет опытных сотрудников при условии их «адекватности» :)
www.youtube.com/watch?v=RuIyNjuaRNA
Насколько знаю, она не только нарушение скоростного режима фиксирует, но и, например, движение по запрещенной полосе, проезд на красный, пересечение стоп-линии и пр.
По поводу новости у меня весьма смешанные чувства, с одной стороны Стрелка — крутое ИТ-решение, с другой — напрягает и хакеры тоже молодцы :)
Может пример и не очень удачен, но в perl'е некоторые вещи можно записать весьма лаконичной конструкцией, которую потом хрен разберешь.
Сортировка пузырьком записывается короче и понятнее, чем quicksort, но не стоит использовать первую только из-за этого.
Хороший понятный код — это который можно понять, прочитав пару раз, он зачастую даже в комментариях не нуждается (здесь не хочу раздувать священную войну про комментирование). За свою практику встречал программистов, способных писать так, крайне редко.
Объем не первичен, но безусловно важны такие вещи как форматирование, единые нотации по оформлению кода по всему проекту, единообразие концепций, паттернов, технологий и пр.
Если проект богат функциональностью, то малым числом строк не обойдешься, но зато можно это дело удачно разбить на модули, сделать хорошее API, при необходимости документировать. Как правило, весь проект знать нет особой нужды, но при соблюдении ряда условий освоение и расширение новой функциональности может быть достаточно тривиальным. Поддержка такого состояния в проекте — ответственность тимлидов и ведущих программистов, инструменты вроде ревью кода в помощь.
Считаю моветоном писать в аннотации к классу имя автора (дефолтный авто-шаблон класса, например), потому что практически любой класс в итоге является результатом совместных правок (в команде из трех человек и более) и нужно уже смотреть историю, чтобы выяснить по каждой конкретной строке. По большому счету даже не так важно, кто автор кода, если, например, в нем есть ошибка. Вопрос, как это исправить и не допустить в будущем. Уведомить автора тоже будет не лишним (например, в личной беседе или через ревью).
Общая кодовая база, даже пусть и с изъянами, зато хорошо и подробно знакомая всем участникам и используемая в десятке проектов — это лучше, чем 10 проектов, сделанных по-разному. Причем если это общеизвестные 3rd-party библиотеки вроде guava или apache commons — вообще здорово. Это упрощает вхождение программиста в новый проект, когда он видит знакомый код, совместное владение кодом повышается. Эти вопросы опять же на ответственности тимлида.
Ревью кода — безусловное добро. Даже старшие коллеги делились кодом на ревью и между собой и с коллегами ниже рангом, которые были «в теме».
При этом инициативы вроде использования альтернативного фреймворка (например, spring di в конкретном проекте вместо guice, как везде) могли быть поддержаны при условии взятия ответственности довести начатое до конца и предоставить необходимые консультации и пр.
Предложенный в статье способ разделения на «норки» мне знаком и стал результатом непреодолимых споров и изначальной договоренности равенства участников. IMHO, это плохой путь, лучше — вертикальная иерархия, т.е. спорные моменты разрешает тимлид, оценивая плюсы и риски решений (в том числе несогласие одной из сторон), тимлид берет ответственность за решение.
Что касается консенсуса, тут интереснее. Бывает, он возможен в малых командах, когда есть взаимное профессиональное уважение коллег и как правило их высокий уровень. Опять же IMHO, только такие команды способны ценой малого числа участников создать качественные продукты. Т.е. ключевое — это авторитет опытных сотрудников при условии их «адекватности» :)