Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Resume-Driven Development

Сейчас у всех на слуху такие понятия как TDD, BDD и тд. А еще есть такая вещь как RDD — resume-driven development. И этот подход к разработки ПО встречается едва ли не чаще, чем остальные, вместе взятые.

RDD подразумевает, что вся ваша деятельность будет управляться одной целью — получить красивую строчку в резюме. То есть все технологии, методологии и фреймворки вы будете выбирать исходя из того, что будет лучше смотреться в резюме, а не из того, что вам нужно. Например, сейчас моден NoSQL и поэтому вы возьмете Hadoop в то время как под ваши задачи идеально подходит MySQL.

К сожалению, к этому подходу подталкивает сама наша с вами так называемая индустрия. Например, для Java-программиста нехватка в резюме волшебных слов Spring и Hibernate может оказаться не то чтобы фатальной, конечно, но довольно таки неприятной.

RDD возможен не только со стороны разработчика. Заказчик тоже вполне может идти на поводу у моды, пусть ему фремйворки и не идут в резюме. Он может выбрать Oracle, потому что его приятель по MBA сказал, что MySQL подходит только для дешевых вебсайтов.

Минусы resume-driven development очевидны: вы руководствуетесь общей модой, а не проектной необходимостью. Вам нужно время на освоение этих новых технологий и фреймворков. И они могут оказаться кривыми и не очень подходящими для крупных коммерческих проектов. Да и может просто оказаться, что к следующему поиску работы эти технологии уже стали немодными.

А какие же тут плюсы? Ну, даже не знаю. По-моему, никаких. Разве что вам действительно позарез нужны строчки про Spring и Hibernate в вашем резюме.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

LinkedIn

Схожі статті




61 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

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

А давайте признаемся — мы все по уши в RDD, как минимум потому, что нас всех волнует завтрашний день.
— Мы выбираем себе более перспективные на наш взгляд проекты
— Мы с радостью осваиваем новые, перспективные на наш взгляд технологии
— Мы с радостью пишем в резюме те знания и опыт, которыми гордимся
— И, в конце концов, мы просто не пишем в резюме те технологии, которые считаем мусором
Или как то не так? ;)

И даже более того, игнорировать мотивацию разработчиков при выборе технологии для проекта — это даже тянет на рецепт эпик фейла... :)

А мне вот не по уши, а где-то пох... пардон, посередине роста :) Как для резюмы, то уж не особо.
Выбор новинок оправдан новизной, и это естественно. В новых проектах должна быть новизна, технологическая как минимум. А этого можно достичь либо старыми средствами и хорошими мозгами, либо новыми средствами и мозгами.
Автор подчеркнул, что типичный минус РДД это когда

вы руководствуетесь общей модой, а не проектной необходимостью

. А у тебя как раз нормальная мотивация при проектной необходимости.

Полностью согласен. Бывает так же, что после нескольких лет разработки, хочется поменять технологию. И вот сдесь приходит момент, когда нужен этот RDD.

Замовник взагалі нічого не повинен вибирати. Його справа — дати ТЗ і не заважати.

это на бумаге так бывает

Да, и смотря кто заказчик. Когда тебе, как третьего уровня субподрядчику, аутсорсят кусочек «пирога» с начинками из хадупов, спрингов, екст-джиэсов и еще какого-то соуса собственного приготовления... И еще в догонку — хот, хот, гарачо вакасьон!!! Испекать бистро, шнеля, шнеля, форверц :))

Я думаю, самі винні. Звичайно, у нас на всіх фірмах, слово замовника — закон. А то ж, якщо я раптом щось скажу не так, то проект заберуть, краще буду робити через жопу, але мовчки. А вкінці, якщо вийде фігня, ну я вроді би і ні при чому, замовник же сам так захотів :)

Преп студенту:
— Какова вероятность того, что идя по городу Вы встретите динозавра?
— 50%
— Почему?!! 8[ ]
— Либо встречу — либо не встречу.

Так и здесь. Если ты меняешь решение принятое заказчиком, то либо тебя потом включают соавтором в патент, либо забирают проект. :)

Вольный перевод:

Если ты меняешь решение принятое заказчиком

то либо тебя потом включают соавтором в патент

Тебя нанимали на роль программиста (разработчика и тд)

либо забирают проект. :)

Тебя нанимали как негро-кодинг-абезянку.

P.S. Давненько на ДОУ не было срача аутсорс/продуктовая.

Он может выбрать Oracle, потому что его приятель по MBA сказал, что MySQL подходит только для дешевых вебсайтов.

Думаю что многие смогут припомнить подобные случаи из своей практики. «Как! У вас не Oracle? а какой-то PostgreSQL...» :)

А если задуматься, то сама идея Resume-Driven-Development не несет никакой практической пользы ни для разработчика ни для заказчика. Разработчику RDD нужен для красивого резюме, т.е. чтобы выглядеть крутым перцем в глазах заказчика, а заказчику в свою очередь нужен продукт/результат исходя из требований, а не исходя из красивых названий технологий. RDD можно сравнить с модой: сегодня модны джинсы, а завтра опять будут в моде узкие брюки-дудки.

Польза таки есть:

Под популярные технологии проще найти людей.

Если компания заинтересована в результате, то я думаю вопрос в специалистах стоять не будет. Проще не значит лучше.

бюджет не резиновый в любом случае. а популярные не значит (не всегда значит) плохие. и поддержка потом (супергерои поддержку не уважают) тоже не забесплатно дается.

В теории да, на практике ...

Считаю, что в выборе технологий следует руководствоваться следующими правилами (в порядке приоритета):

— невозможность выполнения задачи ни на какой другой технологии. Например, единственный компонент для вэба, который позволяет редактировать RTF-файлы (не абы какой ричтекст, а именно текст в RTF-формате) — компонент DevExpress на Silverlight. Значит, придется либо не давать пользователю редактировать RTF, либо использовать Silverlight.
— предполагаемый способ развертывания. Скажем, заказчик требует, чтобы это был .war-файл — значит Haskell отпадает.
— технология, уже используемая в других компонентах системы. Скажем, часть проекта на Spring, поэтому я не вижу смысла использовать для чего-то Guice.
— технология, с которой знаком большинство членов команды. Проще и быстрее переучить одного разработчика, чем десяток.
— новые технологии — это риск, но это не значит, что их следует запретить вовсе. Новые технологии — это еще и шанс удержать ценных сотрудников, а также привлечь новых — они будут чувствовать, что они «в теме», на гребне волны, так сказать. Так что внедрять стоит, но осторожно. Скажем, для отдельных подзадач или для непрофильной активности. Например, база на Оракле, а анализ логов с нескольких вебсерверов — на Hadoop. Или, например, код самого приложения на Java, а юнит-тесты — на Scala.
— новые технологии — не всегда хорошо. Это еще и маркеттинг, и риск. Разработчик, который это понимает — гораздо более ценен как специалист — эту мысль стоит донести до самих разработчиков. Пусть они думают, что отказ от самого модного и разрекламированного тренда, при условии, что был сделан evaluation — это тоже хорошо, причем и для резюме: на интервью девелопер потом может блеснуть знанием слабых сторон технологии, что тоже немаловажно.

— всегда нужно давать людям возможность пробовать что-то новое, если время позволяет. Разработчики должны понимать, что право на использование новых технологий надо заслужить хорошей работой. Закрыл таки раньше срока? Помог джуниору с его задачами? «Украл» у коллеги баг и пофиксил его? — конечно, дружище, возьми напарника и попробуйте в деле Mercurial — вот вам на это четыре дня. О результатах расскажете в следующую пятницу, перед тем, ка мы всей командой пойдем пиво пить.

Как-то так. Буду рад дополнениям.

хорошо написано

а то мы как-то про интересы девелопера забыли совсем

Разработчики должны понимать, что право на использование новых технологий надо заслужить хорошей работой.

Напомнило «куплю кроссовки, когда сносишь коньки» :) Еще стоит не забывать про бюджет. Например, открытые тулзы вместо проприетарных и т.п.

технология, уже используемая в других компонентах системы. Скажем, часть проекта на Spring, поэтому я не вижу смысла использовать для чего-то Guice.

Более интересная ситуация:
Ни то не другое на проекте не использовалось. Решили что проекту нужен IoC. Опыт со Spring и Guice у всех довольно поверхностный. Внешне Guice кажется более ... подходящим ... более подходящим по стилю работы большинству команды.
Но есть человек который уверенно говорит: Spring!

На вопрос «почему?», немой ответ, а в глазах читается: «Spring я могу вписать в резюме, а куда мне засунуть ваш Guice?»

Spring я могу вписать в резюме, а куда мне засунуть %ЭТУ_ПРИБЛУДУ%
+$100500 — c одной стороны, — да — когда ты миддл или джун.
но
на определённом уровне вполне допустимо и даже полезно поковырять узкоспециальные фреймворки и технологии, т.к. владение ими может дать хорошую фору в нужное время в нужном месте.

на определённом уровне вполне допустимо и даже полезно

Тока этот уровень зачастую подразумевает, что Спринг уже есть в резюме. :)

Такого человека надо отстранять от возможности принятия решений, он не должен занимать руководствующий позиций. Он может завалить проект.

В данном случае решение принималось коллективно.

Да, проблема с резюме есть. Хотя лично я бы скорее нанял не человека с опытом в Spring,а человека с опытом в Guice, который сможет объяснить его плюсы-минусы по сравнению со спрингом.

который сможет объяснить его плюсы-минусы по сравнению со спрингом.

Вольный перевод:
Человека с опытом и со Spring-ом и с Guice-ом.

:)

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

Рыба, она обычно гниёт с головы.

Менеджер который думает что он клевый технарь и берется пресcинговать девелоперов в принятии тех. решений — самый страшный человек на проекте.

Да, менеджер должен сразу выделять деньги на покупку и поддержку всего того, что навыбирали девелоперы. Эти решения имеют несколько факторов, и должны приниматься совместно. Кроме технической стороны всегда есть политическая, например использовать решения партнерской организации и т.п.

Покупка-поддержка, 2012 год на дворе, почти все инструменты бесплатны, а те, что стоят денег, обычно стоят каких-то смешных денег из серии сто баксов за разраба.

А про партнеров не надо, ISD — и партнер Микрософт, и Оракл. И что же, одновременно и SQL Server, и Oracle DB использовать? Партнеры не должны давить при выборе тулов.

Я не про тех партнеров, у которых покупают, а о тех с которыми разрабатывают и/или продают.

Рыба у вас гнилая, если девелоперы (ну ок, сениор девелоперы, архитекторы, лиды, не важно) не принимают участия в принятии решений о технологиях.

Ну у многих уж какая есть ... есть такое понятие «корпоративные стандарты». Есть задача — есть рамки в которых можно найти решение есть зарплата. Динозавры обычно неповоротливы но обеспечивают относительно стабильную среднюю зарплату (хороший вариант для тех у кого кредит, пополнение в семье или прочее зло).
Для творческих людей, которым не сильно важна стабильность, есть страртапы ...

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

Рыба, она обычно гниёт с головы.

when developers ask you to choose a particular tool or technology, always have them explain to you why this may not just be a RDD request versus a request that may actually be good for the client. If the developer talks more about the technology as opposed to the solution or the customer’s requirements then the developer is not focused on the right topic. In fact, ask the developer outright: “will this tool, technology, or technique help your career more than it will help the client?” See how the developer responds.

Заранее простите за утрирование.
Можно долго кричать про плюсы и минусы, но есть факты.
А факты говорят, что если у тебя в резюме MySQL, то максимум на что ты способен — это наклепать сайт «любимой кошке». Или если у тебя «нет Agile-а» или (о Боже!) опыта работы в софтверной компании — то ты не котируешься. И 5-10 лет работы уже никому не интересны.

Печально.

Я последние пару лет работаю с MySQL. На серьезных проектах, некоторые даже enterprise в чистом виде.

ага. некоторые конечно кривят носом. ну пускай покривят

а если носом кривит заказчик?

там тоже есть м...даки

Но вообще да, нет некоторых технологий в резюме — и тебя процентов 60-70 эйчаров пропустит. Я там писал об этом.

Это справедливо для мэйнстрима. Но есть еще нишевые, они же продуктовые компании. Не стоит недооценивать их долю на рынке. А вот там как раз охота не за RDD-специалистами, а за зрелыми, которые руководствуются не модой, а здравым смыслом.

Есть подозрение, что их количество значительно меньше и зп тоже. Нет?

таки — нет (имхо)

на продуктах пахать надо як батько Карло

а хороший пахарь денег стоит

есть конечно вариант когда хороший девелопер будет работать бесплатно (ну за возможные опционы (и прочие перспективы) так то уже другая история

60-70 процентов, про которые я написал, это и есть мейнстрим. Цифры, конечно, не точные, могу ошибаться.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

при всей правоте, статья выглядит как плоская проекция многомерного (3++) понятия =профессиональный рост=

он — превыше денег, согласен.

Человек всегда тянется узнать что-то новое, чтобы облегчить себе работу или сделать ее более эфективной.

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

Ну а если позволяют использовать Oracle там где нужен MySQL — значит в компании слишком много денег.

Например, для Java-программиста нехватка в резюме волшебных слов Spring и Hibernate может оказаться не то чтобы фатальной, конечно, но довольно таки неприятной.

Если мода и этот ваш RDD форсируется программистами — то в маленьких проектах и крайне редко. Часто ли у разработчика есть возможность выбора? Судя по требованиям в вакансиях — почти никогда. Даже если есть — то я сомневаюсь что это решается без архитектов, ПМ, и т.п. А уж коль упомянуты большие проекты...

Ну а что, архитектор или ПМ не может руководствоваться RDD?

Может, но это не личная прихоть, а требование рынка. Hibernate будут выбирать, потому что это опыт, который требуют от джавистов работодатели (заказчики). Да, это делается для резюме, но не только. Неадекватный выбор технологии точно приведет к проблемам, опытный программист никогда не выберет технологию только для резюме, если это приведет к гемору для него же, это разве что если речь о тех кто по полгода работает на одном месте, не более.

сережа шо за дешовый вброс )))

поучись вот у него:
www.developers.org.ua/...andnaya-stroka

Это не вброс, это чистая правда. Видишь, никто и не спорит со мной.

А про командную строку эо даже не вброс был, это был чистый отжиг.

Так ли уж плохо?

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

Зато когда сверху спустят жесткое требование — хотим отэто — вы в шоколаде, за 3-4 дня осваиваете любой фреймворк и ГТО :)

Креативность — это хорошо, пока он не мешает. А она в таких случаях мешает.

Таково бремя демократического общества: вам нужно думать не только о проекте, но и о себе.

О вашей будущей карьере начальство за вас думать не будет.

Капиталистического, а не демократического.

+1, але це проблема начальства, а не програміста, їм то завжди щось цікаве і новітнє повчити.

А ще мода простим речам давати якісь круті — незрозумілі слова як SOLID. А ще у нас походу тепер куда не плюнь то знищення «залежностей» скоро через веб конфіги будем аплікухи «будувати»))

В SOLID в одной только букве L скрывается масса полезных вещей.

Якось жив декілька років не чуючи це слово)

Коментар порушує правила спільноти і видалений модераторами.

плюсую

мода она такая мода

Підписатись на коментарі