Комментарии 40
Это грустно но правдиво.
Именно поэтому в сфере программного обеспечения больше нет и скорее всего в ближайшее время не будет качественных продуктов. Причем это утверждение касается и веб аппликаций тоже. Почти. все что касается коммерческого софта ущербно. Но к счастью есть еще конкуренция со стороны opensource, хотя опенсорс проектам требуется гораздо больше времени на раскрутку, так что не все так плохо.
Именно поэтому в сфере программного обеспечения больше нет и скорее всего в ближайшее время не будет качественных продуктов. Причем это утверждение касается и веб аппликаций тоже. Почти. все что касается коммерческого софта ущербно. Но к счастью есть еще конкуренция со стороны opensource, хотя опенсорс проектам требуется гораздо больше времени на раскрутку, так что не все так плохо.
Ерунда, извините :) Качественных вещей в природе нет, все ломается. И всё испортили не жадные программисты, так миру устроен.
:) Холодильник «Днепр» мои родители купили когда мне было 6 лет. Теперь мне 40, а он РАБОТАЕТ у них на балконе.
www.google.com/search?q=%D1%85%D0%BE%D0%BB%D0%BE%D0%B4%D0%B8%D0%BB%D1%8C%D0%BD%D0%B8%D0%BA+%D0%B4%D0%BD%D0%B5%D0%BF%D1%80&hl=en&client=firefox-a&hs=59H
И речь не о программистах.
www.google.com/search?q=%D1%85%D0%BE%D0%BB%D0%BE%D0%B4%D0%B8%D0%BB%D1%8C%D0%BD%D0%B8%D0%BA+%D0%B4%D0%BD%D0%B5%D0%BF%D1%80&hl=en&client=firefox-a&hs=59H
И речь не о программистах.
Это смотря с какой позиции смотреть на качество. Если с точки зрения кода, возможностей быстро добавить ресурсы и аккуратно вставить новую фичу, то да. А с точки зрения удовлетворения быстро меняющихся потребностей пользователя (программы же для юзеров пишутся, не так ли?) до определённой степени разрастания проекта говнокод будет более качественным. Потом он превратится в кашу, в которой сам чёрт ногу сломит, и добавить новую фенечку для пользователя или найти баг будет уже крайне трудно.
Двое мужиков стоят пилят дерево тупой пилой. День пилят, второй пилят, третий…
Мимо проходит третий мужик и говорит:
— Пацаны, вы бы пилу заточили…
— Некогда, мужик, пилить надо!
Мимо проходит третий мужик и говорит:
— Пацаны, вы бы пилу заточили…
— Некогда, мужик, пилить надо!
На мой взгляд, некорректное сравнение. Тупая пила будет долго пилить прямо со старта, и «остропилы» заведомо проиграют. А здесь за счёт ущерба качеству кода повышается стартовая скорость.
Сорри… «Тупопилы» заведомо проиграют.
Никто не выиграет и не проиграет. Просто тупопилы сделают хреновый продукт. Стоимость поддержки и дальнейшего развития которого будет выше чем стоимость его первичной разработки.
корректным оно станет, если добавить что когда-то начали пилить они острой пилой
Почему же никто не читает теги? Теги очень даже полезны в том случае, когда хочется узнать о чем же статья не читая саму статью.
Прелесть разработки в том, что можно практически не останавливаться. Править баги, добавлять фичи, в общем бежать вперёд можно параллельно с рефакторингом, лишь иногда делая короткие остановки для синхронизации старого кода и отрефакторенного. Посмотрите на автогонки типа Формулы-1: автомобили останавливаются чтобы сменить резину, но их ждёт команда, у которой всё готово для этой замены, и она происходит за считанные секунды. Все решения приняты в фоне процесса собственно гонки, процесс замены отработан практически для автоматизма.
Нашел ответы на некоторые свои вопросы… Спасибо за перевод.
Очень интересная точка зрения, а метафора так вообще отлично вписалась. Спасибо за перевод.
Если команда не сидит сложа руки, а важные задачи правильно приоритезированы, то вероятнее всего процесс не виновен.
Вот отсюда следует, что как бы процесс — это чтобы команды не сидела сложа руки и задачи были приоретизированы и все. Но это не так.
Нет тут никакого соревнования. Никто не бежит рядом и проигравшие не выбывают.
Это может быть актуально для бизнеса организации в целом но не о процессе разработки в рамках этого бизнеса. Если не хватает ресурсов их можно нанять, решить вопрос мотивации и т.д.
Вопрос в том чтобы эти ресурсы правильно посчитать — вот для этого нужен процесс.
Не печальтесь, Вы не сделали ничего плохого. Более того — Вы выжили в то время, когда другие были слишком бережными и провалились.
Вот именно что такой подход даст возможность выжить конкретному руководителю, который высоким темпом работы сейчас прикрыл свою некомпетентность. Проект все равно проиграет.
Профессиональная работа — это поддержание устойчивого шага в ходе проекта и создание условий для его контролируемости. А бежать вперед подтягивая штаны — это не из разряда «я всех обгоню», а из разряда «доползу до финиша, куплю новые шмотки, буду выступать за другой клуб, а старые доносит кто-нибудь другой».
Вот отсюда следует, что как бы процесс — это чтобы команды не сидела сложа руки и задачи были приоретизированы и все. Но это не так.
Нет тут никакого соревнования. Никто не бежит рядом и проигравшие не выбывают.
Это может быть актуально для бизнеса организации в целом но не о процессе разработки в рамках этого бизнеса. Если не хватает ресурсов их можно нанять, решить вопрос мотивации и т.д.
Вопрос в том чтобы эти ресурсы правильно посчитать — вот для этого нужен процесс.
Не печальтесь, Вы не сделали ничего плохого. Более того — Вы выжили в то время, когда другие были слишком бережными и провалились.
Вот именно что такой подход даст возможность выжить конкретному руководителю, который высоким темпом работы сейчас прикрыл свою некомпетентность. Проект все равно проиграет.
Профессиональная работа — это поддержание устойчивого шага в ходе проекта и создание условий для его контролируемости. А бежать вперед подтягивая штаны — это не из разряда «я всех обгоню», а из разряда «доползу до финиша, куплю новые шмотки, буду выступать за другой клуб, а старые доносит кто-нибудь другой».
И в первую очередь все начинают винить процесс
Полностью с этим соглашусь.
Занимаюсь консультированием IT-компаний и за 3 года понял, что когда винят процесс, то в 90% случаев лучше сначала взглянуть на код.
Если у вас не хардкорный технологический стартап, то у вас в принципе не должно быть кода, который бы был недоступен для осмысления большинством разработчиков.
То есть все проблемы с кодом — это на самом деле проблемы в организации работы. В том числе, отсутствия стратегического видения будущего проекта и как следствие — неправильной степени гибкости, заранее выбранной для проекта.
То есть все проблемы с кодом — это на самом деле проблемы в организации работы. В том числе, отсутствия стратегического видения будущего проекта и как следствие — неправильной степени гибкости, заранее выбранной для проекта.
Может стратегическое видение было, но благодаря отзывам пользователем изменилось.
Нет, процесс сам по себе мало что дает. Кроме разве что выделения/невыделения времени на постоянный рефакторинг.
Если время выделяется, то всё упирается в квалификацию разработчиков. Т.е. в умении делать рефакторинг, подбирать имена, отражать смысл задачи в коде. Говнокод же появляется не сам по себе, а пишется разработчиками.
Хотя и процесс, если совсем неадекваты в управлении, может существенно тормозить. Например, если есть недоверие разработчикам и требуют утверждения каждого шага. Тогда разработчик попросту простаивает, ожидая встреч, утверждений.
Если время выделяется, то всё упирается в квалификацию разработчиков. Т.е. в умении делать рефакторинг, подбирать имена, отражать смысл задачи в коде. Говнокод же появляется не сам по себе, а пишется разработчиками.
Хотя и процесс, если совсем неадекваты в управлении, может существенно тормозить. Например, если есть недоверие разработчикам и требуют утверждения каждого шага. Тогда разработчик попросту простаивает, ожидая встреч, утверждений.
Когда я работал там, где каждый шаг требовал утверждения, то я только и занимался рефакторингом, да экспериментами. Отрефакторил один кусок, послал его на утверждение, рефакторишь второй, временами переключаясь на решение той же задачи вообще исходя из других положений типа платформы, парадигмы (тогда я и заболел ООП головного мозга с очагами ФП), сценариев и т. п.
Один из вариантов — иметь 2 команды.
Насколько я понимаю — такой подход практиковался в Интеле и Майкрософте
Один несет другого на горбу, тот в это время переобывается и подтягивает штаны
Насколько я понимаю — такой подход практиковался в Интеле и Майкрософте
Один несет другого на горбу, тот в это время переобывается и подтягивает штаны
НЛО прилетело и опубликовало эту надпись здесь
Хм. Одного не могу понять — что делать тем компаниям, где кодовая база уже есть, рефакторить полностью нужно, ибо многие простейшие баги с точки зрения юзера (заказчика) уже не пофиксишь кроме как серьезными изменениями, но времени все равно нет — так как регулярно присылаются новые требуемые фичи, по которым есть таймлайны, и если заниматься ими (что предполагается заказчиком в первую очередь), то на рефакторинг уже просто не осается времени… Уже не в первом проекте, приходя, вижу такие вот проблемы — когда то, что можно было починить легко и бысто, починено, остальное надо ничить долго и с серьезным рефакторингом, а времени объективно нет.
Что делать? — бежать оттуда… ахаха…
Ну а на самом деле выделить ряд изменений по рефакторингу, которые принесут максимальный профит в виде уменьшения стоимости поддержки. А потом продать эти изменения заказчику или руководству. С цифрами понятное дело.
Но если заказчиком фиксируется стоимость разработки и время, то на качество всем насрать — совершенно нормальная ситуация. Ненормально если бы они при этом выставляли какие либо требования к качеству решений.
Ну а на самом деле выделить ряд изменений по рефакторингу, которые принесут максимальный профит в виде уменьшения стоимости поддержки. А потом продать эти изменения заказчику или руководству. С цифрами понятное дело.
Но если заказчиком фиксируется стоимость разработки и время, то на качество всем насрать — совершенно нормальная ситуация. Ненормально если бы они при этом выставляли какие либо требования к качеству решений.
Если прибыль позволяет, то нанимать людей, чтобы времени на рефакторинг хватало. Если даже увеличив количество разработчиков в разы уложиться во объективно требуемое время не получается (про девять женщин я в курсе если чо) сначала сделав рефакторинг, а потом чинить, то мозговой штурм о будущих интерфейсах, а дальше параллельно чинение (даже не знал, что такое слово есть, думал спелчекер подсветит :) ) и рефакторинг. Чинение исходя из результат штурма, рефакторинг по приведению имеющейся базы к нему.
Тут прикол в чём… Как раз в тех самых 9 женщинах. А точнее то, что времени на то, что можно делать параллельно с разработкой новых фич — есть. Но рефакторинг уже нужен для всего ядра. А это значит — что наактывать новые фичи во время рефакторинга нет смысла — ибо само ядро поменяется, логика его работы. Как и фиксить баги (какие-то уйдут рефакторингом, возможно появятся новые :) ). То есть на время этого рефакторинга нужно остановить весь продакшн.
При стандартном обязательстве выхода новой минорки месяца в 2-3, а потенциального времени на тотальный рефакторинг в месяц, выглядит всё проблематично — ведь после такого рефакторинга приличиное время придётся заниматься регрешн тестированием, выявлением что поломали, а что нет. То есть практически все изменения в новой версии и будут тем самым рефакторингом. А это уже отдел продаж не даёт — ибо (с)пользователь этих изменений почти не почувствует, ему давай новый функционал или исправление большого числа багов.
При стандартном обязательстве выхода новой минорки месяца в 2-3, а потенциального времени на тотальный рефакторинг в месяц, выглядит всё проблематично — ведь после такого рефакторинга приличиное время придётся заниматься регрешн тестированием, выявлением что поломали, а что нет. То есть практически все изменения в новой версии и будут тем самым рефакторингом. А это уже отдел продаж не даёт — ибо (с)пользователь этих изменений почти не почувствует, ему давай новый функционал или исправление большого числа багов.
Такое часто бывает когда продукт(проект) сильно вырастает и меняется на столько что он перестает быть тем чем планировался быть(чем проектировался). Очень часто заказчики заказывают одно — получают это, и понимают что лучше сделать по другому, и не программную часть, а сами процессы, иногда даже принципы и структуры предприятий меняются, когда заказчики получают данные и понимание. Кроме того с течением времени все быстро меняется, техника, технологии, структуры, объемы и т.д.
Так что в этом случае действительно нужно остановиться и завязать шнурки, а лучше сменить на обувь без шнурков или даже скорее вместо того чтобы бежать — пересесть на велосипед и ехать быстрее, потом автомобиль, самолет… ракету… Ведь задача не в беге ради бега в обуви со шнурками, а нужно преодолевать бОльшие расстояние за меньшее время… в нашме случае это наверно меньше кода — больше и лучше выполняемых операций… эволюция, как-то так.
Так что в этом случае действительно нужно остановиться и завязать шнурки, а лучше сменить на обувь без шнурков или даже скорее вместо того чтобы бежать — пересесть на велосипед и ехать быстрее, потом автомобиль, самолет… ракету… Ведь задача не в беге ради бега в обуви со шнурками, а нужно преодолевать бОльшие расстояние за меньшее время… в нашме случае это наверно меньше кода — больше и лучше выполняемых операций… эволюция, как-то так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Завяжите шнурки и подтяните свои штаны!