Comments 25
UFO just landed and posted this here
UFO just landed and posted this here
Напоминает известный манифест http://macode.ru.
Вроде начали за здравие — а закончили за упокой) Местами странные рекомендации; пишите код — не пишите код, копипастите — не копипастите.
Но в целом направление верное — меньше кода, более простой код и меньше зависимостей(в том числе и от библиотек).
Но в целом направление верное — меньше кода, более простой код и меньше зависимостей(в том числе и от библиотек).
Не писать код — предельный случай стремления писать мало кода.
Наконец, 8-й шаг: когда-то я был программистом...
Наконец, 8-й шаг: когда-то я был программистом...
В том-то и дело. Можете всегда игнорировать тех, кто даёт совет применимый всегда ( :) ).
В разных ситуациях наилучшими могут оказываться противоположные действия. К сожалению многие у нас любят догмы.
В разных ситуациях наилучшими могут оказываться противоположные действия. К сожалению многие у нас любят догмы.
Посыл статьи — напишите кое как, потом исправляйте, а потом удалите к х… м ))
Руководство по ремонту дома от Tom Smykowski.
Шаг 0. Не делайте ремонт.
Шаг 1. Используйте самые дешевые материалы.
Шаг 2. Теперь переделайте все, используя дорогие материалы.
Шаг 3. Сделайте все быстро и тяп-ляп.
Шаг 4. Теперь все сломайте и переделайте как надо.
Шаг 5. Сделайте настил на пол из цельного куска ДСП.
Шаг 6. Отдерите настил, распилите на доски и прибейте их по отдельности.
Шаг 7. Заготовьте краску и доски для будущего ремонта.
Как-то так.
Не понятна основная идея: зачем мне два раза писать один и тот же код — сначала плохо, а затем хорошо, если я сразу в состоянии сделать хорошо? И да, рефакторить код время от времени необходимо, удаляя лишнее. Это не для кого не секрет. Только зачем это делать со всем написанным кодом?
Шаг 0. Не делайте ремонт.
Шаг 1. Используйте самые дешевые материалы.
Шаг 2. Теперь переделайте все, используя дорогие материалы.
Шаг 3. Сделайте все быстро и тяп-ляп.
Шаг 4. Теперь все сломайте и переделайте как надо.
Шаг 5. Сделайте настил на пол из цельного куска ДСП.
Шаг 6. Отдерите настил, распилите на доски и прибейте их по отдельности.
Шаг 7. Заготовьте краску и доски для будущего ремонта.
Как-то так.
Не понятна основная идея: зачем мне два раза писать один и тот же код — сначала плохо, а затем хорошо, если я сразу в состоянии сделать хорошо? И да, рефакторить код время от времени необходимо, удаляя лишнее. Это не для кого не секрет. Только зачем это делать со всем написанным кодом?
Только зачем это делать со всем написанным кодом?
Никто не требует делать это со всем написанным кодом.
Так, в самом начале 2 пункта указано, когда его (пункт) применять:
Как только вы заметите, что скопипастили какую-то часть программы достаточное количество раз, значит, возможно, пришло время написать на ее основе функцию.
Видимо, автор предполагал видимыми противоречиями привлечь внимание к статье.
Как только вы заметите, что скопипастили какую-то часть программы достаточное количество раз, значит, возможно, пришло время написать на ее основе функцию.
Насколько я помню это из Рефакторинга от Фаулера.
Скопировал 1 раз норм, если 2 раза то выдели метод.
Написать лапшу а потом рефакторить тоже от Фаулера, а вообще тут от него вся статья.
Может я не верно понял Фаулера, но по моему мнению, он не говорил пишите лапшу. Он давал советы что делать с лапшой и как определить лапша или уже блюдо.
Но тогда я не понимаю зачем писать статью которая цитирует то же, но как бы с другой стороны. И упуская некоторые вещи?
Но тогда я не понимаю зачем писать статью которая цитирует то же, но как бы с другой стороны. И упуская некоторые вещи?
Да, советы вполне в стиле Фаулера.
Насчет причин… они могут быть разными.
Возможно, автор не читал Фаулера.
Возможно, автор не помнит, что именно он прочел.
Возможно, автор просто осознал, что именно он делал уже 3\5\7\42 лет, и решил поделиться этим.
Возможно, автор захотел написать отличную статью, путем (относительно) простого рерайта.
Возможно, автор захотел добавить связности в книгу Фаулера. В ней, как правило, описываются типовые ситуации и пошаговый способ излечения. В статье же есть некая общая нить, как код из одного состояния переходит в другой.
Насчет причин… они могут быть разными.
Возможно, автор не читал Фаулера.
Возможно, автор не помнит, что именно он прочел.
Возможно, автор просто осознал, что именно он делал уже 3\5\7\42 лет, и решил поделиться этим.
Возможно, автор захотел написать отличную статью, путем (относительно) простого рерайта.
Возможно, автор захотел добавить связности в книгу Фаулера. В ней, как правило, описываются типовые ситуации и пошаговый способ излечения. В статье же есть некая общая нить, как код из одного состояния переходит в другой.
> Может я не верно понял Фаулера, но по моему мнению, он не говорил пишите лапшу.
Вообще это от Бека если быть точным, спустя годы многое выветрилось из головы, поэтому я помню только что читал об этом в первый раз именно в книге Фаулера. Фаулер же говорил что можно брать более менее приемлимое решение и писать его. По мере написания становятся очевидны какие то просчеты и тогда можно используя рефакторинг устранить их.
> Но тогда я не понимаю зачем писать статью которая цитирует то же, но как бы с другой стороны. И упуская некоторые вещи?
Здесь я с вами согласен, несмотря на то что в статье есть хорошие советы, в целом это перефразированное вырезанное содержание книг типо Рефакторинга(первых 40%) и Совершенного кода.
Вообще это от Бека если быть точным, спустя годы многое выветрилось из головы, поэтому я помню только что читал об этом в первый раз именно в книге Фаулера. Фаулер же говорил что можно брать более менее приемлимое решение и писать его. По мере написания становятся очевидны какие то просчеты и тогда можно используя рефакторинг устранить их.
> Но тогда я не понимаю зачем писать статью которая цитирует то же, но как бы с другой стороны. И упуская некоторые вещи?
Здесь я с вами согласен, несмотря на то что в статье есть хорошие советы, в целом это перефразированное вырезанное содержание книг типо Рефакторинга(первых 40%) и Совершенного кода.
Мне кажется, это по-другому переформулированные правила agile, которые позволяют избежать преждевременной фиксации API и библиотек, что в свою очередь приводит к over-инжинирингу. Сначала надо написать код, который покажет нам как он будет использоваться в реальности — потом переписать его в соответствии с этим знанием. Не оформлять в библиотеку код до того, как мы поймем, что он нужен в библиотеке. Ну и так далее.
С ремонтом, когда делаешь сам первый раз, оно почти так всегда и получается. Сначала делаешь как умеешь и как получится, потом, поняв технологию и нюансы, переделываешь как надо. Покупаешь самые дешевые материалы чтобы сэкономить, потом понимаешь, в чем засада и что тебе точно нужно — и выбираешь дорогой материал по его параметрам, а не по цене. Ну и так далее.
С ремонтом, когда делаешь сам первый раз, оно почти так всегда и получается. Сначала делаешь как умеешь и как получится, потом, поняв технологию и нюансы, переделываешь как надо. Покупаешь самые дешевые материалы чтобы сэкономить, потом понимаешь, в чем засада и что тебе точно нужно — и выбираешь дорогой материал по его параметрам, а не по цене. Ну и так далее.
Ну да, вцелом тезис понятный, но многое спорно. Если удается выделить функциональную единицу, почему бы ее сразу не оформить ввиде отдельного модуля, компонента или библиотеки? Изначально сделанный дизайн системы (в соответствии с правилами слабой связанности и делегирования ответственности) и правильно выбранные абстракции упрощают разработку, тестирование и поддержку кода. И ничего не вижу плохого в том, что дизайн и код будут эволюционировать. Главное всегда уметь выявить зависимости, чтобы знать какой код затронет каждое изменение (поэтому я и не пишу на языках с динамической типизацией). Оверинжиниринг случается не из-за модульного дизайна, а когда люди пытаются абстрагироваться от решаемой задачи, поставив свой модуль как саму цель, а не как часть конкретного решения. И тогда да — появляется куча ненужных методов «на будуще» и абстракций для «расширения функционала».
С ремонтом подразумевается, что ты профессиональный мастер и что далеко не первый дом делаешь. А переделывать приходится когда резко меняются функциональные реквизиты клиента (теперь это будет не дом, а гараж), либо когда этих изменений накапливается такое большое количество, что старый дизайн системы уже не имеет смысла. И тогда созревает новый релиз 2.0, который пишется фактически с нуля, учитывая новые реквизиты. И да, старая ветка идет в помойку. Практически вся.
С ремонтом подразумевается, что ты профессиональный мастер и что далеко не первый дом делаешь. А переделывать приходится когда резко меняются функциональные реквизиты клиента (теперь это будет не дом, а гараж), либо когда этих изменений накапливается такое большое количество, что старый дизайн системы уже не имеет смысла. И тогда созревает новый релиз 2.0, который пишется фактически с нуля, учитывая новые реквизиты. И да, старая ветка идет в помойку. Практически вся.
Если удается выделить функциональную единицу, то это совершенно не означает, что она кому-то понадобится еще и что тот API, который будет для нее создан (а обычно это первый-второй пришедший в голову интерфейс, позволяющий более-менее эффективно решить задачу) будет помогать тем, кто будет это дело использовать.
Поэтому не надо делать из деталей реализации API до того, как она действительно кому-то не понадобится в третий раз. Интересно, что в таких случаях бывает, что проще и быстрее реализовать это заново, чем лепить костыли к существующему API.
Кроме того, если код достаточно сложен и его много, то сколько не проектируй, выделить и предусмотреть все потенциальные зависимости очень сложно, не говоря уже о тех местах, которые надо будет расширить. Тем более, если код старый, то часто бывает, что слабая связанность и делегирование во времена его создания не сильно ценились его создателями, и теперь мы имеем дело с тем что имеем, а переписать/отрефакторить миллион строк кода, которые являются технологическим ядром компании, нельзя. Статическая типизация тут меняет не много, я пишу на С++, куда уж статичнее?
Поэтому не надо делать из деталей реализации API до того, как она действительно кому-то не понадобится в третий раз. Интересно, что в таких случаях бывает, что проще и быстрее реализовать это заново, чем лепить костыли к существующему API.
Кроме того, если код достаточно сложен и его много, то сколько не проектируй, выделить и предусмотреть все потенциальные зависимости очень сложно, не говоря уже о тех местах, которые надо будет расширить. Тем более, если код старый, то часто бывает, что слабая связанность и делегирование во времена его создания не сильно ценились его создателями, и теперь мы имеем дело с тем что имеем, а переписать/отрефакторить миллион строк кода, которые являются технологическим ядром компании, нельзя. Статическая типизация тут меняет не много, я пишу на С++, куда уж статичнее?
Промахнулся
Чтобы легко удалять код, надо писать его как можно более понятно и просто. Тогда в проекте не будут появляться магические места вида «тут водятся драконы», о которых никто не знает зачем они и как работают, поэтому не рискуют трогать. Скучно, но правда.
А статья рассчитана на «вау-импульс» и учит плохому.
А статья рассчитана на «вау-импульс» и учит плохому.
Статья учит тому, что можно умеренно отходить от правил ради экономии, если ты строго понимаешь что ты делаешь.
Черт, я могу написать метод на 50 строк и никто не умрет. Потом через недельку порежу на парочку до 20 строк. Или не порежу, если дедлайн и времени на рефакторнг и ревью нет. Если это модуль который в условиях активного изменения и может вообще улететь, то там еще и сам код будет попахивать. Но это не значит что можно писать как в опенкарт контроллеры из одного метода на тысячу строк и говорить что "Мы true MVC".
Собственно статья и пытается провести эту грань, где "немного попахивает" это нормально, и экономия, а где оно уже не немного, и вообще ахтунг, и технический долг будет стоить кучу рессурсов потом. Но соглашусь что статья несколько корява, и доносит мысль с трудом.
Черт, я могу написать метод на 50 строк и никто не умрет. Потом через недельку порежу на парочку до 20 строк. Или не порежу, если дедлайн и времени на рефакторнг и ревью нет. Если это модуль который в условиях активного изменения и может вообще улететь, то там еще и сам код будет попахивать. Но это не значит что можно писать как в опенкарт контроллеры из одного метода на тысячу строк и говорить что "Мы true MVC".
Собственно статья и пытается провести эту грань, где "немного попахивает" это нормально, и экономия, а где оно уже не немного, и вообще ахтунг, и технический долг будет стоить кучу рессурсов потом. Но соглашусь что статья несколько корява, и доносит мысль с трудом.
Субъективно. Зависит от сферы работы программиста. Наверное, если это какой-нибудь бизнес-софт и надо сделать «сейчас или никогда» — то такой подход приемлим. Но вы будете не рады, если придётся жить с этим кодом дальше.
> дедлайн и времени на рефакторнг и ревью нет
Хреновый менеджемент.
> дедлайн и времени на рефакторнг и ревью нет
Хреновый менеджемент.
От сферы зависят лишь детали.
Технический долг это долг и есть.
И работать с ним нужно как с финансовым.
Да, он сложно детерминируется, его сложно оформить простыми четкими цифрами, но это долг.
Плохо быть "в долгах как в шелках". Но разумное использование кредитов дает нехилое плече для развития.
Также и тут. Быстрое прототипирование может ускорить проектирование, ускорить разработку, начать тестирование функционала раньше и т.п. Что в совокупности даст огромный профит, который уже можно тратить на возврат долга (рефакторинг).
Это работает в любой области.
Даже если ты пишешь прошивку для марсианского ровера, ты можешь в глубокой альфе наговнокодить, если это будет РАЗУМНО, и позволит потом отрефакторить, а не переписывать с нуля потратив еще больше усилий ведь нужно сохранять совместимость.
оффтоп:
сейчас в оффлайне с бывшим партнером идет жесткий файт за ключевого клиента. Мой основной козырь это неограниченный (по сравнению с конкурентом) кредитный ресурс позволяющий кредитовать клиентов и т.п. Я очень надеюсь что это будет фатальный аргумент)
оффтоп2: недавно столкнулся с проблемой, что когда наполняли портфолио по ИТ-проектам, то у нас была большая проблема по лоуэнд проектам. Вроде как их по количеству больше всех, но и смертность у них выше, большинство не проживают и двух лет. Конечно еще фактор того, что дешевые клиенты экономят на всём, и многие не хочется показывать и говорить "это сделали мы", но тем не менее. Под жирные вещи сразу нашлись проекты на которые договоренности не запрещали ставить свои копирайты, а на мелочи пришлось думать. Это я к тому что мне не будет стыдно за говнокод под капотом тех мелких проектов которые уже умерли. И именно об этом и статья. Делай рефакторинг когда он нужен, и не более.
Технический долг это долг и есть.
И работать с ним нужно как с финансовым.
Да, он сложно детерминируется, его сложно оформить простыми четкими цифрами, но это долг.
Плохо быть "в долгах как в шелках". Но разумное использование кредитов дает нехилое плече для развития.
Также и тут. Быстрое прототипирование может ускорить проектирование, ускорить разработку, начать тестирование функционала раньше и т.п. Что в совокупности даст огромный профит, который уже можно тратить на возврат долга (рефакторинг).
Это работает в любой области.
Даже если ты пишешь прошивку для марсианского ровера, ты можешь в глубокой альфе наговнокодить, если это будет РАЗУМНО, и позволит потом отрефакторить, а не переписывать с нуля потратив еще больше усилий ведь нужно сохранять совместимость.
оффтоп:
сейчас в оффлайне с бывшим партнером идет жесткий файт за ключевого клиента. Мой основной козырь это неограниченный (по сравнению с конкурентом) кредитный ресурс позволяющий кредитовать клиентов и т.п. Я очень надеюсь что это будет фатальный аргумент)
оффтоп2: недавно столкнулся с проблемой, что когда наполняли портфолио по ИТ-проектам, то у нас была большая проблема по лоуэнд проектам. Вроде как их по количеству больше всех, но и смертность у них выше, большинство не проживают и двух лет. Конечно еще фактор того, что дешевые клиенты экономят на всём, и многие не хочется показывать и говорить "это сделали мы", но тем не менее. Под жирные вещи сразу нашлись проекты на которые договоренности не запрещали ставить свои копирайты, а на мелочи пришлось думать. Это я к тому что мне не будет стыдно за говнокод под капотом тех мелких проектов которые уже умерли. И именно об этом и статья. Делай рефакторинг когда он нужен, и не более.
Ничего вы не понимаете в ипотека-стайл кодинге
Sign up to leave a comment.
Пишите код, который легко удалять, а не дополнять