Вы утрируете. Полно случаев, когда можно слегка улучшить код по ходу дела, не меняя его поведения и не разбираясь, как можно/нельзя изменить его поведение. И в любом случае, если Вы хоть как-то измените поведение, то это уже будет не рефакторинг. И лучше это делать отдельным коммитом, когда надо.
Притом что они получают мусор?
Почему мусор? undefined — это вполне рабочее значение в JavaScript. Нравится Вам или нет, но факт в том, что это так.
P.S. Слушайте, я тоже не в восторге от JS и вообще фронтом практически не занимаюсь… но там сам JS-мир слегка сумасшедший, Вы конечно можете старательно огораживаться, не принимая их практики, но смысла мало.
В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".
Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?
Не работаем с ним :-)
Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.
Мне попадался: «Мы не можем ничего согласовать, так как это отрежет нам дорогу к изменениям».
Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»
Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.
"тут для простоты я использую квадратичный алгоритм — значит, надо убедиться, что большие наборы данных сюда не попадут"
Шикарный пример оптимизации xD
А если серьёзно, то проблема действительно есть… мало программистов задумываются о производительности своего кода, хотя в большинстве случаев это упирается в незнание SQL. Ну и да, иногда попадаются на ревью квадратичные алгоритмы там, где можно было бы обойтись линейным, но это гораздо реже.
Реализация — это не API. API — это описание параметров и результатов. Подкреплённое тестами, в идеале.
И что? В данном случае, единственное описание API — это сам код. Так тоже бывает.
Устраивать рефакторинг не имея представления что ваш фрагмент кода делает и когда он используется — кончается слезьми.
Ну так я и пытаюсь эту мысль донести. Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров.
Ну или не плачьте, когда прод упадёт :-)
Но стараться «сохранить жизнь» программе когда она уже «слетела с катушек»
В чём тут "слёт с катушек"? Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean? Не так уж редко именно это и требуется, вне зависимости от входных параметров. Ваши фантазии на тему неопределённых результатов имхо оффтопик.
Я же утверждаю, что данная функция изначально должна была быть написана по-другому.
На основании чего? Это уже исключительно Ваши домыслы.
Мы обсуждаем варианты переписать существующую функцию, не имея никаких явных требований (есть только те, что заложены в код)… Это рефакторинг в чистом виде и ничто больше.
Вы же мотивируете только тем, что "автор — дурак, потому что я так считаю"… Это непрофессионально и все эти сокращения по факту оказываются дешевыми понтами, если не можешь сократить без изменения поведения кода.
Ну, а что такое рефакторинг? Это улучшение кода без изменения его API. Исходный код всегда возвращает либо true, либо false. Требований у нас нет, значит мы при переписывании кода обязаны подразумевать что такое требование было. И результат итоговой функции должен совпадать с результатом исходной на всём множестве значений аргументов. Мы тут не вдаёмся в причины этого требования, может результат надо было запихнуть в JSON и отправить какому-нибудь микросервису на Go (вот он обрадуется, когда получит "undefined" вместо false).
Но причины требования не суть важны в данном примере, важно, что сохранность API — это базовые основы рефакторинга. И куча людей этого не понимает, что уже печально. Получается, хотели показать как они круты, переделав код из статьи, а по факту опозорились. Но не в силах признать ошибку, предпочитают заминусить… Ну ладно, желаю им профессионального роста. Может через пару лет поймут, что признать ошибку не стыдно, стыдно — не признать )))
Это отличный вариант для строго типизированного языка. При динамической же типизации у вас нет контракта какого типа аргументы придут в функцию. hardWork внезапно может оказаться undefined.
Поэтому как не изголяйтесь, а явное приведение к boolean будьте любезны написать, раз функции требуется возвращать именно true/false. Забыть про это приведение — типичная ошибка новичка.
Кол-во минусов к моему исходному комментарию показывает только то, что есть немало людей, которые пишут код на JavaScript ещё хуже, чем автор статьи. При этом они сами пока об этом не догадываются… недостаток опыта он такой, даёт ложную уверенность в своей неправоте :-)
Это более хрупкий вариант… в текущем JS сработает, а в других языках не получится сравнить 0 и boolean. А это тоже допустимый вариант, если допустим hardWork — boolean, a luck — число от 0 до 10. Так что либо !!, либо явное приведение: return Boolean(isPrepared);
Ещё была классная подборка материала — Delphi Russian Knowledge Base. Помню, как я в интернет-центре целый час скачивал её… хотя она весила всего 3 Mb :-D
Зато потом дома можно было без интернета изучать интересный материал.
Два символа вместо одного для самого популярного оператора?
Это конкатенация то самый популярный оператор? Для того, чтобы что-то вставить в строку в 90% случаев интерполяция используется… Теперь она даже в JS есть под названием "String Substitution".
Сейчас по-моему уже для любого языка есть либо REPL, либо Playground, либо и то и то. Так что проблем с быстротой старта в первый результат никаких нет.
стандартный ответ на коментарий о качестве перевода с примерами ошибок
Просто считается, что это надо в личку автору перевода писать. Хотя я такую агрессию не одобряю, т.к. тема улучшения переводов тоже интересная.
Фразу можно понять как — мы сделали наш сайт третьим по посещаемости, среди сайтов на Rails и нас третье место в общем устраивало, мы были довольны.
Ну нет, всё-таки оригинал о том, что фреймворк не стал для них узким местом, несмотря на большую посещаемость. Иначе вторая часть фразы(про сегодняшний день) напрочь теряет смысл.
Why I wouldn’t use rails for a new company — увидеть в переводе — Почему я бы не стал использовать Rails для нового проекта — ну очень неожиданно.
Но если подумать, то это вполне корректная адаптация к российским реалиям. Это у них распространённая практика для каждого нового проекта открывать новую компанию. У нас так не принято. Вот и получается, что речь в статье именно о старте новых проектов, просто для американца начать проект и открыть компанию — это одно и то же.
Раз Вы вынесли это в комментарий, подразумеваю, что Вы хотите обсудить тему улучшения переводов не только с автором, поэтому вставлю свои 2 копейки.
Мы сделали Scribd третьим по посещаемости сайтом на rails, и нас это устроило
В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.
Вообще при переводе необязательно сохранять дословный смысл, потому что языки отличаются не только словами, и буквальный перевод будет выглядеть как у ребят из Edison.
Например, "It was the right bet." переведённая как "И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"
Т.е., несмотря на то, что ряд Ваших исправлений в кассу, я бы призвал не гнаться за буквальным соответствием.
Вы утрируете. Полно случаев, когда можно слегка улучшить код по ходу дела, не меняя его поведения и не разбираясь, как можно/нельзя изменить его поведение. И в любом случае, если Вы хоть как-то измените поведение, то это уже будет не рефакторинг. И лучше это делать отдельным коммитом, когда надо.
Почему мусор? undefined — это вполне рабочее значение в JavaScript. Нравится Вам или нет, но факт в том, что это так.
P.S. Слушайте, я тоже не в восторге от JS и вообще фронтом практически не занимаюсь… но там сам JS-мир слегка сумасшедший, Вы конечно можете старательно огораживаться, не принимая их практики, но смысла мало.
В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".
Не работаем с ним :-)
Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.
Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.
Шикарный пример оптимизации xD
А если серьёзно, то проблема действительно есть… мало программистов задумываются о производительности своего кода, хотя в большинстве случаев это упирается в незнание SQL. Ну и да, иногда попадаются на ревью квадратичные алгоритмы там, где можно было бы обойтись линейным, но это гораздо реже.
И что? В данном случае, единственное описание API — это сам код. Так тоже бывает.
Ну так я и пытаюсь эту мысль донести. Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров.
Ну или не плачьте, когда прод упадёт :-)
В чём тут "слёт с катушек"? Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean? Не так уж редко именно это и требуется, вне зависимости от входных параметров. Ваши фантазии на тему неопределённых результатов имхо оффтопик.
На основании чего? Это уже исключительно Ваши домыслы.
Мы обсуждаем варианты переписать существующую функцию, не имея никаких явных требований (есть только те, что заложены в код)… Это рефакторинг в чистом виде и ничто больше.
Вы же мотивируете только тем, что "автор — дурак, потому что я так считаю"… Это непрофессионально и все эти сокращения по факту оказываются дешевыми понтами, если не можешь сократить без изменения поведения кода.
Ну, а что такое рефакторинг? Это улучшение кода без изменения его API. Исходный код всегда возвращает либо true, либо false. Требований у нас нет, значит мы при переписывании кода обязаны подразумевать что такое требование было. И результат итоговой функции должен совпадать с результатом исходной на всём множестве значений аргументов. Мы тут не вдаёмся в причины этого требования, может результат надо было запихнуть в JSON и отправить какому-нибудь микросервису на Go (вот он обрадуется, когда получит "undefined" вместо false).
Но причины требования не суть важны в данном примере, важно, что сохранность API — это базовые основы рефакторинга. И куча людей этого не понимает, что уже печально. Получается, хотели показать как они круты, переделав код из статьи, а по факту опозорились. Но не в силах признать ошибку, предпочитают заминусить… Ну ладно, желаю им профессионального роста. Может через пару лет поймут, что признать ошибку не стыдно, стыдно — не признать )))
Это отличный вариант для строго типизированного языка. При динамической же типизации у вас нет контракта какого типа аргументы придут в функцию. hardWork внезапно может оказаться undefined.
Поэтому как не изголяйтесь, а явное приведение к boolean будьте любезны написать, раз функции требуется возвращать именно true/false. Забыть про это приведение — типичная ошибка новичка.
Кол-во минусов к моему исходному комментарию показывает только то, что есть немало людей, которые пишут код на JavaScript ещё хуже, чем автор статьи. При этом они сами пока об этом не догадываются… недостаток опыта он такой, даёт ложную уверенность в своей неправоте :-)
Это более хрупкий вариант… в текущем JS сработает, а в других языках не получится сравнить 0 и boolean. А это тоже допустимый вариант, если допустим hardWork — boolean, a luck — число от 0 до 10. Так что либо !!, либо явное приведение:
return Boolean(isPrepared);Тогда уж
Только стоит ли сокращать эту запись, если как минимум 6 шутников в комментариях сократили её некорректно? Вопрос далеко неоднозначный.
Ещё была классная подборка материала — Delphi Russian Knowledge Base. Помню, как я в интернет-центре целый час скачивал её… хотя она весила всего 3 Mb :-D
Зато потом дома можно было без интернета изучать интересный материал.
Вы так пишете, как-будто C++ проще и логичнее, чем Delphi. Хотя по факту там своих "особенностей" выше крыши и гораздо больше, чем у Delphi.
Да, неправильно Вас понял… Насчёт точка vs стрелочка для вызова методов, согласен, что точка удобнее.
Это конкатенация то самый популярный оператор? Для того, чтобы что-то вставить в строку в 90% случаев интерполяция используется… Теперь она даже в JS есть под названием "String Substitution".
Нормальный REPL обещают в Java 9. В общем, слоупочат с официальной поддержкой, как всегда.
Java Playground, Java REPL. Далеко не самые удобные, но хоть что-то…
В качестве первого языка, я бы Java не советовал.
Сейчас по-моему уже для любого языка есть либо REPL, либо Playground, либо и то и то. Так что проблем с быстротой старта в первый результат никаких нет.
Тут нужен баланс… Код должен быть настолько коротким, насколько это возможно без потери выразительности, но не короче :-)
Просто считается, что это надо в личку автору перевода писать. Хотя я такую агрессию не одобряю, т.к. тема улучшения переводов тоже интересная.
Ну нет, всё-таки оригинал о том, что фреймворк не стал для них узким местом, несмотря на большую посещаемость. Иначе вторая часть фразы(про сегодняшний день) напрочь теряет смысл.
Но если подумать, то это вполне корректная адаптация к российским реалиям. Это у них распространённая практика для каждого нового проекта открывать новую компанию. У нас так не принято. Вот и получается, что речь в статье именно о старте новых проектов, просто для американца начать проект и открыть компанию — это одно и то же.
Раз Вы вынесли это в комментарий, подразумеваю, что Вы хотите обсудить тему улучшения переводов не только с автором, поэтому вставлю свои 2 копейки.
В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.
Вообще при переводе необязательно сохранять дословный смысл, потому что языки отличаются не только словами, и буквальный перевод будет выглядеть как у ребят из Edison.
Например, "It was the right bet." переведённая как "И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"
Т.е., несмотря на то, что ряд Ваших исправлений в кассу, я бы призвал не гнаться за буквальным соответствием.