Comments 200
Типичный разговор с ПМ:
— Что вы делали всю итерацию и почему задачи не закрыты?
— Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.
— Мне пофиг, почему задачи не закрыты?
— Что вы делали всю итерацию и почему задачи не закрыты?
— Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.
— Мне пофиг, почему задачи не закрыты?
Если задачи были критичными и нужными именно в это итерацию — программисты не правы и занимались фигнёй. Если же не были, и через пару итераций это позволит нагнать темпы — не прав ПМ.
Для этого и стоят статусы в задачах же, и для этого вспомогательные классы для x,y и z тоже должны быть заранее учтены в спринте. В общем, я с вами согласен :) Но не спросить, почему так вышло, тоже было бы неверно со стороны ПМ.
Ответ программистов в принципе неверен, более того, какой-то не программистский:)
Корректнее такой диалог
— Что вы делали всю итерацию и почему задачи не закрыты?
— Что делали — писали вспомогательные классы. Почему задачи не закрыты — приоритет их закрытия был ниже (их невозможно было закрыть без написания вспомогательных классов, etc).
ПМ не хватило прямого ответа на вопрос «почему», собственно поэтому ему пришлось его повторить.
Корректнее такой диалог
— Что вы делали всю итерацию и почему задачи не закрыты?
— Что делали — писали вспомогательные классы. Почему задачи не закрыты — приоритет их закрытия был ниже (их невозможно было закрыть без написания вспомогательных классов, etc).
ПМ не хватило прямого ответа на вопрос «почему», собственно поэтому ему пришлось его повторить.
А если ПМ неправильно оценил сроки?
А если ПМ заведомо неправильно указал сроки?
А если из-за x продукт падал в 10% случаев, а из-за y — выпиливал базу в 1%?
А если ПМ заведомо неправильно указал сроки?
А если из-за x продукт падал в 10% случаев, а из-за y — выпиливал базу в 1%?
— Мне пофиг, почему задачи не закрыты?А вот с этого момента — поподробнее: почему классов x, y и z не было в списке задач?
Если их создание — достаточно важно для дальнейшей работы, то они там должны были быть. Если нет — то нафиг вы о них вообще вспоминаете.
Программирование — тут ни разу не исключение. Рассмотрите в качестве примера бухгалтерию. Если бухгалтера наняли на работу и он обнаружил, что бухгалтерия, фактически, не велась, так просто квитанции в папку подшивались, то он, разумеется, выкатит немалый счёт за «восстановление бухучёта». Но если он просто засядет и начнёт «проводить рефакторинг» не согласовав это дело с руководством, то его за это вряд ли похвалит.
«Создание классов x, y, и z» всегда должно выводиться из реальных задач. И исходя из потенциальной важности решения этих задач менеджер уже и решит — стоит ими заниматься или нет. А если вы не можете придумать ситуацию, когда ваши вспомогательные классы чему-то помогут — то зачем они вообще нужны?
Если бы ПМ-у можно было объяснить зачем в программе конкретные классы, он был бы не ПМ, а ТимЛид и ПродуктОунер. В реальности почти никакому ПМ-у и почти никогда не хватит квалификации чтобы понять какие классы есть в его продукте и почему должны быть именно они. Причём квалификации не хватит раз в 8, где-то.
Если ПМ, этого не понимает, а в примере выше он этого, очевидно не понимает. Значит он неквалифицирован не только как ПМно и как менеджер и всю оставшуюся жизнь вынужден будет писать на Хабре обиженные комментарии на программистов жаловаться, что что-то пошло не так. Потому что так как надо у него никогда не пойдёт. Разве что случайно, если у проекта по недосмотру появится лид и оунер, который вытянет проект вопреки ПМ-у.
Суровая такая вот правда жизни.
Если ПМ, этого не понимает, а в примере выше он этого, очевидно не понимает. Значит он неквалифицирован не только как ПМно и как менеджер и всю оставшуюся жизнь вынужден будет писать на Хабре обиженные комментарии на программистов жаловаться, что что-то пошло не так. Потому что так как надо у него никогда не пойдёт. Разве что случайно, если у проекта по недосмотру появится лид и оунер, который вытянет проект вопреки ПМ-у.
Суровая такая вот правда жизни.
ПМ не должен понимать зачем в программе конкретные классы, он должен:
1) контролировать приоритеты и выполнения задач (для этого не нужно ничего понимать в программировании),
2) на ответ " Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.", должен задать вопрос какие именно задачи и на сколько в будущих итерациях эти «вспомогательные классы» должны ускорить разработку. И отсюда уже делать вывод от «ребята молодцы, сократили мой план на итерацию 10 на две недели» или «какого фига вы потратили месяц на фраймворк сортировки бабочек, если мы никогда ими не будем заниматься»
То есть хороший ПМ, совершенно не разбирающийся программировании, может прекрасно рулить техническими задачами исключительно из КПД полезности (текущей и будущей).
1) контролировать приоритеты и выполнения задач (для этого не нужно ничего понимать в программировании),
2) на ответ " Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.", должен задать вопрос какие именно задачи и на сколько в будущих итерациях эти «вспомогательные классы» должны ускорить разработку. И отсюда уже делать вывод от «ребята молодцы, сократили мой план на итерацию 10 на две недели» или «какого фига вы потратили месяц на фраймворк сортировки бабочек, если мы никогда ими не будем заниматься»
То есть хороший ПМ, совершенно не разбирающийся программировании, может прекрасно рулить техническими задачами исключительно из КПД полезности (текущей и будущей).
К сожалению почти всегда менеджер не понимает почему плохое решение в коде что-то замедлит и когда оно это сделает, а программисты не имеют возможности улучшение кода менеджерам продать. Как потому, что плохо умеют это делать, это вообще-то не входит в круг их прямых обязанностей, так и потому что ПМ их просто не слушает в этой части.
Поэтому, у меня другое видение, как мне кажется, умный ПМ не пытается решать этот вопрос самостоятельно, тем более не пытается составлять детальный план сколько копеек это ему съэкономит через год. Потому что такие подсчёты почти всегда будут профанацией. Вместо этого он находит промежуточное звено, ну или выделяет это промежуточное звено из имеющихся у него программистов, и делает из него крайнего за принятие и обоснование таких решений.
Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию — мне кажется далеко за пределами возможностей не только ПМ-а, но и вообще человека. Грубо говоря Бест-практикс по архитектуре именно потому и являются бест-практикс, а не получаются каждый раз заново методом анализа КПД по планам, что никто, даже самые круты чуваки из GoF не смогут вам такой план составить. Вот, собственно поэтому GoF пропагандировали паттерны, и Фаулер рефакторинг.
Поэтому, у меня другое видение, как мне кажется, умный ПМ не пытается решать этот вопрос самостоятельно, тем более не пытается составлять детальный план сколько копеек это ему съэкономит через год. Потому что такие подсчёты почти всегда будут профанацией. Вместо этого он находит промежуточное звено, ну или выделяет это промежуточное звено из имеющихся у него программистов, и делает из него крайнего за принятие и обоснование таких решений.
Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию — мне кажется далеко за пределами возможностей не только ПМ-а, но и вообще человека. Грубо говоря Бест-практикс по архитектуре именно потому и являются бест-практикс, а не получаются каждый раз заново методом анализа КПД по планам, что никто, даже самые круты чуваки из GoF не смогут вам такой план составить. Вот, собственно поэтому GoF пропагандировали паттерны, и Фаулер рефакторинг.
Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию — мне кажется далеко за пределами возможностей не только ПМ-а, но и вообще человека.Надо понимать, что в большинстве случаев эффект от «вспомогательных классов» разработчик будет завышать, а время на их разработку — занижать. И если он даже в таких, «тепличных» условиях не может «заглянуть в будущее» настолько далеко, чтобы показать, что от его действий будет какая-то экономия, то, стало быть, все эти действия точно никакой экономии не несут и, соответственно, бессмысленны. Если хотя бы теоретически что-то такое вырисовывается — тогда можно уже и обсуждать сценарии.
Иногда, правда, можно дать возможность людям делать то, чего они хотят просто, чтобы поддержать уровень морали, но тут надо тоже меру знать.
Про меру согласен. Про не несут — не согласен.
Сейчас, например, переделываем ядро одной игры, как раз потому что предыдущие кодеры наделали… Со строгим соблюдением сроков в первой части проекта. Закладываюсь на то что в игре будет резво добавляться правил и геймплея и под это код, котоырй управляет моделью данных более сложен и содержит возможности для быстрого увеличения количества правил и варианта геймплея в разы. Однако когда дойдёт до дела хрен его знает как повернётся, может они с геймплеем будут активно вяло экспериментировать, а со статистикой и рекламой активно. тогда половина наших наворотов останется не у дел. Сейчас этого не знают ни они, подвязавшиеся ждать когда эта архитектура будет, ни мы, взявшиеся её делать. Но если будут с геймплеем экспериментировать — экономия будет о-го-го.
Конечно разные отрасли — разные ситуации, но там где я работал, — в игрострое, когда начинаешь работать контуры того, как будет устроена игра через пол года не просматриваются даже в сизой дымке.
Сейчас, например, переделываем ядро одной игры, как раз потому что предыдущие кодеры наделали… Со строгим соблюдением сроков в первой части проекта. Закладываюсь на то что в игре будет резво добавляться правил и геймплея и под это код, котоырй управляет моделью данных более сложен и содержит возможности для быстрого увеличения количества правил и варианта геймплея в разы. Однако когда дойдёт до дела хрен его знает как повернётся, может они с геймплеем будут активно вяло экспериментировать, а со статистикой и рекламой активно. тогда половина наших наворотов останется не у дел. Сейчас этого не знают ни они, подвязавшиеся ждать когда эта архитектура будет, ни мы, взявшиеся её делать. Но если будут с геймплеем экспериментировать — экономия будет о-го-го.
Конечно разные отрасли — разные ситуации, но там где я работал, — в игрострое, когда начинаешь работать контуры того, как будет устроена игра через пол года не просматриваются даже в сизой дымке.
Однако когда дойдёт до дела хрен его знает как повернётся, может они с геймплеем будут активно вяло экспериментировать, а со статистикой и рекламой активно. тогда половина наших наворотов останется не у дел.
Тем не менее, вы же вполне можете объяснить: если будет сценарий 1 мы сэкономим столько-то времени, потратив сейчас столько-то, а если сценарий 2 то столько-то и столько-то. Вообще, ПМ'а как раз с вероятностями пи рисками должен работать по хорошему (вероятность, что разработчик поссорится с женой и его работоспособность резко упадет, вероятность что пол команды решит уволиться, вероятность что заказчик вообще не захочит платить за сделанную суперфичу.)
Закладываюсь на то что в игре будет резво добавляться правил и геймплея и под это код, котоырй управляет моделью данных более сложен и содержит возможности для быстрого увеличения количества правил и варианта геймплея в разы.Ну вот вы и привели некоторое обоснование. Добавить сюда пару цифр — и можно говорить с PMом.
Сейчас этого не знают ни они, подвязавшиеся ждать когда эта архитектура будет, ни мы, взявшиеся её делать. Но если будут с геймплеем экспериментировать — экономия будет о-го-го.А это уже риски, которые оценивает как раз PM. Если он оценивает вероятность развития событий так, что вариант, для которого вы собираетесь «соломки подстелить» весьма высоковероятен — он вас поддержит, если он решит, что «мы туда ходить не будем» — он вам скажет делать что-то другое.
Будущего не может знать никто, это понятно, но если вы не можете привести обоснование для вашей деятельности в терминах предметной области (не в «в среднем размере функции» или, прости госсподи, в «проценте покрытия тестами», а во «времени на изменения одного правила» или в «цене создания нового монстра») — то это значит, что обоснования у вас нет.
Холивар, но все же.
=== По поводу менеджера:
Плохой прожект менеджер это такой прожект менеджер, который как раз не дает писать «дополнительные классы». Это рано или поздно заваливает проект и он сходит с рельс. Прожект менеджер должен знать где требуются архитектурные решения, а где требуются 2 гвоздя с доской. Если он не знает, а думает только метриками типа «отлично сэкономим, тут — ну вы же сказали же да?», то надо его садить либо на аутсорс, либо куда подальше.
Все другое мол это «никого не интересует» в топку обиженных ПМ-ов. Смотря на каком уровне и для кого, все это интересует.
А вообще очень важно, что бы на каждом уровне были профессиональные и мотивированные люди, а схема взаимодействия плоская, а не древовидная во главе с Боже упоси ПМ-ом. А с ПМ-деревом все вокруг покроется убогими досками, и все сгниет на корню.
=== По поводу девелопера
Девелопер действительно должен понимать, что код для кода это бессмысленно. Главная задача решить задачу с возможностью масштабирования кода на одну-две итерации вперед, кроме выраженных конечных случаев где такое масштабирование не будет (забить досками). Соответственно, если по этому коду масштабирование все же требуется произвести, то будет дополнительный оверхеад на переработку архитектуры, о чем разработчик должен уведомить менеджера — мол мы это забили досками, поэтому надо надо сломать и забетонировать.
=== Резюмируем
Самый первый комментарий это гнилой базар ПМ-а. Потому что разработчик сказал, что он делал. ПМ должен разобраться и направить в нужное русло, а не вонять.
=== По поводу менеджера:
Плохой прожект менеджер это такой прожект менеджер, который как раз не дает писать «дополнительные классы». Это рано или поздно заваливает проект и он сходит с рельс. Прожект менеджер должен знать где требуются архитектурные решения, а где требуются 2 гвоздя с доской. Если он не знает, а думает только метриками типа «отлично сэкономим, тут — ну вы же сказали же да?», то надо его садить либо на аутсорс, либо куда подальше.
Все другое мол это «никого не интересует» в топку обиженных ПМ-ов. Смотря на каком уровне и для кого, все это интересует.
А вообще очень важно, что бы на каждом уровне были профессиональные и мотивированные люди, а схема взаимодействия плоская, а не древовидная во главе с Боже упоси ПМ-ом. А с ПМ-деревом все вокруг покроется убогими досками, и все сгниет на корню.
=== По поводу девелопера
Девелопер действительно должен понимать, что код для кода это бессмысленно. Главная задача решить задачу с возможностью масштабирования кода на одну-две итерации вперед, кроме выраженных конечных случаев где такое масштабирование не будет (забить досками). Соответственно, если по этому коду масштабирование все же требуется произвести, то будет дополнительный оверхеад на переработку архитектуры, о чем разработчик должен уведомить менеджера — мол мы это забили досками, поэтому надо надо сломать и забетонировать.
=== Резюмируем
Самый первый комментарий это гнилой базар ПМ-а. Потому что разработчик сказал, что он делал. ПМ должен разобраться и направить в нужное русло, а не вонять.
Прожект менеджер должен знать где требуются архитектурные решения, а где требуются 2 гвоздя с доской.Не совсем так. Его задача скорее помочь разработчикам перевести требования задачи, сформулированные в терминах предметной области на требования к коду и наоборот.
Потому «Мне пофиг, почему задачи не закрыты?» — это, конечно, отвратительный PM. Сходу говорить о том, что раз мы об этом не договаривались, то и делать ничего такого не нужно — это признак двойной некомпетентности. Просто потому что он чего-то упустил: если команда занималась не тем, чем планировалось заниматься, то это, во-многом его вина.
Нет, всё возможно: бывает так, что вся команда (особенно небольшая) учиталась очередной новомодной книжкой и какую-то фигню творит, но так бывает всё-таки не слишком часто. Обычно если уж какие-то вспомогательные классы создаются, то тут есть какая-то цель и задача PM'а — понять что это за цель, нужна ли она нам и т.д. и т.п. Иногда стоит эту деятельность и прекратить, но сразу «мне пофиг» — это неконструктивно. Вообще позиция «все кругом идиоты, а я один — д'Артаньян» не очень конструктивна.
Давайте проведём мысленный эксперимент. Дано:
Вы в коде сделали сортировку пузырьком, но не так и не там. У вас есть варианты:
— Оставить как есть и всё. В следующий раз написать с нуля
— Оставить как есть и запомнить где. В следующий раз найти, откопипастить и исправить существующий код. Коллеги сами пусть мучаются.
— Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.
— Вынести во вспомогательный класс, класс вынести в отдельную библиотеку, Написать документацию.
— свой вариант
Как вы заглядываете в будущее и показываете полезность метода N, если начальство при любом раскладе смотрит на вас уставшим взглядом и говорит «да ну, когда ещё сортировка нам пригодится»?
Тот же вопрос по прошествии года, когда в коде уже 12 сортировок пузырьком, а начальство по-прежнему смотрит на вас уставшим взглядом и говорит «да ну, теперь то ещё сортировка нам точно не пригодится»
Проходит ещё год, сортировок уже 150, но больше доделок ну вот совсем не планируется. Ну может быть вот ещё последняя, но точно последняя.
Вы в коде сделали сортировку пузырьком, но не так и не там. У вас есть варианты:
— Оставить как есть и всё. В следующий раз написать с нуля
— Оставить как есть и запомнить где. В следующий раз найти, откопипастить и исправить существующий код. Коллеги сами пусть мучаются.
— Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.
— Вынести во вспомогательный класс, класс вынести в отдельную библиотеку, Написать документацию.
— свой вариант
Как вы заглядываете в будущее и показываете полезность метода N, если начальство при любом раскладе смотрит на вас уставшим взглядом и говорит «да ну, когда ещё сортировка нам пригодится»?
Тот же вопрос по прошествии года, когда в коде уже 12 сортировок пузырьком, а начальство по-прежнему смотрит на вас уставшим взглядом и говорит «да ну, теперь то ещё сортировка нам точно не пригодится»
Проходит ещё год, сортировок уже 150, но больше доделок ну вот совсем не планируется. Ну может быть вот ещё последняя, но точно последняя.
Как вы заглядываете в будущее и показываете полезность метода N, если начальство при любом раскладе смотрит на вас уставшим взглядом и говорит «да ну, когда ещё сортировка нам пригодится»?Ответ на это люди дали сотни лет назад. «То что случилось однажды, больше может никогда не случится, но то что случилось дважды, обязательно произойдёт в третий».
Только не нужно всё воспринимать догматично. Скажем переход на новую архитектуру процессора происходит-таки регулярно (в соответствии с пословицей), но происходит это примерно раз в 10 лет в среднем, так что для большинства проектов это то, что «больше никогда не случится».
Так что ждать пока появится 150 сортировок не стоит, но и выделять что-то в отдельный модуль не имея двух-трёх точек, где оно используется — тоже не стоит. Оптимальное число, пожалуй, всё-таки как раз три а не два: вам нужно продумать интерфейс, а практика показывает что два варианта использования таки маловато. Вообще чем больше мест где ваш модуль будет использоваться тем проще спроектировать его интерфейс — но и тем сложнее все места переделать.
Практика показывает, что
1) на большом проекте люди не в курсе, что эта копипаста и вообще где-то есть ещё, поэтому каждый раз — второй.
2) 2 одинаковых копипасты не бывает. Их нельзя просто взять и обобщить не пойдя, как минимум, по третьему варианту.
А в мысленном эксперименте я специально не сделал опции «2 места» или «3 места». У вас есть или одно место, которое абстрагировать не за чем. Или дюжина, которые обобщать долго и дорого. Или совсем задница.
Как это получилось — не суть важно (те люди тут уже не работают).
Но вам надо с этим жить, пока начальник с тем же усталым видом говорит «Только не нужно всё воспринимать догматично».
1) на большом проекте люди не в курсе, что эта копипаста и вообще где-то есть ещё, поэтому каждый раз — второй.
2) 2 одинаковых копипасты не бывает. Их нельзя просто взять и обобщить не пойдя, как минимум, по третьему варианту.
А в мысленном эксперименте я специально не сделал опции «2 места» или «3 места». У вас есть или одно место, которое абстрагировать не за чем. Или дюжина, которые обобщать долго и дорого. Или совсем задница.
Как это получилось — не суть важно (те люди тут уже не работают).
Но вам надо с этим жить, пока начальник с тем же усталым видом говорит «Только не нужно всё воспринимать догматично».
1) на большом проекте люди не в курсе, что эта копипаста и вообще где-то есть ещё, поэтому каждый раз — второй.В этом случае вам уже ничего не поможет. У вас будет либо 150 сортировок пузырьком «по месту», либо 150 (ну хорошо, пусть 100) сортировок, каждая из которых разработана так, как если бы она была «последней и окончательной реализацией сотрировки пузырьком».
И из этих двух вариантов первый — гораздо лучше. Ибо в смысле поддержки он примерно столь же ужасен как и последний, но времени на его разработку и на работу с ним уходит меньше. А после налаживания взаимодействия между командами и людьми вы можете выделить-таки время на рефакторинг и реализовать одну «самую правильную» версию сортировки тоже будет проще (заменить реализацию «по месту» на вызов универсальной реализации обычно проще, чем объединять «универсальные реализации», так как в реализации «по месту» есть только то, что конкретно в этом месте нужно, а в куче «универсальных реализаций» обязательно найдётся куча фич, которые непонятно как реализовать в одной «универсальной реализации»… и которые, в общем-то никому нафиг не нужны).
2) 2 одинаковых копипасты не бывает. Их нельзя просто взять и обобщить не пойдя, как минимум, по третьему варианту.Вот потому я и предлагаю ваш «универсальный класс» писать после появления третей реализации. А для того, чтобы этот момент заметить при копировании кода из одного места в другое в обоих местах нужно добавить комментарий, объясняющий, где находится второе место. Ну или если случай простой, то вместо копирования можно уже на втором разе выделить общий класс, описать его интерфейс и т.д. и т.п.
Как это получилось — не суть важно (те люди тут уже не работают).В таком случае нужно это обсудить с теми, кто работает и, возможно, даже переписать заново пару компонент.
> В этом случае вам уже ничего не поможет.
Я же с этого начал, «Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.»
> А после налаживания взаимодействия между командами и людьми вы можете выделить-таки время на рефакторинг
Не могу, ибо «все эти действия точно никакой экономии не несут и, соответственно, бессмысленны» пока не доказано обратное.
> Вот потому я и предлагаю ваш «универсальный класс» писать после появления третей реализации.
Ну не то, что бы плохое предложение. Спорить я не буду. Я повторю, что кейса «после третьей» в мысленном эксперименте нет. Совсем. Я не спрашивал «когда надо писать».
> вместо копирования можно уже на втором разе выделить общий класс, описать его интерфейс и т.д. и т.п.
> возможно, даже переписать заново пару компонент.
Нельзя, ПМ рефакторинг не одобрял. Обоснуйте экономию?
Я же с этого начал, «Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.»
> А после налаживания взаимодействия между командами и людьми вы можете выделить-таки время на рефакторинг
Не могу, ибо «все эти действия точно никакой экономии не несут и, соответственно, бессмысленны» пока не доказано обратное.
> Вот потому я и предлагаю ваш «универсальный класс» писать после появления третей реализации.
Ну не то, что бы плохое предложение. Спорить я не буду. Я повторю, что кейса «после третьей» в мысленном эксперименте нет. Совсем. Я не спрашивал «когда надо писать».
> вместо копирования можно уже на втором разе выделить общий класс, описать его интерфейс и т.д. и т.п.
> возможно, даже переписать заново пару компонент.
Нельзя, ПМ рефакторинг не одобрял. Обоснуйте экономию?
Нельзя, ПМ рефакторинг не одобрял. Обоснуйте экономию?Да раз плюнуть. По условиям задачи у нас уже есть 150 (да пусть даже 12) мест, где эта самая сортировка пузырьком используется. Берём историю проекта, грубо оцениваем сколько таких мест мы порождаем за год, дальше смотрим сколько времени уйдёт на рефакторинг, сколько мы получим от того, что нужно будет вместо XX строчек кода поставить один вызов функции, получаем экономию. COCOMO вам в помощь.
Вот как раз перевод существующего кода на новый интерфейс — тут сложнее, может оказаться, что «овчинка выделки не стоит».
А если обоснование «не срастается» (то есть никак не вытанцовываетя экономия даже при самых оптимистичных допущениях), то вы не поверите, нужно-таки оставить эти сортировки в покое и не париться.
1) Если игнорировать грустный взгляд ПМ и его слова о YAGNI, то вы обосновали «сделать функцию», но не «рефакторинг старого».
2) Любая новая копипаста не имеет истории и к ней такой подход не применим.
3) Я могу сделать достаточно оптимистичные допущения, что бы срослось.
2) Любая новая копипаста не имеет истории и к ней такой подход не применим.
3) Я могу сделать достаточно оптимистичные допущения, что бы срослось.
1) Если игнорировать грустный взгляд ПМ и его слова о YAGNI, то вы обосновали «сделать функцию», но не «рефакторинг старого».Истинная правда — и более глубокая, чем вам кажется. Действительно — решить нужно ли переводить существующий код на новую функцию куда сложнее.
2) Любая новая копипаста не имеет истории и к ней такой подход не применим.Ну это вы уже начинаете рассказывать сказки. Да, отличия бывают, но если бы мир был устроен так, как вы его хотите представить, то никто вообще ничего бы не смог спланировать. В первом приближении любая новая копипаста устроена так же, как и все предыдущие, для грубой оценки большего и не нужно.
3) Я могу сделать достаточно оптимистичные допущения, что бы срослось.Но сможете ли вы убедить в них PM'а? Учтите, что ведь по окончании работ он будет иметь возможность сравнить то, что вы обещали с тем, что реально получилось…
> и более глубокая, чем вам кажется.
Серьёзно, перечитайте условия мысленного эксперимента, прежде чем мне истину открывать.
> В первом приближении любая новая копипаста устроена так же, как и все предыдущие, для грубой оценки большего и не нужно.
Вы опять не туда. Без разницы как она устроена, её никто не поддерживал, нет статистики.
> Но сможете ли вы убедить в них PM'а?
То есть вы тоже не можете, понял. Мысленный эксперимент на этом и закончим.
> И если он даже в таких, «тепличных» условиях не может «заглянуть в будущее» настолько далеко, чтобы показать, что от его действий будет какая-то экономия, то, стало быть, все эти действия точно никакой экономии не несут и, соответственно, бессмысленны.
Это чушь, вы никогда скептически настроенного ПМ не убедите в эффекте и это путь в никуда.
Не скептически настроенный ПМ всё равно проверять не полезет.
Да и невозможно проверить эффект на достаточно длительном промежутке (или ишак, или падишах)
Серьёзно, перечитайте условия мысленного эксперимента, прежде чем мне истину открывать.
> В первом приближении любая новая копипаста устроена так же, как и все предыдущие, для грубой оценки большего и не нужно.
Вы опять не туда. Без разницы как она устроена, её никто не поддерживал, нет статистики.
> Но сможете ли вы убедить в них PM'а?
То есть вы тоже не можете, понял. Мысленный эксперимент на этом и закончим.
> И если он даже в таких, «тепличных» условиях не может «заглянуть в будущее» настолько далеко, чтобы показать, что от его действий будет какая-то экономия, то, стало быть, все эти действия точно никакой экономии не несут и, соответственно, бессмысленны.
Это чушь, вы никогда скептически настроенного ПМ не убедите в эффекте и это путь в никуда.
Не скептически настроенный ПМ всё равно проверять не полезет.
Да и невозможно проверить эффект на достаточно длительном промежутке (или ишак, или падишах)
А ещё в каждой из реализации Баги. Причём в каждой разные.
Вместо этого он находит промежуточное звено, ну или выделяет это промежуточное звено из имеющихся у него программистов, и делает из него крайнего за принятие и обоснование таких решений.
Вообще, у нас для таких целей был технический менеджер, то есть самый крутой бывший программист, делящий с ПМ ответственность за проект.
Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию
Почему в точности? ПМ должен хотя примерно представлять что ждет проект и прикидывать вероятность пользы и успеха. Из разряда:
— Давайте мы построим кран?
— А нафига? Мы же строим пятиэтажку.
— Ну, если а вдруг заказчик захочет построить небоскреб, это сильно нам потом время сэкономит.
— Не, ребят, небоскреб он точно не захочет, у него боязнь высоты.
У меня 12 лет программерского стажа. И я с вами не соглашусь в корне :)
ПМ не должен знать технических деталей. Вы (команда) — ответственная и автономная единица (до первых косяков). Если команда решает подзабить на план и порефакторить — то менеджер автономность будет убирать и будет микроменеджить девелоперов, «как пастух своих овец», извиняюсь за аналогию. Вам это надо?
Интересно, как обрадуется команда, если ПМ решить невыдать всей команде бонус, т.к. потратит его, например, на покупку растений в офис, где работают девелоперы. И когда люди начнут приходить с вопросами, он скажет (например): «Ребят, у вас теперь среда какая комфортная. Это важно для вашей будущей работы, что бы дышалось хорошо и это окупиться в будущем вашим здоровьем и настроением».
Вот интересно было бы послушать реакцию девелоперов :) И если эта реакция будет отличная от: «конечно, все верно, молодец ПМ!», то следует ли из этого делать вывод, что команда — необразованная и непонимает важности комфортной и разряженной рабочей среды для коллектива? :)
Суровая правда жизни, что программеры забивают на ПМа, считая, что уменьшение technical debt важнее, чем delivery. Поэтому и плодятся у нас говноотношения между менеджерами и девелоперами.
Последние несколько лет я работаю в командах с налаженной коммуникацией. Если нужно заложить время на улучшение кода или его изменение в пользу стабильности, масштабируемости и прочего, это обсуждается девелоперами еще до планирования этапа (внезапно возникла необходимость переписать полпроекта? харош...). На планировании это выносится на повестку с аргументированием, почему это важно (надеюсь, не будет вопроса «чтоооо? еще и аргументировать ему надо? да он необразованный, раз не понимает»… может быть, вы сами не образованы, если не можете аргументировать необходимость чего-то бизнесу?).
Я еще ниразу не встречал ситуации, когда менеджеру сообщалось бы: «нам нужно провести оптимизацию/рефакторинг, и это очень важно для проекта, т.к. нагрузка на продакшн сервере уже превысила 70%, и если мы не возьмем это в этап, на следующей неделе наш продукт ляжет и мы потеряем клиентов и деньги», и менеджер в ответ говорил бы: «нет, в этап берем только новые фичи» :)
Я еще ниразу не встречал ситуации (по крайней мере, с компетентными девелоперами), которые встретив препятствие вчера не сообщили бы о нем команде сегодня и если препятствие не устранено — менеджеру к концу дня, что бы он понимал риски по реализации той или иной задачи. И что бы менеджер после этого спросил с команды — «мне пофиг, почему задачи не выполнены»…
ПМ не должен знать технических деталей. Вы (команда) — ответственная и автономная единица (до первых косяков). Если команда решает подзабить на план и порефакторить — то менеджер автономность будет убирать и будет микроменеджить девелоперов, «как пастух своих овец», извиняюсь за аналогию. Вам это надо?
Интересно, как обрадуется команда, если ПМ решить невыдать всей команде бонус, т.к. потратит его, например, на покупку растений в офис, где работают девелоперы. И когда люди начнут приходить с вопросами, он скажет (например): «Ребят, у вас теперь среда какая комфортная. Это важно для вашей будущей работы, что бы дышалось хорошо и это окупиться в будущем вашим здоровьем и настроением».
Вот интересно было бы послушать реакцию девелоперов :) И если эта реакция будет отличная от: «конечно, все верно, молодец ПМ!», то следует ли из этого делать вывод, что команда — необразованная и непонимает важности комфортной и разряженной рабочей среды для коллектива? :)
Суровая правда жизни, что программеры забивают на ПМа, считая, что уменьшение technical debt важнее, чем delivery. Поэтому и плодятся у нас говноотношения между менеджерами и девелоперами.
Последние несколько лет я работаю в командах с налаженной коммуникацией. Если нужно заложить время на улучшение кода или его изменение в пользу стабильности, масштабируемости и прочего, это обсуждается девелоперами еще до планирования этапа (внезапно возникла необходимость переписать полпроекта? харош...). На планировании это выносится на повестку с аргументированием, почему это важно (надеюсь, не будет вопроса «чтоооо? еще и аргументировать ему надо? да он необразованный, раз не понимает»… может быть, вы сами не образованы, если не можете аргументировать необходимость чего-то бизнесу?).
Я еще ниразу не встречал ситуации, когда менеджеру сообщалось бы: «нам нужно провести оптимизацию/рефакторинг, и это очень важно для проекта, т.к. нагрузка на продакшн сервере уже превысила 70%, и если мы не возьмем это в этап, на следующей неделе наш продукт ляжет и мы потеряем клиентов и деньги», и менеджер в ответ говорил бы: «нет, в этап берем только новые фичи» :)
Я еще ниразу не встречал ситуации (по крайней мере, с компетентными девелоперами), которые встретив препятствие вчера не сообщили бы о нем команде сегодня и если препятствие не устранено — менеджеру к концу дня, что бы он понимал риски по реализации той или иной задачи. И что бы менеджер после этого спросил с команды — «мне пофиг, почему задачи не выполнены»…
Квалифицированный ПМ совершенно не должен понимать, зачем нужен каждый конкретный класс в программе. Его задача — обеспечивать общий ход работ и коммуникации. Есть в команде архитектор системы, есть тимлиды/сеньоры, они и решают, где там быть дополнительным вспомогательным классам. Задача ПМ'а (если он сам не выходец из их кругов) — консультироваться с экспертом в соответствующей области, и принимать решения по советам эксперта. Но если тимлид необходимость этой вспомогательной задачи не обозначил, а программист «проявил инициативу», и вместо данного ему тасклиста занялся украшением архитектуры, то ПМ вполне резонно даёт ему по шапке. В самой инициативе нет ничего плохого, наоборот, это замечательно… но она должна выглядеть как-то так: программист подходит и говорит: «Вот есть такая потребность/идея, с ней будет вот так-то хорошо, без нее будет вот так-то плохо, но она потребует дополнительно столько-то времени». А ПМ говорит: «Ок, это правильно, делаем». Или говорит: «Да, это было бы неплохо, но если мы выкатим продукт без этой штуки, то продажи стартуют на неделю раньше».
Договороспособность и взаимопонимание менеджера и команды стремиться к 0. Как они вообще проекты выпускают? Почему им насрать друг на друга? Откуда такая сценка — фантазии или быль?
И что хотел узнать менеджер своим вопросом, если получения ответа все равно его задает?
Уровень коммуникации как у каких-то барыг из фильмов. «Где мой товар?»
И что хотел узнать менеджер своим вопросом, если получения ответа все равно его задает?
Уровень коммуникации как у каких-то барыг из фильмов. «Где мой товар?»
И действительно. Почему задачи не закрыты?
— Работа по вспомогательным классам для x, y и z была включена в этап? Если нет, то почему вы этим занимались в ущерб этапа?
— О том, что вместо работы над задачами, вам необходимо было делать что-то другое было ли сообщено кому-то (ПМ-у)? Если нет, то на что жалуемся, где закрытые задачи?
— Когда пришло понимание того, что задачи этапа не будут выполнены? Только в последний день этапа протяженностью в месяц? Да что за бред.
Действительно, описанный диалог довольно типичен у нас. Он бы не состоялся (точнее, состоялся бы подругому), если бы в команде была бы хорошая коммуникация.
— Работа по вспомогательным классам для x, y и z была включена в этап? Если нет, то почему вы этим занимались в ущерб этапа?
— О том, что вместо работы над задачами, вам необходимо было делать что-то другое было ли сообщено кому-то (ПМ-у)? Если нет, то на что жалуемся, где закрытые задачи?
— Когда пришло понимание того, что задачи этапа не будут выполнены? Только в последний день этапа протяженностью в месяц? Да что за бред.
Действительно, описанный диалог довольно типичен у нас. Он бы не состоялся (точнее, состоялся бы подругому), если бы в команде была бы хорошая коммуникация.
Если вам не нравится это — смело уходите. Зачем терпеть это?
Мой код никого не интересует.
Мой код интересует команду в которой я работаю, так же как и меня интересует их код.
В реальности это слишком маленькая аудитория, и в большинстве случаев к сожалению куда важней фактор быстрого завершения задачи.
Потому что у вас кодобаза общая. если 1 из команды работает, допустим, над серверной частью, а другой над клиентской. то как написал тот товарищ волновало бы вас мало. вы туда никогда не полезете, главное чтоб не падало и отвечало заявленному АПИ
А в обратной ситуации очень бы даже волновало, еслиб быстронаписанный код выпадал по таймауту на половине запросов от клиента(негуманный поиск или сортировка, однопоточные запросы к сторонним апи, что угодно) и Вам пришлось бы весить на это костылики.
Вам было бы легче, если бы падал хорошо написанный код?
Упасть может любой код. В хорошем коде просто баг правится и правится быстро, скорее всего. Если код плохой, то исправляться, как заметил tenoclock, это будет скорее всего костылём, который в добавок вполне может спровоцировать ошибку в другом месте.
Конечно, так как хорошо написанный код:
1) легче исправить,
2) проще отладить,
3) в конце концов, он просто не падает на глупых вещах (и падения не приводят к катастрофическим последствиям), запутанный плохо написанный код без всякого тестирования легко может содержать баги вроде полного удаления базы на продакшене, а вот в хорошо написанным коде такие вещи легко видно невооруженным глазом.
1) легче исправить,
2) проще отладить,
3) в конце концов, он просто не падает на глупых вещах (и падения не приводят к катастрофическим последствиям), запутанный плохо написанный код без всякого тестирования легко может содержать баги вроде полного удаления базы на продакшене, а вот в хорошо написанным коде такие вещи легко видно невооруженным глазом.
Вы, как и остальные минусующее, забываете мой изначальный тезис. Вы используете некий сторонний продукт, пусть даже созданный в вашей компании, который удовлетворяет вас по параметрам Стабильность и Функциональность. Я не знаю почему в этой ситуации вас должно беспокоить как это написано.
Даже если сторонний продукт, я пишу на Java и один из самых главных плюсов — ты можешь открыть любую стороннею библиотеку/продукт, в которой случилась ошибка, и посмотреть что там произошло. Много раз таким образом находил причину ошибок, пару раз отправлял pull request в эти сторонние библиотеки, пару раз разобрался с недокументрованными возможностями, например, монги, иногда делал форки и создавал свои собственные реализации библиотек в которых исправлял ошибки.
Но плохой код все это осложняет в десяток раз.
Но плохой код все это осложняет в десяток раз.
прибыль вашей компании складывается не от продажи кода, а от вашего продукта. Все что вы пишите кроме ваших внутренних участников процесса ни кого не интересует.
Не совсем так, продукт должен быть соответствующего качества. Скажем, за одну ошибку в ПО космической ракеты компания может просто разорится. Да, можно добиться нужного качества на самом ужасном коде, но намного легче выйти на нужное качество при определенном уровне качества кода.
Понятно сам по себе «красивый» код нафиг никому не важен, но если он ускорит разработку, облегчит поиск ошибок или сопровождение, то он вполне себе принесет прибыль. Грубо говоря если на стройки работают одни джамшуты в худшем смысле этого слова, то она легко может оказаться «золотой» при приемке дома. С другой стороны, на строке никому не нужны и великие гении-художники, которые десять лет будут шедевральный кафель класть в одной комнате.
Понятно сам по себе «красивый» код нафиг никому не важен, но если он ускорит разработку, облегчит поиск ошибок или сопровождение, то он вполне себе принесет прибыль. Грубо говоря если на стройки работают одни джамшуты в худшем смысле этого слова, то она легко может оказаться «золотой» при приемке дома. С другой стороны, на строке никому не нужны и великие гении-художники, которые десять лет будут шедевральный кафель класть в одной комнате.
Сказать про ракеты ничего не могу, кого там что волнует) в любом случае полёт это цель. Качество совершенно сложное определение… Ну вот wordpress продукт качественный или говнокод? И да и нет.А битрикс? Ясно одно — его цель это популярность и она огромна.
Можно до посинения ругаться на его говнокод но никого это не волнует, кроме горстки гениальных программистов на гране нервного истощения. Там такое комьюнити что любой говнокод перекрывается двумя щелчками мышкой. Где там качество как скажут многие? Замените это слово на «спрос» и многое станет понятно.
Идеально можно переписать продукт который уже умер и с ним уже ясно как нужно было его писать.
До тех пор пока в команде существует некий дух, говнокодный продукт будет продолжать существовать и всегда как то находить решения и продолжать развиваться и переделываться.
Скорее всего вы говорили не о качестве а о неком духе связывающих вас и ваших коллег.
Можно до посинения ругаться на его говнокод но никого это не волнует, кроме горстки гениальных программистов на гране нервного истощения. Там такое комьюнити что любой говнокод перекрывается двумя щелчками мышкой. Где там качество как скажут многие? Замените это слово на «спрос» и многое станет понятно.
Идеально можно переписать продукт который уже умер и с ним уже ясно как нужно было его писать.
До тех пор пока в команде существует некий дух, говнокодный продукт будет продолжать существовать и всегда как то находить решения и продолжать развиваться и переделываться.
Скорее всего вы говорили не о качестве а о неком духе связывающих вас и ваших коллег.
Скорее всего вы говорили не о качестве
Именно о качестве. Понимаете при серьезной разработке, есть и серьезные уровни качества — критическая бага и штраф в десятки тысяч долларов.
Качество совершенно сложное определение…
Очень простое, качество это кол-во критичных багов во время работы продукта. Например качество хостинга измеряется временем когда он был недоступен или частично недоступен. Качество программного продукта тоже имеет вполне формальное выражение — кол-во потерянного времени пользователя (полностью, если продукт вообще не работал или частично если не работала лишь часть функций).
Да, в ряде случаев маркетинг может продвигать некачественный продукт, как например Internet Explorer, но рано или поздно функции и качество другого продукта возьмут свое над маркетингом и рекламой.
Поверьте, качество кода напрямую влияет и на скорость разработки и на качество и на простоту поддержки.
Да, в ряде случаев маркетинг может продвигать некачественный продукт, как например Internet ExplorerВот только не нужно на Internet Explorer баллоны катить. Там были вбуханы безумные деньги в разработку и в те времена, когда он занимал 90% рынка он был, вполне себе объективно, лучшим браузером. Это потом, когда его развитие было заморожены на годы (до версии 6 каждый год выходило по версии, а версия 7 вышла через 5 лет и была очень-очень слабым изменением по сравнение с MS IE 6) он стал «притчей во языцах».
К слову код интересует людей очень сильно в одной области уж точно — opensource.
Браво!
Согласен. А если грамотно «продавать» необходимость обслуживания кода и уменьшение technical debt бизнесу, то и «его» будет интересовать твой код, т.к. он позволит снизить расходы на его поддержку в будущем, время на поиск и устранение проблем (уменьшенеи расходов), ускорить процесс разработки новых фич (опять же, выливается в уменьшенеи расходов), уменьшит риск отвала клиентов из-за нестабильности приложения и т.д.
Более того, проблема бизнеса здесь заключается в том, что хороший программист хочет работать с приличным кодом, а если бизнес не рассчитывает на перманентную оплату технического долга, то часто он не может рассчитывать и на приличных наемных рабочих, которого, что не удивительно, в первую очередь беспокоит его комфорт и благополучие. Конечно, можно платить таким сотрудникам втридорого, но на мой взгляд проще всё же учитывать не только необходимость бизнеса в фичах, но и потребность программиста в приличном коде. Ведь работодатель как-то пытается сделать офис соответствующим ожиданиям работников, почему же он не должен делать то же с кодом?
… со следующего уровня абстракции. :)
Если программист работает над проектом один (а статья как будто бы и писалась под такой случай), то его код может не интересует никого. А когда в команде, ваш код, думаю, еще как заинтересует ваших коллег, ведь им его и поддерживать.
Ваш код заинтересует вас тогда, когда вы начнете его поддерживать. Или когда нужно будет внести модификации. Читайте Фаулера, батенька.
Я вижу, большинство не согласно с автором) (не забывайте, что автор не я)
Конечно, нельзя писать код абы как (об этом тоже есть в статье), но основная идея в том, что не надо ставить код во главу угла, так как главное — проект
Конечно, нельзя писать код абы как (об этом тоже есть в статье), но основная идея в том, что не надо ставить код во главу угла, так как главное — проект
Это не взаимозаменяемые понятия.
Это скорее не несогласие, а протест. Вы же видите комментарии,
очень многим не хватает просто признания в своей работе как и мне. Многих программистов статья вообще не колышит. У них завидный экшн))
очень многим не хватает просто признания в своей работе как и мне. Многих программистов статья вообще не колышит. У них завидный экшн))
В статье, грубо говоря, выстроена аргументация, что строитель должен думать о строящемся доме, а не об укладке кирпичей. Лично мне это кажется абсурдным. Второе — неотъемлемая и важная часть первого. Программист должен думать о коде, и стараться писать качественный код, и думать о выполнении поставленных задач, и о конечной цели думать, и о жене вечером должен думать. Много о чем думать, в общем. Поэтому к чему автор выстроил весь этот антагонизм кода и проекта, мне непонятно.
Пост читали?
Это что, значит, можно писать отстойный код? Нет, не значит.
Странная статья. Такие резкие утверждения, которые потом чуть ли не сам автор опровергает. Ваш код может никого не интересовать пока не придёт новый человек и вас не уволят за говнокод, с которым ничего нельзя сделать. Просто не надо (не всегда) заморачиваться на идеальности кода.
В целом большинство моментов справедливы, но аналогия неправильная:
В этом ключе, получается, что код — это не инструмент, а материал. И для хорошего решения как правило требуются определенные свойства материала (каленое железо, сухое дерево, мягкое или жесткое дерево, гладкая поверхность соприкасающихся подвижных частей).
Получение материала с теми или иными свойствами — вот это и есть мастерство.
Поэтому и заказчику или кому бы то ни было нужно не показывать сколько строк написано (сколько дыр просверлено или как гладко отполировали), а объяснять, что отшлифовали те и те детали, и сумели сделать сложное отверстие таким образом, что деталь теперь одна цельная, а это значит, что двигатель сможет нормально работать и не взорвется на презентации.
Так же как работа столяра не заключается в использовании молотка или пилы — она заключается в производстве чего-либо при помощи этих инструментов.Инструменты: молоток и пила — IDE и компилятор. А качество кода — это качество дерева. Если дерево гнилое, то результат работы столяра сломается при первом же прикосновении.
В этом ключе, получается, что код — это не инструмент, а материал. И для хорошего решения как правило требуются определенные свойства материала (каленое железо, сухое дерево, мягкое или жесткое дерево, гладкая поверхность соприкасающихся подвижных частей).
Получение материала с теми или иными свойствами — вот это и есть мастерство.
Поэтому и заказчику или кому бы то ни было нужно не показывать сколько строк написано (сколько дыр просверлено или как гладко отполировали), а объяснять, что отшлифовали те и те детали, и сумели сделать сложное отверстие таким образом, что деталь теперь одна цельная, а это значит, что двигатель сможет нормально работать и не взорвется на презентации.
Хотел тоже написать про неправильную аналогию кода с инструментами, но увидел ваш комментарий.
Я бы провел аналогию кода со строящимся домом. Если у дома плохой фундамент — то и качество, и характеристики, и эксплутационный срок всего дома плохие. Или если технология возведения стен не соблюдена (каким бы хорошим не был материал), или допущены серьезные ошибки, то и здесь аналогично…
Я бы провел аналогию кода со строящимся домом. Если у дома плохой фундамент — то и качество, и характеристики, и эксплутационный срок всего дома плохие. Или если технология возведения стен не соблюдена (каким бы хорошим не был материал), или допущены серьезные ошибки, то и здесь аналогично…
1. ты просто пишешь программы. Как умеешь.
2. начинаешь глубже изучать язык, пробуешь внедрять новые штуки.
3. для каждого случая находишь наиболее правильное решение, соответствующее паттернам из GoF, рекомендациям Фаулера, Мартина и других правильных пацанов.
4. Ты просто пишешь программы. Как умеешь.
2. начинаешь глубже изучать язык, пробуешь внедрять новые штуки.
3. для каждого случая находишь наиболее правильное решение, соответствующее паттернам из GoF, рекомендациям Фаулера, Мартина и других правильных пацанов.
4. Ты просто пишешь программы. Как умеешь.
Ваш код должен интересовать в первую очередь самих вас, ведь вам с ним работать и вам его поддерживать. Самомотивация должна присутствовать в любом деле.
Я тоже думал, что мой код никому не интересен. В комментариях оставлял «коаны программирования».
А потом весь тех отдел лежал в истерике, когда на них наткнулись.
А потом весь тех отдел лежал в истерике, когда на них наткнулись.
>> Например, рефакторинг: что мы улучшаем с его помощью: код или продукт? Если ответ код — ни один менеджер не даст времени на это занятие.
Вот именно по этому менеджеры никогда не должны ставить задачи разработчикам. Это должен делать только тим-лид, знающий матчасть.
Вот именно по этому менеджеры никогда не должны ставить задачи разработчикам. Это должен делать только тим-лид, знающий матчасть.
Тимлид как правило не имеет права самовольно расходовать труд.ресурс без санкции рук.проекта.
Грамотный ПМ ещё как даст.
И да и нет.
У грамотного ПМа будет тим лид которому он доверяет и который проверен временем. Все технические аспекты он будет делегировать ему. ПМ должен заниматься стратегией, тактикой, бюджетом и договорами и решением споров команды и заказчика. Если в проекте agile, то роль ПМа сводится именно к этому. Все коммуникации с заказчиком будут лежать на команде и тим лиде.
Если тим лид для ПМа новый, он не даст санкции на расход ресурсов. Он будет контролировать чтобы убедится в отвественности и грамотности тим лида.
Если ПМ доверяет тим лиду, а тим лид доверяет команде, то всё будет нормально с проектом. И понимать все друг друга начнут. И отвественность разделять. И программисты не будут гнуть свою линию, и причёсывать код в ущерб срокам. Все эти действия должны быть согласованы. В первую очередь с ПМом, так как он первый кто несёт отвественность за сроки и бюджет.
У грамотного ПМа будет тим лид которому он доверяет и который проверен временем. Все технические аспекты он будет делегировать ему. ПМ должен заниматься стратегией, тактикой, бюджетом и договорами и решением споров команды и заказчика. Если в проекте agile, то роль ПМа сводится именно к этому. Все коммуникации с заказчиком будут лежать на команде и тим лиде.
Если тим лид для ПМа новый, он не даст санкции на расход ресурсов. Он будет контролировать чтобы убедится в отвественности и грамотности тим лида.
Если ПМ доверяет тим лиду, а тим лид доверяет команде, то всё будет нормально с проектом. И понимать все друг друга начнут. И отвественность разделять. И программисты не будут гнуть свою линию, и причёсывать код в ущерб срокам. Все эти действия должны быть согласованы. В первую очередь с ПМом, так как он первый кто несёт отвественность за сроки и бюджет.
А я согласен с автором, как это не прискорбно. Всегда хочется усовершенствовать, попробовать приделать что-то новое, или перейти с какого-нибудь angular 1 на 2 для этого переписав все к чертям, но реальной пользы для достижения конечной цели от этого будет немного, и оправдать ее получится только будучи программистом. По этому и делают проекты на всяких там wordpress.
Но черт возьми без, а давайте перепишем вот здесь, работа скатится в унылое…
Но черт возьми без, а давайте перепишем вот здесь, работа скатится в унылое…
Обычно с PM'ом можно уточнять, как следует сделать: «на совесть» или «как попало».
И часто ПМ берет на себя смелость ответить «как попало»?
Хороший ПМ — да. (И это отличный метод отличить труса, перекладывающего свою ответственность на команду, от хорошего тимлида). Хороший может ответить «мне нужно сейчас наговнякать к завтрашнему утру, а потом будем уже разбираться можно это сделать, нет, и если да, то насколько хорошо».
Ведь чуть ли не половина гениальных идей «надо сделать» часто оказываются нужны один или два раза.
А задачей команды будет при случае сказать «мы вот тут вот наговнякали, если мы это собираемся дальше тянуть, то его надо писать по-нормальному».
Разумеется, это требует хорошего отношения между PM и командой. Но в его отсутствие, как процесс не назови, всё равно будет плохо, не то, и медленно.
Ведь чуть ли не половина гениальных идей «надо сделать» часто оказываются нужны один или два раза.
А задачей команды будет при случае сказать «мы вот тут вот наговнякали, если мы это собираемся дальше тянуть, то его надо писать по-нормальному».
Разумеется, это требует хорошего отношения между PM и командой. Но в его отсутствие, как процесс не назови, всё равно будет плохо, не то, и медленно.
У нас не раз было как-то так:
— Нам нужно наговнякать за месяцок прототип, посмотреть, может ли оно взлететь вообще. Потом переделаем хорошо.
(через месяц)
— Значится так, прототип уже летает и мы его продали с допфичами, поэтому никаких вам переделать, а пилить допфичи.
В ответ на трепыхание разрабов менеджеры говорили словами из этой статьи :(
— Нам нужно наговнякать за месяцок прототип, посмотреть, может ли оно взлететь вообще. Потом переделаем хорошо.
(через месяц)
— Значится так, прототип уже летает и мы его продали с допфичами, поэтому никаких вам переделать, а пилить допфичи.
В ответ на трепыхание разрабов менеджеры говорили словами из этой статьи :(
Нет коммуникации между PM'ом и программистами. Либо PM плохой, либо он нанял плохих программистов. Либо, если он не контролирует HR-политику, то работают они вместе в хреновой конторе. Обычное дело такое.
Никто тут не плохой. Это высший пилотаж переговорщика, как купить феррари по цене лады.
Хитрый ПМ специально заказывает «наговнять», чтобы снизить начальные сроки, а затем программеры в мыле меняют на ходу движок (это ведь им больше надо) вместе с пилением фич, вместо того, чтобы пилить фичи и попивать чай, читая хабр.
Хитрый ПМ специально заказывает «наговнять», чтобы снизить начальные сроки, а затем программеры в мыле меняют на ходу движок (это ведь им больше надо) вместе с пилением фич, вместо того, чтобы пилить фичи и попивать чай, читая хабр.
Покупка феррари по цене лады в большинстве случаев попадает под категорию «мошенничество». Так же и тут: либо PM действительно нифига не понимает «в колбасных обрезках», либо он сознательно выжимает из программистов больше, чем то, на что они подписывались.
И в любом случае такой PM плох: в первом случае он просто не исполняет своих функций и ему во многом зря платится зарплата (хотя ему можно помочь — смотри ниже), во втором — он сам ставит себя в позицию «кто — кого». Это может привести в выигрышу в краткосрочной перспективе, но в долгосрочной — дело будет швах: раз PM поставил разработчиков в позицию «либо я вас на№%бу, либо вы меня», то рано или поздно он получит ответку, когда команда разработчиков будет, по бумагам, пыхтеть в поте лица, а на практике будет чаи гонять и придумывать какой бы ещё лапши на уши PMу навесить.
А вообще это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда (по-первости-то результаты улучшаются!), а к тому моменту, когда начинается развал он успевает свалить в другой отдел (часто на повышение). В конце-концов получается Стиве Элоп, который гробит компании с десятками тысяч сотрудников, а ему ещё и аплодируют. В маленьких же компаниях они обычно не выживают (вернее могут выжить если вовремя и удачно продадут компанию), так как расхлёбывать последствия приходится им же самим.
Упаси нас бог от таких PM'ов.
И в любом случае такой PM плох: в первом случае он просто не исполняет своих функций и ему во многом зря платится зарплата (хотя ему можно помочь — смотри ниже), во втором — он сам ставит себя в позицию «кто — кого». Это может привести в выигрышу в краткосрочной перспективе, но в долгосрочной — дело будет швах: раз PM поставил разработчиков в позицию «либо я вас на№%бу, либо вы меня», то рано или поздно он получит ответку, когда команда разработчиков будет, по бумагам, пыхтеть в поте лица, а на практике будет чаи гонять и придумывать какой бы ещё лапши на уши PMу навесить.
А вообще это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда (по-первости-то результаты улучшаются!), а к тому моменту, когда начинается развал он успевает свалить в другой отдел (часто на повышение). В конце-концов получается Стиве Элоп, который гробит компании с десятками тысяч сотрудников, а ему ещё и аплодируют. В маленьких же компаниях они обычно не выживают (вернее могут выжить если вовремя и удачно продадут компанию), так как расхлёбывать последствия приходится им же самим.
Упаси нас бог от таких PM'ов.
>Это может привести в выигрышу в краткосрочной перспективе, но в долгосрочной — дело будет швах
Когда, дело действительно станет швах, то главный виновник всего шваха — просто уйдёт в другую фирму. И ему глубоко насрать на то, что стало с прежней фирмой.
>это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда
… по причине дурных HR, считающих себя всех умнее, и лучше разбирающимся в том какие люди нужны фирме, отсеивая нормальных кандидатов, чтобы своим отсевом заниматься Имитацией Бурной Деятельности.
Когда, дело действительно станет швах, то главный виновник всего шваха — просто уйдёт в другую фирму. И ему глубоко насрать на то, что стало с прежней фирмой.
>это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда
… по причине дурных HR, считающих себя всех умнее, и лучше разбирающимся в том какие люди нужны фирме, отсеивая нормальных кандидатов, чтобы своим отсевом заниматься Имитацией Бурной Деятельности.
А почему при этом программисты «в мыле»? Вообще говоря, если PM вас хочет гонять «в мыле» — то это повод либо проявить трудовой героизм (если в этот момент экспа идёт), либо заняться исследованием альтернатив (если экспа не идёт или не нужно).
Повторю, если PM хочет поставить программистов в ситуацию, когда от них ожидается качество, а на качество ресурсов не выделяется, то это проблема PM'а и тех, кому не повезло с ним работать (hint: второе исправимо).
Но важно понимать, что есть моменты, когда PM точно знает, что ему надо _наговнякать_. Прямо тут. Херак-херак, и на продакшен. И забыли. PM и только PM понимает business value для того, что делается. А задачей команды является донести до PM'а, сколько ресурсов для данного качества нужно выделить на инфраструктурную часть (то есть на «качество» кода). Это довольно неформальный процесс, часто на грани ненормативной лексики.
Зато на выходе имеется, что всё важное написано хорошо (с покрытием тестами и рефакторингом), а миллионы строк кода, которые не особо-то и нужны в сопровождении в будущем, написаны наотъе… сь, и стоили компании немного. При попытке их развить и начать использовать как код, а не как костыли, PM это понимает (и ему объясняют!) и выделяются ресурсы на приведение в порядок.
То есть проблема обычно в коммуникации между PM и командой. И тут должен быть и хороший PM (который понимает программистов) и хорошие программисты, которые понимают, что иногда надо вчера и говнокод.
Повторю, если PM хочет поставить программистов в ситуацию, когда от них ожидается качество, а на качество ресурсов не выделяется, то это проблема PM'а и тех, кому не повезло с ним работать (hint: второе исправимо).
Но важно понимать, что есть моменты, когда PM точно знает, что ему надо _наговнякать_. Прямо тут. Херак-херак, и на продакшен. И забыли. PM и только PM понимает business value для того, что делается. А задачей команды является донести до PM'а, сколько ресурсов для данного качества нужно выделить на инфраструктурную часть (то есть на «качество» кода). Это довольно неформальный процесс, часто на грани ненормативной лексики.
Зато на выходе имеется, что всё важное написано хорошо (с покрытием тестами и рефакторингом), а миллионы строк кода, которые не особо-то и нужны в сопровождении в будущем, написаны наотъе… сь, и стоили компании немного. При попытке их развить и начать использовать как код, а не как костыли, PM это понимает (и ему объясняют!) и выделяются ресурсы на приведение в порядок.
То есть проблема обычно в коммуникации между PM и командой. И тут должен быть и хороший PM (который понимает программистов) и хорошие программисты, которые понимают, что иногда надо вчера и говнокод.
Часто проблема в том, что ПМ не сообщает, что ему надо весь проект наговнякать, что любые заделы на будущее его не интересуют, а то и вредят бизнес-модели, не позволяет раздувать бюджет заказчика.
Видел очень мало таких. Вернее видел много таких, кто готовы рассказывать про важность быстрого выпуска продукта и прочего, но достаточно попросить завизировать своей подписью простую бумажку с парой фраз (типа по результатам обсуждения решено, что выпуск прототипа должен состояться в как можно более сжатые сроки без затрат времени на создание задела по возможной модернизации, так как окончательная версия будет реализована с нуля без использования каких-либо частей протипа) и они вдруг «прозревают».
Нужно отделять желание «на чужом горбу въехать в рай» от «непонимания ситуации». Одно дело — рассказывать про то, какой ты молодец, как отлично у тебя всё получается и как твои последователи всё разваливают и совсем другое — подставлять свою задницу.
Нужно отделять желание «на чужом горбу въехать в рай» от «непонимания ситуации». Одно дело — рассказывать про то, какой ты молодец, как отлично у тебя всё получается и как твои последователи всё разваливают и совсем другое — подставлять свою задницу.
Это уже другая история. И при это тоже писали.
Если вы хотите, чтобы ваш прототип воспринимали как прототип, то и сделайте, чтобы он выглядел как прототип. Чтобы у него кнопки были убогими. И чтобы он тормозил нещадно. И запускался через раз. Поверьте — это несложно,
А если вы сделали прототип, который выглядит как готовое изделие, то менеджер и будет считать, что у вас уже готовое изделие.
Опять-таки — это проблема не только программистов, просто почему-то непрограммистам это проще понять. Вы видели «протипы» железячников? Когда из картонной коробки торчат какие-то провода, запускается всё засовыванием проводов куда-то вместо щёлкания тумблерами и т.д. и т.п. Неужели же сложно сделать красивую коробочку, напечатать корпус на 3D-принтере и вообще «сделать красиво»? Можно — но тогда заказчик начнёт задавать совсем уж странные вопросы типа «когда мы сможем получить от наших подрядчиков серийные образцы?»…
Если вы хотите, чтобы ваш прототип воспринимали как прототип, то и сделайте, чтобы он выглядел как прототип. Чтобы у него кнопки были убогими. И чтобы он тормозил нещадно. И запускался через раз. Поверьте — это несложно,
А если вы сделали прототип, который выглядит как готовое изделие, то менеджер и будет считать, что у вас уже готовое изделие.
Опять-таки — это проблема не только программистов, просто почему-то непрограммистам это проще понять. Вы видели «протипы» железячников? Когда из картонной коробки торчат какие-то провода, запускается всё засовыванием проводов куда-то вместо щёлкания тумблерами и т.д. и т.п. Неужели же сложно сделать красивую коробочку, напечатать корпус на 3D-принтере и вообще «сделать красиво»? Можно — но тогда заказчик начнёт задавать совсем уж странные вопросы типа «когда мы сможем получить от наших подрядчиков серийные образцы?»…
Ок, тогда я повторю свой вопрос, но немного в другом ключе. Как часто встречаются такие хорошие и правильные ПМ?
Чтобы оценить вероятность надо сделать большую выборку. У меня такой нет. Но хорошего ПМ я нашёл, и всё отлично. Подозреваю, что если искать работу не по критерию «ЗП/близость к дому/любимый ЯП», а по критерию «толковый и вменяемый ПМ», то работа легко найдётся.
У меня ПМ тоже отличный. Но тем не менее я как-то не представляю, как по этому критерию можно искать работу. Сам процесс неуловимо ускользает :)
Ну, беседа при собеседовании. Например, компании, где HR до последнего человека ведёт, а PM'а не видно, наверное, не лучшее место для трудоустройства. Личное впечатление о человеке. Поговорить о возможных проектах, где предстоит работа и т.д.
Увы, в большинстве крупных компаний с хорошей зарплатой у HR (как правило) — слишком большая роль. А PM появляется, только если HR разрешит.
А однажды, вообще был клинический случай
0. HR — была в отпуске
1. успешно поговорил с PM и уже обговорили устройство на работу
2. HR — возвращается из отпуска
3. объявляют, что требуется обязательное одобрение HR
4. HR — зарубает, и хрен кто что может поделать
(самое обидное, что зарплата там была очень и очень нехилая, да, ещё тогда Кризис был, и с работой было туго)
А однажды, вообще был клинический случай
0. HR — была в отпуске
1. успешно поговорил с PM и уже обговорили устройство на работу
2. HR — возвращается из отпуска
3. объявляют, что требуется обязательное одобрение HR
4. HR — зарубает, и хрен кто что может поделать
(самое обидное, что зарплата там была очень и очень нехилая, да, ещё тогда Кризис был, и с работой было туго)
Да ладно вам. В Российском офисе Гугла PM'а вообще в штате не было несколько лет ни одного — и ничего, как-то же удавалось нанимать людей и получать премии «за лучшее место работы».
UFO just landed and posted this here
UFO just landed and posted this here
Многие заметили совершенно правильно — прежде всего код интересует команду. Качество кода сильно влияет на скорость с которой новый сотрудник сможет адаптироваться. Оно влияет на возможность качественно заделать ваши баги когда вы в отпуске. Хороший тимлид никогда не допустит гниющего кода, потому что каждый человек, работающий над проектом, становится трудно заменим.
Но безусловно, во всем надо знать меру.
Но безусловно, во всем надо знать меру.
Не одних программистов это касается. Трехмерщики полируют топологию, дизайнеры двигают пиксели, геймхудожники перерисовывают текстурки. Нельзя однозначно сказать, что это задротство никто не оценит. Еще как оценит, на себе проверено. Но, самое важное это разумный подход. Нужно четко понимать, когда нужно сделать добротно и тупо, а когда вылизывать до идеала.
> Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?
А вот кстати, таки кодом. Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.
А вот кстати, таки кодом. Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.
Хороший код может содержать больше багов, чем плохой. Качество кода не всегда влияет на качество продукта.
> Хороший код может содержать больше багов, чем плохой
Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.
В результате после просмотра кода ты имеешь представление, что от этой библиотеки ожидать, и если там что-то сильно не так — лучше я добавлю недостающий функционал другую библиотеку, чем возьму эту.
Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.
В результате после просмотра кода ты имеешь представление, что от этой библиотеки ожидать, и если там что-то сильно не так — лучше я добавлю недостающий функционал другую библиотеку, чем возьму эту.
Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
У меня был недавно инцидент. Надо было regex-библиотеку прикрутить к дельфи-проекту. Взял какой-то TRegex, написан вроде прилично, по всем гайдам. Но на практике тормозит нещадно и падает на паттернах в пару КБ. Просто автор в алгоритмах не понимает ничего, что такое автоматы, грамматики и т.п. Просто взял и в лоб накодил.
Кончилось тем, что я взял страшный вырвиглазный pcre и завернул в dll. Вот и весь сказ про «красивый код».
Если для пользователя нет видимых изменений, значит я за день ничего не сделал. Хороший код нужен самому себе, либо группе разработчиков, которые тоже над этим кодом работают.
А меня не интересует, чего хочет заказчик. Меня интересует только код и моя зарплата.
Но разве вы не пишете код для того, чтобы решить какую-то проблему? Неважно что за задача, если вы её решаете за деньги, значит кому-то она настолько важна, что он готов заплатить.
Не из решения проблем ли состоит программирование, и только потом уже из кода?
Не из решения проблем ли состоит программирование, и только потом уже из кода?
Бывает, что больше половины кода вылетает в помойку. Поэтому не стоит переживать, если код не решил задачу. Не получилось — заходим на следующую итерацию. Если не воспринимать кодирование как игру, можно потерять мотивацию (я столько думал, кодил и всё напрасно). А так — я играю, мне платят. Получилось что-то полезное — хорошо, но на деньги это как правило не влияет.
Результат программирования — решение проблемы, а состоит оно из изменения кода. Есть два основных подхода к ним: решаем за минимальное время озвученную проблему или увеличиваем время решения с целью избежать в будущем новых проблем.
я чет не уверен на счет первого с таким подходом.
А вот интересно, есть ли примеры проектов, где код блестящий, а конечный продукт не огонь?
Я в практике постоянно с этим сталкивался. Прекраснейшие архитектуры складывались «в стол» потому что никак не помогали продукту лучше удовлетворять пользователя и лучше продаваться.
Как можно назвать архитектуру прекрасной, если она не помогала продукту? Это равносильно «мы сделали замечательный дизайн-концепт автомобиля, одна проблема — он ездить не может».
Пока мы делали блестящий автомобиль, конкуренты сделали рельсы и ржавый паровоз он нас обошёл по всем пунктам, кроме лоска.
Это равносильно скорее «мы сделали самый быстрый в мире автомобиль, но никто не хочет его покупать потому что дорого». Или, в общем, «мы сделали лучший по таким-то критериям продукт, но не можем найти тех, кто по этому критерию выбирает»
Архитектура не может помочь продукту, если ошибочны требования к продукту.
Архитектура не может помочь продукту, если ошибочны требования к продукту.
Сколько угодно. Последний пример — Windows Phone. По многим признакам видно, что код там куда лучше, чем, скажем, в Android'е. Одна беда: пока Microsoft порождал на основе передовых концепций самый лучший код Android захватил весь рынок и теперь отвоевать хоть малюсенький кусочек будет проблемой.
По многим признакам видно, что код там куда лучше, чем, скажем, в Android'е.
По каким признакам? Вы делали синтактический анализ качества Java кода Android и C# (вроде он там) Windows Phone? Да, я могу поверить что код Android'а менее протестирован, но это не значит что там писали говнокод.
Подозреваю что проблема совсем не в том что в гугле говнокодили, а в Microsoft'е вылизывали код, там на самом деле куча других причин почему Android обыграл Microsoft.
На всякий случай добавлю Android построен на оперсорсном Линуксе, а Windows Phone на усеченной винде. Традиционно многими винда исторически считалась более прожорливой и менее качественной чем Линукс (честно говоря не знаю как на самом деле сейчас дела обстоят), так что о качестве кода (производительности, отлажености ядра) тут можно поспорить.
Ядро у Android'а — действительно ничего. Но вот всё что выше… Harmony, Dalvik и многое другое из Android 1.x в сравнении даже с Windows Phone 7 — это просто велосипед по сравнению с самолётом. Но вот беда: Android 1.0 вышел на рынок в 2009м году, а Windows Phone 7 — только через год, NDK для Android'а — появился в 2009м и работал на всех телефонах начиная с Dream'а, а в Windows Phone 7 поддержки нативного кода не было, а Windows Phone 8 с его поддержкой появилась аж в 2012м году. И т.д. и т.п.
Многие «болячки» Android'а с тех пор исправили, конечно, но есть куча вещей, о которые разработчики до сих пор постоянно спотыкаются.
Многие «болячки» Android'а с тех пор исправили, конечно, но есть куча вещей, о которые разработчики до сих пор постоянно спотыкаются.
> Традиционно многими винда исторически считалась более прожорливой
Традиционно многими Земля исторически считалась плоской (честно говоря не знаю как на самом деле сейчас дела обстоят, меня не берут в космонавты...)
Традиционно многими Земля исторически считалась плоской (честно говоря не знаю как на самом деле сейчас дела обстоят, меня не берут в космонавты...)
Разумеется, я не спрашиваю водителя когда он менял резину и тех. жидкости, моя задача доехать из п А в пункт Б. Разумеется это проблема водителя. Как и водителя когда он приходит в магазин, не интересует, регулярно ли платит магазин налоги, как и руководителя магазина… У каждого есть своя доля ответственности, соблюдение которой дает плюшки, не соблюдение определенные проблемы. В случае с кодом, плохой код, плохо отлаживать и сопровождать.Сложность процесса ухудшает результат за который ты как раз получаешь деньги.
Тем не менее сплошь и рядом видишь как люди бьются за вещи, которые напрямую к результату не относятся. Когда вместо «количества ошибок» оценивается «покрытие тестами», а вместо решения конкретных задач появляются фабрики фабрик фабрик.
Тут нельзя забывать, что программист в команде не один. Программисты по большему счету соревнуются друг с другом в том, как быстро они выполняют задачи, потому как от этого зависит зп, бонусы и т.п. Особенно это справедливо для больших команд. В результате, при отсутствии должного контроля за качеством кода, качество зачастую приносится в жертву в угоду скорости и срокам (программистами). С качеством кода наблюдается эффект аналогичный "трагедии общинного поля". Чтобы этого избежать, отчасти, вводят кодинг гайдлайны и ревью кода, которые сами по себе вносят большой оверхед в разработку (т.к. требуют время программистов, и, иногда, много).
Это ровно две крайности одна habrahabr.ru/post/256175/?reply_to=8385619#comment_8385461 (первый ответ на мой комментарий) вторая та которую описываете вы. Но их то как раз просто не должно быть, должна быть грань разумного, так и водила может колотить ходовую, не разбирая дороги и забыть про ТО или наоборот переползать через каждую ямочку и торчать по полдня в автосервисе при каждом чихе(что разумеется будет нервировать тех, кого он возит).
Поэтому ТО делается не водителем и есть ГИБДД, которое его проверяет. Т.к., иначе, про ТО забудут все. Со временем.
ТО имелось ввиду не техосмотр, а техобслуживание. И да меня волнует техническое состояние автомобиля и тех узлов которые проверяют на ТехОсмотре тоже. На данные момент ТехОсмотр проходится, не подходя к моей машине, взнос заплатил? Давай бланк. Я регулярно проверяю состояние машины, потому что это моя безопасность, вне зависимости от требований ГИБДД.
Это как раз не важно. Вот что получается, когда все пытаются ехать как можно быстрее по своим делам, на чем под руку попалось, с максимальной возможной скоростью, при полном несоблюдении ПДД:
Сверхскоростями тут и не пахнет. Тут можно пешком ходить и выглядеть крутым перцем ;-)
Сверхскоростями тут и не пахнет. Тут можно пешком ходить и выглядеть крутым перцем ;-)
Как аккуратно сюда добавилось еще и несоблюдение ПДД. Я разве говорил, что они не должны соблюдаться или что они крайность? Я говорил вроде про другие крайности.
Я разве говорил, что они не должны соблюдаться или что они крайность?
Не говоили. Но, кто ж меня заставляет ограничиваться рамками вашего примера? Машина — ресурс личный, как время программиста. А вот дороги и дорожное движение — общий, как код проекта и CI для команды. Каждый заботится о своей машине, но не заботится о дорогах и удобстве другого. В отсутствие контроля — неизбежно получается «индийский траффик», а точнее — его программный аналог. Поэтому, помимо программистов, кто-то ещё должен быть заинтересован в качестве кода. Иначе, время возмет свое.
>>Но, кто ж меня заставляет ограничиваться рамками вашего примера?
Тогда смысл и суть спора пропадает.
Есть правила которые участник дорожного движения\программист в команде обязан соблюдать, как раз по вышеобозначенным причинам. Эти правила продиктованы опытом, написаны кровью и являются вполне себе жизненной необходимостью. И вот как раз не обсуждается в статье. Насколько нужно\не нужно соблюдать правила принятые в команде, про это вообще речи не было.
Тогда смысл и суть спора пропадает.
Есть правила которые участник дорожного движения\программист в команде обязан соблюдать, как раз по вышеобозначенным причинам. Эти правила продиктованы опытом, написаны кровью и являются вполне себе жизненной необходимостью. И вот как раз не обсуждается в статье. Насколько нужно\не нужно соблюдать правила принятые в команде, про это вообще речи не было.
В каждой команде правила свои. Они не берутся в потолка. Да. Они вырабатываются кровью и потом. Но, программисты сами по себе не самоорганизуются. Без участия мэнеджера у них не появится само по себе CI, Code Review и тесты. Всё это требует времени, которое распределяет и выделяет мэнеджер. Поэтому, он должен интересоваться кодом. Или, хотябы полагаться на мнение лида, или другого, специально выделенного лица. И, планировать на это время.
Я ж вроде как раз говорю, что и статья, и беседа изначально не об этом. Есть должностные инструкции выполняй, о чем мы сейчас разговариваем то? Извините за французский: Что б было меньше пиздежу, делай все по чертежу.
Слова CI, Code Review, тесты и менеджер вместе не употребляются.
Ты говоришь менеджеру тесты, он слышит — задачи будут закрываться на неделю позже.
Ты говоришь ему Code Review, он слышит — на одну задачу придётся выделять в 3 раза больше народу.
Ты говоришь ему CI, он слышит — деплой я сделаю не сейчас, а через 2 дня, после того, как всё настрою.
Ты говоришь менеджеру тесты, он слышит — задачи будут закрываться на неделю позже.
Ты говоришь ему Code Review, он слышит — на одну задачу придётся выделять в 3 раза больше народу.
Ты говоришь ему CI, он слышит — деплой я сделаю не сейчас, а через 2 дня, после того, как всё настрою.
Программисты по большему счету соревнуются друг с другом в том, как быстро они выполняют задачи, потому как от этого зависит зп, бонусы и т.п.
Поэтому, если ввести метрики, программисты будут работать на метрики.
Поэтому, если ввести метрики, программисты будут работать на метрики.А разве это плохо? Просто метрики должны соответствовать состоянию проекта. Если у нас клиенты жалуются на то, что продукт всё время падает — поощряем тех, кто фиксит баги, если у нас скоро релиз — тех, кто допиливает фичи, если у нас код такой, что его править невозможно — вводим плюшки за покрытие тестами (по согласованию с PM'ом, конечно) и т.д. и т.п.
Если же вы про то, что нельзя установить раз и навсегда какие-то метрики за которыми только и следить, то это, как бы, самоочевидно… хотя удивительным образом не всем почему-то.
Фантастика. Цикл обратной связи месяца два? Чтобы заранее сказать: «следующий месяц метрики по тестам». А з/п по периоду дадут только в начале следующего, при быстрой смене в голове у всех каша, за что платят. Если же срочно заказчику приспичит внедрить фичу «А», которую ему пропиарили где-то на тренинге, то разработчики только недоумённо посетуют «Какая фича? А нас месяц тестов».
И зачем поощрять багфиксы метриками? Ставишь вверх по приоритетам и на митинге напоминаешь: «Коля, что ты сегодня делаешь? Фичу? Нет, бросай фичу, тут баг есть повыше».
А метрики по тестам это как? Бинарно писал/не писал, или по количеству? В любом случае очевидно, что делать, чтобы программисту максимизировать прибыль при минимизации затрат времени.
И зачем поощрять багфиксы метриками? Ставишь вверх по приоритетам и на митинге напоминаешь: «Коля, что ты сегодня делаешь? Фичу? Нет, бросай фичу, тут баг есть повыше».
А метрики по тестам это как? Бинарно писал/не писал, или по количеству? В любом случае очевидно, что делать, чтобы программисту максимизировать прибыль при минимизации затрат времени.
Проблема в том, что зачастую решение писать код качественно или нет, лежит в зоне ответственности не программиста, если качество требует дополнительных затрат.
Когда не по себе от качества «быстрых решений», сажусь и рефакторю/пишу свои старые/новые идеи в свободное время. В итоге хватает уверенности начать писать правильно сразу в большинстве случаев ввиду регулярных тренировок.
Ну и конечно есть радикальный вариант — смена работы и стабильный проект (все же в этом случае куда больше шансов быть услышанным).
Ну и конечно есть радикальный вариант — смена работы и стабильный проект (все же в этом случае куда больше шансов быть услышанным).
Автор перевода не угадал с аудиторией. Программиста очень сложно переубедить, что код — это не вещь в себе, а лишь средство решения проблем. И если бы эти проблемы решались вообще без кода и стоило бы дешевле — все бы так и делали.
Нормального опытного программиста легко. Если я могу решить задачу написав формулу в Excel'e за 15 секунд, я напишу формулу в Excel'e, а не буду пытаться написать класс. Нормального опытного программиста сложно переубедить, что хороший код и плохой код с точки зрения прибыли одинаковы, потому что у каждого программиста есть свое кладбище загубленных баз данных, глупых ошибок на много нулей в долларах, модулей на много тысяч человекодней, который проще выкинуть и переписать заново, чем пытаться понять.
Везде должна быть золотая середина: код не искусство, это лишь средство. Однако, глупо покупать набор отверток за десятки тысяч $, но и пользоваться китайской фигней за 10 центов/набор тоже не очень умно.
Везде должна быть золотая середина: код не искусство, это лишь средство. Однако, глупо покупать набор отверток за десятки тысяч $, но и пользоваться китайской фигней за 10 центов/набор тоже не очень умно.
UFO just landed and posted this here
Код — как спальня. Всегда могут нагрянуть гости. Или гостья. А у вас не прибрано.
Если мэнеджера совсем не интересует код, то, регулярные косяки от всех разработчиков по очереди с оценками в $ заставят его начальство задуматься, что в этой сказке не так.
Но вообще, да. Код это не самоцель. Усилия по поддержанию кода в порядке должны как-то соответствовать рискам.
Но вообще, да. Код это не самоцель. Усилия по поддержанию кода в порядке должны как-то соответствовать рискам.
Сколько раз я слышал это блаблабла продукт блаблабла инструмент. И ни разу — от действительно хороших программистов.
Программисты неплохо получают, и у них закрыты почти все уровни пирамиды Маслоу, кроме самоактуализации. Если тебе не нравится продукт, который ты делаешь на работе, если он тебе безразличен или если тебе не дают принять участие в его проектировании, то единственная возможность творчества и самовыражения — это твой код.
Это не значит, конечно, что нужно все время потратить на непрерывный рефакторинг и написание Общего Ядра Всего, но говнячить прикрываясь девизом «я делаю продукт» тоже не стоит, можно и канделябром-с получить…
Программисты неплохо получают, и у них закрыты почти все уровни пирамиды Маслоу, кроме самоактуализации. Если тебе не нравится продукт, который ты делаешь на работе, если он тебе безразличен или если тебе не дают принять участие в его проектировании, то единственная возможность творчества и самовыражения — это твой код.
Это не значит, конечно, что нужно все время потратить на непрерывный рефакторинг и написание Общего Ядра Всего, но говнячить прикрываясь девизом «я делаю продукт» тоже не стоит, можно и канделябром-с получить…
… © Б. Мейер. Основы объектно-ориентированного программирования, глава о критериях качества ПО.
По статье: а как же такие критерии, как расширяемость и модульность?
По статье: а как же такие критерии, как расширяемость и модульность?
Мой код интересует того склонного к насилию психопата, который знает, где я живу.
Качество кода означает:
1. уменьшение вероятности собственных ошибок
2. уменьшение вероятности ошибок тех, кто будет с ним работать в дальнейшем, а также экономию их времени
3. уменьшение сложности решения
Тем не менее, нельзя не приветствовать отсутствие интереса к качеству кода и ориентацию на короткосрочную перспективу при решении задач. У меня будет меньше конкурентов на рынке труда.
1. уменьшение вероятности собственных ошибок
2. уменьшение вероятности ошибок тех, кто будет с ним работать в дальнейшем, а также экономию их времени
3. уменьшение сложности решения
Тем не менее, нельзя не приветствовать отсутствие интереса к качеству кода и ориентацию на короткосрочную перспективу при решении задач. У меня будет меньше конкурентов на рынке труда.
Это статья для руководителей разработки, поскольку с них спрашивают результат, а не листинг кода.
Соответственно, вполне предсказуемая отрицательная реакция со стороны разработчиков, поскольку написание хорошего кода есть главный мотив к тому, чтобы вообще работать (не хлебом одним сыт человек).
Соответственно, вполне предсказуемая отрицательная реакция со стороны разработчиков, поскольку написание хорошего кода есть главный мотив к тому, чтобы вообще работать (не хлебом одним сыт человек).
1. Любой рефакторинг должен быть согласован с руководителем
2. В данном случае руководитель прав — с него спрашивают функционал, а не код, поэтому при оценке «что сделал» оценивается реализованный функционал.
3. Качество кода анализируется отдельно техническим специалистом. После этого в код вносятся правки, а к разработчику применяется животворящий паяльник для корректировки поведения.
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.
2. В данном случае руководитель прав — с него спрашивают функционал, а не код, поэтому при оценке «что сделал» оценивается реализованный функционал.
3. Качество кода анализируется отдельно техническим специалистом. После этого в код вносятся правки, а к разработчику применяется животворящий паяльник для корректировки поведения.
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.
1. Рефакторинг не должен быть соглсован с руководителем. Рефакторинг должен быть постоянным процессом, идущим совместно вместе с любыми задачами. В этом варианте затраты на поддержку кода в хорошем состоянии будут минимальны. Иначе, да, всё будет накапливаться и выполнение «рефакторинга» станет само по себе настолько тяжеловесной задачей, что вам придется «продавать» это PM-у. И он скорее всего не купит. И будет прав (2).
3. Каким «техническим специалистом»? Тем, что работает в этой же команде? Если да, то почему бы это не сделать частью процесса?
3. Каким «техническим специалистом»? Тем, что работает в этой же команде? Если да, то почему бы это не сделать частью процесса?
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.Именно поэтому бизнес не должен принимать технических решений. В частности о том, делать рефакторинг или нет.
1. В результате «самопального» рефакторинга вы скорее всего после очередного просранного срока просто окажетесь на улице. Это раз.
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.
3. Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.
Не должен и, вообще говоря, не обязан. Но бизнес должен понимать сроки и риски, потому что на эти параметры также завязывается и целесообразность/окупаемость внедрения той или иной фичи.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.
Правильный ответ в данной ситуации (для «бизнеса») такой: «В данный момент мы не можем это реализовать технически, но если мы доработаем ПО (+ 2 недели), то задача будет выполнена в течение недели после завершения доработки».
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.
Рефакторинг должен быть постоянным процессом, идущим совместно вместе с любыми задачами.
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.
3. Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.
Именно поэтому бизнес не должен принимать технических решений. В частности о том, делать рефакторинг или нет.
Не должен и, вообще говоря, не обязан. Но бизнес должен понимать сроки и риски, потому что на эти параметры также завязывается и целесообразность/окупаемость внедрения той или иной фичи.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.
Правильный ответ в данной ситуации (для «бизнеса») такой: «В данный момент мы не можем это реализовать технически, но если мы доработаем ПО (+ 2 недели), то задача будет выполнена в течение недели после завершения доработки».
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.Кстати обратной стороной медали будет то, что люди бизнес-стороны начнёт задумываться и о том, что иногда стоит «сделать правильно» с самого начала.
Пока весь нобходимый рефакторинг вы делаете по ночам или срывая сроки и жалобно потом оправдываясь — бизнесу кажется что все эти ваши заморочки есть суть ваша некомпетентность, если вы чётко связываете решение «забить досками год назад, чтобы ускорить релиз на два дня» и сегодняшние «доработки», которые займут две недели, то менеджмент неожиданно окажется куда более сговорчивым и в вопросах выделения времени на то, чтобы всё было сделано правильно.
Вообще для того, чтобы понять как «общаться с бизнесом» нужно усвоить очень простой факт: они другие. Их сила — в другом. Они неспособны «глубоко вникнуть» в суть дела, зато могут держать в голове одномоментно столько факторов из разных, не связанных между собой областей, сколько вы и в тетрадку не запишите. А практически это выливается это в то, что во всех письмах читается одно предложение. Первое. Ну хорошо — может быть два. Первых. Дальше — ну просто в исключительных случаях. Отсюда и любовь бизнес-людей к топ-постингу, кстати. Все ваши многоуровневые построения вылетают в трубу. Вы подробно описываете кучу ньюансов, где-то в 10м абзаце задаёте вопрос, а потом ждёте ответ? Вы его не получите: после прочтения (с приложением героических усилий) трёх абзацев ваше письмо было классифицировано как «бла-бла-бла» и… выкинуто. Как не имеющее содержания. При этом могут быть и очень длинные письма, которые бизнесмен прочтёт — но они всё равно должны начинаться с заключения (чего конкретно сейчас конкретно от получателя письма ожидается) и дальше — может быть цепочка, которая отходит от вопроса и показывает откуда он взялся. Тогда — да, тогда письмо будет прочитано целиком. В надежде найти ошибку в цепочке и ничего не делать :-)
Кстати обратной стороной медали будет то, что люди бизнес-стороны начнёт задумываться и о том, что иногда стоит «сделать правильно» с самого начала.
Бизнес не будет и не должен об этом задумываться, об этом задумываться должен CIO, это его работа.
Ко всему остальному это тоже относится. Прекращайте решать, как нужно думать бизнесу, это подростковый эгоцентризм.
Ко всему остальному это тоже относится. Прекращайте решать, как нужно думать бизнесу, это подростковый эгоцентризм.Похоже тут опять столкнулись представители разных миров. Если ваш бизнес заключается в разработке софта «под заказ», то да, может быть бизнесу и не стоит об этом задумываться. А вот если речь идёт о «коробочном» ПО, то это чуть ли ни основное о чём в принципе должен думать бизнес. Как уже говорилось выбор может быть совсем не таким, как хочется перфекционистам, но его нужно делать и это именно бизнес-решение.
Что такое «самопальный рефактоинг»? Рефакторинг, который не был официально подписан PM-ом? )
В результате «самопального» рефакторинга вы скорее всего после очередного просранного срока просто окажетесь на улице.Я не встречал проектов, в которых над уровнем когда следят и при этом хронически фейлящих сроки. Зато встречал проекты, где всё делалось «побыстрее», на технический долг регулярно забивалось и в итоге в один прекрасный момент оказывалось, что для исправления накопившихся проблем проще (и быстрее) всё выкинуть и переписать с нуля. Удивительно, правда?
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.Это дОлжно быть оговорено им (архитектором/техлидом) и всей командой в целом один раз и навсегда, еще на старте проекта. PM-а это касается только косвенно. Поддержка качества кода проекта должна присутствовать в каждой задаче, а не делаться задним числом. Это как сначала писать приложение, а потом добавлять в него «безопасность».
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.То, что вы описываете — это не проблема, а следствие проблемы. Если функционал приходится «стабилизировать» — значит он изначально был сделан хреново. Это значит, что либо код не проходил ревью (ССЗБ), либо проходил, но ревьюеры это пропустили (вдвойне ССЗБ).
Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.Если ревью занимаются по сути сторонние люди, а не другие члены этой же команды, то вы теряете канал передачи между разработчиками ифнормации о том, что вообще на проекте происходит, как именно что делается, какие были обнаружены ошибки/недочеты/замечания по коду и т.д. Ревью должны делать все. В том числе джуниору весьма полезно ревьювать то, что делает техлид/архитектор ибо это весьма способствует улучшению понимания проекта джуниором.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.Соверешенно верно. Называя срок «неделя» вы должны в том числе учитывать, что вы точно будете делать рефакторинг. Потому что вы всегда должны делать рефакторинг. Как часть каждой задачи. Постоянно.
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.Еще раз: бизнесу не нужно и не положено знать про рефакторинг вообще. Оценки времени — да. Риски — да. Как именно оно «внутре» работает и что именно входит в оценку реализации конкретной задачи — нет.
Когда сроки жмут, то лучше потратиться на тщательное проектирование, что поможет избежать обязательности рефакторинга. Проектировать нужно так, чтобы заранее избежать и ситуации кода нужно переписывать всё с нуля, и необходимости рефакторинга.
Это возможно только если ваши пректы похожи один на другой как две капли воды.
Необязательно все похожи и одинаковы, просто, если есть большой опыт, то легче примерно представить на что это будет скорее всего похоже и как скорее всего будет работать. Даже, если проект абсолютно новый, то все равно лучше потратить пару дней на тщательное проектирование ДО начала написания кода, чем потом потратить пару недель (если не больше) на исправление ошибок, переписывание заново, рефакторинг итд итп в том же духе.
Ну собственно все, кто практикует аджайл методологию, с этим не согласятся.
И снова мы упираемся в разные миры. Да, конечно, если вас не очень волнует качество результата, у вас нет времени на вылизывание и продумывание и вы вообще не очень понимаете в начале работы чего вы, собственно говоря, хотите, то постоянный и непрерывный рефакторинг — единственный выход. Если же вы делаете ПО, которым будут [предположительно] пользоваться миллионы или, скажем, такое ПО, которое будет практически невозможно обновить — тогда увлечение рефакторингом скорее вредно. По одно простой причине: если вы отлично понимаете что делает ваш код, то рефакторинг не нужен ибо вы и так понимаете, чего хотите добиться, если же нет — никакие тесты вас не спасут и ошибки и глюки вы насажаете всё равно. В «заказном» ПО — это нормально, во многих других типах ПО — нет.
Обычно и сроки жмут, и требования меняются. А когда меняются требования, тщательное проектирование хорошо, но не достаточно.
Во время проектирования самое время, ДО написания кода, самое время тщательно проанализировав требования выявить в них мутные места и недоговорки, и задав вопросы внести ясность. Лучше приступить к написанию кода позже, но без переписывания заново или/и ломания структуры программы.
В эти мутные места нельзя внести ясность. Клиент — не в курсе что там будет. А если думает, что в курсе — то скорее всего ошибается. Разработчик, если он опытный — понимает что будет в этих мутных местах лучше клента, но тоже не владеет всей полнотой информации. Работать по мутным местам имеет смысл когда они прояснятся — не раньше. А до этого имеет смысл применить самое простое решение из возможных.
Клиент — не в курсе что там будет. А если думает, что в курсе — то скорее всего ошибается. Разработчик, если он опытный — понимает что будет в этих мутных местах лучше клента, но тоже не владеет всей полнотой информации.Погодите — а что в этой связке делает PM? Вообще-то это как раз его задача поговорив с разработчиков и [потенцильными] клиентами нарисовать некую «картину мира», которую потом разработчики будут воплощать.
Но в любом случае слово «клиент» (один!) опять наводит на нехорошую мысль о том, что нам снова впаривают решение из совсем другого мира. Того мира где нет и никогда не будет каественных программ без глюков, того мира где нет и никогда не будет вылизанных интерфейсов. И вообще там много чего не будет. И это нормально.
Но почему эти идеи снова и снова пытаются притянуть за уши в совсем другие области?
PM он один из разработчиков. В том смысле, что он с нашей стороны команды. И если клиент сам не вполне понимает, что ему надо, то PM может решить за него. Но только если таких проектов у PM уже было много. И все они одинаковые. А если это не так, то слишком подробную картину мира лучше не рисовать — это незибежно влечёт за собой горы работы впустую.
Ну и я говорю о мире номер один. Который ширпотреб в русском варианте и Shrinkwrap в английском.
Ну и я говорю о мире номер один. Который ширпотреб в русском варианте и Shrinkwrap в английском.
Ну и я говорю о мире номер один. Который ширпотреб в русском варианте и Shrinkwrap в английском.Тогда совершенно неясно откуда взялся «клиент» и ещё более неясно почему нельзя понять чего вы хотите сделать в версии продукта номер N без ежедневных «вихляний задом».
А если это не так, то слишком подробную картину мира лучше не рисовать — это незибежно влечёт за собой горы работы впустую.Картина мира (настолько подробная, насколько получится) рисуется на один релиз. Потом собираются отзывы, проводятся исследования и выпускается следующий релиз. Так как сбор достаточного количества отзывов занимает несколько месяцев (а то и год), то всякий аджайл отпадает, уж извините. Некому там высказывать мнения каждый день или даже каждую неделю.
Клиент один, потому что он один в данный момент времени. Нельзя же разрабатывать например сайт Сбербанка для нескольких клиентов. Может быть слово заказчик тут лучше подходит.
Понять, чего хочет заказчик на один релиз ещё более-менее реально, хотя сложно. Но понять, чего он захочет в следующем релизе может только Ванга.
Когда цилы релизов долгие, с аджайлом тяжеловато, да. Но в идеале релиз можно выпускать каждый месяц, а сбором отзывов заниматься перманентно, постоянно корректируя направление разработки согласно результатам.
Понять, чего хочет заказчик на один релиз ещё более-менее реально, хотя сложно. Но понять, чего он захочет в следующем релизе может только Ванга.
Когда цилы релизов долгие, с аджайлом тяжеловато, да. Но в идеале релиз можно выпускать каждый месяц, а сбором отзывов заниматься перманентно, постоянно корректируя направление разработки согласно результатам.
Может быть слово заказчик тут лучше подходит.Тут много слов подходит. И очень мало цензурных.
Клиент один, потому что он один в данный момент времени. Нельзя же разрабатывать например сайт Сбербанка для нескольких клиентов.Если мы говорим о мире номер один? Можно и нужно, конечно. Ибо главное в [этом мире] том, что такое ПО будет установлено и будет использоваться тысячами или миллионами людей. Сколько у вашего чуда-юда пользователей — неважно: если у этих пользователей по существу нет никакого выбора, так что им придётся как-то уж с ним уживаться, то это второй мир. Ну или, может быть, Консультационное ПО, которое хотя и притворяется ширпотребом, но высокая стоимость реализации означает, что оно больше похоже на внутреннее.
Когда цилы релизов долгие, с аджайлом тяжеловато, да. Но в идеале релиз можно выпускать каждый месяц, а сбором отзывов заниматься перманентно, постоянно корректируя направление разработки согласно результатам.И что вам даст этот «сбор отзывов»? Его ещё обработать нужно. А то у вас любители Linux'а в первый приоритет попадут: они составляют 1% пользователей, причём если по деньгам взять, то, скорее всего, ещё и меньше, а вони от них столько, как если бы они составляли 90% всех посетилей какого-нибудь YouTube.
Отличие «ширпотреба» от «внутреннего ПО» в первую очередь в том, что в случае с ширпотребом вам никто не скажет — что именно вам нужно делать, это вам самим нужно определить и решить. Угадаете — молодцы, несколько раз промахнётесь — и вам уже никто не поможет, конкуренты сожрут. И вот это: «понять, чего он захочет в следующем релизе может только Ванга» — это тоже признак далего не «ширпотребного ПО». Так как заказчика нет, а есть конкуренты, то вы очень часто, чтобы выпустить хоть что-то, вынуждены отказываться от части фич. Понятно, что вот именно они и будут реализованы в следующей версии в первую очередь.
Как сказал Джоел:
Подумайте, откуда говорящий. Стив МакКоннелл, Стив Магуайр и я все из одной песочницы: мира ширпотребных электронных таблиц, написанных в Редмонде, штат Вашингтон. И у таких у нас высокая планка на лёгкость в использовании и низкая для ошибок. Большинство других гуру методологии зарабатывают свой кусок хлеба, консультируя внутренние корпоративные разработки, поэтому о них они и говорят.Аджайл — это для низкой планки на лёгкость в использовании и высокой — для ошибок, а никак не для «ширпотреба».
Рефакторинг — это не трата времени из-за недостатка времени на проектирование, это перенос части проектирования на время когда проблема уже решена.
Возвращаясь к аналогии с плотником, грязный молоток забьет гвоздь не хуже начищенного до блеска,, если не выскользнет из рук и не пробьет потолок при размахе, а грязный молоток намного легче это сделает, чем чистый.
Позволю себе цитату — мы пишем код не для компьютера а для других людей (а среди них и мы сами).
Написание кода не является работой программиста. А является ей создание приложения для решения определенных задач.
А код и приложение — это какие- то ортогональные вещи? После этой фразы читал уже по инерции. Не статья, а манифест говнокодера.
Очевидно, манифест того, кто мнит себя Системным Архитектором, свободным от написания какого-либо кода, с охенной зарплатой, а написание кода считает работой говно-кодеров, работающих если не за жрат, то за гроши => в результате имеем, что вместо одного нормального программера, программу пишут десяток говно-кодеров, а руководит ими Его Величество Системный Архитектор (три раза «ку!»), который ни хрена в коде, который пишут кодеры — не смыслит, так как считает себя выше этого => так что, получаем заваленные сроки проекта.
Мысль статьи ясна, но предпосылка совершенно неверна. Для разработчика итоговый «продукт» не входит в его сферу ответственности. В его сферу ответственности входит тот код, который он пишет. И именно он является его продуктом. А коммерческим продуктом этот код делают менеджеры, которые его продают, которые формулируют требования, которые ставят реквесты команде разработчиков и тд. Потому что им за это платят. А программистам платят за написание кода (или удаление в хорошем случае). И в общем случае бизнесу и не надо знать о рефакторингах, для него просто есть время выполнения той или иной задачи. На стыке этих сфер есть ПМ, который в курсе происходящего в двух мирах и именно он переводит с языка разработчиков на язык бизнеса и обратно, формирует сроки с учетом рефакторингов и тд, а разработчик — пусть занимается своим делом, пусть пишет код, и пусть делает этого хорошо, не надо на него вешать компетенции вне его ответственности. Хорошие границы ответственности — залог здоровой компании.
Все уже давно пережевано.
Все стандарты, паттерны и так далее — придуманы программистами для программистов, чтобы упростить работу в команде.
Все стили правильного кода придуманы для того, чтобы удешевить и ускорить работу с кодом в ДОЛГОЙ перспективе. Это никак не касается исправления бага или вводом фичи. Просто грамотная команда понимает, что лучше сразу придерживаться некоего стандарта, чем потом рефакторить. Если есть много времени/денег, можно больше потратить на красивый и читабельный код. Но это опять таки только для долгосрочной перспективы в плане поддержки и дальнейшей разработки.
Все стандарты, паттерны и так далее — придуманы программистами для программистов, чтобы упростить работу в команде.
Все стили правильного кода придуманы для того, чтобы удешевить и ускорить работу с кодом в ДОЛГОЙ перспективе. Это никак не касается исправления бага или вводом фичи. Просто грамотная команда понимает, что лучше сразу придерживаться некоего стандарта, чем потом рефакторить. Если есть много времени/денег, можно больше потратить на красивый и читабельный код. Но это опять таки только для долгосрочной перспективы в плане поддержки и дальнейшей разработки.
Но ведь код в первую очередь не столько важен для других, сколько для себя. Самому через неделю/месяц/год надо будет что-то добавить, улучшить… В конечном счете просто поддерживать. И от качества кода зависит на сколько продуктивна будет поддержка и развитие этого кода.
Для начала — понимание своего кода, и как следствие его поддержка и развитие, как мне кажется.
Если я три года назад написал приложение, какую нить домашнюю бухгалтерию для семьи, оно три года работает, и тут я понимаю что вот то, то и вооон то надо переделать вот так и так, открываю код и не понимаю в нём уже ничерта — это был плохой код.
Да, это не отменяет того, что через три года я изменю и количественно и качественно параметры написания своего кода с учетом новых знаний/практик (не учитывая Фреймворки/ЯП), улыбнусь коду трехлетней давности, и его неспешно переделаю.
Если я три года назад написал приложение, какую нить домашнюю бухгалтерию для семьи, оно три года работает, и тут я понимаю что вот то, то и вооон то надо переделать вот так и так, открываю код и не понимаю в нём уже ничерта — это был плохой код.
Да, это не отменяет того, что через три года я изменю и количественно и качественно параметры написания своего кода с учетом новых знаний/практик (не учитывая Фреймворки/ЯП), улыбнусь коду трехлетней давности, и его неспешно переделаю.
Твой код нужен — не твоему заказчику, для которого программа — как чёрный ящик, внутри которого что творится — не известно, но, зато он выдаёт нужные результаты, и код которого для него столь же интересен и понятен как для тебя зубчатые колёсики и шестерёнки внутри Rollex'а.
Твой код нужен — прежде всего тебе самому, чтобы когда тебе через N месяцев вдруг придётся, что-то доделывать/приделывать, ты смог бы с лёгкостью разобраться в коде, про который ты уже успел подзабыть как он вообще работает.
Твой код нужен — прежде всего тебе самому, чтобы когда тебе через N месяцев вдруг придётся, что-то доделывать/приделывать, ты смог бы с лёгкостью разобраться в коде, про который ты уже успел подзабыть как он вообще работает.
Расскажу историю из практики. Был я в длительной командировке в одной достаточно отдаленной стране. Писали большое-большое внедрение — проект реально без начала и без конца, но зарплату платят, все довольны. Команда была интернациональная. Индусов не было, что удивительно, но были местные бледнолицые братья. Один из них нес титул ТМ-а и неформальную роль эксперта, а фактически писал некий свой кусок, независимый от всего остального, так что в его код никто не лез.
На этом проекте были внедрены разные продвинутые практики типа парного программирования, большого экрана с красной лампочкой, которая загоралась, если падали автотесты, и т.п., а еще там проводились раз в неделю собрания по улучшению качества кода. И вот этот заграничный товарищ, который ТМ, очень занудно объяснял, как писать красивый код, чтобы функции не длиннее одной страницы, чтобы имена переменных не слишком длинные и не слишком короткие, и т.п. Лично я на одном таком собрании изо всех сил старался не упасть со стула, если совсем засну.
Потом пришло время вставлять разработку этого ТМа в CI. Он, фактически, писал вторую версию какого-то движка, который преобразовывал интеграционные запросы от внешней системы к нам. Поставили его вторую версию, и тут же начали падать автотесты. А на том проекте было заведено так: кто-то комитит — сразу запускается сборка, потом всевозможные тесты. Если тесты падают — загорается красная лампочка, при этом комитить может только кто-то из узкого круга тим лидов, которые можгут грамотно поправить ошибку. Но тут тесты падали случайным образом независимо от того, что было закомичено. Неделю разбирались — оказалось, что дело в той приблуде, которую написал ТМ. Тестов прогонялось много, и они пулялись сотнями в секунду. Первая версия этой приблуды проглатывала и не давилась, а когда поставили код ТМа — вторая версия стала падать из-за чрезмерной нагрузки. От этого валились автотесты и загоралась лампочка. Откатиться назад на первую версию было нельзя, т.к. вторая версия содержала какие-то необходимые фичи, на которых базировался код, разрабатываемый остальной командой. Экспериментальным путем выяснили, что на 4 тестах в секунду все проходит с вероятностью больше 50%. Спросили ТМа, когда он поправит ошибку — тот запросил где-то месяц.
Целый месяц работа команды была не то, чтобы парализована, но омрачалась тормозами и досадными ложными срабатываниями лампочки. Самое обидное, если лампочка срабатывала после комита из бэк офиса ночью по местному времени — бэк офис оказывался парализованным до того, как проснется кто-то из резидентов отдаленной страны и перезапустит сборку.
После той истории ТМа стали за глаза называть ТН — толстозадый нерд. Мораль сей басни такова: не столь важен код, главное, чтобы работало.
На этом проекте были внедрены разные продвинутые практики типа парного программирования, большого экрана с красной лампочкой, которая загоралась, если падали автотесты, и т.п., а еще там проводились раз в неделю собрания по улучшению качества кода. И вот этот заграничный товарищ, который ТМ, очень занудно объяснял, как писать красивый код, чтобы функции не длиннее одной страницы, чтобы имена переменных не слишком длинные и не слишком короткие, и т.п. Лично я на одном таком собрании изо всех сил старался не упасть со стула, если совсем засну.
Потом пришло время вставлять разработку этого ТМа в CI. Он, фактически, писал вторую версию какого-то движка, который преобразовывал интеграционные запросы от внешней системы к нам. Поставили его вторую версию, и тут же начали падать автотесты. А на том проекте было заведено так: кто-то комитит — сразу запускается сборка, потом всевозможные тесты. Если тесты падают — загорается красная лампочка, при этом комитить может только кто-то из узкого круга тим лидов, которые можгут грамотно поправить ошибку. Но тут тесты падали случайным образом независимо от того, что было закомичено. Неделю разбирались — оказалось, что дело в той приблуде, которую написал ТМ. Тестов прогонялось много, и они пулялись сотнями в секунду. Первая версия этой приблуды проглатывала и не давилась, а когда поставили код ТМа — вторая версия стала падать из-за чрезмерной нагрузки. От этого валились автотесты и загоралась лампочка. Откатиться назад на первую версию было нельзя, т.к. вторая версия содержала какие-то необходимые фичи, на которых базировался код, разрабатываемый остальной командой. Экспериментальным путем выяснили, что на 4 тестах в секунду все проходит с вероятностью больше 50%. Спросили ТМа, когда он поправит ошибку — тот запросил где-то месяц.
Целый месяц работа команды была не то, чтобы парализована, но омрачалась тормозами и досадными ложными срабатываниями лампочки. Самое обидное, если лампочка срабатывала после комита из бэк офиса ночью по местному времени — бэк офис оказывался парализованным до того, как проснется кто-то из резидентов отдаленной страны и перезапустит сборку.
После той истории ТМа стали за глаза называть ТН — толстозадый нерд. Мораль сей басни такова: не столь важен код, главное, чтобы работало.
«Мой код никого не интересует».
Можно немножко поспорить, мне встречались люди, которые смотрят на то, как программа написана. Некоторые из этих людей имеют к IT косвенное отношение. Зачем, спрашивается?
«Стиль и общее оформление кое-что говорят о программе». Вернее, об ея авторе.
Но в целом, да. Код никого не интересует, важно, что программа визуально работает корректно, внутри может быть сколько угодно ошибок.
Люди смотрели и смотрят на оформление, на коробку. Изучение оформления кода — примерно то же самое, те же мотивы.
Можно немножко поспорить, мне встречались люди, которые смотрят на то, как программа написана. Некоторые из этих людей имеют к IT косвенное отношение. Зачем, спрашивается?
«Стиль и общее оформление кое-что говорят о программе». Вернее, об ея авторе.
Но в целом, да. Код никого не интересует, важно, что программа визуально работает корректно, внутри может быть сколько угодно ошибок.
Люди смотрели и смотрят на оформление, на коробку. Изучение оформления кода — примерно то же самое, те же мотивы.
Как минимум, качество моего кода интересует того, кто будет с ним работать после меня
Sign up to leave a comment.
Твой код никого не интересует