Комментарии 35
high cohesion и low coupling не совсем корректно переведены…
Скорость и постоянное переписывание кода — это хорошо а не плохо. И это никак не отменяет творческого подхода и сосредоточенности. Я ни разу не встречал инженеров, которые были бы способны продумать систему полностью с нуля, описать ее тестами и реализовать за одну итерацию. Если вы думаете, что вы — именно такой — вы себя обманываете. Мы работаем в слишком сложных условиях, чтобы это было возможно в принципе. В реальном мире, нас поджидают сюрпризы со всех сторон: со стороны бизнеса, технологий, отношений в команде и так далее. Лучше выстраивать процесс и архитектуру таким образом, чтобы скорость и перманентный рефакторинг не были проблемой вообще. Это возможно, и в этом, на мой взгляд, и есть высшее мастерство разработчика.
В статье как "плохое" обозначается переписывание в смысле разработки заново, с нуля.
Допустимость и необходимость рефакторинга на любом этапе жизненного цикла ближе к концу статьи обозначается.
То есть, насколько я вижу, противоречия между написанным в статье и написанным вами нет. Или я какой-то момент упускаю?
Полагаю что некоторые продукты со временем все же окажутся практически переписанными с нуля путем переписывания компонентов продукта, поскольку меняются масштабы их использования, требования к безопасности. Это тоже плохо?
Нет ничего плохого в переписывании с нуля, если вы четко знаете чего хотите этим добиться. В текущий момент, вы всегда можете опереться на полученный опыт работы с системой, которого у вас еще не было в предыдущей итерации. И этот опыт, порой, на многое позволяет взглянуть сильно по новому. Игнорировать это новое и пытаться лечить проблемы заплатками, будучи свято уверенными в непогрешимости изначальной архитектуры — это путь в ад. Автор сам указывает на то, что мы не пишем код в его финальной версии, но, на мой взгляд, это противоречит тому, с чего статья началась. Часто быстрая проверка теорий бывыет важнее возможности без спешки реализовать качественную систему, основываясь на неверных предпосылках.
Люди присоединяются к компаниям, в которые верят.Эта фраза сразу выдаёт перевод. Я бы сказал, у нас люди присоединяются к тем трём с половиной компаниям, которые обнаруживаются на hh.ru в твоём городе.
Похоже на предсмертную записку фермеров после изобретения конвейеров. Мол, качество, давайте работать для людей. А в итоге низкокачественные шаблонные приложения приносят многократно большую прибыль в краткосрочной перспективе. А потом либо поддержка прекращается, либо окупается с микротранзакций, либо приложение перевыпускается.
А как фермеры и конвейеры связаны?
Это конечно немного размыто, но суть в том, что фермеры начали загибаться после промышленной революции, т.к. горожане покупали дешёвые, конвейерные, низкокачественные продукты, которые изготавливались практически не отходя от кассы. Поэтому сейчас в плей маркете 99% игр — это шаблонная ерунда, сделанная по какому-нибудь популярному фильму, с кучей доната. И эта игра просто работает, пока люди платят. Когда перестают донатить, выпускают игру по следующему фильму.
Наверное имелись в виду ремесленники против мануфактур.
До конвейеров на мой взгляд еще не доросли.
До конвейеров на мой взгляд еще не доросли.
НЛО прилетело и опубликовало эту надпись здесь
Не путайте виртуозов и проффесионалов. Виртуоз — это из кино, когда там какой-то псих ежесекундно рискуя, умудряется чудом в одиночку расстрелять кучу врагов и победить. ПРикольная стратегия, но работает раз из ста, потом про это кино снимают. Профессионал, это тот кто знает что для штурма укрепленного противника требуется в пять раз больше сил, чем укрепилось и артилеррийская подготовка.
НЛО прилетело и опубликовало эту надпись здесь
Профессионал — это не волшебник. Профессионально отказаться выполнять задачу, если сроки или ресурсы недостаточны, потому что твоя задача — гарантировать результат. Непрофессионально взяться за задачу и просрать ее. Непрофессионально соглашаться на заниженные ресурсы и заниженное время.
Профессионал при анализе ситуации должен четко заявить, что в указанное время задачу выполнить не удастся, а не рвать на груди рубашку: «Все сделаем!».
Если вы пообещали сделать за неделю, а сделали за две, а кто-то другой пообещал сделать за месяц и сделал за месяц, то профессионал кто-то другой, а вы-любитель.
Профессионал при анализе ситуации должен четко заявить, что в указанное время задачу выполнить не удастся, а не рвать на груди рубашку: «Все сделаем!».
Если вы пообещали сделать за неделю, а сделали за две, а кто-то другой пообещал сделать за месяц и сделал за месяц, то профессионал кто-то другой, а вы-любитель.
НЛО прилетело и опубликовало эту надпись здесь
У меня был риск-менеджмент в универе, но я б не сказал, что нам его давали хорошо)))
Есть профи прораммист, который говорит сделаю за две недели, есть профи продавец, который смотрит рыбу договора видит, что там срок неделя, но штрафов за просрочку сроков нет и принимает решение участвовать в тендере. Это профессионально.
Мало того профессионально даже просрачивать, если ты выполняешь все штрафные санкции. Потому что ты сработал точно по договору. Непрофессионально не писать в договор штрафных санкций, если сроки критичны для тебя.
Вы опять же судите с любительской точки зрения:«скажут неделя, сделают за две». Если ваша задача ускорить проект максимально, вы делаете премию за скорость, и штраф за просрочку. Если грубо, +1% к цене контракта за каждый досрочный день, и -1% за каждый просроченный день. Это отсечет любителей. Вы можете сделать свободный срок, что его указывали сами разработчики, но определить формулу выигрыша тендера, который будет учитывать указанный срок.
В США если вы все просрете к фигам, но сделаете точно по договору, учитывая штрафные санкции, то вам напишут положительное рекомендательное письмо.
Есть профи прораммист, который говорит сделаю за две недели, есть профи продавец, который смотрит рыбу договора видит, что там срок неделя, но штрафов за просрочку сроков нет и принимает решение участвовать в тендере. Это профессионально.
Мало того профессионально даже просрачивать, если ты выполняешь все штрафные санкции. Потому что ты сработал точно по договору. Непрофессионально не писать в договор штрафных санкций, если сроки критичны для тебя.
Вы опять же судите с любительской точки зрения:«скажут неделя, сделают за две». Если ваша задача ускорить проект максимально, вы делаете премию за скорость, и штраф за просрочку. Если грубо, +1% к цене контракта за каждый досрочный день, и -1% за каждый просроченный день. Это отсечет любителей. Вы можете сделать свободный срок, что его указывали сами разработчики, но определить формулу выигрыша тендера, который будет учитывать указанный срок.
В США если вы все просрете к фигам, но сделаете точно по договору, учитывая штрафные санкции, то вам напишут положительное рекомендательное письмо.
НЛО прилетело и опубликовало эту надпись здесь
Все это работает когда твоя фирма делает свой продукт. У нее есть стремление улучшать свои процессы, адаптироваться и так далее. Другой тип разработки — полный аутсорс. И для таких ребят, которые программируют на заказных проектах — это все это звучит как насмешка. Они бы и рады все это тоже делать, да кто им даст. Нужно фигачить без оглядки, потому что заказчик назначил релиз на вчера. На костылях с завязаными глазами, через поле граблей (по которому бегают еще десять подрядчиков) без карты, к финишному флажку, после которого не конец, а следующий раунд.
Я помню, как во время телефонного разговора с product-менеджером я сказал, что нам необходимо переписать всю систему. После 30 секунд молчания менеджер спросил: «Ты говоришь, что твоя команда разработала продукт настолько низкого качества, что теперь эта же самая команда должна переписать этот же продукт заново, но на этот раз сделать лучше. Верно? Прости, но это неприемлемо. Вы должны были писать его лучше сразу.»
1. Если требования не менялись, а система не делает того, что нужно — она была плохо спроектирована и сеньор мудак.
2. Если требования менялись, но сеньор не предупреждал каждый раз, что изменения требований ухудшают качество системы и приведут к остановке работы, то сеньор мудак.
3. Если менеджера предупреждали о последствиях накопления технического долга, но он игнорировал предупреждения, то менеджер мудак.
И хотя условий при которых мудаком оказывается разработчик больше, в наших реалиях чаще всего выполняется пункт 3.
НЛО прилетело и опубликовало эту надпись здесь
Я так понимаю, здесь сеньор исполняет обязанности тимлида. Как же его оградить от менеджера если эта связь — его прямая обязанность?
По моей практике, увидеть целостную картину, не запрограммировав частные случаи и не проведя после этого анализа — зачастую невозможно. К тому же на месте менеджера, который мудак зачастую находится клиент, который, как известно, всегда прав, к тому же заплатил деньги.
Поэтому да — хорошо, когда есть возможность остановиться, проанализировать, переделать, и только потом двигаться дальше.
Поэтому да — хорошо, когда есть возможность остановиться, проанализировать, переделать, и только потом двигаться дальше.
«Позабыв покой и лень,
Делай деньги, делай деньги,
А остальное всё — дребедень!» (с)
Все связано со всем. Если есть продукт, есть продажи, есть деньги на развитие, то можно не спеша шлифовать. Если нет продаж, то и зарплаты нет, и шлифовальщикам надо искать другие места.
Делай деньги, делай деньги,
А остальное всё — дребедень!» (с)
Все связано со всем. Если есть продукт, есть продажи, есть деньги на развитие, то можно не спеша шлифовать. Если нет продаж, то и зарплаты нет, и шлифовальщикам надо искать другие места.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чтобы вести разработку быстрее, необходимо замедлиться