Comments 53
… не каждый продукт следует разрабатывать. /закопали.
извините, не понял
Если не каждую функцию стоит программировать и не каждый баг фиксить, то и не каждый продукт стоит разрабатывать.
Вот придумали PM'ы новый суперметод на аукционе продавать рекламу по приватным данным фейсбука.
Стоит такой продукт делать? Вот, допустим, программисту, который любит код писать чисто и хорошо, да и в целом, человек этичный. А его PM считает, что надо делать всё, за что деньги платят.
Так и рождаются странные вещи, которыми нельзя удалённо открыть дверь, а необходимо именно самому подойти. т.е. открыть кому то дверь не вскакивая каждый раз — будет тем ещё приключением )
Да, решение очень странное. За дверью нужен чёткий контроль в плане открытия.
плюс постоянные открывания двери когда просто проходишь мимо неё… решение не то что странное, а идиотское и вредное
Странные вещи рождаются от непроработки всех вариантов использования и "бездумной" реализации всех фич, которые где-то видел менеджер или разработчик. А если в процессе разработки есть фильтр на "странные/ненужные фичи" и отдел тестирования, странных вещей на выходе уже должно получаться меньше.
Те же постоянные автоматические открывания/закрывания двери возможны, скорее всего, тогда, когда кому-то автоматическое открывание показалось отличной идеей, но он не подумал, что можно ходить не только сквозь дверь, но и рядом с дверью. Но этот вариант может быть лучше, чем постоянный виджет на экране блокировки смартфона (зачем он, когда пользователь далеко от двери?). Тут надо много думать, прежде чем делать (собственно, вся статья про это).
Виджет нужен если вы хотите кого то впустить-выпустить.
А вариант с автоматически открывающейся дверью было бы интересно отработать на предмет проверки направления движения человека — можно определять угол движения и траекторию.
Насчёт думать и делать… это всё прекрасно, конечно, но, чаще всего просто фантазии.
Для этого должны быть специальные люди (аналитики?) которые должны понимать пользователя, собирать данные и формулировать задания программистам и инженерам в таком виде, в котором они должны быть сделаны. Потому что требовать от программиста ещё и изучать предметную область, определять пользовательские пути и специфику их работы и мировоззрений — это требовать его выполнять не его обязанности, очевидно.
Более того, когда «видиние» программиста входит в конфликт с тем, как это видит начальство или его же аналитик… не избежать беды. =)
А вариант с автоматически открывающейся дверью было бы интересно отработать на предмет проверки направления движения человека — можно определять угол движения и траекторию.
Насчёт думать и делать… это всё прекрасно, конечно, но, чаще всего просто фантазии.
Для этого должны быть специальные люди (аналитики?) которые должны понимать пользователя, собирать данные и формулировать задания программистам и инженерам в таком виде, в котором они должны быть сделаны. Потому что требовать от программиста ещё и изучать предметную область, определять пользовательские пути и специфику их работы и мировоззрений — это требовать его выполнять не его обязанности, очевидно.
Более того, когда «видиние» программиста входит в конфликт с тем, как это видит начальство или его же аналитик… не избежать беды. =)
Для этого должны быть специальные люди (аналитики?) которые должны понимать пользователя, собирать данные и формулировать задания программистам и инженерам в таком виде, в котором они должны быть сделаны.
Наверно, статья больше рассчитана на людей, которые формулируют задания (и, возможно, сами их исполняют), а не на тех, что пишет код по уже сформулированным заданиям.
Для этого должны быть специальные люди (аналитики?)
Возможно, продуктовые дизайнеры.
А вариант с автоматически открывающейся дверью было бы интересно отработать на предмет проверки направления движения человека — можно определять угол движения и траекторию.
А теперь смотрите прикол — в попытке избавиться от разработки виджета вы приходите к тому, что нужно усложнить и поддерживать код, который будет анализировать необходимость открытия двери. И этот код можно не усложнять и не писать, если создать… виджет, где пользователь сам нажмет на кнопку, если захочет открыть дверь. Вот такой вот прикол.
Про самооткрывающуюся гостеприимную дверь я читал в одной детской книжке:
Там это было образцом идиотского изобретения. Дверь отрывалась, ставила чайник на плиту и приглашала заходить на чай. Закончилось тем, что кухня была забита десятками пробегающих мимо физкультурников, которые съели всё печенье и выпили весь чай.
Frank Cottrell Boyce «Chitty Chitty Bang Bang Flies Again»
But that afternoon, as Mum trudged up the garden path after a hard day’s work at Unbeatable Motoring Bargains, a very refreshing thing happened. The front door opened all by itself, and a bright little voice said, “Do come in. The kettle is on.”
“What a lovely homecoming,” said Mum, strolling into the kitchen just as the kettle came to the boil.
“I installed an automatic self-opening on the front door,” explained Dad, “and hooked it up to the kettle.”
“My genius.” Mum smiled.
“The word today,” said Dad, “is welcome home.”
“What a lovely homecoming,” said Mum, strolling into the kitchen just as the kettle came to the boil.
“I installed an automatic self-opening on the front door,” explained Dad, “and hooked it up to the kettle.”
“My genius.” Mum smiled.
“The word today,” said Dad, “is welcome home.”
Там это было образцом идиотского изобретения. Дверь отрывалась, ставила чайник на плиту и приглашала заходить на чай. Закончилось тем, что кухня была забита десятками пробегающих мимо физкультурников, которые съели всё печенье и выпили весь чай.
Это менеджерское мнение и оно в стратегическом смысле справедливое. То есть в перспективе, если программисты постоянно занимаются тем, что никому не нужно, то это повредит всем, в том числе, опосредованно и самим программистам.
А есть другое мнение. Есть программист, ему платят зп за 8 часов работы, он наемный работник и его судьба проекта (особенно большого) интересует не слишком сильно. Ему же интересно попробовать новые технологии, порешать сложные задачи (даже если не просят), прокачать скиллы для резюме. А дальше, если с проектом все пойдет плохо, он плюнет, уволится и будет технически готов к новой работе. Это выглядит цинично, менеджерам это не нравится и они пишут подобные статьи.
А есть другое мнение. Есть программист, ему платят зп за 8 часов работы, он наемный работник и его судьба проекта (особенно большого) интересует не слишком сильно. Ему же интересно попробовать новые технологии, порешать сложные задачи (даже если не просят), прокачать скиллы для резюме. А дальше, если с проектом все пойдет плохо, он плюнет, уволится и будет технически готов к новой работе. Это выглядит цинично, менеджерам это не нравится и они пишут подобные статьи.
А что мешает совмещать одно с другим? Ну вот скажем вы программист и отработав свои 8 часов вы уходите домой. Пока вы на фирме вы пробуете новые технологии и решаете сложные задачи. Но если к вам приходят с юзер стори/техзаданием, то вы можете попытаться прокачать скилл «определение адекватности техзадания и нахождения более оптимальных вариантов решений». Ну или что-то в этом роде ;)
П.С. И на мой взгляд такой скилл очень даже полезен на рынке труда и вполне себе пригодится в профессиональной карьере. И мне кажется вся статья как раз об этом.
П.П.С. И я бы даже сказал что в как минимум в некоторых областях ИТ именно этот скил необходим чтобы стать сениором или техлидом.
П.С. И на мой взгляд такой скилл очень даже полезен на рынке труда и вполне себе пригодится в профессиональной карьере. И мне кажется вся статья как раз об этом.
П.П.С. И я бы даже сказал что в как минимум в некоторых областях ИТ именно этот скил необходим чтобы стать сениором или техлидом.
А что мешает совмещать одно с другим?
Видимо, склад мышления. Не даром есть разделение на программистов, аналитиков и менеджеров. Хотя, иногда, программист может решать и аналитические и менеджерские задачи, но это скорее исключение.
Ну я бы не сказал что такое как-то обязательно противоречит складу мышления программиста.
Но да, в чём-то вы правы и тогда я бы сказал что «сениор/техлид» из моего поста выше это комбинация «программист-аналитик». А «программист-менеджер» это уже какой-нибудь тимлид :)
P.S.Но останусь при своём: если вы можете такие навыки прокачать, то оно пожалуй того стоит и в жизни/профессии пригодится.
Но да, в чём-то вы правы и тогда я бы сказал что «сениор/техлид» из моего поста выше это комбинация «программист-аналитик». А «программист-менеджер» это уже какой-нибудь тимлид :)
P.S.Но останусь при своём: если вы можете такие навыки прокачать, то оно пожалуй того стоит и в жизни/профессии пригодится.
Но останусь при своём: если вы можете такие навыки прокачать, то оно пожалуй того стоит и в жизни/профессии пригодится.
Я с этим и не спорил. Да и со статьей несильно спорю, просто показал другую точку зрения, которая очень распространена в последнее время.
Да она всегда была распространена. И я бы даже сказал что раньше её придерживалось гораздо больше айтишников чем сейчас. Ну как минимум в процентном соотношении уж точно.
И ты не перестаёшь быть хорошим айтишником если ты этого всего не делаешь. Просто вопрос ещё одного дополнительного «техно-софт-скилла» :)
И ты не перестаёшь быть хорошим айтишником если ты этого всего не делаешь. Просто вопрос ещё одного дополнительного «техно-софт-скилла» :)
UFO just landed and posted this here
Есть программист, ему платят зп за 8 часов работы, он наемный работник и его судьба проекта (особенно большого) интересует не слишком сильно.
Иногда людей, пишущих код, презрительно разделяют на кодеров и программистов. В этой "классификации", ваш программист — это кодер.
А есть и другой путь — заниматься не написанием фич, а созданием программного продукта. Не просто множества разных функций, а упорядоченной, гибкой и логичной системы, позволяющей пользователям решать даже такие задачи, о которых создатели системы не подозревали. Узкие примеры таких систем — word, excel (по принципу "чего в них только не пишут"). Ещё примеры — СУБД, файловые системы, различные редакторы и т.д.
В этой «классификации», ваш программист — это кодер.
Во-первых, нет, не обязательно кодер. Во-вторых, при чем тут это деление, для красного словца? Ну хорошо, подставьте кодера туда, если нравится. Ситуация-то не изменится, есть кодер, ему платят зп за работу, ему пофиг на судьбу проекта и т.д.
А есть и другой путь
Ваш пример требует архитектора или команды архитекторов, в статье про это ни слова, это другой кейс.
UFO just landed and posted this here
Очень часто, а в мире OpenSource так в большинстве случаев, код пишется не потому, что хотят решить какую-то проблему, а потому, что нравится писать код. Т.е. людей интересует не цель, которой часто может и не быть, а сам процесс.
Вот возьмём в качестве примера такой крупный OpenSource проект, как radare2. Это кроссплатформенный фреймворк для анализа и реверсинжениринга кода, который иногда даже осмеливаются назвать свободным аналогом IDA. Но вся его крутость разбивается о тот маленький фактик, что r2 не позволяет загружать ранее созданные проекты. Ну то есть вы можете загрузить бинарник, провести анализ, расставить комментарии, обозвать переменные и структуры, даже провести частичную декомпиляцию в псевдокод. Вот только при повторной загрузке всё это потеряется, потому что загружать проекты r2 пока не умеет.
В итоге софт, над которыми работали многие сотни людей, пригоден разве только для примитивных крекмисов. И знаете что? Никого из разработчиков это не волнует, потому что у них нет цели создать рабочий продукт. Они занимаются ровно теми вещами, над которыми им интересно работать, пишут новые фичи, добавляют поддержку новых архитектур. В общем, получают кайф от процесса кодирования. А результат? Да кому он вообще нужен.
К счастью, когда подобные проекты в достаточной мере обрастают более-менее рабочими фичами, на них могут обратить внимание крупные корпорации. Вот например достал всех Autodesk совершенно неадекватной работой с крупными клиентами, и корпорации подбросили бабла в Blender. После чего вместо насквозь глючного кошмара, в котором даже union двух кубов булился с дырами, образовался вполне себе пригодный к использованию продукт.
Именно для того в разработке и нужны менеджеры — чтобы ставить чёткие цели и контролировать их достижение вне зависимости от того, нравится это кодерам или нет.
Вот возьмём в качестве примера такой крупный OpenSource проект, как radare2. Это кроссплатформенный фреймворк для анализа и реверсинжениринга кода, который иногда даже осмеливаются назвать свободным аналогом IDA. Но вся его крутость разбивается о тот маленький фактик, что r2 не позволяет загружать ранее созданные проекты. Ну то есть вы можете загрузить бинарник, провести анализ, расставить комментарии, обозвать переменные и структуры, даже провести частичную декомпиляцию в псевдокод. Вот только при повторной загрузке всё это потеряется, потому что загружать проекты r2 пока не умеет.
В итоге софт, над которыми работали многие сотни людей, пригоден разве только для примитивных крекмисов. И знаете что? Никого из разработчиков это не волнует, потому что у них нет цели создать рабочий продукт. Они занимаются ровно теми вещами, над которыми им интересно работать, пишут новые фичи, добавляют поддержку новых архитектур. В общем, получают кайф от процесса кодирования. А результат? Да кому он вообще нужен.
К счастью, когда подобные проекты в достаточной мере обрастают более-менее рабочими фичами, на них могут обратить внимание крупные корпорации. Вот например достал всех Autodesk совершенно неадекватной работой с крупными клиентами, и корпорации подбросили бабла в Blender. После чего вместо насквозь глючного кошмара, в котором даже union двух кубов булился с дырами, образовался вполне себе пригодный к использованию продукт.
Именно для того в разработке и нужны менеджеры — чтобы ставить чёткие цели и контролировать их достижение вне зависимости от того, нравится это кодерам или нет.
Проекты radare вроде умеет с 2017 http://radare.today/posts/project-files/. Или вы имели в виду что-то другое?
Нужны менеджеры, которым нравится Open Source :)
Гитхаб в последнее время активно внедряет поддержку спонсорства. Уже можно спонсорить как проекты, так и самих пользователей. Может это больше их больше стимулирует пилить нужные фичи.
Одним словом — изучите предметную область, прежде чем писать код.
Рекомендую почитать «Психбольница в руках пациентов».
Если кратко, то все программисты, согласно автору (вроде тоже бывшему программисту), являются особым подклассом людей, которые не умеют проектировать, но умеют писать код. И их и близко нельзя подпускать к проектированию, иначе все равно получится дурно пахнущая субстанция. Для проектирования нужны специально обученные люди.
Задача же программиста определить, насколько предлагаемое решение является осуществимым технически и сколько по времени и ресурсам займет реализация. Ну и написать код. Все.
P.S. А дверной замок, открывающийся при приближении телефона не купил бы никогда. Слишком непредсказуемая система.
Если кратко, то все программисты, согласно автору (вроде тоже бывшему программисту), являются особым подклассом людей, которые не умеют проектировать, но умеют писать код. И их и близко нельзя подпускать к проектированию, иначе все равно получится дурно пахнущая субстанция. Для проектирования нужны специально обученные люди.
Задача же программиста определить, насколько предлагаемое решение является осуществимым технически и сколько по времени и ресурсам займет реализация. Ну и написать код. Все.
P.S. А дверной замок, открывающийся при приближении телефона не купил бы никогда. Слишком непредсказуемая система.
Есть довольно интересный взгляд немного с другой стороны: программисты и менеджеры, которые непосредственно руководят разработкой, обычно не очень тупые. И они понимают, что им платят за процесс разработки, а завершение разработки приведёт к массовым сокращениям, когда на поддержке останется пара человек. Поэтому надо сесть и продолжать кодить, выдавая тысячи обновлений и новые проекты, получая при этом зарплату. Так появляются безумные приложения для замков (!), почта, которая тормозит на современном ноутбуке, приложение мобильного оператора, которое требует максимальную версию IOS и посылает остальных, и пиццерия, которая нанимает десятки разработчиков и аналитиков, чтобы стабильно возить невкусную пиццу.
Отдельный вопрос в том, что в куче компаний разработчик получит больше бонусов (внутренняя известность, продвижение в должности, премии) если проект, который он писал и продвигал, провалится или будет просто закрыт с гигантским убытком, чем если бы этого проекта не было. Привет, Гугл, ваши методы повышения в должности шикарны.
Отдельный вопрос в том, что в куче компаний разработчик получит больше бонусов (внутренняя известность, продвижение в должности, премии) если проект, который он писал и продвигал, провалится или будет просто закрыт с гигантским убытком, чем если бы этого проекта не было. Привет, Гугл, ваши методы повышения в должности шикарны.
И они понимают, что им платят за процесс разработки, а завершение разработки приведёт к массовым сокращениям, когда на поддержке останется пара человек. Поэтому надо сесть и продолжать кодить, выдавая тысячи обновлений и новые проекты, получая при этом зарплату.
Извините, но во первых это на мой взгляд обыкновенный саботаж и не то чтобы особо моральное поведение.
Во вторых среди начальства тоже далеко не все идиоты и рано или поздно такое раскроется. И опять же есть хороший шанс получить определённую репутацию от которой уже будет не избавиться.
В третьих я слабо могу себе представить как может «завершиться разработка» большинства известных мне систем и продуктов. Практически всегда пользователи, бизнес и окружающий мир «придумывают» что ещё можно добавить в продукт или как его изменить.
Ну и напоследок лично я вообще ничего не имею против если продукт доходит до какого-то уровня развития, когда лично мне в нём больше нет места. Значит уволюсь(а ещё лучше пусть меня уволят) и найду новую работу по нраву. Причём скорее всего ещё и с большей зарплатой.
бизнес и окружающий мир «придумывают» что ещё можно добавить в продукт или как его изменить
Бизнес и окружающий мир — это часто и есть те люди, которые не заинтересованы в том, чтобы проект закончился. И они не хотят, в отличие от вас, увольняться и искать новую работу по нраву.
Я скорее имел ввиду «хозяев фирмы» и «мир за пределами фирмы». И если не хотят чтобы проект заканчивался и платят за это, то тут у меня вообще никаких проблем нет.
На стороне заказчика тоже есть люди, которые вели проект, довели до рабочего состояния, но как и с ремонтом — невозможно завершить, всегда можно придумать что-то еще.
С этим я не спорю. И я ничего не имею против того чтобы проекты развивались и продолжались. Я против того чтобы разработчики сами «создавали» себе ненужную работу просто из боязни быть уволенными,
П.С. И ненужная работа это именно ненужная, а не какой-нибудь действительно полезный рефакторинг или технологичеслий апгрэйд.
П.С. И ненужная работа это именно ненужная, а не какой-нибудь действительно полезный рефакторинг или технологичеслий апгрэйд.
The first prerequisite you need to fulfill before beginning construction is a clear statement of the problem that the system is supposed to solve.
© Code complete, Steve McConnell
Программисты, кажется, забыли реальную цель программного обеспечения — это решать реальные проблемы.
Программисты ничего не забыли. Просто существует очень сильная корреляция между хорошим кодом, лучшим практикам, современным технологиям, продуманным решениям с одной стороны и качеством ПО, стабильностью работы, стоимостью разработки и поддержки с другой. И если аналитик, менеджер, либо кто-то еще этого не понимает, то, вполне возможно, проблемным звеном в цепи разработки являются не программисты.
Программисты осознают, что их первостепенная задача решить проблему. Вот только проблема не бывает в отрыве от контекста. У проблемы есть некий бекграунд, у проблемы есть причина, у проблемы может быть классификация. А еще иногда проблема на самом деле не является проблемой, а это просто наша собственная интерпретация ее как проблемы.
Есть такая поговорка: «Если у вас есть только молоток, все выглядит как гвоздь».
И все же забитый молотком шуруп держится куда лучше, чем завернутый отверткой гвоздь.
Проблема, которую вы решаете, важнее, чем код, который вы пишете
Программисты не решают проблемы. Программисты пишут код. А те, кто решают проблемы, сами код не пишут. Если для решения проблемы им нужен код, они зовут программистов для написания кода. И почему-то думают, что программисты решают их проблему. Господи, да мы в большинстве случаев только от вас и узнаём, что проблема существует! Хотите открывать дверь по кнопке — нате вам кнопку, хотите по GPS — нате вам GPS. Вы сами не знаете, чего хотите, и вам просто нужно с кем-то об этом поговорить? ОК, давайте устроим совещание.
Проблема, которую вы решаете, важнее, чем код, который вы пишетеОдни разработчики не могут сделать и шага, пока не видят всю задачу создаваемого продукта в целом, других разработчиков интересуют только текущие четко поставленные задачи и технологии их решения и ничего другого они не желают знать. ИМХО, коллективы состоящие из первых всегда эффективнее, если разве что, речь не идет о том, чтобы шлепать похожие проекты на конвейере.
Вот вообще ни разу не согласен, какая-то однобокая статья.
КМК, тот же Spring Framework код ради кода, но при этом упрощает решение бизнесовых задач.
Про виджет вам выше вполне обоснованно написали когда он удобен, возможно из-за его отсутствия стартап и накрылся?
На сколько правильно я понял посыл, зачем писать ___, которое займет 3 часа если в нужном месте можно добавить костыль за 5 минут. Так и рождается тех долг.
поставьте себя на место клиента, а если еще и сопровождается фин издержками со стороны клиента?
то что произошло 1н раз може повториться в будущем неоднократно, тогда и баг придется править и людям разгребать.
Программисты, кажется, забыли реальную цель программного обеспечения — это решать реальные проблемы.
КМК, тот же Spring Framework код ради кода, но при этом упрощает решение бизнесовых задач.
Про виджет вам выше вполне обоснованно написали когда он удобен, возможно из-за его отсутствия стартап и накрылся?
Однако, как и в случае с «Техническим долгом», ничто не должно служить оправданием для написания дерьмового кода.
Не каждый код стоит писать
На сколько правильно я понял посыл, зачем писать ___, которое займет 3 часа если в нужном месте можно добавить костыль за 5 минут. Так и рождается тех долг.
Если у вас криптобиржа и в системе один и тот же платеж провелся дважды
Не каждый баг стоит исправлять
поставьте себя на место клиента, а если еще и сопровождается фин издержками со стороны клиента?
то что произошло 1н раз може повториться в будущем неоднократно, тогда и баг придется править и людям разгребать.
"Пожулуйста" это конечно не ошибка перевода...)
UFO just landed and posted this here
Sign up to leave a comment.
Проблема, которую вы решаете, важнее, чем код, который вы пишете