Твой код никого не интересует

http://mortoray.com/2015/04/20/nobody-cares-about-your-code/
  • Перевод
Мой код никого не интересует. Я был повержен в шок, когда осознал это в процессе работы программистом. Я тратил много времени на оттачивание своего кода, пока не понял, что он никого не интересует, ведь в зачет идет не сам код, а продукт. Принятие программистом этого факта приведет к повышению продуктивности и ценности его работы.

Код — это инструмент


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

Однако, некоторые действия могут привести к ошибочному мнению, что именно код является продуктом. Например, рефакторинг: что мы улучшаем с его помощью: код или продукт? Если ответ код — ни один менеджер не даст времени на это занятие. Но стоит объяснить, что это может исправить существующие ошибки или поможет внедрить новую возможность, и, внезапно, время на это найдется.

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

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

Идея «Код — это инструмент» является причиной важности знаний нескольких языков и фреймворков; причиной пользы знаний математики и теории сложности, однако отсутствия необходимости в таких знаниях; причиной, по которой среда разработки может оказаться как замечательной находкой, так и самой страшной ловушкой. Все это является мерилом гибкости для программиста, которая напрямую зависит от разнообразия его инструментария.

Упор на характеристики


Возьмем, к примеру, встречу с ПМом или заказчиком. Что ты ему расскажешь? Сколько строк кода написано, сколько классов создано, как работают скрипты, обрабатываются исключения и как устроена база?

К сожалению, часто ответ на все эти вопросы «Да, именно это я ему и расскажу». А его лицо в это время ты видал? Ему скучно. Ему бы поскорей перейти к следующим пунктам. Эти детали не имеют для него ни малейшей ценности. Не то, чтобы он не понимал, о чем речь, его просто это не волнует.

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

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

Твоя библиотека ничего не стоит


Я часто встречаю вопросы в интернете, связанные с защитой исходного кода. Программист пишет код для заказчика и использует для этого свою личную библиотеку. И вот, клиент требует исходный код всего проекта, и программист задумывается: не хочется отдавать ценный код своей библиотеки.

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

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

Но что, если библиотека действительно ценная? Если действительно есть уверенность, что она сама может быть продуктом. Тогда можно поделиться ей, или же даже продать, может, что и выйдет. Стоит только учитывать, что очень немногие такие продукты достигли хоть какой-нибудь успешности.

Такое упражнение вообще полезно для любого программиста. Оно приводит к осознанию того, как мало других программистов интересует твоя работа. Да взять хоть даже твой собственный проект. Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?

Да, но...


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

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

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

Подробнее
Реклама
Комментарии 200
  • +31
    Типичный разговор с ПМ:
    — Что вы делали всю итерацию и почему задачи не закрыты?
    — Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.
    — Мне пофиг, почему задачи не закрыты?
    • +25
      Если задачи были критичными и нужными именно в это итерацию — программисты не правы и занимались фигнёй. Если же не были, и через пару итераций это позволит нагнать темпы — не прав ПМ.
      • +2
        Для этого и стоят статусы в задачах же, и для этого вспомогательные классы для x,y и z тоже должны быть заранее учтены в спринте. В общем, я с вами согласен :) Но не спросить, почему так вышло, тоже было бы неверно со стороны ПМ.
        • +11
          Ответ программистов в принципе неверен, более того, какой-то не программистский:)
          Корректнее такой диалог
          — Что вы делали всю итерацию и почему задачи не закрыты?
          — Что делали — писали вспомогательные классы. Почему задачи не закрыты — приоритет их закрытия был ниже (их невозможно было закрыть без написания вспомогательных классов, etc).
          ПМ не хватило прямого ответа на вопрос «почему», собственно поэтому ему пришлось его повторить.
          • +3
            Почему этих задач(вспомогательных классов) не существовало тогда? — спросил бы ПМ
            • +7
              Чем занимался ПМ если он об этом узнает только в конце итерации? Может быть ему стоило хотя бы иногда смотреть хотя бы на burn-down chart?
        • 0
          А если ПМ неправильно оценил сроки?
          А если ПМ заведомо неправильно указал сроки?
          А если из-за x продукт падал в 10% случаев, а из-за y — выпиливал базу в 1%?
          • 0
            Всё верно. Если ПМ оценивал сроки — это неправильно :)
        • +13
          — Мне пофиг, почему задачи не закрыты?
          А вот с этого момента — поподробнее: почему классов x, y и z не было в списке задач?

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

          Программирование — тут ни разу не исключение. Рассмотрите в качестве примера бухгалтерию. Если бухгалтера наняли на работу и он обнаружил, что бухгалтерия, фактически, не велась, так просто квитанции в папку подшивались, то он, разумеется, выкатит немалый счёт за «восстановление бухучёта». Но если он просто засядет и начнёт «проводить рефакторинг» не согласовав это дело с руководством, то его за это вряд ли похвалит.

          «Создание классов x, y, и z» всегда должно выводиться из реальных задач. И исходя из потенциальной важности решения этих задач менеджер уже и решит — стоит ими заниматься или нет. А если вы не можете придумать ситуацию, когда ваши вспомогательные классы чему-то помогут — то зачем они вообще нужны?
          • +5
            Если бы ПМ-у можно было объяснить зачем в программе конкретные классы, он был бы не ПМ, а ТимЛид и ПродуктОунер. В реальности почти никакому ПМ-у и почти никогда не хватит квалификации чтобы понять какие классы есть в его продукте и почему должны быть именно они. Причём квалификации не хватит раз в 8, где-то.

            Если ПМ, этого не понимает, а в примере выше он этого, очевидно не понимает. Значит он неквалифицирован не только как ПМно и как менеджер и всю оставшуюся жизнь вынужден будет писать на Хабре обиженные комментарии на программистов жаловаться, что что-то пошло не так. Потому что так как надо у него никогда не пойдёт. Разве что случайно, если у проекта по недосмотру появится лид и оунер, который вытянет проект вопреки ПМ-у.

            Суровая такая вот правда жизни.
            • +2
              ПМ не должен понимать зачем в программе конкретные классы, он должен:
              1) контролировать приоритеты и выполнения задач (для этого не нужно ничего понимать в программировании),
              2) на ответ " Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.", должен задать вопрос какие именно задачи и на сколько в будущих итерациях эти «вспомогательные классы» должны ускорить разработку. И отсюда уже делать вывод от «ребята молодцы, сократили мой план на итерацию 10 на две недели» или «какого фига вы потратили месяц на фраймворк сортировки бабочек, если мы никогда ими не будем заниматься»

              То есть хороший ПМ, совершенно не разбирающийся программировании, может прекрасно рулить техническими задачами исключительно из КПД полезности (текущей и будущей).
              • 0
                К сожалению почти всегда менеджер не понимает почему плохое решение в коде что-то замедлит и когда оно это сделает, а программисты не имеют возможности улучшение кода менеджерам продать. Как потому, что плохо умеют это делать, это вообще-то не входит в круг их прямых обязанностей, так и потому что ПМ их просто не слушает в этой части.

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

                Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию — мне кажется далеко за пределами возможностей не только ПМ-а, но и вообще человека. Грубо говоря Бест-практикс по архитектуре именно потому и являются бест-практикс, а не получаются каждый раз заново методом анализа КПД по планам, что никто, даже самые круты чуваки из GoF не смогут вам такой план составить. Вот, собственно поэтому GoF пропагандировали паттерны, и Фаулер рефакторинг.
                • 0
                  Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию — мне кажется далеко за пределами возможностей не только ПМ-а, но и вообще человека.
                  Надо понимать, что в большинстве случаев эффект от «вспомогательных классов» разработчик будет завышать, а время на их разработку — занижать. И если он даже в таких, «тепличных» условиях не может «заглянуть в будущее» настолько далеко, чтобы показать, что от его действий будет какая-то экономия, то, стало быть, все эти действия точно никакой экономии не несут и, соответственно, бессмысленны. Если хотя бы теоретически что-то такое вырисовывается — тогда можно уже и обсуждать сценарии.

                  Иногда, правда, можно дать возможность людям делать то, чего они хотят просто, чтобы поддержать уровень морали, но тут надо тоже меру знать.
                  • 0
                    Про меру согласен. Про не несут — не согласен.
                    Сейчас, например, переделываем ядро одной игры, как раз потому что предыдущие кодеры наделали… Со строгим соблюдением сроков в первой части проекта. Закладываюсь на то что в игре будет резво добавляться правил и геймплея и под это код, котоырй управляет моделью данных более сложен и содержит возможности для быстрого увеличения количества правил и варианта геймплея в разы. Однако когда дойдёт до дела хрен его знает как повернётся, может они с геймплеем будут активно вяло экспериментировать, а со статистикой и рекламой активно. тогда половина наших наворотов останется не у дел. Сейчас этого не знают ни они, подвязавшиеся ждать когда эта архитектура будет, ни мы, взявшиеся её делать. Но если будут с геймплеем экспериментировать — экономия будет о-го-го.

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

                      Тем не менее, вы же вполне можете объяснить: если будет сценарий 1 мы сэкономим столько-то времени, потратив сейчас столько-то, а если сценарий 2 то столько-то и столько-то. Вообще, ПМ'а как раз с вероятностями пи рисками должен работать по хорошему (вероятность, что разработчик поссорится с женой и его работоспособность резко упадет, вероятность что пол команды решит уволиться, вероятность что заказчик вообще не захочит платить за сделанную суперфичу.)
                      • 0
                        Очень сложно предсказать такого рода экономию точно. То есть, опытному программисту очевидео, что одно решение приведет к проблемам в будущем, а другое — нет. Это скорее личный опыт и интуиция, нежели строгие расчеты и теорвер.
                      • 0
                        Закладываюсь на то что в игре будет резво добавляться правил и геймплея и под это код, котоырй управляет моделью данных более сложен и содержит возможности для быстрого увеличения количества правил и варианта геймплея в разы.
                        Ну вот вы и привели некоторое обоснование. Добавить сюда пару цифр — и можно говорить с PMом.

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

                        Будущего не может знать никто, это понятно, но если вы не можете привести обоснование для вашей деятельности в терминах предметной области (не в «в среднем размере функции» или, прости госсподи, в «проценте покрытия тестами», а во «времени на изменения одного правила» или в «цене создания нового монстра») — то это значит, что обоснования у вас нет.
                      • +2
                        Холивар, но все же.

                        === По поводу менеджера:
                        Плохой прожект менеджер это такой прожект менеджер, который как раз не дает писать «дополнительные классы». Это рано или поздно заваливает проект и он сходит с рельс. Прожект менеджер должен знать где требуются архитектурные решения, а где требуются 2 гвоздя с доской. Если он не знает, а думает только метриками типа «отлично сэкономим, тут — ну вы же сказали же да?», то надо его садить либо на аутсорс, либо куда подальше.

                        Все другое мол это «никого не интересует» в топку обиженных ПМ-ов. Смотря на каком уровне и для кого, все это интересует.

                        А вообще очень важно, что бы на каждом уровне были профессиональные и мотивированные люди, а схема взаимодействия плоская, а не древовидная во главе с Боже упоси ПМ-ом. А с ПМ-деревом все вокруг покроется убогими досками, и все сгниет на корню.

                        === По поводу девелопера
                        Девелопер действительно должен понимать, что код для кода это бессмысленно. Главная задача решить задачу с возможностью масштабирования кода на одну-две итерации вперед, кроме выраженных конечных случаев где такое масштабирование не будет (забить досками). Соответственно, если по этому коду масштабирование все же требуется произвести, то будет дополнительный оверхеад на переработку архитектуры, о чем разработчик должен уведомить менеджера — мол мы это забили досками, поэтому надо надо сломать и забетонировать.

                        === Резюмируем
                        Самый первый комментарий это гнилой базар ПМ-а. Потому что разработчик сказал, что он делал. ПМ должен разобраться и направить в нужное русло, а не вонять.
                        • +1
                          Прожект менеджер должен знать где требуются архитектурные решения, а где требуются 2 гвоздя с доской.
                          Не совсем так. Его задача скорее помочь разработчикам перевести требования задачи, сформулированные в терминах предметной области на требования к коду и наоборот.

                          Потому «Мне пофиг, почему задачи не закрыты?» — это, конечно, отвратительный PM. Сходу говорить о том, что раз мы об этом не договаривались, то и делать ничего такого не нужно — это признак двойной некомпетентности. Просто потому что он чего-то упустил: если команда занималась не тем, чем планировалось заниматься, то это, во-многом его вина.

                          Нет, всё возможно: бывает так, что вся команда (особенно небольшая) учиталась очередной новомодной книжкой и какую-то фигню творит, но так бывает всё-таки не слишком часто. Обычно если уж какие-то вспомогательные классы создаются, то тут есть какая-то цель и задача PM'а — понять что это за цель, нужна ли она нам и т.д. и т.п. Иногда стоит эту деятельность и прекратить, но сразу «мне пофиг» — это неконструктивно. Вообще позиция «все кругом идиоты, а я один — д'Артаньян» не очень конструктивна.
                          • 0
                            Ну. Как-то так. Да.
                        • +1
                          Давайте проведём мысленный эксперимент. Дано:
                          Вы в коде сделали сортировку пузырьком, но не так и не там. У вас есть варианты:
                          — Оставить как есть и всё. В следующий раз написать с нуля
                          — Оставить как есть и запомнить где. В следующий раз найти, откопипастить и исправить существующий код. Коллеги сами пусть мучаются.
                          — Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.
                          — Вынести во вспомогательный класс, класс вынести в отдельную библиотеку, Написать документацию.
                          — свой вариант

                          Как вы заглядываете в будущее и показываете полезность метода N, если начальство при любом раскладе смотрит на вас уставшим взглядом и говорит «да ну, когда ещё сортировка нам пригодится»?

                          Тот же вопрос по прошествии года, когда в коде уже 12 сортировок пузырьком, а начальство по-прежнему смотрит на вас уставшим взглядом и говорит «да ну, теперь то ещё сортировка нам точно не пригодится»

                          Проходит ещё год, сортировок уже 150, но больше доделок ну вот совсем не планируется. Ну может быть вот ещё последняя, но точно последняя.
                          • 0
                            Как вы заглядываете в будущее и показываете полезность метода N, если начальство при любом раскладе смотрит на вас уставшим взглядом и говорит «да ну, когда ещё сортировка нам пригодится»?
                            Ответ на это люди дали сотни лет назад. «То что случилось однажды, больше может никогда не случится, но то что случилось дважды, обязательно произойдёт в третий».

                            Только не нужно всё воспринимать догматично. Скажем переход на новую архитектуру процессора происходит-таки регулярно (в соответствии с пословицей), но происходит это примерно раз в 10 лет в среднем, так что для большинства проектов это то, что «больше никогда не случится».

                            Так что ждать пока появится 150 сортировок не стоит, но и выделять что-то в отдельный модуль не имея двух-трёх точек, где оно используется — тоже не стоит. Оптимальное число, пожалуй, всё-таки как раз три а не два: вам нужно продумать интерфейс, а практика показывает что два варианта использования таки маловато. Вообще чем больше мест где ваш модуль будет использоваться тем проще спроектировать его интерфейс — но и тем сложнее все места переделать.
                            • 0
                              Практика показывает, что
                              1) на большом проекте люди не в курсе, что эта копипаста и вообще где-то есть ещё, поэтому каждый раз — второй.
                              2) 2 одинаковых копипасты не бывает. Их нельзя просто взять и обобщить не пойдя, как минимум, по третьему варианту.

                              А в мысленном эксперименте я специально не сделал опции «2 места» или «3 места». У вас есть или одно место, которое абстрагировать не за чем. Или дюжина, которые обобщать долго и дорого. Или совсем задница.
                              Как это получилось — не суть важно (те люди тут уже не работают).

                              Но вам надо с этим жить, пока начальник с тем же усталым видом говорит «Только не нужно всё воспринимать догматично».
                              • 0
                                1) на большом проекте люди не в курсе, что эта копипаста и вообще где-то есть ещё, поэтому каждый раз — второй.
                                В этом случае вам уже ничего не поможет. У вас будет либо 150 сортировок пузырьком «по месту», либо 150 (ну хорошо, пусть 100) сортировок, каждая из которых разработана так, как если бы она была «последней и окончательной реализацией сотрировки пузырьком».

                                И из этих двух вариантов первый — гораздо лучше. Ибо в смысле поддержки он примерно столь же ужасен как и последний, но времени на его разработку и на работу с ним уходит меньше. А после налаживания взаимодействия между командами и людьми вы можете выделить-таки время на рефакторинг и реализовать одну «самую правильную» версию сортировки тоже будет проще (заменить реализацию «по месту» на вызов универсальной реализации обычно проще, чем объединять «универсальные реализации», так как в реализации «по месту» есть только то, что конкретно в этом месте нужно, а в куче «универсальных реализаций» обязательно найдётся куча фич, которые непонятно как реализовать в одной «универсальной реализации»… и которые, в общем-то никому нафиг не нужны).

                                2) 2 одинаковых копипасты не бывает. Их нельзя просто взять и обобщить не пойдя, как минимум, по третьему варианту.
                                Вот потому я и предлагаю ваш «универсальный класс» писать после появления третей реализации. А для того, чтобы этот момент заметить при копировании кода из одного места в другое в обоих местах нужно добавить комментарий, объясняющий, где находится второе место. Ну или если случай простой, то вместо копирования можно уже на втором разе выделить общий класс, описать его интерфейс и т.д. и т.п.

                                Как это получилось — не суть важно (те люди тут уже не работают).
                                В таком случае нужно это обсудить с теми, кто работает и, возможно, даже переписать заново пару компонент.
                                • 0
                                  > В этом случае вам уже ничего не поможет.

                                  Я же с этого начал, «Вынести код в отдельный метод, внятно назвать. В следующий раз удобно будет найти и откопипастить, даже коллегам.»

                                  > А после налаживания взаимодействия между командами и людьми вы можете выделить-таки время на рефакторинг

                                  Не могу, ибо «все эти действия точно никакой экономии не несут и, соответственно, бессмысленны» пока не доказано обратное.

                                  > Вот потому я и предлагаю ваш «универсальный класс» писать после появления третей реализации.

                                  Ну не то, что бы плохое предложение. Спорить я не буду. Я повторю, что кейса «после третьей» в мысленном эксперименте нет. Совсем. Я не спрашивал «когда надо писать».

                                  > вместо копирования можно уже на втором разе выделить общий класс, описать его интерфейс и т.д. и т.п.
                                  > возможно, даже переписать заново пару компонент.

                                  Нельзя, ПМ рефакторинг не одобрял. Обоснуйте экономию?
                                  • 0
                                    Нельзя, ПМ рефакторинг не одобрял. Обоснуйте экономию?
                                    Да раз плюнуть. По условиям задачи у нас уже есть 150 (да пусть даже 12) мест, где эта самая сортировка пузырьком используется. Берём историю проекта, грубо оцениваем сколько таких мест мы порождаем за год, дальше смотрим сколько времени уйдёт на рефакторинг, сколько мы получим от того, что нужно будет вместо XX строчек кода поставить один вызов функции, получаем экономию. COCOMO вам в помощь.

                                    Вот как раз перевод существующего кода на новый интерфейс — тут сложнее, может оказаться, что «овчинка выделки не стоит».

                                    А если обоснование «не срастается» (то есть никак не вытанцовываетя экономия даже при самых оптимистичных допущениях), то вы не поверите, нужно-таки оставить эти сортировки в покое и не париться.
                                    • 0
                                      1) Если игнорировать грустный взгляд ПМ и его слова о YAGNI, то вы обосновали «сделать функцию», но не «рефакторинг старого».

                                      2) Любая новая копипаста не имеет истории и к ней такой подход не применим.

                                      3) Я могу сделать достаточно оптимистичные допущения, что бы срослось.
                                      • 0
                                        1) Если игнорировать грустный взгляд ПМ и его слова о YAGNI, то вы обосновали «сделать функцию», но не «рефакторинг старого».
                                        Истинная правда — и более глубокая, чем вам кажется. Действительно — решить нужно ли переводить существующий код на новую функцию куда сложнее.

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

                                        3) Я могу сделать достаточно оптимистичные допущения, что бы срослось.
                                        Но сможете ли вы убедить в них PM'а? Учтите, что ведь по окончании работ он будет иметь возможность сравнить то, что вы обещали с тем, что реально получилось…
                                        • 0
                                          > и более глубокая, чем вам кажется.

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

                                          > В первом приближении любая новая копипаста устроена так же, как и все предыдущие, для грубой оценки большего и не нужно.

                                          Вы опять не туда. Без разницы как она устроена, её никто не поддерживал, нет статистики.

                                          > Но сможете ли вы убедить в них PM'а?

                                          То есть вы тоже не можете, понял. Мысленный эксперимент на этом и закончим.

                                          > И если он даже в таких, «тепличных» условиях не может «заглянуть в будущее» настолько далеко, чтобы показать, что от его действий будет какая-то экономия, то, стало быть, все эти действия точно никакой экономии не несут и, соответственно, бессмысленны.

                                          Это чушь, вы никогда скептически настроенного ПМ не убедите в эффекте и это путь в никуда.
                                          Не скептически настроенный ПМ всё равно проверять не полезет.
                                          Да и невозможно проверить эффект на достаточно длительном промежутке (или ишак, или падишах)
                            • 0
                              А ещё в каждой из реализации Баги. Причём в каждой разные.
                          • +1
                            Вместо этого он находит промежуточное звено, ну или выделяет это промежуточное звено из имеющихся у него программистов, и делает из него крайнего за принятие и обоснование таких решений.

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

                            Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию

                            Почему в точности? ПМ должен хотя примерно представлять что ждет проект и прикидывать вероятность пользы и успеха. Из разряда:

                            — Давайте мы построим кран?
                            — А нафига? Мы же строим пятиэтажку.
                            — Ну, если а вдруг заказчик захочет построить небоскреб, это сильно нам потом время сэкономит.
                            — Не, ребят, небоскреб он точно не захочет, у него боязнь высоты.
                        • +13
                          У меня 12 лет программерского стажа. И я с вами не соглашусь в корне :)

                          ПМ не должен знать технических деталей. Вы (команда) — ответственная и автономная единица (до первых косяков). Если команда решает подзабить на план и порефакторить — то менеджер автономность будет убирать и будет микроменеджить девелоперов, «как пастух своих овец», извиняюсь за аналогию. Вам это надо?

                          Интересно, как обрадуется команда, если ПМ решить невыдать всей команде бонус, т.к. потратит его, например, на покупку растений в офис, где работают девелоперы. И когда люди начнут приходить с вопросами, он скажет (например): «Ребят, у вас теперь среда какая комфортная. Это важно для вашей будущей работы, что бы дышалось хорошо и это окупиться в будущем вашим здоровьем и настроением».

                          Вот интересно было бы послушать реакцию девелоперов :) И если эта реакция будет отличная от: «конечно, все верно, молодец ПМ!», то следует ли из этого делать вывод, что команда — необразованная и непонимает важности комфортной и разряженной рабочей среды для коллектива? :)

                          Суровая правда жизни, что программеры забивают на ПМа, считая, что уменьшение technical debt важнее, чем delivery. Поэтому и плодятся у нас говноотношения между менеджерами и девелоперами.

                          Последние несколько лет я работаю в командах с налаженной коммуникацией. Если нужно заложить время на улучшение кода или его изменение в пользу стабильности, масштабируемости и прочего, это обсуждается девелоперами еще до планирования этапа (внезапно возникла необходимость переписать полпроекта? харош...). На планировании это выносится на повестку с аргументированием, почему это важно (надеюсь, не будет вопроса «чтоооо? еще и аргументировать ему надо? да он необразованный, раз не понимает»… может быть, вы сами не образованы, если не можете аргументировать необходимость чего-то бизнесу?).

                          Я еще ниразу не встречал ситуации, когда менеджеру сообщалось бы: «нам нужно провести оптимизацию/рефакторинг, и это очень важно для проекта, т.к. нагрузка на продакшн сервере уже превысила 70%, и если мы не возьмем это в этап, на следующей неделе наш продукт ляжет и мы потеряем клиентов и деньги», и менеджер в ответ говорил бы: «нет, в этап берем только новые фичи» :)

                          Я еще ниразу не встречал ситуации (по крайней мере, с компетентными девелоперами), которые встретив препятствие вчера не сообщили бы о нем команде сегодня и если препятствие не устранено — менеджеру к концу дня, что бы он понимал риски по реализации той или иной задачи. И что бы менеджер после этого спросил с команды — «мне пофиг, почему задачи не выполнены»…
                          • 0
                            Квалифицированный ПМ совершенно не должен понимать, зачем нужен каждый конкретный класс в программе. Его задача — обеспечивать общий ход работ и коммуникации. Есть в команде архитектор системы, есть тимлиды/сеньоры, они и решают, где там быть дополнительным вспомогательным классам. Задача ПМ'а (если он сам не выходец из их кругов) — консультироваться с экспертом в соответствующей области, и принимать решения по советам эксперта. Но если тимлид необходимость этой вспомогательной задачи не обозначил, а программист «проявил инициативу», и вместо данного ему тасклиста занялся украшением архитектуры, то ПМ вполне резонно даёт ему по шапке. В самой инициативе нет ничего плохого, наоборот, это замечательно… но она должна выглядеть как-то так: программист подходит и говорит: «Вот есть такая потребность/идея, с ней будет вот так-то хорошо, без нее будет вот так-то плохо, но она потребует дополнительно столько-то времени». А ПМ говорит: «Ок, это правильно, делаем». Или говорит: «Да, это было бы неплохо, но если мы выкатим продукт без этой штуки, то продажи стартуют на неделю раньше».
                        • +1
                          Договороспособность и взаимопонимание менеджера и команды стремиться к 0. Как они вообще проекты выпускают? Почему им насрать друг на друга? Откуда такая сценка — фантазии или быль?
                          И что хотел узнать менеджер своим вопросом, если получения ответа все равно его задает?

                          Уровень коммуникации как у каких-то барыг из фильмов. «Где мой товар?»
                          • 0
                            И действительно. Почему задачи не закрыты?

                            — Работа по вспомогательным классам для x, y и z была включена в этап? Если нет, то почему вы этим занимались в ущерб этапа?
                            — О том, что вместо работы над задачами, вам необходимо было делать что-то другое было ли сообщено кому-то (ПМ-у)? Если нет, то на что жалуемся, где закрытые задачи?
                            — Когда пришло понимание того, что задачи этапа не будут выполнены? Только в последний день этапа протяженностью в месяц? Да что за бред.

                            Действительно, описанный диалог довольно типичен у нас. Он бы не состоялся (точнее, состоялся бы подругому), если бы в команде была бы хорошая коммуникация.
                            • 0
                              Если вам не нравится это — смело уходите. Зачем терпеть это?
                            • +46
                              Мой код никого не интересует.

                              Мой код интересует команду в которой я работаю, так же как и меня интересует их код.
                              • +1
                                В реальности это слишком маленькая аудитория, и в большинстве случаев к сожалению куда важней фактор быстрого завершения задачи.
                                • +2
                                  Потому что у вас кодобаза общая. если 1 из команды работает, допустим, над серверной частью, а другой над клиентской. то как написал тот товарищ волновало бы вас мало. вы туда никогда не полезете, главное чтоб не падало и отвечало заявленному АПИ
                                  • 0
                                    А в обратной ситуации очень бы даже волновало, еслиб быстронаписанный код выпадал по таймауту на половине запросов от клиента(негуманный поиск или сортировка, однопоточные запросы к сторонним апи, что угодно) и Вам пришлось бы весить на это костылики.
                                    • –3
                                      Вам было бы легче, если бы падал хорошо написанный код?
                                      • +2
                                        Упасть может любой код. В хорошем коде просто баг правится и правится быстро, скорее всего. Если код плохой, то исправляться, как заметил tenoclock, это будет скорее всего костылём, который в добавок вполне может спровоцировать ошибку в другом месте.
                                        • +2
                                          На самом деле, плохой код вызывает и плохие ошибки. То что в хорошем коде просто выкинет понятный exception сразу как произойдет ошибка, в плохом может привести к незаметному игнорированию ошибок, блокировкам, зацикливаниям, утечки памяти, падению производительности, а то и повреждению данных.
                                        • +3
                                          Конечно, так как хорошо написанный код:
                                          1) легче исправить,
                                          2) проще отладить,
                                          3) в конце концов, он просто не падает на глупых вещах (и падения не приводят к катастрофическим последствиям), запутанный плохо написанный код без всякого тестирования легко может содержать баги вроде полного удаления базы на продакшене, а вот в хорошо написанным коде такие вещи легко видно невооруженным глазом.
                                          • 0
                                            Вы, как и остальные минусующее, забываете мой изначальный тезис. Вы используете некий сторонний продукт, пусть даже созданный в вашей компании, который удовлетворяет вас по параметрам Стабильность и Функциональность. Я не знаю почему в этой ситуации вас должно беспокоить как это написано.
                                            • 0
                                              Даже если сторонний продукт, я пишу на Java и один из самых главных плюсов — ты можешь открыть любую стороннею библиотеку/продукт, в которой случилась ошибка, и посмотреть что там произошло. Много раз таким образом находил причину ошибок, пару раз отправлял pull request в эти сторонние библиотеки, пару раз разобрался с недокументрованными возможностями, например, монги, иногда делал форки и создавал свои собственные реализации библиотек в которых исправлял ошибки.
                                              Но плохой код все это осложняет в десяток раз.
                                    • 0
                                      прибыль вашей компании складывается не от продажи кода, а от вашего продукта. Все что вы пишите кроме ваших внутренних участников процесса ни кого не интересует.
                                      • +1
                                        Не совсем так, продукт должен быть соответствующего качества. Скажем, за одну ошибку в ПО космической ракеты компания может просто разорится. Да, можно добиться нужного качества на самом ужасном коде, но намного легче выйти на нужное качество при определенном уровне качества кода.

                                        Понятно сам по себе «красивый» код нафиг никому не важен, но если он ускорит разработку, облегчит поиск ошибок или сопровождение, то он вполне себе принесет прибыль. Грубо говоря если на стройки работают одни джамшуты в худшем смысле этого слова, то она легко может оказаться «золотой» при приемке дома. С другой стороны, на строке никому не нужны и великие гении-художники, которые десять лет будут шедевральный кафель класть в одной комнате.
                                        • 0
                                          Сказать про ракеты ничего не могу, кого там что волнует) в любом случае полёт это цель. Качество совершенно сложное определение… Ну вот wordpress продукт качественный или говнокод? И да и нет.А битрикс? Ясно одно — его цель это популярность и она огромна.
                                          Можно до посинения ругаться на его говнокод но никого это не волнует, кроме горстки гениальных программистов на гране нервного истощения. Там такое комьюнити что любой говнокод перекрывается двумя щелчками мышкой. Где там качество как скажут многие? Замените это слово на «спрос» и многое станет понятно.
                                          Идеально можно переписать продукт который уже умер и с ним уже ясно как нужно было его писать.
                                          До тех пор пока в команде существует некий дух, говнокодный продукт будет продолжать существовать и всегда как то находить решения и продолжать развиваться и переделываться.

                                          Скорее всего вы говорили не о качестве а о неком духе связывающих вас и ваших коллег.
                                          • 0
                                            Скорее всего вы говорили не о качестве

                                            Именно о качестве. Понимаете при серьезной разработке, есть и серьезные уровни качества — критическая бага и штраф в десятки тысяч долларов.
                                            Качество совершенно сложное определение…

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

                                            Да, в ряде случаев маркетинг может продвигать некачественный продукт, как например Internet Explorer, но рано или поздно функции и качество другого продукта возьмут свое над маркетингом и рекламой.

                                            Поверьте, качество кода напрямую влияет и на скорость разработки и на качество и на простоту поддержки.
                                            • +2
                                              Да, в ряде случаев маркетинг может продвигать некачественный продукт, как например Internet Explorer
                                              Вот только не нужно на Internet Explorer баллоны катить. Там были вбуханы безумные деньги в разработку и в те времена, когда он занимал 90% рынка он был, вполне себе объективно, лучшим браузером. Это потом, когда его развитие было заморожены на годы (до версии 6 каждый год выходило по версии, а версия 7 вышла через 5 лет и была очень-очень слабым изменением по сравнение с MS IE 6) он стал «притчей во языцах».
                                              • 0
                                                а версия 7 вышла через 5 лет и была очень-очень слабым изменением по сравнение с MS IE 6

                                                ну, хорошо в ряде случаев маркетинг может продвигать морально устаревший на годы продукт, как например Internet Explorer, но рано или поздно более качественный и современный продукт возьмет свое
                                                • +1
                                                  А про более качественные продукты узнают без маркетинга, что-то я сомневаюсь что хром обошел бы даже сафари будь за ни не google.
                                      • +6
                                        К слову код интересует людей очень сильно в одной области уж точно — opensource.
                                        • 0
                                          Полностью согласен. В OpenSource проектах очень даже интересует.
                                          Сразу становится понятно какое количество боли будет вызывать использование той или иной OpenSource библиотеки.
                                          • +2
                                            Болтовня бесполезна. Покажите мне код.

                                            (с) Linus Torvalds 2006
                                        • –1
                                          Браво!
                                          • 0
                                            Согласен. А если грамотно «продавать» необходимость обслуживания кода и уменьшение technical debt бизнесу, то и «его» будет интересовать твой код, т.к. он позволит снизить расходы на его поддержку в будущем, время на поиск и устранение проблем (уменьшенеи расходов), ускорить процесс разработки новых фич (опять же, выливается в уменьшенеи расходов), уменьшит риск отвала клиентов из-за нестабильности приложения и т.д.
                                            • 0
                                              Более того, проблема бизнеса здесь заключается в том, что хороший программист хочет работать с приличным кодом, а если бизнес не рассчитывает на перманентную оплату технического долга, то часто он не может рассчитывать и на приличных наемных рабочих, которого, что не удивительно, в первую очередь беспокоит его комфорт и благополучие. Конечно, можно платить таким сотрудникам втридорого, но на мой взгляд проще всё же учитывать не только необходимость бизнеса в фичах, но и потребность программиста в приличном коде. Ведь работодатель как-то пытается сделать офис соответствующим ожиданиям работников, почему же он не должен делать то же с кодом?
                                            • +1
                                              … со следующего уровня абстракции. :)
                                              • +7
                                                Если программист работает над проектом один (а статья как будто бы и писалась под такой случай), то его код может не интересует никого. А когда в команде, ваш код, думаю, еще как заинтересует ваших коллег, ведь им его и поддерживать.
                                                • +16
                                                  Ваш код заинтересует вас тогда, когда вы начнете его поддерживать. Или когда нужно будет внести модификации. Читайте Фаулера, батенька.
                                                  • +5
                                                    Я вижу, большинство не согласно с автором) (не забывайте, что автор не я)

                                                    Конечно, нельзя писать код абы как (об этом тоже есть в статье), но основная идея в том, что не надо ставить код во главу угла, так как главное — проект
                                                    • +2
                                                      Это не взаимозаменяемые понятия.
                                                      • +2
                                                        Это скорее не несогласие, а протест. Вы же видите комментарии,
                                                        очень многим не хватает просто признания в своей работе как и мне. Многих программистов статья вообще не колышит. У них завидный экшн))
                                                        • 0
                                                          В статье, грубо говоря, выстроена аргументация, что строитель должен думать о строящемся доме, а не об укладке кирпичей. Лично мне это кажется абсурдным. Второе — неотъемлемая и важная часть первого. Программист должен думать о коде, и стараться писать качественный код, и думать о выполнении поставленных задач, и о конечной цели думать, и о жене вечером должен думать. Много о чем думать, в общем. Поэтому к чему автор выстроил весь этот антагонизм кода и проекта, мне непонятно.
                                                        • 0
                                                          Пост читали?

                                                          Это что, значит, можно писать отстойный код? Нет, не значит.
                                                        • +3
                                                          Странная статья. Такие резкие утверждения, которые потом чуть ли не сам автор опровергает. Ваш код может никого не интересовать пока не придёт новый человек и вас не уволят за говнокод, с которым ничего нельзя сделать. Просто не надо (не всегда) заморачиваться на идеальности кода.
                                                          • +2
                                                            За говнокод не увольняют, а оставляют в наказание исправлять. Ведь больше никто не справится.
                                                          • +23
                                                            В целом большинство моментов справедливы, но аналогия неправильная:
                                                            Так же как работа столяра не заключается в использовании молотка или пилы — она заключается в производстве чего-либо при помощи этих инструментов.
                                                            Инструменты: молоток и пила — IDE и компилятор. А качество кода — это качество дерева. Если дерево гнилое, то результат работы столяра сломается при первом же прикосновении.

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

                                                            Получение материала с теми или иными свойствами — вот это и есть мастерство.

                                                            Поэтому и заказчику или кому бы то ни было нужно не показывать сколько строк написано (сколько дыр просверлено или как гладко отполировали), а объяснять, что отшлифовали те и те детали, и сумели сделать сложное отверстие таким образом, что деталь теперь одна цельная, а это значит, что двигатель сможет нормально работать и не взорвется на презентации.
                                                            • 0
                                                              Хотел тоже написать про неправильную аналогию кода с инструментами, но увидел ваш комментарий.
                                                              Я бы провел аналогию кода со строящимся домом. Если у дома плохой фундамент — то и качество, и характеристики, и эксплутационный срок всего дома плохие. Или если технология возведения стен не соблюдена (каким бы хорошим не был материал), или допущены серьезные ошибки, то и здесь аналогично…
                                                            • +10
                                                              1. ты просто пишешь программы. Как умеешь.
                                                              2. начинаешь глубже изучать язык, пробуешь внедрять новые штуки.
                                                              3. для каждого случая находишь наиболее правильное решение, соответствующее паттернам из GoF, рекомендациям Фаулера, Мартина и других правильных пацанов.
                                                              4. Ты просто пишешь программы. Как умеешь.
                                                              • +3
                                                                1. ты просто пишешь программы. Как умеешь.

                                                                4. Ты просто пишешь программы. Как умеешь. Но это другие программы.
                                                              • +1
                                                                Ваш код должен интересовать в первую очередь самих вас, ведь вам с ним работать и вам его поддерживать. Самомотивация должна присутствовать в любом деле.
                                                                • 0
                                                                  Я тоже думал, что мой код никому не интересен. В комментариях оставлял «коаны программирования».
                                                                  А потом весь тех отдел лежал в истерике, когда на них наткнулись.
                                                                  • +7
                                                                    >> Например, рефакторинг: что мы улучшаем с его помощью: код или продукт? Если ответ код — ни один менеджер не даст времени на это занятие.

                                                                    Вот именно по этому менеджеры никогда не должны ставить задачи разработчикам. Это должен делать только тим-лид, знающий матчасть.
                                                                    • 0
                                                                      Тимлид как правило не имеет права самовольно расходовать труд.ресурс без санкции рук.проекта.
                                                                      • 0
                                                                        Грамотный ПМ ещё как даст.
                                                                        • +2
                                                                          И да и нет.
                                                                          У грамотного ПМа будет тим лид которому он доверяет и который проверен временем. Все технические аспекты он будет делегировать ему. ПМ должен заниматься стратегией, тактикой, бюджетом и договорами и решением споров команды и заказчика. Если в проекте agile, то роль ПМа сводится именно к этому. Все коммуникации с заказчиком будут лежать на команде и тим лиде.
                                                                          Если тим лид для ПМа новый, он не даст санкции на расход ресурсов. Он будет контролировать чтобы убедится в отвественности и грамотности тим лида.
                                                                          Если ПМ доверяет тим лиду, а тим лид доверяет команде, то всё будет нормально с проектом. И понимать все друг друга начнут. И отвественность разделять. И программисты не будут гнуть свою линию, и причёсывать код в ущерб срокам. Все эти действия должны быть согласованы. В первую очередь с ПМом, так как он первый кто несёт отвественность за сроки и бюджет.
                                                                      • +2
                                                                        А я согласен с автором, как это не прискорбно. Всегда хочется усовершенствовать, попробовать приделать что-то новое, или перейти с какого-нибудь angular 1 на 2 для этого переписав все к чертям, но реальной пользы для достижения конечной цели от этого будет немного, и оправдать ее получится только будучи программистом. По этому и делают проекты на всяких там wordpress.

                                                                        Но черт возьми без, а давайте перепишем вот здесь, работа скатится в унылое…
                                                                        • +2
                                                                          Обычно с PM'ом можно уточнять, как следует сделать: «на совесть» или «как попало».
                                                                          • +1
                                                                            И часто ПМ берет на себя смелость ответить «как попало»?
                                                                            • +6
                                                                              Хороший ПМ — да. (И это отличный метод отличить труса, перекладывающего свою ответственность на команду, от хорошего тимлида). Хороший может ответить «мне нужно сейчас наговнякать к завтрашнему утру, а потом будем уже разбираться можно это сделать, нет, и если да, то насколько хорошо».

                                                                              Ведь чуть ли не половина гениальных идей «надо сделать» часто оказываются нужны один или два раза.

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

                                                                              Разумеется, это требует хорошего отношения между PM и командой. Но в его отсутствие, как процесс не назови, всё равно будет плохо, не то, и медленно.
                                                                              • +6
                                                                                У нас не раз было как-то так:
                                                                                — Нам нужно наговнякать за месяцок прототип, посмотреть, может ли оно взлететь вообще. Потом переделаем хорошо.
                                                                                (через месяц)
                                                                                — Значится так, прототип уже летает и мы его продали с допфичами, поэтому никаких вам переделать, а пилить допфичи.
                                                                                В ответ на трепыхание разрабов менеджеры говорили словами из этой статьи :(
                                                                                • +2
                                                                                  Нет коммуникации между PM'ом и программистами. Либо PM плохой, либо он нанял плохих программистов. Либо, если он не контролирует HR-политику, то работают они вместе в хреновой конторе. Обычное дело такое.
                                                                                  • 0
                                                                                    Никто тут не плохой. Это высший пилотаж переговорщика, как купить феррари по цене лады.
                                                                                    Хитрый ПМ специально заказывает «наговнять», чтобы снизить начальные сроки, а затем программеры в мыле меняют на ходу движок (это ведь им больше надо) вместе с пилением фич, вместо того, чтобы пилить фичи и попивать чай, читая хабр.
                                                                                    • 0
                                                                                      Покупка феррари по цене лады в большинстве случаев попадает под категорию «мошенничество». Так же и тут: либо PM действительно нифига не понимает «в колбасных обрезках», либо он сознательно выжимает из программистов больше, чем то, на что они подписывались.

                                                                                      И в любом случае такой PM плох: в первом случае он просто не исполняет своих функций и ему во многом зря платится зарплата (хотя ему можно помочь — смотри ниже), во втором — он сам ставит себя в позицию «кто — кого». Это может привести в выигрышу в краткосрочной перспективе, но в долгосрочной — дело будет швах: раз PM поставил разработчиков в позицию «либо я вас на№%бу, либо вы меня», то рано или поздно он получит ответку, когда команда разработчиков будет, по бумагам, пыхтеть в поте лица, а на практике будет чаи гонять и придумывать какой бы ещё лапши на уши PMу навесить.

                                                                                      А вообще это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда (по-первости-то результаты улучшаются!), а к тому моменту, когда начинается развал он успевает свалить в другой отдел (часто на повышение). В конце-концов получается Стиве Элоп, который гробит компании с десятками тысяч сотрудников, а ему ещё и аплодируют. В маленьких же компаниях они обычно не выживают (вернее могут выжить если вовремя и удачно продадут компанию), так как расхлёбывать последствия приходится им же самим.

                                                                                      Упаси нас бог от таких PM'ов.
                                                                                      • 0
                                                                                        >Это может привести в выигрышу в краткосрочной перспективе, но в долгосрочной — дело будет швах

                                                                                        Когда, дело действительно станет швах, то главный виновник всего шваха — просто уйдёт в другую фирму. И ему глубоко насрать на то, что стало с прежней фирмой.

                                                                                        >это бич больших компаний: такого PM'а-разрушителя начальство сразу отловить может не всегда

                                                                                        … по причине дурных HR, считающих себя всех умнее, и лучше разбирающимся в том какие люди нужны фирме, отсеивая нормальных кандидатов, чтобы своим отсевом заниматься Имитацией Бурной Деятельности.
                                                                                      • 0
                                                                                        А почему при этом программисты «в мыле»? Вообще говоря, если PM вас хочет гонять «в мыле» — то это повод либо проявить трудовой героизм (если в этот момент экспа идёт), либо заняться исследованием альтернатив (если экспа не идёт или не нужно).

                                                                                        Повторю, если PM хочет поставить программистов в ситуацию, когда от них ожидается качество, а на качество ресурсов не выделяется, то это проблема PM'а и тех, кому не повезло с ним работать (hint: второе исправимо).

                                                                                        Но важно понимать, что есть моменты, когда PM точно знает, что ему надо _наговнякать_. Прямо тут. Херак-херак, и на продакшен. И забыли. PM и только PM понимает business value для того, что делается. А задачей команды является донести до PM'а, сколько ресурсов для данного качества нужно выделить на инфраструктурную часть (то есть на «качество» кода). Это довольно неформальный процесс, часто на грани ненормативной лексики.

                                                                                        Зато на выходе имеется, что всё важное написано хорошо (с покрытием тестами и рефакторингом), а миллионы строк кода, которые не особо-то и нужны в сопровождении в будущем, написаны наотъе… сь, и стоили компании немного. При попытке их развить и начать использовать как код, а не как костыли, PM это понимает (и ему объясняют!) и выделяются ресурсы на приведение в порядок.

                                                                                        То есть проблема обычно в коммуникации между PM и командой. И тут должен быть и хороший PM (который понимает программистов) и хорошие программисты, которые понимают, что иногда надо вчера и говнокод.
                                                                                        • +1
                                                                                          Часто проблема в том, что ПМ не сообщает, что ему надо весь проект наговнякать, что любые заделы на будущее его не интересуют, а то и вредят бизнес-модели, не позволяет раздувать бюджет заказчика.
                                                                                          • 0
                                                                                            Видел очень мало таких. Вернее видел много таких, кто готовы рассказывать про важность быстрого выпуска продукта и прочего, но достаточно попросить завизировать своей подписью простую бумажку с парой фраз (типа по результатам обсуждения решено, что выпуск прототипа должен состояться в как можно более сжатые сроки без затрат времени на создание задела по возможной модернизации, так как окончательная версия будет реализована с нуля без использования каких-либо частей протипа) и они вдруг «прозревают».

                                                                                            Нужно отделять желание «на чужом горбу въехать в рай» от «непонимания ситуации». Одно дело — рассказывать про то, какой ты молодец, как отлично у тебя всё получается и как твои последователи всё разваливают и совсем другое — подставлять свою задницу.
                                                                                    • +10
                                                                                      Это уже другая история. И при это тоже писали.

                                                                                      Если вы хотите, чтобы ваш прототип воспринимали как прототип, то и сделайте, чтобы он выглядел как прототип. Чтобы у него кнопки были убогими. И чтобы он тормозил нещадно. И запускался через раз. Поверьте — это несложно,

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

                                                                                      Опять-таки — это проблема не только программистов, просто почему-то непрограммистам это проще понять. Вы видели «протипы» железячников? Когда из картонной коробки торчат какие-то провода, запускается всё засовыванием проводов куда-то вместо щёлкания тумблерами и т.д. и т.п. Неужели же сложно сделать красивую коробочку, напечатать корпус на 3D-принтере и вообще «сделать красиво»? Можно — но тогда заказчик начнёт задавать совсем уж странные вопросы типа «когда мы сможем получить от наших подрядчиков серийные образцы?»…
                                                                                    • 0
                                                                                      Ок, тогда я повторю свой вопрос, но немного в другом ключе. Как часто встречаются такие хорошие и правильные ПМ?
                                                                                      • 0
                                                                                        Чтобы оценить вероятность надо сделать большую выборку. У меня такой нет. Но хорошего ПМ я нашёл, и всё отлично. Подозреваю, что если искать работу не по критерию «ЗП/близость к дому/любимый ЯП», а по критерию «толковый и вменяемый ПМ», то работа легко найдётся.
                                                                                        • 0
                                                                                          У меня ПМ тоже отличный. Но тем не менее я как-то не представляю, как по этому критерию можно искать работу. Сам процесс неуловимо ускользает :)
                                                                                          • 0
                                                                                            Ну, беседа при собеседовании. Например, компании, где HR до последнего человека ведёт, а PM'а не видно, наверное, не лучшее место для трудоустройства. Личное впечатление о человеке. Поговорить о возможных проектах, где предстоит работа и т.д.
                                                                                            • 0
                                                                                              Увы, в большинстве крупных компаний с хорошей зарплатой у HR (как правило) — слишком большая роль. А PM появляется, только если HR разрешит.

                                                                                              А однажды, вообще был клинический случай
                                                                                              0. HR — была в отпуске
                                                                                              1. успешно поговорил с PM и уже обговорили устройство на работу
                                                                                              2. HR — возвращается из отпуска
                                                                                              3. объявляют, что требуется обязательное одобрение HR
                                                                                              4. HR — зарубает, и хрен кто что может поделать
                                                                                              (самое обидное, что зарплата там была очень и очень нехилая, да, ещё тогда Кризис был, и с работой было туго)
                                                                                              • +1
                                                                                                Признак плохой компании. Если HR может зарубить человека, которого хочет PM, и это не фатальные основания (судимость-стоплист-проблемы с гражданством), то PM слишком слаб, либо его проект не играет никакой значительной роли в компании.
                                                                                              • 0
                                                                                                Да ладно вам. В Российском офисе Гугла PM'а вообще в штате не было несколько лет ни одного — и ничего, как-то же удавалось нанимать людей и получать премии «за лучшее место работы».
                                                                                                • 0
                                                                                                  Мы же говорим про PM'ов, а не про «работу вообще». И я думаю, в гугле так или иначе есть люди (lead'ы, project owner'ы, как не назови), которые имеют интерес в развитии продукта и представляют себе каким он должен быть.
                                                                                                  • 0
                                                                                                    В Гугле есть и PMы и TLи и OWNERы и много кто ещё, но они не общаются с кандидатами при приёме на работу. Вернее общаются — но только с теми кандидатами, которые устраиваются на должность PMа :-)
                                                                                    • +4
                                                                                      — Вам на совесть или быстро?
                                                                                      — Да
                                                                                      • 0
                                                                                        Вы хотите мне рассказать, что бывают конфликты в коллективе. Бывают. Бывают и не такие. И?
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • 0
                                                                                        Многие заметили совершенно правильно — прежде всего код интересует команду. Качество кода сильно влияет на скорость с которой новый сотрудник сможет адаптироваться. Оно влияет на возможность качественно заделать ваши баги когда вы в отпуске. Хороший тимлид никогда не допустит гниющего кода, потому что каждый человек, работающий над проектом, становится трудно заменим.
                                                                                        Но безусловно, во всем надо знать меру.
                                                                                        • 0
                                                                                          Не одних программистов это касается. Трехмерщики полируют топологию, дизайнеры двигают пиксели, геймхудожники перерисовывают текстурки. Нельзя однозначно сказать, что это задротство никто не оценит. Еще как оценит, на себе проверено. Но, самое важное это разумный подход. Нужно четко понимать, когда нужно сделать добротно и тупо, а когда вылизывать до идеала.
                                                                                          • 0
                                                                                            Вот это самое сложное на самом деле, а не вылизывание до идеала.
                                                                                            • 0
                                                                                              Нужда заставит рано или поздно.
                                                                                              Или сломает, если мозги деревянные.
                                                                                          • +1
                                                                                            > Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?

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

                                                                                            Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.
                                                                                            • +1
                                                                                              Хороший код может содержать больше багов, чем плохой. Качество кода не всегда влияет на качество продукта.
                                                                                              • +2
                                                                                                > Хороший код может содержать больше багов, чем плохой
                                                                                                Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
                                                                                                В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.

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

                                                                                                У меня был недавно инцидент. Надо было regex-библиотеку прикрутить к дельфи-проекту. Взял какой-то TRegex, написан вроде прилично, по всем гайдам. Но на практике тормозит нещадно и падает на паттернах в пару КБ. Просто автор в алгоритмах не понимает ничего, что такое автоматы, грамматики и т.п. Просто взял и в лоб накодил.

                                                                                                Кончилось тем, что я взял страшный вырвиглазный pcre и завернул в dll. Вот и весь сказ про «красивый код».
                                                                                                • 0
                                                                                                  От этого никто не застрахован. Стандарт может быть не соблюдён вне зависимости от качества кода. Но всё таки лично для меня при выборе библиотеки из множества вариантов качество кода выступает первым фильтром. Фанатизмом не страдаю, но откровенный говнокод не возьму.
                                                                                              • –1
                                                                                                Если для пользователя нет видимых изменений, значит я за день ничего не сделал. Хороший код нужен самому себе, либо группе разработчиков, которые тоже над этим кодом работают.
                                                                                                • +3
                                                                                                  Ну так это потому что вы визуальщиной занимаетесь. Подозреваю что далеко не всем такая работа интересна.
                                                                                                • +15
                                                                                                  А меня не интересует, чего хочет заказчик. Меня интересует только код и моя зарплата.
                                                                                                  • 0
                                                                                                    Но разве вы не пишете код для того, чтобы решить какую-то проблему? Неважно что за задача, если вы её решаете за деньги, значит кому-то она настолько важна, что он готов заплатить.
                                                                                                    Не из решения проблем ли состоит программирование, и только потом уже из кода?
                                                                                                    • 0
                                                                                                      Бывает, что больше половины кода вылетает в помойку. Поэтому не стоит переживать, если код не решил задачу. Не получилось — заходим на следующую итерацию. Если не воспринимать кодирование как игру, можно потерять мотивацию (я столько думал, кодил и всё напрасно). А так — я играю, мне платят. Получилось что-то полезное — хорошо, но на деньги это как правило не влияет.
                                                                                                      • 0
                                                                                                        Результат программирования — решение проблемы, а состоит оно из изменения кода. Есть два основных подхода к ним: решаем за минимальное время озвученную проблему или увеличиваем время решения с целью избежать в будущем новых проблем.
                                                                                                      • +1
                                                                                                        я чет не уверен на счет первого с таким подходом.
                                                                                                      • 0
                                                                                                        А вот интересно, есть ли примеры проектов, где код блестящий, а конечный продукт не огонь?
                                                                                                        • +2
                                                                                                          Я в практике постоянно с этим сталкивался. Прекраснейшие архитектуры складывались «в стол» потому что никак не помогали продукту лучше удовлетворять пользователя и лучше продаваться.
                                                                                                          • 0
                                                                                                            Как можно назвать архитектуру прекрасной, если она не помогала продукту? Это равносильно «мы сделали замечательный дизайн-концепт автомобиля, одна проблема — он ездить не может».
                                                                                                            • 0
                                                                                                              Пока мы делали блестящий автомобиль, конкуренты сделали рельсы и ржавый паровоз он нас обошёл по всем пунктам, кроме лоска.
                                                                                                              • +2
                                                                                                                Это равносильно скорее «мы сделали самый быстрый в мире автомобиль, но никто не хочет его покупать потому что дорого». Или, в общем, «мы сделали лучший по таким-то критериям продукт, но не можем найти тех, кто по этому критерию выбирает»

                                                                                                                Архитектура не может помочь продукту, если ошибочны требования к продукту.
                                                                                                                • 0
                                                                                                                  Золотые Слова!
                                                                                                                  (жаль плюс не могу поставить)
                                                                                                            • 0
                                                                                                              Сколько угодно. Последний пример — Windows Phone. По многим признакам видно, что код там куда лучше, чем, скажем, в Android'е. Одна беда: пока Microsoft порождал на основе передовых концепций самый лучший код Android захватил весь рынок и теперь отвоевать хоть малюсенький кусочек будет проблемой.
                                                                                                              • +1
                                                                                                                По многим признакам видно, что код там куда лучше, чем, скажем, в Android'е.

                                                                                                                По каким признакам? Вы делали синтактический анализ качества Java кода Android и C# (вроде он там) Windows Phone? Да, я могу поверить что код Android'а менее протестирован, но это не значит что там писали говнокод.
                                                                                                                Подозреваю что проблема совсем не в том что в гугле говнокодили, а в Microsoft'е вылизывали код, там на самом деле куча других причин почему Android обыграл Microsoft.
                                                                                                                • –3
                                                                                                                  На всякий случай добавлю Android построен на оперсорсном Линуксе, а Windows Phone на усеченной винде. Традиционно многими винда исторически считалась более прожорливой и менее качественной чем Линукс (честно говоря не знаю как на самом деле сейчас дела обстоят), так что о качестве кода (производительности, отлажености ядра) тут можно поспорить.
                                                                                                                  • +3
                                                                                                                    Ядро у 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'а с тех пор исправили, конечно, но есть куча вещей, о которые разработчики до сих пор постоянно спотыкаются.
                                                                                                                    • 0
                                                                                                                      > Традиционно многими винда исторически считалась более прожорливой

                                                                                                                      Традиционно многими Земля исторически считалась плоской (честно говоря не знаю как на самом деле сейчас дела обстоят, меня не берут в космонавты...)
                                                                                                              • +1
                                                                                                                Разумеется, я не спрашиваю водителя когда он менял резину и тех. жидкости, моя задача доехать из п А в пункт Б. Разумеется это проблема водителя. Как и водителя когда он приходит в магазин, не интересует, регулярно ли платит магазин налоги, как и руководителя магазина… У каждого есть своя доля ответственности, соблюдение которой дает плюшки, не соблюдение определенные проблемы. В случае с кодом, плохой код, плохо отлаживать и сопровождать.Сложность процесса ухудшает результат за который ты как раз получаешь деньги.
                                                                                                                • 0
                                                                                                                  Тем не менее сплошь и рядом видишь как люди бьются за вещи, которые напрямую к результату не относятся. Когда вместо «количества ошибок» оценивается «покрытие тестами», а вместо решения конкретных задач появляются фабрики фабрик фабрик.
                                                                                                                  • +1
                                                                                                                    вместо решения конкретных задач появляются фабрики фабрик фабрик.

                                                                                                                    это кстати пример плохого кода
                                                                                                                    • +1
                                                                                                                      Лучше фабрики-строителей-фабрик ;-)
                                                                                                                    • 0
                                                                                                                      Покрытие тестами напрямую относится к результатам. Это способ демонстрации результата.
                                                                                                                      • 0
                                                                                                                        «результат» и «демонстрация результата» напрямую не относятся.
                                                                                                                    • 0
                                                                                                                      Тут нельзя забывать, что программист в команде не один. Программисты по большему счету соревнуются друг с другом в том, как быстро они выполняют задачи, потому как от этого зависит зп, бонусы и т.п. Особенно это справедливо для больших команд. В результате, при отсутствии должного контроля за качеством кода, качество зачастую приносится в жертву в угоду скорости и срокам (программистами). С качеством кода наблюдается эффект аналогичный "трагедии общинного поля". Чтобы этого избежать, отчасти, вводят кодинг гайдлайны и ревью кода, которые сами по себе вносят большой оверхед в разработку (т.к. требуют время программистов, и, иногда, много).
                                                                                                                      • 0
                                                                                                                        Это ровно две крайности одна habrahabr.ru/post/256175/?reply_to=8385619#comment_8385461 (первый ответ на мой комментарий) вторая та которую описываете вы. Но их то как раз просто не должно быть, должна быть грань разумного, так и водила может колотить ходовую, не разбирая дороги и забыть про ТО или наоборот переползать через каждую ямочку и торчать по полдня в автосервисе при каждом чихе(что разумеется будет нервировать тех, кого он возит).
                                                                                                                        • 0
                                                                                                                          Поэтому ТО делается не водителем и есть ГИБДД, которое его проверяет. Т.к., иначе, про ТО забудут все. Со временем.
                                                                                                                          • 0
                                                                                                                            ТО имелось ввиду не техосмотр, а техобслуживание. И да меня волнует техническое состояние автомобиля и тех узлов которые проверяют на ТехОсмотре тоже. На данные момент ТехОсмотр проходится, не подходя к моей машине, взнос заплатил? Давай бланк. Я регулярно проверяю состояние машины, потому что это моя безопасность, вне зависимости от требований ГИБДД.
                                                                                                                            • +1
                                                                                                                              Это как раз не важно. Вот что получается, когда все пытаются ехать как можно быстрее по своим делам, на чем под руку попалось, с максимальной возможной скоростью, при полном несоблюдении ПДД:


                                                                                                                              Сверхскоростями тут и не пахнет. Тут можно пешком ходить и выглядеть крутым перцем ;-)
                                                                                                                              • 0
                                                                                                                                Как аккуратно сюда добавилось еще и несоблюдение ПДД. Я разве говорил, что они не должны соблюдаться или что они крайность? Я говорил вроде про другие крайности.
                                                                                                                                • 0
                                                                                                                                  Я разве говорил, что они не должны соблюдаться или что они крайность?

                                                                                                                                  Не говоили. Но, кто ж меня заставляет ограничиваться рамками вашего примера? Машина — ресурс личный, как время программиста. А вот дороги и дорожное движение — общий, как код проекта и CI для команды. Каждый заботится о своей машине, но не заботится о дорогах и удобстве другого. В отсутствие контроля — неизбежно получается «индийский траффик», а точнее — его программный аналог. Поэтому, помимо программистов, кто-то ещё должен быть заинтересован в качестве кода. Иначе, время возмет свое.
                                                                                                                                  • 0
                                                                                                                                    >>Но, кто ж меня заставляет ограничиваться рамками вашего примера?
                                                                                                                                    Тогда смысл и суть спора пропадает.

                                                                                                                                    Есть правила которые участник дорожного движения\программист в команде обязан соблюдать, как раз по вышеобозначенным причинам. Эти правила продиктованы опытом, написаны кровью и являются вполне себе жизненной необходимостью. И вот как раз не обсуждается в статье. Насколько нужно\не нужно соблюдать правила принятые в команде, про это вообще речи не было.
                                                                                                                                    • 0
                                                                                                                                      В каждой команде правила свои. Они не берутся в потолка. Да. Они вырабатываются кровью и потом. Но, программисты сами по себе не самоорганизуются. Без участия мэнеджера у них не появится само по себе CI, Code Review и тесты. Всё это требует времени, которое распределяет и выделяет мэнеджер. Поэтому, он должен интересоваться кодом. Или, хотябы полагаться на мнение лида, или другого, с