Я бы сказал что настоящая креативность - это выразить сложные идеи просто. А писать сложный код, с трудом проходящий ревью означает планировать ад в процессе отладки и сопровождения.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan
I hardly ever debug anything at all. с чем вас и поздравляю :Р
а если серьезно, достичь одних и тех же целей можно разными способами, назовем их условно "изящными", "умными" и "простыми".
Так вот "простые" - наиболее эффективны с точки зрения бизнеса (а ведь подавляющее большинство из нас работает за деньги, не правда ли). "простые" методы легче понять окружающим, их легче поддерживать, после того, как автор решит, что ему пора двигать из этого гадюшника, и т.д. Именно поэтому правильно организованный процесс (adequate change descriptions, code reviews, reproducible tests with every single change) - залог долговременного здоровья компании.
Да, "простой" код возмущает эстетов от программирования (я сам к таким когда-то относился). Но многолетний опыт заставил понять и противоположную точку зрения.
В мелких изменениях, и ревьюях на каждое изменение. То есть, идея частых коммитов мне тоже нравится, но мне нравится их делать на рабочую ветку (или ствол), который до полного релиза не виден пользователям. А ревьюи по уму надо делать на большие законченные фичи. Если их делать на каждое мелкое изменение, то волей-неволей ревьюер следует за ходом мысли изначального автора и не видит большую картину. То есть, если ставить целью ревьюев поиск неправильно поставленных пробелов - то да, так проще. Но это плохие, негодные ревьюи. А если ставить целью оценку правильности всей фичи и мыслепоиск глюков в ней, то надо рвеьюить большие куски кода сразу, разглядывая всю суету с дистанции.
И кто будет их отлаживать, когда результат получается неправильный?
Не говоря уже о том, что собственно классические юнит-тесты, да еще и не дай бог с моками - штука игрушечная. Упускает многие реальные взаимодействия. Правильные тесты должны быть юнит в том смысле, что по тесту на каждую мелкую фичу, но на как можно более интегрированном продукте.
Some code reviews made me throw away clever and creative code and replace it with something simple. Other code reviews made me throw away clumsy code and be quite creative to express the same thing clearly and simply. (And shorter!) Also, defending one's decisions in review comments is sometimes fun :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2012-03-15 07:54 pm (UTC)no subject
Date: 2012-03-15 07:59 pm (UTC)А писать сложный код, с трудом проходящий ревью означает планировать ад в процессе отладки и сопровождения.
no subject
Date: 2012-03-15 08:13 pm (UTC)no subject
Date: 2012-03-15 08:39 pm (UTC)no subject
Date: 2012-03-16 12:34 am (UTC)no subject
Date: 2012-03-15 08:17 pm (UTC)no subject
Date: 2012-03-15 08:38 pm (UTC)And complexity and cleverness are two very different things, you know. Simple vs easy, Rich Hickey.
no subject
Date: 2012-03-15 10:15 pm (UTC)с чем вас и поздравляю :Р
а если серьезно, достичь одних и тех же целей можно разными способами, назовем их условно "изящными", "умными" и "простыми".
Так вот "простые" - наиболее эффективны с точки зрения бизнеса (а ведь подавляющее большинство из нас работает за деньги, не правда ли). "простые" методы легче понять окружающим, их легче поддерживать, после того, как автор решит, что ему пора двигать из этого гадюшника, и т.д. Именно поэтому правильно организованный процесс (adequate change descriptions, code reviews, reproducible tests with every single change) - залог долговременного здоровья компании.
Да, "простой" код возмущает эстетов от программирования (я сам к таким когда-то относился). Но многолетний опыт заставил понять и противоположную точку зрения.
no subject
Date: 2012-03-16 01:06 am (UTC)Впрочем, процентов на 80 я ещё верю в тесты.
no subject
Date: 2012-03-16 01:15 am (UTC)no subject
Date: 2012-03-20 03:37 pm (UTC)no subject
Date: 2012-03-15 09:51 pm (UTC)no subject
Date: 2012-03-15 08:24 pm (UTC)no subject
Date: 2012-03-15 08:36 pm (UTC)no subject
Date: 2012-03-16 04:20 pm (UTC)no subject
Date: 2012-03-18 05:13 pm (UTC)no subject
Date: 2012-03-19 04:03 pm (UTC)no subject
Date: 2012-03-20 07:28 am (UTC)Не зря же изменения делаются маленькими.
А как следует проводить code review: в одиночистве или в диалоге с писателем?
no subject
Date: 2012-03-20 03:33 pm (UTC)СобÑÑвенно, пÑоблема в маленÑÐºÐ¸Ñ Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸ÑÑ ÐºÐ°Ðº Ñаз в Ñом, ÑÑо за деÑалÑми ÑеÑÑеÑÑÑ Ð±Ð¾Ð»ÑÑÐ°Ñ ÐºÐ°ÑÑина, и запÑоÑÑо можно поÑиниÑÑ Ð¾Ð´Ð½Ð¾ меÑÑо и пÑи ÑÑом иÑпоÑÑиÑÑ Ð´ÐµÑÑÑÑ Ð´ÑÑÐ³Ð¸Ñ . ÐÐ¾Ñ Ð´Ð»Ñ ÑÑого по ÑÐ¼Ñ Ð¸ нÑÐ¶Ð½Ñ ÑевÑÑи: ÑÑоб оÑойÑи на некое ÑаÑÑÑоÑние и поÑмоÑÑеÑÑ Ñо ÑÑоÑонÑ, впиÑÑваÑÑÑÑ Ð»Ð¸ Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸Ñ Ð² болÑÑÑÑ ÐºÐ°ÑÑинÑ. Рне пÑоÑивоÑеÑÐ°Ñ Ð»Ð¸ дÑÑг дÑÑÐ³Ñ ÑаÑÑи ÑезÑлÑÑаÑа.
ÐÑ Ð´Ð°, ÑеÑÑÑ ÑÑÑ ÐºÐ¾Ð½ÐµÑно Ñоже в помоÑÑ, но Ñ ÑеÑÑов дÑÑÐ³Ð°Ñ ÑÑнкÑиÑ: они ловÑÑ ÑовÑем гÑÑбÑе поломки, и более Ñого, заÑанее пÑедÑказаннÑе гÑÑбÑе поломки. ФÑнкÑÐ¸Ñ ÑевÑÑÑ - в Ñом, ÑÑÐ¾Ð±Ñ Ð½Ðµ дÑблиÑоваÑÑ Ñобой ÑеÑÑÑ, а дополнÑÑÑ Ð¸Ñ . ÐоддеÑживаÑÑ ÐºÐ¾Ð½ÑиÑÑенÑноÑÑÑ Ð±Ð¾Ð»ÑÑой каÑÑинÑ. ÐÑкаÑÑ Ð²Ð¾Ð·Ð¼Ð¾Ð¶Ð½Ð¾ÑÑи новÑÑ Ð¿Ð¾Ð»Ð¾Ð¼Ð¾Ðº, коÑоÑÑе не пÑедÑÐºÐ°Ð·Ð°Ð½Ñ Ð² ÑÑаÑÑÑ ÑеÑÑÐ°Ñ , и ÑооÑвеÑÑÑвенно добавлÑÑÑ Ð´Ð»Ñ Ð½Ð¸Ñ Ð½Ð¾Ð²Ñе ÑеÑÑÑ.
ÐÑоводиÑÑ ÑевÑÑй ÑледÑÐµÑ ÑнаÑала ÑÑением в одиноÑеÑÑве, а поÑом в диалоге. ÐÑли неÑÑо непонÑÑно пÑи ÑÑении в одиноÑеÑÑве, Ñо знаÑÐ¸Ñ Ð¾Ð½Ð¾ или Ð¿Ð»Ð¾Ñ Ð¾ докÑменÑиÑовано и ÑÑда надо добавиÑÑ ÐºÐ¾Ð¼Ð¼ÐµÐ½ÑаÑий, или пÑоÑÑо кÑиво и должно бÑÑÑ Ð¸ÑпÑавлено.
no subject
Date: 2012-03-20 08:13 pm (UTC)Ðа мой взглÑд диалог пÑи code review полезен Ñем, ÑÑо позволÑÐµÑ Ð¿ÑовеÑÑи review в ÑÐ°Ð·Ñ Ð±ÑÑÑÑее.
ÐÑÑÑÑее обÑÑдиÑÑ Ð°Ð»ÑÑеÑнаÑивнÑе Ð¿Ð¾Ð´Ñ Ð¾Ð´Ñ Ðº напиÑÐ°Ð½Ð¸Ñ ÐºÐ¾Ð´Ð°.
ÐÑÑÑÑее обÑÑдиÑÑ Ð²Ð¾Ð·Ð¼Ð¾Ð¶Ð½Ñе подводнÑе камни и где именно код Ð¸Ñ Ð¾Ð±Ñ Ð¾Ð´Ð¸Ñ.
ÐÑÑÑÑее воÑÑоздаÑÑ ÐºÐ¾Ð½ÑекÑÑ Ð² голове пÑовеÑÑÑÑего.
2) ÐейÑÑвиÑелÑно: еÑли непонÑÑно из кода, ÑÑо пÑоиÑÑ Ð¾Ð´Ð¸Ñ, Ñо код, веÑоÑÑно, нÑжно пеÑепиÑÑваÑÑ.
no subject
Date: 2012-03-15 10:13 pm (UTC)no subject
Date: 2012-03-15 10:17 pm (UTC)no subject
Date: 2012-03-15 10:16 pm (UTC)no subject
Date: 2012-03-16 01:07 am (UTC)no subject
Date: 2012-03-16 01:09 am (UTC)no subject
Date: 2012-03-18 10:37 am (UTC)no subject
Date: 2012-03-19 04:06 pm (UTC)Не говоря уже о том, что собственно классические юнит-тесты, да еще и не дай бог с моками - штука игрушечная. Упускает многие реальные взаимодействия. Правильные тесты должны быть юнит в том смысле, что по тесту на каждую мелкую фичу, но на как можно более интегрированном продукте.
no subject
Date: 2012-03-19 04:56 pm (UTC)no subject
Date: 2012-03-19 07:08 pm (UTC)no subject
Date: 2012-03-19 10:46 pm (UTC)no subject
Date: 2012-03-20 02:36 pm (UTC)no subject
Date: 2012-03-20 05:08 pm (UTC)no subject
Date: 2012-03-21 04:31 am (UTC)no subject
Date: 2012-03-21 05:39 pm (UTC)no subject
Date: 2012-03-16 04:12 am (UTC)Other code reviews made me throw away clumsy code and be quite creative to express the same thing clearly and simply. (And shorter!)
Also, defending one's decisions in review comments is sometimes fun :)
no subject
Date: 2012-03-16 05:33 am (UTC)Integration tests detect ~35% of bugs.
Code review detects ~60% of bugs.
+ code review helps to share experience between team members, including creative experience.
no subject
Date: 2012-03-16 02:57 pm (UTC)no subject
Date: 2012-03-18 10:32 am (UTC)no subject
Date: 2012-03-18 05:11 pm (UTC)Если бы были все разные, то находилось бы 120% багов
:-)
Конечно же, нужно использовать все три инструмента.
Это должно устранить ~95% багов.