Очень хороший и правильный пост. Функциональное тестирование в контексте мониторинга «правильности работы» — обязательная часть любого крупного проекта или сервиса. Я уже в третьей компании за свою карьеру ввожу тестирование именно в таком контексте. Кстати, позволю себе немного пропиариться, похожую услугу мы предлагаем в составе нашего сервиса www.trackfort.com/
Я бы предложил Ольге Бруковской продать мне своё обручальное кольцо. А то тут у жены брата дяди юбилей, надо подарок сделать. За текущую рыночную цену. А лучше пусть поддастся моему мужскому обаянию и скинет цену в три раза.
Удивительно как много комментов о том, что киберсквоттер якобы что-то украл. У кого он украл, прости господи? Он честно купил никому не принадлежащий домен.
А конец истории вполне разумен — между «теоретически в будущем получить большую сумму» и «получить чуть меньше прямо сейчас» — выбор очевиден.
Опять всё в кучу намешали. Процесс, результат… Есть такие люди, задача которых в компании — поддерживать и развивать процессы, потому что без них начинается кромешный ад. Так вот у них одновременно никогда нет результата, и в то же время каждый день есть результат. При таком опыте, который у автора в профайле перечислен, грех этого не знать. И вся вот эта очередная бодяга про самомотивацию подходит только для конечных исполнителей (разработчиков, дизайнеров и т.д.), но не подходит для управленцев.
Поэтому весь пост — очередная демагогия, направленная на то чтобы превратить разработчиков в роботов, выполняющих план. Потому что на самом деле человек, стремящийся к высокой продуктивности, думает не о том, какую задачу в первую очередь решать. Он думает о том, кто решит эту задачу вместо него. Управляет, а не реализует.
Ааа, вот в чем дело. У нас просто сильная декомпозиция задач, коммиты частые, и звать ревьюера на каждый — чудовищно отвлекать его от работы. Поэтому контекстом является вся feature в целом, перед merge.
Тем не менее, вы реально молодцы, с удовольствием пообщался бы в оффлайне.
Молодцы.
У нас всё так же, только мы используем модель feature branches.
Это позволяет в любое время иметь stable сборку и избавляет от необходимости некоторых мелочей типа упомянутой вами pre-commit code review (коммит в принципе ничего не ломает и его ревьюят позже).
В статье рассмотрен прекрасный идеализированный мир, который никогда не сложится в реальности. Квалифицированные программисты, аналитическая документация, рефакторинг, чистая модульность… Ещё наверное надо добавить разумные сроки и вменяемого заказчика :)
За статью +1 как за хорошую сказку. Но по своему более чем 10-летнему опыту работы ПМ-ом и техдиром скажу: основная задача техдира — это уметь наиболее эффективно оперировать той реальностью, которая ему дана в конкретном проекте.
Делать упор на фичи, а не на PR — приносит успех в основном когда вы продаёте решение B2B и ваши реселлеры (дилеры) продают точно так же — создают добавочную стоимость засчёт имиджа и пиара.
А если они продают конечному клиенту «за фичи», а вы пытаетесь им впарить «за имидж», то это не прокатит. Нельзя продать болт на M20 из сырой незакалённой стали, лишь описывая чем он выгодно отличается от конкурентов.
Ваш подход справедлив для вчерашних школьников или студентов, которым интересно изучать новое.
Но в крупных проектах средний возраст разработчиков — около 28-32 лет. Они уже наработали себе опыт и определённый консерватизм, у них есть семья, маленькие дети, пожилые родители. Они не заинтересованы, да и просто не смогут «быстро осваиваться и что-то там выдавать». Им нужна стабильная работа в сфере комфорта на привычных технологиях.
Я не против ерланга, как и любого другого «нетипичного» языка программирования. Но когда бюджет проекта измеряется миллионами (хотя бы рублей), вам их под «быстро осваивающегося студента» никто не даст.
Ваша позиция называется «порулил и убегай».
Наивно полагать, что произвольно взятая команда вот так единогласно что-то выберет :) Программистов хлебом не корми — дай поспорить о технологиях. По себе знаю.
А в случае ухода ключевых специалистов вы окажетесь в ж… пе на несколько месяцев, пытаясь срочно найти хоть кого-то им на замену.
Группа программистов, как и любая другая группа, нуждается в разумном управлении.
Я бы оставил только первый пункт: «не делать ненужные вещи» :)
Именно эта способность — регулярно отказывать начальству, заказчикам и коллегам в выполнении ненужных задач — позволяла мне вытаскивать команды и проекты из самых, казалось бы, безнадёжных ситуаций.
В проекте должен быть явно выделенный разработчик, отвечающий за архитектуру системы
— нет! Ни в коем случае нельзя делать одного выделенного системного архитектора.
1. Он может банально уволиться в середине проекта.
2. Он может счесть себя богом, и начать творить самодурство в проекте.
3. Он может быть аутистом и психопатом, и вместо общепринятых в мире решений — начнёт делать свой собственный велосипед под каждую задачу.
Архитекторов в проекте должно быть как минимум двое, причём разных типов личности. Парное программирование, кстати, ещё никто не отменял.
Епрст. Никакие домены не продаются и не даются в собственность. Только в аренду на ограниченный период времени. Собственником доменов в зоне «ru» является Руцентр. Собственником субдоменов "*.vkontakte.ru" является Вконтакт. Собственник вправе дать кому-то попользоваться доменом (за деньги), и вправе отобрать назад. Это, млять, основы доменного регулирования. Топикстартер, о чём вы вообще?
Забавно, как меняется рынок. Три года назад формировать стоимость проекта из трудочасов считалось кощунством. Люди продавали «арт-концепции» и «комплексные решения», накручивая на них пятикратную прибыль без объяснения причин. За разглашение клиенту часовых трудозатрат сотрудников чуть ли не приговаривали к расстрелу через повешение :)
Встречал конечно, посмотрите на мою историю работы в IT. Некоторые годами не осознают, что сидят в джайле. Рядовой сотрудник саппорта хостинга точно не догадается.
Взломщику незачем тревожить владельца сервера, удалять все файлы, запускать левые процессы, и совершать прочие деструктивные действия. Машина просто тихо становится гейтом к чьим-то корпоративным данным или сетям.
Хорошо написано, но ни слова про jail. А если тебя сломали и всю систему имитировали в jail, то хоть до посинения меняй рутовый пароль и ищи руткиты — настоящая система всё равно остаётся «выше» и остаётся полностью в распоряжении взломщика.
А конец истории вполне разумен — между «теоретически в будущем получить большую сумму» и «получить чуть меньше прямо сейчас» — выбор очевиден.
Поэтому весь пост — очередная демагогия, направленная на то чтобы превратить разработчиков в роботов, выполняющих план. Потому что на самом деле человек, стремящийся к высокой продуктивности, думает не о том, какую задачу в первую очередь решать. Он думает о том, кто решит эту задачу вместо него. Управляет, а не реализует.
Тем не менее, вы реально молодцы, с удовольствием пообщался бы в оффлайне.
У нас всё так же, только мы используем модель feature branches.
Это позволяет в любое время иметь stable сборку и избавляет от необходимости некоторых мелочей типа упомянутой вами pre-commit code review (коммит в принципе ничего не ломает и его ревьюят позже).
За статью +1 как за хорошую сказку. Но по своему более чем 10-летнему опыту работы ПМ-ом и техдиром скажу: основная задача техдира — это уметь наиболее эффективно оперировать той реальностью, которая ему дана в конкретном проекте.
А если они продают конечному клиенту «за фичи», а вы пытаетесь им впарить «за имидж», то это не прокатит. Нельзя продать болт на M20 из сырой незакалённой стали, лишь описывая чем он выгодно отличается от конкурентов.
Но в крупных проектах средний возраст разработчиков — около 28-32 лет. Они уже наработали себе опыт и определённый консерватизм, у них есть семья, маленькие дети, пожилые родители. Они не заинтересованы, да и просто не смогут «быстро осваиваться и что-то там выдавать». Им нужна стабильная работа в сфере комфорта на привычных технологиях.
Я не против ерланга, как и любого другого «нетипичного» языка программирования. Но когда бюджет проекта измеряется миллионами (хотя бы рублей), вам их под «быстро осваивающегося студента» никто не даст.
Наивно полагать, что произвольно взятая команда вот так единогласно что-то выберет :) Программистов хлебом не корми — дай поспорить о технологиях. По себе знаю.
А в случае ухода ключевых специалистов вы окажетесь в ж… пе на несколько месяцев, пытаясь срочно найти хоть кого-то им на замену.
Группа программистов, как и любая другая группа, нуждается в разумном управлении.
Именно эта способность — регулярно отказывать начальству, заказчикам и коллегам в выполнении ненужных задач — позволяла мне вытаскивать команды и проекты из самых, казалось бы, безнадёжных ситуаций.
— нет! Ни в коем случае нельзя делать одного выделенного системного архитектора.
1. Он может банально уволиться в середине проекта.
2. Он может счесть себя богом, и начать творить самодурство в проекте.
3. Он может быть аутистом и психопатом, и вместо общепринятых в мире решений — начнёт делать свой собственный велосипед под каждую задачу.
Архитекторов в проекте должно быть как минимум двое, причём разных типов личности. Парное программирование, кстати, ещё никто не отменял.
В Казань поеду обязательно, спасибо за анонс.
Взломщику незачем тревожить владельца сервера, удалять все файлы, запускать левые процессы, и совершать прочие деструктивные действия. Машина просто тихо становится гейтом к чьим-то корпоративным данным или сетям.