Комментарии 107
Наводите порядок в коде, с которым работаете.
Сомнительный совет.
Любая правка — это автоматически ненулевой шанс внести ошибку. Люди, знаете ли, не автоматы, и довольно часто ошибаются в простых казалось бы вещах.
А то, что затронутый код не нужен для решения вашей текущей задачи, автоматически означает, что и тестировать его вы вряд ли будете так же качественно, как основные правки. И вот тут — внимание, большой вопрос: стоит ли заниматься таким «улучшайзингом» в системе, если от нее зависит прибыль всей конторы (или жизни людей, или и то, и другое)?
Ну, если не учитывать конкретную ситуацию и здравый смысл, то в принципе любой совет можно назвать сомнительным при определенных условиях. Но это не значит что совет плох.
Разумеется, заниматься «улучшайзингом» стоит с учетом покрытия тестами, зоны ответсвенности, и того, насколько код горячий, либо грешит неочевидными последствиями
Разумеется, заниматься «улучшайзингом» стоит с учетом покрытия тестами, зоны ответсвенности, и того, насколько код горячий, либо грешит неочевидными последствиями
Поспорю, это прекрасный совет. По моим наблюдениям основная причина багов, это то, что программист не совсем понимает код, вторая причина — невнимательность, вследствие усталости. Баги от рефакторинга, это большая редкость, ну если вы не рефакторите вручную конечно.
Сам процесс рефакторинга очень помогает разобраться в деталях, ведь что бы все пересобрать «как надо» и очистить, нужно понять, как оно вообще работает.
Далее, пересобранный и очищенный код легче понять, следовательно в нем меньше багов, его легче поддерживать и вносить изменения.
Ну если такой код не покрыт тестами на 1000%, то это как с бэкапами, «люди делятся на 2 типа, на тех кто еще не делает бэкап...» и так далее.
Сам процесс рефакторинга очень помогает разобраться в деталях, ведь что бы все пересобрать «как надо» и очистить, нужно понять, как оно вообще работает.
Далее, пересобранный и очищенный код легче понять, следовательно в нем меньше багов, его легче поддерживать и вносить изменения.
стоит ли заниматься таким «улучшайзингом» в системе, если от нее зависит прибыль всей конторы (или жизни людей, или и то, и другое)?
Ну если такой код не покрыт тестами на 1000%, то это как с бэкапами, «люди делятся на 2 типа, на тех кто еще не делает бэкап...» и так далее.
основная причина багов, это то, что программист не совсем понимает код, вторая причина — невнимательность, вследствие усталости.Отсюда, имхо, можно сделать логичный вывод. Важнее понять код, чем рефакторить его. Не надо тратить время на необязательный рефакторинг, что бы не устать на момент когда дойдет дело до обязательной работы:)
Сам процесс рефакторинга очень помогает разобраться в деталях, ведь что бы все пересобрать «как надо» и очистить, нужно понять, как оно вообще работает.Тому кто рефакторит — безусловно помогает. Т.к. рефакторинг даже будучи сделанный по гайд-лайнам, все равно несет в себе индивидуальный отпечаток.
Помогает и новичкам, при условии что после рефакторинга код действительно стал именно лучше, а не просто стал другим — такое тоже бывает.
А вот старой команде, которой был привычен старый код — необходимость разбираться в новом, пусть и более качественном коде, не обязательно поможет.
Тут немного есть ассоциация с анекдотом, где мысль в том, что жена прибралась в гараже у мужа и теперь он ничего не может найти.
если такой код не покрыт тестами на 1000%Ни разу не видели код покрытый тестами хотя бы на 80%.
Как по нам с рефакторингом ситуация простая — «работает — не трогай»©
Просто «для искусства» можно рефакторить свои пет-проекты на досуге, благо это процесс бесконечный, как ремонт.
Ни разу не видели код покрытый тестами хотя бы на 80%.
В SQLite 100% branch coverage. Правда, на практике это не особо помогает.
Думаю, тут имелась в виду коммерческая разработка. Все компании на собеседованиях говорят, что «да, конечно, мы юнит-тесты практикуем». На деле тестами покрыт максимум самые мишшн-критикал куски кода, которые, внимание, редко меняются. Так как в них зашита логика базовых бизнес-процессов компании, которые, понятно, не могут резко поменяться. А править нужно ту самую утилиту, написанную два года назад в спешке, что всё это время отлично работала и вдруг сломалась — и такие места обычно имеют ровно 0% code coverage.
Жизнь…
Жизнь…
В этой ветке остро не хватает Дедфуда.
Я из тех кто раньше делал бакабы теперь в коробках дежат cd, dvd, mini-dv кассеты (а ведь их перематывать надо) hdd от 100мб до 1гб, теперь уже и не подключить часть из них ide.
Короче я перестал делать бакапы их невозможно хранить, т.е. носители отмирают слишком быстро.
Все что мне нужно или на гугл-фото или на гитхабе, остальное вероятно никому-никогда не понадобится.
я перестал делать бакапы их невозможно хранить, т.е. носители отмирают слишком быстро.Без обид, но имхо это не носители отмирают слишком быстро, а Вы просто забили на это дело.
Даже сейчас — mini-dv кассету — на автомате можно слить, поставил оно качается, в зависимости от камеры можно даже 4х скорость сделать. Да, менять руками придется. А h264/h265 ужмет некисло и быстро на современном железе.
cd/dvd до сих пор живы, даже ноуты с ними можно найти.
Для ide устройств продаются недорогие usb адаптеры, тоже не проблема.
остальное вероятно никому-никогда не понадобится.У нас была куча фоток сделанных еще хз когда, когда много ходили с фотиком и снимали все подряд. Думали уже — никто никогда все это не разберет и на фиг надо.
Ан нет.
Благодаря относительно недавнему появлению качественного софта по сортировке и объемным современным дискам — удалось загнать всё на пару хдд и большУю часть разложить по датам (данные с exif или имя файла там где оно не dsc000), людям (распознавание лиц), географии съемки (снятые объекты + привязка по времени соседних фоток) и заодно избавиться от некачественных дублей на автомате (там где снимаешь серию, но 9 из 10 со смазом).
Некоторые вещи которые уже и забыли что они где-то есть — неожиданно и приятно всплыли.
А что за софт?
НЛО прилетело и опубликовало эту надпись здесь
+1 к просьбе подсказать имя софта :)
А что за софт? На каком-то NAS?
Особенно интересна тема распознавания лиц. Из того софта что я лично переюзал на линухе осталось в целом неудовлетворительное ощющение. Потому что вроде нормально, но начинаешь использовать и начинается: то одной фичи нет, то другой, то интерфейс отвратный.
НЛО прилетело и опубликовало эту надпись здесь
Все прекрасно делается. Поднимите RAID-1 хотя бы на террабайтниках и пишите туда.
Согласен с тем, что это — сомнительный совет. Но в основном не из-за ошибок. Если уж вы рефакторите кусок кода, то либо он уже покрыт тестами, либо это ваша обязанность перед рефакторингом.
Но сомнительный он из-за возможных изменений в тех частях кода, которые не связаны с вашей текущей задачей. Это вносит большую неразбериху в систему контроля версий. Тот, кто после вас будет разбираться с тем, как вы решили задачу, увидит, например, что вы изменили 10 файлов вместо одного, в котором содержался баг. Как ему найти собственно исправление бага?
Но сомнительный он из-за возможных изменений в тех частях кода, которые не связаны с вашей текущей задачей. Это вносит большую неразбериху в систему контроля версий. Тот, кто после вас будет разбираться с тем, как вы решили задачу, увидит, например, что вы изменили 10 файлов вместо одного, в котором содержался баг. Как ему найти собственно исправление бага?
Тот, кто после вас будет разбираться с тем, как вы решили задачу, увидит, например, что вы изменили 10 файлов вместо одного, в котором содержался баг. Как ему найти собственно исправление бага?Два коммита? Рефакторинг и непосредственно исправление бага. С пометками о том что есть что разумеется.
НЛО прилетело и опубликовало эту надпись здесь
Это был ритуал? Или какое-то обоснование такой практике озвучивали?
Обоснование очевидно любому, кто делает ревью таким PR.
Да, ревью кода, где намешаны изменения логики работы и рефакторинг — это ад. Visual Studio с ее предложениями изменения синтаксиса в С# особенно прекрасна. Смотришь мёрж реквест, вникаешь в изменения и тут бац, заменённый синтаксис case на новый модный в двадцати файлах проекта. Посылаешь лучи добра автору кода.
У нас, например, есть четкое правило: заметил говнокод — заводи отдельный таск в джире с типом «рефакторинг» и делай все изменения в его ветке. Если позволяет время спринта, он вносится асапом и выполняется до таска с изменениями логики. Если нет — ну сорян, надо работать с тем, что есть, а рефакторить после (зависит от критичности таска, конечно).
У нас, например, есть четкое правило: заметил говнокод — заводи отдельный таск в джире с типом «рефакторинг» и делай все изменения в его ветке. Если позволяет время спринта, он вносится асапом и выполняется до таска с изменениями логики. Если нет — ну сорян, надо работать с тем, что есть, а рефакторить после (зависит от критичности таска, конечно).
У нас, например, есть четкое правило: заметил говнокод — заводи отдельный таск в джире с типом «рефакторинг» и делай все изменения в его ветке.
А если исправление маленькое? Завести задачу, завести ветку, а потом ещё раз описать изменение в коммите — звучит чересчур громоздко для, например, исправления опечатки в имени переменной. Не получается ли в результате, что на мелкие исправления просто забивают? Или "протаскивают" их в несвязанных по смыслу коммитах, за что потом шлются лучи добра?
Если переменная используется в пределах одного метода, то да, разумеется заводить багу отдельную никто не будет. Но если например ошибка в имени класса, который используется в десятках других классов, то даже только ради удобства ревью я бы предпочел это видеть отдельной задачей. А вдруг эту самую библиотеку, в которой делаются правки, кто-то импортит из другого проекта и в следующий импорт код внезапно сломается.
Или, скажем, мы видим очепятку на сайте, вносим никому не сказав правки. В том числе не предупредив людей, отвечающих за контент сайта. В следующий раз они пришлют правки текстов снова с этой очепяткой и другой программист тупо заменит пофиксенные тексты на сайте на пришедшие с оставшейся в них опечаткой.
Общая идея, что с одной стороны бюрократия — зло, но с другой лично у меня заведение типовой задачи в джире + сделать ветку в гитхаб десктоп занимает ну секунд 30 времени. Зато потом всем проще.
Или, скажем, мы видим очепятку на сайте, вносим никому не сказав правки. В том числе не предупредив людей, отвечающих за контент сайта. В следующий раз они пришлют правки текстов снова с этой очепяткой и другой программист тупо заменит пофиксенные тексты на сайте на пришедшие с оставшейся в них опечаткой.
Общая идея, что с одной стороны бюрократия — зло, но с другой лично у меня заведение типовой задачи в джире + сделать ветку в гитхаб десктоп занимает ну секунд 30 времени. Зато потом всем проще.
Хороший пример того, как простая опечатка правилась несколько лет: в libxml кто-то завёл поле childs в структуре. Ну не слишком хорошо знаком разработчик знает английский.
Проблема в том, что вся эта библиотека, сверху донизу и снизу доверху — построена вокруг работы с этой структурой. Банальная правка привелабы к тому, что перестали бы собираться тысячи программ у десятков тысяч разработчиков…
В результате переименования
Проблема в том, что вся эта библиотека, сверху донизу и снизу доверху — построена вокруг работы с этой структурой. Банальная правка привелабы к тому, что перестали бы собираться тысячи программ у десятков тысяч разработчиков…
В результате переименования
childs в children пришлось ждать несколько лет — до выхода версии libxml 2.В чём принципиальная разница между отдельной веткой и отдельным комитом со стилевыми правками в фича-ветке? При ревью можно же взглянуть на правки конкретных комитов.
Если коммитов в ветке два — на первый взгляд никакой, их действительно несложно посмотреть отдельно. Но первая проблема в том, что их почти никогда не два — дальше начинаются правки по замечаниям ревью и количество коммитов растёт, а вторая в том, что на ревью замечания пишутся на весь PR, т.е. на ветку, а не на коммит. Аппрув ставить и мержить так же имеет смысл раздельно рефакторинг и изменения функционала.
Правки по замечаниям ревью обычно амендятся в тот коммит, к которому они относятся, итого было 2 коммита в первой версии PR — осталось два коммита в финальной версии PR. Разных коммита, ну да.
Тут зависит от того, как процесс построен. Если команда понимает и обсудила workflow, то проблем никаких. И да, я определенно согласен с автором комментария, что заводить отдельную(!) таску(!!) в джире(!!!) на рефакторинг, который может быть произведен «на лету» без последствий (и когда время, затраченное на, собственно, рефакторинг, много меньше времени, затраченного на создание тасок, лишней ветки, времени ревьюверов) — это какой-то оверкилл.
В то же время, если рефакторинг затрагивает внешнее API, или затрагивает сотню файлов проекта, или это не тупое переименование переменных а именно смысловое написание кода, то в этом случае, конечно, отдельная таска и планирование имеют место быть.
Тут зависит от того, как процесс построен. Если команда понимает и обсудила workflow, то проблем никаких. И да, я определенно согласен с автором комментария, что заводить отдельную(!) таску(!!) в джире(!!!) на рефакторинг, который может быть произведен «на лету» без последствий (и когда время, затраченное на, собственно, рефакторинг, много меньше времени, затраченного на создание тасок, лишней ветки, времени ревьюверов) — это какой-то оверкилл.
В то же время, если рефакторинг затрагивает внешнее API, или затрагивает сотню файлов проекта, или это не тупое переименование переменных а именно смысловое написание кода, то в этом случае, конечно, отдельная таска и планирование имеют место быть.
обычно амендятся в тот коммит
Это требует несколько большей аккуратности от разработчиков, чем в большинстве команд реально добиться. Я пришёл к тому, что разрешаю в своей команде коммиты в PR делать сколько и как им угодно, но при мерже этот PR squash-ится с корректным (по conventional commits) сообщением. Это даёт и чистую историю, и не перегружает команду формальными требованиями к процессу.
Кроме того, мы не практикуем никакое переписывание истории после git push, а ревью определённо начинается уже после git push.
Ок, понятно. У нас в команде наоборот — у нас был Gerrit еще год-полтора назад, поэтому привычка «писать нормальные коммиты и сообщения коммитов» у всех есть, во время Геррита за кривые коммиты по рукам били и не аппрувили ревью :). И с переездом на Gitlab она не изменилась, посему и merge policy у нас — rebase-only, fast-forward, no squash, no merge commit. Т.е. если автор PR сам хочет, он, конечно же, может засквошить свои коммиты при мерже, но обычно все вливается «как есть». И да, force push в своих ветках (где разработчик один работает) — абсолютно нормальное и каждодневное явление, поддерживает чистую историю на протяжении всей жизни PR/бранча.
Так после отправки кода на код ревью он уже не один работает. Кто-то посмотрит в вебморде пулл-реквест, а кто-то спуллит локально, чтобы в ИДЕ посмотреть нормально
Кто-то мешает новую версию к себе втянуть?
Ну так пусть пуллит, а после апдейта обновляете и все отлично
git fetch && git reset --hard origin/myfeaturenamegit pull проще
Если вы используете git pull. то вы смотрите не на тот код, который вам прислали на review, а на некую «вариацию на тему».
Это, конечно, ваше право — но если вы этим занимаетесь, то и разгребание последствий — тоже ваша задача.
Git — это инструмент для написания истории, не для хранения (для этого есть mercurial).
Если вы историю, в принципе, не пишите — нафига вам Git???
Это, конечно, ваше право — но если вы этим занимаетесь, то и разгребание последствий — тоже ваша задача.
Git — это инструмент для написания истории, не для хранения (для этого есть mercurial).
Если вы историю, в принципе, не пишите — нафига вам Git???
Почему я смотрю не тот код, который мне прислали на ревью? У меня нет привычки в ветках, отданных на ревью коммитить что-то своё. А изменения истории запрещены соглашениями.
Можно пруф, что гит — это для написания истории? Мне-то как раз mercurial больше нравится, но стандарт де-факто — git.
У меня нет привычки в ветках, отданных на ревью коммитить что-то своё.Если вы туда ничего своего не коммитите, то зачем вам Git Pull? Достаточно Git Fetch.
Можно пруф, что гит — это для написания истории?Ну почитайте оффициальные рекомендации.
Или загляните в LKML. Вот прямо сегодня: PATCH v2, PATCH v3, PATCH v5, PATCH v7… вот что это такое?
Это — изменение серии PATCH'ей с целью сделать так, чтобы каждый из них был понятен. Ядро всегда так разрабатывалось. Ещё с прошлого века. А Git, в общем-то, был создан именно чтобы поддержать разработку ядра. Про остальное же Линус чётко говорит: What I find interesting is how it took over so many other projects, too.
Они никогда этого не планировал и на это не рассчитывал…
Мне-то как раз mercurial больше нравится, но стандарт де-факто — git.Меня это вообще всегда удивляли. Потому что у них, во-многом, противоположные подходы.
У Mercurial подход «история проекта важна — и потому мы не позволим каким-то там девелоперам её тривиально менять». И набор инструментов которые позволяют (и не позволяют, что в данном случае важнее) что-то делать.
У Git подход «история проекта важна — и потому мы дадим разработчику инструменты для её написания».
Git rebase, Git cherry-pick, Git rerere (вы вообще в курсе существования такой команды… поинтересуйтесь что она делает и подумайте о том — зачем она вообще может быть нужна) и прочие.Потому больше всего удивляют люди, которые выбирают Git, а потом начинают жаловаться на то, что кто-то им историю «попортил»! Не «попортил», а «написал»… и Git для этого, в общем-то, и предназначен!
Хотите неизменную историю и стабильных бранчей… зачем вам Git, возьмите Mercurial!
Вот в официальных рекомендациях первое правило: History that has been exposed to the world beyond your private system should usually not be changed
Ну и дальше: Merging is a common operation in the kernel development process;
И ещё раз, обычно git выбирают как индустриальный стандарт де-факто, а не сравнивая его с другими VCS.
Ну и дальше: Merging is a common operation in the kernel development process;А вот ещё дальше: While merges from downstream are common and unremarkable, merges from other trees tend to be a red flag when it comes time to push a branch upstream
Вот в официальных рекомендациях первое правило: History that has been exposed to the world beyond your private system should usually not be changedДа. Это полезно и разумно. Потому после
rebase ваша история получает приписку «v2», «v3», «v7», «v10». Разумеется вливается в окончательную версию только «v7» или «v10». Всё остальные — остаются только в деревьях авторов, их породивших.У других (пользователей Gerrit, например) — считается, что это не так важно и приписка «v10» не делается. И да, история, конечно, не меняется — в том смысле что в том репозитории, которым заведует Gerrit-сервер всё остаётся.
Но вот уже в релиз — идёт только «причёсанная история». Ну вот как-то так и так.
И ещё раз, обычно git выбирают как индустриальный стандарт де-факто, а не сравнивая его с другими VCS.Но… почему? Я понимаю отказаться от какого-нибудь GNU arch, которым никто не пользуются и разработка заброшена, потому что это «не стандарт», но Mercurial не является уж чем-то сильно хитрым и редким.
Если вы так часто это делаете, то в гите есть алиасы :) И никто вам не мешает сделать алиас типа
Ну или через git aliases что-то подобное можно провернуть. И та-да, теперь еще проще — просто «pullmr» и все.
А просто pull, как уже выше сказали, имеет некоторые сайд эффекты, что рано или поздно приведет вас к неожиданному редактированию сообщения мерж-коммита (когда образовались конфликты). А если вы не работаете с мержами в принципе, то «проще» разработчикам будет «git pull --rebase», что уже не так «проще» напечатать как просто пулл.
.bashrc
alias pullmr=git fetch && git reset --hard `git rev-parse --abbrev-ref --symbolic-full-name @{u}`Ну или через git aliases что-то подобное можно провернуть. И та-да, теперь еще проще — просто «pullmr» и все.
А просто pull, как уже выше сказали, имеет некоторые сайд эффекты, что рано или поздно приведет вас к неожиданному редактированию сообщения мерж-коммита (когда образовались конфликты). А если вы не работаете с мержами в принципе, то «проще» разработчикам будет «git pull --rebase», что уже не так «проще» напечатать как просто пулл.
Амендятся на давно запушенный коммит?
Ну что значит «давно», если это PR, то вроде как по определению все коммиты в фиче-ветке не очень «давно». Мы ребейзим постоянно на мастер, чтобы поддерживать в актуальном состоянии.
Амендятся в соответствующий коммит в фиче-ветке, ну да, который был запушен некоторое время назад, до того, как ревьювер написал комментарий.
Амендятся в соответствующий коммит в фиче-ветке, ну да, который был запушен некоторое время назад, до того, как ревьювер написал комментарий.
Так мы в конце концов и договорились делать в команде.
Никто не призывает рефакторить вообще везде (см. совет про перебарщивание). Выносите рефакторинг отдельным PR, если там много изменений. А совет отличный.
Мне в связи с этим вспоминается комментарий в одном changelog'е (слава богу, я на том проекте не работал) — «версия законченная, но неработоспособная». Так и тут — код чистый и хороший, но не работает.
Читайте совет полностью. Он предлагает улучшить код, например, в том же классе, в который вы вносите правки. А не переделывать всё подряд под себя, потому что не нравится.
А если совсем не заниматься «улучшайзингом», то система в скором времени скатится в «Big ball of mud» — для чего есть очевидные предпосылки — первоначальный дизайн никогда не удовлетворит все будущие требования.
А если совсем не заниматься «улучшайзингом», то система в скором времени скатится в «Big ball of mud» — для чего есть очевидные предпосылки — первоначальный дизайн никогда не удовлетворит все будущие требования.
Он предлагает улучшить код, например, в том же классе, в который вы вносите правки. А не переделывать всё подряд под себя, потому что не нравится.
Читайте комментарий полностью. Я нигде не утверждаю, что «улучшайзингом» надо заниматься сразу по всей кодовой базе.
А если совсем не заниматься «улучшайзингом», то система в скором времени скатится в «Big ball of mud»
Читайте комментарий полностью. Я нигде не утверждаю, что «улучшайзингом» вообще не надо заниматься.
TL;DR: Я утверждаю, что смешивать рабочий код с «улучшайзингом» соседнего кода — плохо.
Совет плох из-за того, что предлагает смешать два различных вида деятельности в один. Это вносит неразбериху в систему контроля версий: вместе с кодом задачи программист коммитит и не относящиеся к задаче правки. В результате найти концы («кто добавил эту логику?») становится затруднительно: git annotate покажет не автора, а «я только табы подправил».
Ну и про недостаточно тщательное тестирование правок в «не своем» коде я уже писал. «Собирается — и ладно, что там может сломаться?». Автотесты — это прекрасно, но далеко не везде они покрывают 100% кода (а в большинстве проектов, которые я видел, они вообще покрывают произвольно выбранные клочки кода — то, что автор посчитал «сложным кодом»).
Посему во многих проектах такая деятельность прямо запрещена гайдами. Для рефакторинга — отдельная таска. Обнаружил ошибочный код при решении своей задачи? Если он не входит в область видимости задачи — создавай отдельную таску. А мешать — не надо.
Согласен, что закладывать совместно и решение задачи, и что-то слабо относящееся к задаче в одном коммите это вносит неразбериху. (Хотя если следовали Single Responsibility — код в одном классе будет всё-таки связан с задачей или багом. А если не следовали, то фикс для бага — хороший повод провести улучшение кода — всё равно придётся анализировать код в процессе фикса.)
И тут, конечно, могут быть свои стайл гайды — вплоть до отдельной таски или отдельной ветки. Но всё это не нарушает совет — главное оставить код лучше, чем он был — хоть немного.
И тут, конечно, могут быть свои стайл гайды — вплоть до отдельной таски или отдельной ветки. Но всё это не нарушает совет — главное оставить код лучше, чем он был — хоть немного.
Я видел проект, несколько лет разрабатываемый по принципу «работает — не трожь» или «патч должен быть минимальным».
— Код встречается в 20 разных местах? Нет, в функцию выносить не надо, правь все 20 мест как есть.
— Надо добавить параметр в функцию? Дай ему значение по умолчанию, чтобы не править все вызовы, даже если оно там бессмысленно.
— Код зависит от глобальных переменных? Нет, не надо ничего переделывать, просто добавь еще одну. Тестов у нас все равно нет.
— Что-то больше не используется? Ну и что, пусть будет. В крайнем случае закомментируй.
И так далее и тому подобное, повторенное многократно.
В результате получается прекрасная, компактная история в контроле версий, где все по делу.
Правда, непосредственно код при этом почему-то превращается в спагетти, правка багов требует медитации и телепатических способностей, а от предложений новых фич случается нервный смех и дергается глаз.
— Код встречается в 20 разных местах? Нет, в функцию выносить не надо, правь все 20 мест как есть.
— Надо добавить параметр в функцию? Дай ему значение по умолчанию, чтобы не править все вызовы, даже если оно там бессмысленно.
— Код зависит от глобальных переменных? Нет, не надо ничего переделывать, просто добавь еще одну. Тестов у нас все равно нет.
— Что-то больше не используется? Ну и что, пусть будет. В крайнем случае закомментируй.
И так далее и тому подобное, повторенное многократно.
В результате получается прекрасная, компактная история в контроле версий, где все по делу.
Правда, непосредственно код при этом почему-то превращается в спагетти, правка багов требует медитации и телепатических способностей, а от предложений новых фич случается нервный смех и дергается глаз.
НЛО прилетело и опубликовало эту надпись здесь
В целом полностью согласен с вами, но не могли бы вы развернуть конкретный пункт?
Понятно, что через несколько итераций имеет смысл пересмотреть и, быть может, переписать функцию, но конкретно сейчас «ага, вот у нас есть функция, нам надо добавить выбор формата, допустим. Добавим параметром, по умолчанию оставим текущее поведение» — я в упор не вижу проблемы, что не так? Если условный параметр на самом деле принадлежит этой функции, то почему бы и нет?
— Надо добавить параметр в функцию? Дай ему значение по умолчанию, чтобы не править все вызовы, даже если оно там бессмысленно.
Понятно, что через несколько итераций имеет смысл пересмотреть и, быть может, переписать функцию, но конкретно сейчас «ага, вот у нас есть функция, нам надо добавить выбор формата, допустим. Добавим параметром, по умолчанию оставим текущее поведение» — я в упор не вижу проблемы, что не так? Если условный параметр на самом деле принадлежит этой функции, то почему бы и нет?
Добавим параметром, по умолчанию оставим текущее поведение» — я в упор не вижу проблемы, что не так?
Не так там последняя часть. А именно «даже если оно там бессмысленно».
Проблема как раз в том, что на каждой итерации никто проблемы не видит.
Через 10 итераций у функции 10 параметров по умолчанию, половина из них используется только если, например, первый параметр равен false, другая половина — если первый параметр равен true, а третий — 42. Новые параметры, естественно, добавляются в конец (чтобы не менять существующий код), даже если они используются куда чаще существующих. В результате, чтобы указать этот последний параметр, надо указать и все остальные, при этом см. выше — понять по сигнатуре, что там происходит, уже невозможно. В коде тут и там появляются шедевры вида function(false, true, false, false, false, true, true, true, false). В один прекрасный день кто-то забывает явно указать последний параметр в паре мест, но все компилируется и даже вроде бы работает, а через пару лет вы тщетно пытаетесь понять, что давно уволившийся автор хотел этим сказать.
Через 10 итераций у функции 10 параметров по умолчанию, половина из них используется только если, например, первый параметр равен false, другая половина — если первый параметр равен true, а третий — 42. Новые параметры, естественно, добавляются в конец (чтобы не менять существующий код), даже если они используются куда чаще существующих. В результате, чтобы указать этот последний параметр, надо указать и все остальные, при этом см. выше — понять по сигнатуре, что там происходит, уже невозможно. В коде тут и там появляются шедевры вида function(false, true, false, false, false, true, true, true, false). В один прекрасный день кто-то забывает явно указать последний параметр в паре мест, но все компилируется и даже вроде бы работает, а через пару лет вы тщетно пытаетесь понять, что давно уволившийся автор хотел этим сказать.
Надо добавить параметр в функцию? Дай ему значение по умолчанию, чтобы не править все вызовы, даже если оно там бессмысленно.
Конечно дай значение по умолчанию. Нет, оно там не бессмысленно, иначе бы не добавляли.
зачастую пишется, черновой алгоритм в виде одной большой процедуры, а переложить его в функции при повторении, людям уже лень. А потом ты смотришь на процедуру в 1000 строк, которая делает 19 вариантов, одного и того же действия. И не можешь ничего с ней делать, поскольку проще ее переписать, чем если бы изначально человек после выполнения, первого варианта вынес действие в функцию. Это базовый пример.
Золотое правило сисадминов, но и программистов — работает, не трогай! «Улучшательство» ради «улучшательства» может привести к ошибкам во всей системе. И выставлению санкций «улучшателю» само собой
3 противоречит 1. KISS всегда противоречит порядку (шаблонам) потому что шаблоны добавляют сущности.
5 никто не использует. Код меняется быстрее и комментарии устаревают, вводят в заблуждение. Комментарии нужны только там, где код делает то что от него не ожидается.
5 никто не использует. Код меняется быстрее и комментарии устаревают, вводят в заблуждение. Комментарии нужны только там, где код делает то что от него не ожидается.
5 никто не использует. Код меняется быстрее и комментарии устаревают, вводят в заблуждение. Комментарии нужны только там, где код делает то что от него не ожидается.
Вот не надо говорить за всех. Потому что во первых комментарии и документация это далеко не всегда одно и тоже.
Кроме того там стоит и следующее:
Дайте себе некоторое время на то, чтобы придумать описательные имена переменных. Это себя окупит. Выбор хороших имён для переменных, методов и классов требует времени. Но хорошие имена позволят сэкономить больше времени, чем нужно на их выдумывание.
И это на мой взгляд очень хороший совет.
НЛО прилетело и опубликовало эту надпись здесь
3 не противоречит 1.
3-ий говорит о том, что не надо писать то, что действительно не требуется прямо сейчас (заказчиком или требованиями), то есть не надо реализовывать что-то на будущее. Потому что в будущем могут появиться, вообще, прямо противоположные требования.
1-ый же говорит: «Вот делаешь изменения — почисти старый код, чтобы он, возможно, не конфликтовал с новыми реалиями, а, возможно, просто не очень аккуратный старый код или совсем не аккуратный старый код.»
3-ий говорит о том, что не надо писать то, что действительно не требуется прямо сейчас (заказчиком или требованиями), то есть не надо реализовывать что-то на будущее. Потому что в будущем могут появиться, вообще, прямо противоположные требования.
1-ый же говорит: «Вот делаешь изменения — почисти старый код, чтобы он, возможно, не конфликтовал с новыми реалиями, а, возможно, просто не очень аккуратный старый код или совсем не аккуратный старый код.»
Комментарии нужны только там, где код делает то что от него не ожидается.
Да, было у нас таких пара человек. Слава богу быстро выгнали.
Наводите порядок в коде, с которым работаете
В политике гугла (или рекомендациях), тоже есть это, мол новый код не должен быть идеальным, и если он уже приносит улучшения в существующий код, то это уже хорошо.
Там немного про разные вещи. Рекомендация гугла относится к ежедневному процессу code review — не надо требовать рефакторинга, если правки кода не приводят к его явной необходимости. Собственно, я надеюсь, это правило соблюдается и вне гугла. Нужен рефакторинг? Сделай его в отдельном коммите, а лучше ветке.
Ужасно опасная статья, так как некоторые «советы» могут принести очень много вреда:
1. Наводите порядок в коде, с которым работаете
— Практика показала, что после парочки «мини изменений» git blame и прочие способы понять в какой момент была написана эта строча, а значит понять связь с таской, перестают работать.
4. Планируйте работу над кодом
— Самый ужасны из советов. Дело в том, что более менее сложные задачи достаточно тяжело распланировать заранее в голове. Как результат — ступор, когда ты не можешь написать первую строчку кода. Гораздо более надежное решение — итеративный инкрементальный подход, когда мы сначала реализуем задачу, а потом обязательно полируем-рефакторим. И да, я специально не говорю про TDD, дабы не разводить флейм.
5. Документируйте свои проекты
— А вот это, определенно, полезно. Только есть проблема — написать работающую безвредную документацию не менее сложно чем написать работающий безвредный код. Одной привычке недостаточно, необходимо умение и опыт
1. Наводите порядок в коде, с которым работаете
— Практика показала, что после парочки «мини изменений» git blame и прочие способы понять в какой момент была написана эта строча, а значит понять связь с таской, перестают работать.
4. Планируйте работу над кодом
— Самый ужасны из советов. Дело в том, что более менее сложные задачи достаточно тяжело распланировать заранее в голове. Как результат — ступор, когда ты не можешь написать первую строчку кода. Гораздо более надежное решение — итеративный инкрементальный подход, когда мы сначала реализуем задачу, а потом обязательно полируем-рефакторим. И да, я специально не говорю про TDD, дабы не разводить флейм.
5. Документируйте свои проекты
— А вот это, определенно, полезно. Только есть проблема — написать работающую безвредную документацию не менее сложно чем написать работающий безвредный код. Одной привычке недостаточно, необходимо умение и опыт
НЛО прилетело и опубликовало эту надпись здесь
п4. как раз о том чтобы не попадать в ступор и чётко видеть, где находишься при решении конкретной задачи. Естественно, не возможно детализировать задачу полностью до последней строчки кода. Но какие-то вешки надо сделать — определить какие классы будут затронуты в процессе решения, что там требуется изменить и в каком порядке. Возможно в процессе реализации что-то уточнится, а что-то из первоначального плана откинется. Но зато будет понятно двигаешься ли к поставленной цели или пытаешься по кругу вносить какие-то изменения наобум.
Окончательную полировку-рефакторинг, конечно, никто не отменял. В процессе реализации может накопиться много лишнего — всё-таки примерный план — это не UML с описанием всего возможного.
Окончательную полировку-рефакторинг, конечно, никто не отменял. В процессе реализации может накопиться много лишнего — всё-таки примерный план — это не UML с описанием всего возможного.
Гораздо более надежное решение — итеративный инкрементальный подход, когда мы сначала реализуем задачу, а потом обязательно полируем-рефакторим.
Ну вот вы уже составили минимальный план:
- реализуем задачу
- полируем-рефакторим
Разве это ужасно?
Ещё куда-то можно впихнуть "хотя бы минимально тестами покрыть"
- Сначала делаем, потом думаем и исправляем?
по п4.
баг или таск — это проблема, если вы впали в ступор, значит проблему вы ещё не нашли
если вы не нашли проблему, то что править? вы за слепой поиск?
баг или таск — это проблема, если вы впали в ступор, значит проблему вы ещё не нашли
если вы не нашли проблему, то что править? вы за слепой поиск?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Давайте, придумайте мне хорошее называние для переменной «количество пользователей, зарегистрировавшихся за последний месяц, но еще не удаленных, исключая бета-пользователей, и имевших за это время такую-то(еще предложение текста) активность»Лехко! Спросите у ваших менеджеров — как они таких пользователей называют. Получится имя в духе ActiveUsers, RealUsers или, на худой конец Active30DayUsers.
Ну потому что не зря же вы в переменную вот это вот число засовывается — очевидно что оно как-то участвует в ваших бизнес-процессах. И в документации и переписке ну никто же не говорит про «количество пользоватей, которые бла-бла-бла… » — так обсуждать ничего невозможно… какой-то термин для вот этого числа используется же.
Если вы не можете придумать хорошее название для переменной — значит вы не понимаете ни зачем она вам нужна, ни что в ней, на самом деле хранится… продолжайте читать код и/или ТЗ дальше, до наступления просветления.
activeLastMonthUsers_toDelete
activeLastMonthBetaUsers
Можете qty добавить если хотите подчеркнуть что это именно количество
Можете змею с верблюдом не смешивать, если религия
А вообще вон выше подсказали, что наверняка для всей этой бабушки уже есть какое-то общепринятое в команде слово. Вот его и используйте.
Все «полезные советы» являются типичными благопожеланиями. По большей части они тривиальны и даже несколько навязли в зубах. Все они плохо согласуются друг с другом, потому что используют один и тот же конечный ресурс: время программиста. Некоторые если не вступают в прямое противоречие, то вплотную к этому подходят, что хорошо заметно на примере первого, третьего и четвертого советов. В конечном счете, все советы, кроме, может быть, третьего, сводятся к тому, чтобы «быть хорошим мальчиком» и выполнять большую работу «за ту же зарплату». Опыт мировой педагогики за последние две тысячи лет показывает, что даже среди малолетних наблюдается серьезный дефицит энтузиастов, откликающихся на такие призывы, даже если они исходят от любимой мамочки.
НЛО прилетело и опубликовало эту надпись здесь
В конечном счете, все советы, кроме, может быть, третьего, сводятся к тому, чтобы «быть хорошим мальчиком» и выполнять большую работу «за ту же зарплату».
Выполнение этих советов полезно непосредственно для вашего здоровья, если только вы не последний день работаете с этим проектом.
Айзек Азимов сказал: «День, когда вы перестанете учиться, это день, когда вы начнёте деградировать»полностью согласен, уже на себе чувствую этот эффект. Надо это исправлять, пока не начал смотреть еще и пусть говорят…
2. Заботьтесь о тех, кто будет работать с вашим кодом после вас
Как-то я слышал, что код нужно писать думая, что его будет поддерживать маньяк-убийца, который будет знать ваш адрес.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Кстати да. Просветление настало именно когда в гордом одиночестве больше года работал над проектом. Пару раз столкнулся с тем что моя лень мне-же аукнулась, перестал откладывать на потом и стал делать аккуратнее. Ну и обидно когда на вопрос «какой му**к писал этоткод?» знаешь точный ответ.
Я стараюсь писать, думая про миллениала, получавшего "автоматы" по информатике.
Сорри, никого не хотел обидеть если что.
Заботьтесь о тех, кто будет работать с вашим кодом после вас.
Пошёл налил себе кофе, погладил по голове, сказал какой я молодец и что у меня всё получится
Одной из самых полезных привычек, которых нет у программистов: просыпаться до 11.
На мой взгляд, самый важный совет в этой статье — планировать код. Любой план сэкономит уйму времени. Без плана ты просто будешь тыкаться туда-сюда, не понимая, что именно от тебя требуется. Мне кажется, благодаря этому пункту ты просто на автомате будешь писать понятный код. Ну и благодаря плану его будет легче задокументировать)
Есть технология проектной разработки кода, когда сначала разрабатывается шаблон-структура проекта вместе с тестами, потом заполняются и детализируются отдельные блоки, детализация доходит до полнофункциональных блоков, и на этом разработка заканчивается. Тут автоматически и планирование и рефакторинг и документация, созданная еще до начала разработки кода…
НЛО прилетело и опубликовало эту надпись здесь
Компания MathWorks уже несколько лет демонстрирует возможность разработки радиолокатора таким путем — сначала создается проект, заполняется пустыми блоками, обвешивается тестами прямо в Simulink, потом блоки детализируются, проходят тесты, и дальше содержимое блоков переносится в конечные устройства (микроконтроллеры и ПЛИС). При этом структура проекта и тесты не меняются, меняется только детализация и конечные устройства. Наконец полученные и протестированные устройства стыкуются между собой и начинают работать без Simulink'а. То есть технология работает, есть примеры с подтверждением. И мы тоже стараемся так делать.
Разные есть хорошие технологии для написания проекта с нуля. Но чаще надо что-то модифицировать.
Основная проблема в том, что программисты, яро нарушающие какие-то из этих замечательных правил, искренне уверены, что уж они-то работают именно по ним.
Вот взять правило про планирование. Ну ведь каждый перед тем, как написать первую строку кода хоть чуть задумался, а что он кодит? Ну хоть на тридцать секунд? Ну а чем не планирование?!
и так далее, и так далее…
Вот взять правило про планирование. Ну ведь каждый перед тем, как написать первую строку кода хоть чуть задумался, а что он кодит? Ну хоть на тридцать секунд? Ну а чем не планирование?!
и так далее, и так далее…
О, горизонт планирования — это вопрос очень философский. Один мой знакомый рассказывал о том, как они обсуждали кадровый состав его отдела и планы… на 3 года вперёд.
Вы думаете — это возможно распланировать? Нет, если у вас задача — попил бюджета, тогда да, легко… А вот если вы чего-то реально разрабатываете?
Вы думаете — это возможно распланировать? Нет, если у вас задача — попил бюджета, тогда да, легко… А вот если вы чего-то реально разрабатываете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
6 полезных привычек, которые, что удивительно, есть лишь у немногих программистов