Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 92
А куда относится изменение кода в связи с найдеными ошибками в ходе тестирования? Куда отнести изменения архитектуры и переписывание кода во время выхода, например, другой мажорной версии?
Специально время не выделяется, но когда при, например, измении архитектуры, протокола работы между модулями, заменяются блоки кода и код как бы изменяется и, вроде бы, улучшается. Хотя всегда можно сказать, что одни баги выкинули — новые написали.
Специально время не выделяется, но когда при, например, измении архитектуры, протокола работы между модулями, заменяются блоки кода и код как бы изменяется и, вроде бы, улучшается. Хотя всегда можно сказать, что одни баги выкинули — новые написали.
>>А куда относится изменение кода в связи с найдеными ошибками в ходе тестирования?
В отладку.
>>Куда отнести изменения архитектуры и переписывание кода во время выхода, например, другой мажорной версии?
В разработку новой мажорной версии.
Имелось ввиду именно специально выделенное время: не меняем поведения, не добавляем фич, не фиксим багов. Просто делаем говнокод менее говном.
В отладку.
>>Куда отнести изменения архитектуры и переписывание кода во время выхода, например, другой мажорной версии?
В разработку новой мажорной версии.
Имелось ввиду именно специально выделенное время: не меняем поведения, не добавляем фич, не фиксим багов. Просто делаем говнокод менее говном.
Та же ситуация. Иногда возникают идеи, что этот кусок неплохо бы соптимизировать, а здесь добавить новую возможность. Для этого иногда переписываются целые классы. Код получается быстрее, богаче возможностями и, вроде бы, надежнее. Таких слов, как code review и refactoring до последнего времени официально не произносилось.
Первый пункт выигрывает. И самое интересное, что это действительно так по экономическим причинам. Обычному заказчику дофени, что вы там понапишете. Другое дело относится к крупным проектам, где надо «для себя» и этих проектов относительно мало.
Факты жизни, оттуда и говнокод, потому что заказчики такие. «бизьнесь» заказчики. тфьу…
Факты жизни, оттуда и говнокод, потому что заказчики такие. «бизьнесь» заказчики. тфьу…
Печально все это.
Ну, я не экономист. Просто у меня так же как и написал ниже Infernal
А если я не экономист, то я опираюсь на массовую практику — статистику поста. Как вы видите, большинство как и я готовы сделать говнокод для заказчика и заработать денег, чем писать умные конструкции без еды и самое главное всем все равно в первую очередь заказчику. Это знаете как у торгашей, кто-то продает качественный квас, а кто-то разбавляет. Так вот вторые выигрывают.
Я то сам против говнокода и вы в этом можете убедиться по моим постам.
А если я не экономист, то я опираюсь на массовую практику — статистику поста. Как вы видите, большинство как и я готовы сделать говнокод для заказчика и заработать денег, чем писать умные конструкции без еды и самое главное всем все равно в первую очередь заказчику. Это знаете как у торгашей, кто-то продает качественный квас, а кто-то разбавляет. Так вот вторые выигрывают.
Я то сам против говнокода и вы в этом можете убедиться по моим постам.
Да никто не спорит, что специалист хороший стоит больше))). Тут вопрос о том что в фирме принято, а это принимается согласно рыночным тенденциям. Тут о специалистах речь не идет, я же сказал свое отношение к говнокоду, и я думаю любой нормальный спец считает так же.
> для кого сайт в интернете это что-то совсем не профильное
Мир не только в IT живет. Таких большинство, сделают супердорогой сайт и даже его не продвигают, думая что все они станут в одночасье миллионерами, статья была на хабре где-то. Жалко таких людей встречать, истинных «бизнесЬменов» — одни амбиции и никакого аналитического мышления. А другие заказчики вроде Макдональдса не нуждаются в расширяемой архитектуре, и у них есть постоянный подрядчик который «для себя» её все равно делает, что бы было дешевле.
> Мне более близок второй вариант, программирование это моё ремесло.
я еще раз повторю, да для меня тоже чистый код важно, но дело не в этом. Мы же не о личных делах думаем сейчас, а о фирменных (читай экономических). =) Давно доказано лучше миллион по рублю чем 10 по 100 тысяч.
> для кого сайт в интернете это что-то совсем не профильное
Мир не только в IT живет. Таких большинство, сделают супердорогой сайт и даже его не продвигают, думая что все они станут в одночасье миллионерами, статья была на хабре где-то. Жалко таких людей встречать, истинных «бизнесЬменов» — одни амбиции и никакого аналитического мышления. А другие заказчики вроде Макдональдса не нуждаются в расширяемой архитектуре, и у них есть постоянный подрядчик который «для себя» её все равно делает, что бы было дешевле.
> Мне более близок второй вариант, программирование это моё ремесло.
я еще раз повторю, да для меня тоже чистый код важно, но дело не в этом. Мы же не о личных делах думаем сейчас, а о фирменных (читай экономических). =) Давно доказано лучше миллион по рублю чем 10 по 100 тысяч.
Итого, совмещая ваши позиции:
Надо писать быстрый говнокод, лишь бы работало. И быстро выходить на рынок, снимать сливки, знакомиться с областью, читать отзывы, делать ТЗ (да-да, только сейчас. Всё что было до этого — часто только догадки и предположения)
И в период первого же затишья, или параллельно с бурей, строить нормальное ПО с нормальной расширяемой архитектурой, с ревью, рефакторингом. Кроме того ТЗ и знакомство с матчастью команды будет уже гораздо лучше, чем в первый раз. И выводить его как версию 2.
Надо писать быстрый говнокод, лишь бы работало. И быстро выходить на рынок, снимать сливки, знакомиться с областью, читать отзывы, делать ТЗ (да-да, только сейчас. Всё что было до этого — часто только догадки и предположения)
И в период первого же затишья, или параллельно с бурей, строить нормальное ПО с нормальной расширяемой архитектурой, с ревью, рефакторингом. Кроме того ТЗ и знакомство с матчастью команды будет уже гораздо лучше, чем в первый раз. И выводить его как версию 2.
Хабрапользоватесь, минусуй-неминусуй, статистику ты не изменишь. Можешь даже в карму заминусовать, только посты мои прочитай для начала, и думай головой когда что-нибудь делаешь. А когда ставишь минус комментарий пиши.
Иногда находим под это время. Либо в свободное время сам.
У нас два типа проектов: свои и заказы. Для своих есть и code review, и специальные спринты под рефакторинг. Для заказов, как правило, ревью или нет, или оно гораздо менее строгое, рефакториг делается тоже значительно реже и обычно время на него закладывается во время разработки очередной фичи. Причины уже сказал выше wartur.
Пишем нормальный код, дебажим, хотим уже много лет убить старый код и переписать то, что вызывает кучу ошибок.
Но есть большое «НО». Это «эффективный и мудрейший» менеджмент, который хапает заказы постоянно, переводит работу программистов в состояние «паника, надо было сделать еще на прошлой неделе».
Ну и еще свято верить, что code и review и рефакторинг = смерть проекта
Но есть большое «НО». Это «эффективный и мудрейший» менеджмент, который хапает заказы постоянно, переводит работу программистов в состояние «паника, надо было сделать еще на прошлой неделе».
Ну и еще свято верить, что code и review и рефакторинг = смерть проекта
Только идеальный код, только хардкор.
Судя по тому, что начинает набирать голоса пункт «Да, практикуется и code и review и рефакторинг», а опрос я публиковал утром, то те, кто использует разбор кода и рефакторинг еще и на работу приходят позже. =)
Вообще, я давно понял, что требовать у менеджеров отдельно время на рефакторинг — гиблое дело. А кроме того, писать, скажем, месяц говнокод, а потом неделю его рефакторить — неверно идеологически. Я пытаюсь как-то делить своё время ежедневно в пропорции 90% времени пишу код / 10% рефакторю. Получается и код в любой момент времени более или менее нормальный и менеджеры о трате времени на рефакторинг даже не догадываются.
Догадываются.
Такой подход Джоэл Спольски и Мартин Фаулер советовали — не говорить начальству о необходимости времени на рефакторинг, а просто включать это время в решение основной задачи. Видимо он и есть самый идеологически верный.
Можно им просто не говорить, что это рефакторинг делается.
Code review делается только для новых проектов, старый код не трогаем уже
code review есть, но времени под него очень мало и на качество кода это не особо влияет — что на входе, что на выходе говно. времени на рефакторинг нет вообще. пытаюсь что-то делать в свободное время или по ходу реализации других фич, но всем понятно, что это неправильный подход
Рефакторю «унаследованный код» втайне от начальства. Выделяю кусок процедурного кода, который нужно изменить/дополнить, в метод класса (надеюсь безопасно :) ), покрываю тестами метод, лёгкий рефакторинг, если требуется (типа вынести запросы к мускулу в отдельный класс) и пишу тесты для новой функциональности. Когда свободное время есть, то если не трачу его на хабр, то покрываю тестами и лёгкий рефакторинг делаю и для кусков, которые пока не предполагается трогать. Задача-максимум пока — покрыть всё тестами и примитивный рефакторинг без особого изменения архитектуры, лишь разделение на слои каждой задачи без объединения аналогичных слоев в единое целое.
Не, ну коненчо проводится. Естественно написанный на код никто не забивает.
Но это делается только в плане разработки.
Если что-то работает давно, то вряд ли без необходимости мы будем лезть чего-то менять.
Но это делается только в плане разработки.
Если что-то работает давно, то вряд ли без необходимости мы будем лезть чего-то менять.
Пишем сразу идеально.
Ну а вообще, нет, — время под это не выделается, хотя я всегда при вопросе директора «что делаешь» моу ответить «нужно переписать этот код потому, что ...», разработчики самостоятельно рефакторят код, code review на уровне «ну ты и залепу там написал».
Ну а вообще, нет, — время под это не выделается, хотя я всегда при вопросе директора «что делаешь» моу ответить «нужно переписать этот код потому, что ...», разработчики самостоятельно рефакторят код, code review на уровне «ну ты и залепу там написал».
Да, но время на рефакторинг официально не выделяется. Всё делается в свободное от основных проектов время на голом энтузиазме разработчиков.
Похоже на правду, кроме:
Что Вы подразумевали здесь под оптимизацией? Если скорость выполнения, то зачастую она страдает от рефакторинга.
Рефакторинг делать нужно ради: «оптимизация...
Что Вы подразумевали здесь под оптимизацией? Если скорость выполнения, то зачастую она страдает от рефакторинга.
>«Я вам платил год деньги и вы писали дерьмо, а теперь хотите на неделю остановить развитие проекта???»
>ну очень часто случаются такие моменты, когда надо очень быстро и крайне сильно изменить логику.
«Помните вы кричали, что красивый баннер на главной нужен был вчера? А я говорил, что только на соплях могу его быстро приклеить? Вот, сопли начали отклеиваться.» Это, конечно, в теории, у меня не прокатывает :(
>ну очень часто случаются такие моменты, когда надо очень быстро и крайне сильно изменить логику.
«Помните вы кричали, что красивый баннер на главной нужен был вчера? А я говорил, что только на соплях могу его быстро приклеить? Вот, сопли начали отклеиваться.» Это, конечно, в теории, у меня не прокатывает :(
У нас программисты — люди второго сорта. Предприятие должно выполнять свою основную роль, в которой IT выполняет с одной стороны вспомогательные, с другой основные функции. Программы должны работать правильно, быстро и в срок. Что там в коде, волнует только начальника и некоторых других коллег-программистов. Так что первый пункт наше все. На остальные просто не хватает времени. Только при наличии хорошего опыта происходит написание правильного кода сразу. Новечки пишут как придется, лишь бы заработать авторитет «специалиста». Код-то их всеравно никто не проверяет. Контора связана с газом, если что.
Те кто говорят, что пишут идеальный код, скорее всего пишут говнокод, но у них высокая самооценка!
59.07% Нет, пишем говнокод, дебажим, снова пишем.
Я разочаровался в этой планете.
Зато люди честные! Это должно вам снизить разочарование.
Так дебажат же!
Да нет, всё более чем закономерно.
>> Да, практикуется и code и review и/или рефакторинг.
Опросник составлен не очень однозначно, но я полагаю, что под этими тремя ответами подразумевалось «В компании выделяется отдельное время, вне business-value задач, под эти цели». Это означает, что либо программиты — лодыри, которые до конца задачи не доделывают, либо менеджеры не рубят в разработке.
Code review, рефакторинг, дебагинг, покрытие тестами, комментирование и прочая мишура — это обязанности программистов-исполнителей точно такие же как и написание букв кода. Под выполнением задачи ведь подразумевается написание кода, который ведёт к появлению определённой фичи? Так почему не подразумевается остальное?! На выходе должен получаться KISS, DRY & YAGNI результат.
Так вот, если требуется дополнительное время, дополнительными тасками на упомянутые процедуры, значит программисты: либо схалтурили, либо просто воспользовались лояльностью начальства, чтобы выбить дополнительное время сверх того, под которым подписывались в начале выполнения задачи.
Не всякое начальство очень лояльно, поэтому пункт голосования не выигрывает.
>> Нет, просто сразу пишем идеальный код, который всегда работает.
Это некоторое преувеличение, но всё же довольно близкое к тому, что происходит в командах, состоящих из профессионалов. Команда профессионалов не может работать у менеджеров-самодуров, поэтому профессионализм менеджеров также подразумевается.
Довольно редкий сценарий, когда в одном месте получается собраться грамотному stakeholder'у, который ясно даёт понять что ему нужно и команде программистов, которая ясно понимает, что лучше этой работы/проекта в их городе/стране/мире нет и делает что нужно. Разработчики вынуждены писать идеальный код, потому что понимают, что от этого зависит их хлеб, уважение коллег, пользователей, начальства и собственное удовлетворение в конечном итоге.
Сценарий редкий, поэтому пункт голосования опять же не выигрывает.
>> Нет, пишем говнокод, дебажим, снова пишем.
Либо непрофессионализм (в разработке) топ-менеджмента, либо безразличие к результату — что-то из этого есть в большинстве проектов. Вот вам и win!
>> Да, практикуется и code и review и/или рефакторинг.
Опросник составлен не очень однозначно, но я полагаю, что под этими тремя ответами подразумевалось «В компании выделяется отдельное время, вне business-value задач, под эти цели». Это означает, что либо программиты — лодыри, которые до конца задачи не доделывают, либо менеджеры не рубят в разработке.
Code review, рефакторинг, дебагинг, покрытие тестами, комментирование и прочая мишура — это обязанности программистов-исполнителей точно такие же как и написание букв кода. Под выполнением задачи ведь подразумевается написание кода, который ведёт к появлению определённой фичи? Так почему не подразумевается остальное?! На выходе должен получаться KISS, DRY & YAGNI результат.
Так вот, если требуется дополнительное время, дополнительными тасками на упомянутые процедуры, значит программисты: либо схалтурили, либо просто воспользовались лояльностью начальства, чтобы выбить дополнительное время сверх того, под которым подписывались в начале выполнения задачи.
Не всякое начальство очень лояльно, поэтому пункт голосования не выигрывает.
>> Нет, просто сразу пишем идеальный код, который всегда работает.
Это некоторое преувеличение, но всё же довольно близкое к тому, что происходит в командах, состоящих из профессионалов. Команда профессионалов не может работать у менеджеров-самодуров, поэтому профессионализм менеджеров также подразумевается.
Довольно редкий сценарий, когда в одном месте получается собраться грамотному stakeholder'у, который ясно даёт понять что ему нужно и команде программистов, которая ясно понимает, что лучше этой работы/проекта в их городе/стране/мире нет и делает что нужно. Разработчики вынуждены писать идеальный код, потому что понимают, что от этого зависит их хлеб, уважение коллег, пользователей, начальства и собственное удовлетворение в конечном итоге.
Сценарий редкий, поэтому пункт голосования опять же не выигрывает.
>> Нет, пишем говнокод, дебажим, снова пишем.
Либо непрофессионализм (в разработке) топ-менеджмента, либо безразличие к результату — что-то из этого есть в большинстве проектов. Вот вам и win!
Ого, какой большой ответ на такой маленький комментарий. Говнокод пишется всегда и везде, особенно в веб-дев, обычно из-за того, что из треугольника (качество — скорость — стоимость), выбираются скорость и стоимость, с точки зрения бизнеса это отпимально.
Вёб разный бывает. Если делается сайт для Громпромстройпрокатмаш, где нужно изобразить подобие калькулятора для расчёта стоимости чугунных труб, а потом забыть — всецело согласен: говнокод — оптимальное решение.
Если речь идёт об амбициозной MMO-игре (ну тоже вёб формально), которой нет ещё ни у кого, за которую платят 200К/мес и разработка которой расчитана на год… Вот тут подумаешь, стоит писать Г или нет.
Если речь идёт об амбициозной MMO-игре (ну тоже вёб формально), которой нет ещё ни у кого, за которую платят 200К/мес и разработка которой расчитана на год… Вот тут подумаешь, стоит писать Г или нет.
Меня специально наняли чтобы провести рефакторинг кода (Сказали на собеседовании). Вот уже практически год ковыряю.
BDSM на уровне команды и анальный секс со стороны руководства!
Ну а если серьезно — ревьюим мало, у нас сейчас высокое разделение труда, а рефакторим часто.
Ну а если серьезно — ревьюим мало, у нас сейчас высокое разделение труда, а рефакторим часто.
Джуниоры на рефакторинге звучит сурово. Вы случайно не в Челябинске работаете? =)
Значит начальство банально не знает, что такое рефакторинг. Приведение стиля кодирования в рамках проекта к одной нотации не есть рефакторинг. А рефакторинг без опыта в разработке именно архитекутры вряд ли возможен. Но в принципе в вашей ситуации нет ничего удивительного, так как в комментариях к этому опросу прослеживается непонимание, что такое рефакторинг даже у жителей Хабра.
Ну почему только стиль кодирования. Ставится задача покрыть весь код тестами. Полным комплектом причём, от юнит до приемочных. Более опытный показывает на примере типичной ветки выполнения сначала как создать приемочный, потом функциональный, потом интеграционные, потом юниты, последовательно применяя легкий безопасный рефакторинг. Не надо что-то объяснять про архитектуру и паттерны, а просто описывать что делаешь на примитивном уровне типа «выносим запрос к БД в отдельный метод нового класса, чтоб при тестировании не обращаться к БД», «чтобы при тестировании смогли подставить вместо этого объекта мок, выделяем этот код в другой метод, другого класса и передаём ему объект БД в конструктор», «в этом месте тоже самое делаем», «опа, получилось два очень похожих класса, работающих с БД, отличаются только строкой SQL — объединяем в один класс, конструкторы одинаковые, в методах общее выносим в приватный метод, а эти методы вызывают его каждый со своим SQL» и т. п. А потом дать остальное разбирать.
Только на основании требований, что код должен быть покрыт юнит-тестами (причём настоящими юнит, а не приемочными по сути и, желательно, тестирующими поведение, а не состояние) и должен соблюдаться DRY уже можно значительно улучшить архитектуру «унаследованного спагетти». А если ещё про SOLID рассказать… Естественно на самотек не пускать, а регулярно проверять, что они там тестируют и рефакторят и «мягким добрым словом» объяснять, что 10 моков на один юнит-тест перебор. Заодно приучить кажде значимое изменение коммитить и только тогда, когда все тесты проходят. Можно хуки повесить, чтоб первичную проверку делать и не давать коммитить с непроходящими тестами.
Только на основании требований, что код должен быть покрыт юнит-тестами (причём настоящими юнит, а не приемочными по сути и, желательно, тестирующими поведение, а не состояние) и должен соблюдаться DRY уже можно значительно улучшить архитектуру «унаследованного спагетти». А если ещё про SOLID рассказать… Естественно на самотек не пускать, а регулярно проверять, что они там тестируют и рефакторят и «мягким добрым словом» объяснять, что 10 моков на один юнит-тест перебор. Заодно приучить кажде значимое изменение коммитить и только тогда, когда все тесты проходят. Можно хуки повесить, чтоб первичную проверку делать и не давать коммитить с непроходящими тестами.
А по-моему, достаточно разумно. По крайней мере, если в конторе практикуется покрытие тестами или вообще TDD, а джуниоры о них ни слухом, ни духом. Хотя бы поймут, что такое легко тестируемый код и как важно наличие швов.
Согласен, что рознь, меня вот вообще не берут :(
Прежде чем осваивать TDD нужно, наверное, научиться писать тесты :) Может не всем, но всем точно не хватит для этого прочитать Бека. А учить новичка писать хорошие тесты на живом проекте с TDD схоже, по-моему, с обучением плаванью путем бросания на глубину. А давать каждому учебный проект, да ещё следить постоянно и за качеством тестов, и за качеством кода — накладно, наверное, для владельцев, ведь спецы будут надолго отвлекаться от живых проектов.
Прежде чем осваивать TDD нужно, наверное, научиться писать тесты :) Может не всем, но всем точно не хватит для этого прочитать Бека. А учить новичка писать хорошие тесты на живом проекте с TDD схоже, по-моему, с обучением плаванью путем бросания на глубину. А давать каждому учебный проект, да ещё следить постоянно и за качеством тестов, и за качеством кода — накладно, наверное, для владельцев, ведь спецы будут надолго отвлекаться от живых проектов.
Как раз переживаю :( Хоть бы сказал кто почему не берут, знал бы над чем работать, одному уже надоело. Очень.
Интересная практика. Правда не понятно, это больше тестовое задание (испытательный срок) или именно обучение (самообучение?) То есть если в самом начале что-то не то начал делать, то хотя бы скажут «не так» сразу или только когда придёт время сдачи узнаешь, что всё не так?
Первый человек, от которого слышу, что так научился. То ли практика нераспространенная, то ли другие не научились O_o
Интересная практика. Правда не понятно, это больше тестовое задание (испытательный срок) или именно обучение (самообучение?) То есть если в самом начале что-то не то начал делать, то хотя бы скажут «не так» сразу или только когда придёт время сдачи узнаешь, что всё не так?
Первый человек, от которого слышу, что так научился. То ли практика нераспространенная, то ли другие не научились O_o
У нас все на совести программера, если чето захош переписать — тибе никто ничего не запретит, а не хош, ну как хош. Каждый как хочет ртак и дроч… Работет.
Вообще рефакторинг, это не какая-то отдельная задача, об это кстати говорит Фаулер. Это постоянный процесс. Поэтому выелать на рефакторинг, какое-то особое время не следует. Там где я работаю, я поступаю так (хотя это не тредование, и не все так делают), я рефакторю то что мне не нравится и что я заметил. Т.е если мне нужна функция, которую кто-то написал год назад, и не не нравится как она выглядит, я трачу рабочее время чтобы ее переписать. Хотя, конечно, я не делаю глобальных рефакторингов, которые могут сильно затронуть вопрос проектирования в старом коде. В том коде который пишу я, стараюсь рефакторить все на ходу, не боюсь координально менять код написанный две недели назад или вчера. Знаю что чем лучше это будет выглядеть тем полезнее это будет для меня.
Мы в фирме используем парное программирование и TDD. Поэтому код получается сразу высокого качества (но не идеального, конечно).
Отдельно Code Review не проводим, но поскольку пары постоянно меняются, они периодически натыкаются на код товарищей и перед тем, как менять, просматривают и подправляют его, там где это уместно.
Отдельно Code Review не проводим, но поскольку пары постоянно меняются, они периодически натыкаются на код товарищей и перед тем, как менять, просматривают и подправляют его, там где это уместно.
Ахахахахахха проголосовал честно — результаты убили ))))))))))
Мой вариант: пишем говнокод, он никому не нравится, поэтому переписываем, создавая новый, еще более тру говнокод.
«Говнокод», если оценить творения полугодичной давности, хотя тогда казалось всё отлично.
От проекта к проекту стараюсь совершенствоваться, всё же самому приятно, когда как следует делаешь.
Что сказать ещё.
Во-первых, банально нет времени, чтобы вылизывать код. Есть дедлайн и требуется результат.
Во-вторых, овчинка выделки не стоит, если ставить целью достижение идеального кода — все проекты успешно выполняют свои задачи, а высокой нагрузки там не предвидится в принципе. Если это и произойдет, то к тому времени уже потребуется написание нового сайта. Вот с учетом новых обстоятельств и будет смысл дополнительно напрячься.
От проекта к проекту стараюсь совершенствоваться, всё же самому приятно, когда как следует делаешь.
Что сказать ещё.
Во-первых, банально нет времени, чтобы вылизывать код. Есть дедлайн и требуется результат.
Во-вторых, овчинка выделки не стоит, если ставить целью достижение идеального кода — все проекты успешно выполняют свои задачи, а высокой нагрузки там не предвидится в принципе. Если это и произойдет, то к тому времени уже потребуется написание нового сайта. Вот с учетом новых обстоятельств и будет смысл дополнительно напрячься.
Люди, а зачем вы пишете этот говнокод? А если и пишете, почему не подтираете за собой?
(Не буду спрашивать, почему вы работаете на таких компаниях. Заставляют, видимо)
(Не буду спрашивать, почему вы работаете на таких компаниях. Заставляют, видимо)
Патамушта постоянные гонки. Вот думаешь, воткну щас костыль, а потом приберусь и будет все круто. А потом… это идет в прод. Патамушта бизнес кричит давай-давай!
Ещё бывает, выкатываешь прототип, который думаешь ещё неделю будешь пилить, а говорят: «всё ОК, пошли на следующую задачу».
Ну, это частный случай имхо. Прототипы вообще не имеет смысла (опять-таки, имхо) делать красиво и хорошо. Это ж прототип, пилотная версия. Показать чтоб.
А потом, уж если оно пойдет — дописывать, рефакторить, покрывать тестами, коментить…
Да и много ли наговнокодишь прототипами? Если ж это прототип в день, так это уже не прототип. А если потом на этот прототип зависимости какие нависнут, опять-таки, надо включить мозг и посмотреть, что будет дешевле — выправить все или подлатать.
А потом, уж если оно пойдет — дописывать, рефакторить, покрывать тестами, коментить…
Да и много ли наговнокодишь прототипами? Если ж это прототип в день, так это уже не прототип. А если потом на этот прототип зависимости какие нависнут, опять-таки, надо включить мозг и посмотреть, что будет дешевле — выправить все или подлатать.
Я перешёл к правилу делать протипы на рельсах, когда проект заказывается на PHP. И то не помогает — не так давно один заказчик не захотел после согласования прототипа на рельсах, чтоб я переписал на PHP, хотя это было обговорено, просто сказал, что не нужно тратить время (заплатил сколько было оговорено с учетом переписывания). Пришлось допиливать на рельсах, не трогая основной говнокод, а лишь вынося его в отдельные методы на будущее, которое, скорее всего, никогда не настанет — работает же.
пишем идеальный говнокод
Программирование из ранга искусства становится чем то обыденным. Обидно!!! Программы штампуются как дома из бетонных плит (готовыми шаблонами), главное чтобы быстро сделать. Ассемблер я по тебе скучаю!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А в вашей фирме производится улучшение существующего кода?