Мне понравилась идея. Видимо, потому, что я люблю путешествовать, а после прочтения «Человеческого фактора» мечтаю работать в кристаллизованной команде единомышленников. По крайней мере в моем воображении идея работает
Вы очень интересную тему затронули, и, судя по результатам голосования, это вовсе не Ваша личная проблема. Когда читал, казалось, будто сам это написал — настолько знакомым было описанное. Часто я могу очень углубиться в проблему, что остальное кажется неважным. Например, могу целый день писать сценарий, делающий бэкапы, нумерующий версии, делающий еще кучу всего, и думаю: «Как же я раньше-то жил без этого, это ведь так важно!». То есть ухожу в сторону от решаемой задачи, хотя, вроде, и не бездельничаю.
Если такое возникает, и решить вопрос сходу не получается, то нужно вынести его на обсуждение с друзьями. Может оказаться, что проблема надумана, или друзья подскажут красивое решение, или вместе придем к выводу, что проблема действительно важная, но нужно пока отложить ее решение. У меня бывало, что тратил кучу времени и сил, и не мог решить проблему, а через некоторое время находил красивое решение. Так было, например, с scm-manager.
Часто возникает вопрос, до какой степени качества доводить систему. Должен быть разумный баланс, и я думаю, что помочь в этом могут заранее заданные критерии качества. Они могут существовать для кода, для интерфейса, для документации и т.п. Прохождение этих критериев снимает с человека психологическую нагрузку, повышается доверие к разрабатываемому продукту.
Еще пользуюсь таким приемом: после того, как сделаю основу, пробегаюсь по результатам и записываю все, что мне не очень нравится. Часто оказывается, что многие недостатки можно устранить «малой кровью», это не отнимает много времени, но делает программу эстетичнее.
Выше в комментариях говорили про внешние обязательства, например, регулярные релизы. Тоже хороший метод. Я, например, для себя составляю оперативные планы в Redmine, и пусть они носят для меня рекомендательный характер, но внутренне структурируют, позволяют сохранять направление на курс.
Лучшее — враг хорошего, нужно давать системе пространство для роста. Как у меня друзья сегодня сказали, пользователи могут не пользоваться плохим продуктом, но хорошим, но не выпущенным продуктом, они вообще не смогут пользоваться!
И да, понравилась мантра «Make it Work, Make it Right, Make it Fast». Разработка — процесс итеративный. Вселенная по спирали эволюционирует :)
Полностью согласен с вашими замечаниями про рефакторинг в прототипе. Не раз уже замечал, что до того наэкспериментируешься, такого кода нагородишь в прототипе, что дальше экспериментировать просто невозможно. И тогда просто выбора не остается, приходится делать рефакторинг. И чем более высокого уровня язык, тем это быстрее и проще
Всем, кто принимал участие в проверке. Причем, это не должно быть компромиссным решением, а именно решение, устраивающее всех. Если у кому-то из участников решение не нравится, значит либо в решении есть противоречие, которое нужно устранить, либо участник не правильно его понимает, и эта проблема решается обсуждением.
А размер группы не имеет смысла делать более 4-5 человек, а такое количество людей вполне могут договориться
Сложно точно сказать, можно только предположить. Я в последнее время все больше прихожу к тому, что в работе важнее всего взаимодействие, командная работа. Для участников команды важно, что они трудятся под одной крышей. И еще важна эстетическая составляющая. В «офисе», расположенном на берегу горного озера приятнее работать. А для стартаперов, не имеющих возможности снимать дорогой офис в красивом месте, это может быть важно. И еще рабочий процесс своеобразно переплетается с игровым процессом, поэтому и взаимодействие в команде будет более живым, интересным, может команда даже станет сплоченнее
Точнее работа-игра. Поработал, решил отдохнуть — поиграл прямо тут же. Но все же я не думаю, что это будет игра в работу. Я представляю, что в основном на экране будет именно обычная рабочая среда, просто при этом будет ощущение, что ты сидишь не у себя дома, а в офисе с другими людьми. Большее ощущение присутствия, по сравнению, например, со скайпом
Чтобы отследить такие вещи, анализатор должен понимать смысл написанного. Поэтому оставим эту задачу на откуп человеку. По крайней мере пока.
А чтобы помочь будущим разработчикам в анализе кода, можно заранее определиться с терминологией, на подобии того, как заранее продумываются интерфейсы. А то я часто встречал примеры (иногда и сам грешил), когда одна вещь в разных местах называется по-разному, разные вещи называются одинаково, а некоторые названия придумываются мимоходом в процессе кодирования. Мне вообще кажется, что задачи проектирования и реализации должны разграничиваться. Сначала придумываем, что и как хотим сделать, а потом делаем. Если пытаться проектировать «по ходу», получается плохо. Проверял.
Извините, я не понял, что вы имеете ввиду. По-моему, все приведенные вами примеры хорошо укладываются в предложенную метрику. Если бы вместо суммирования был какой-то сложный код, то его стоило бы вынести в функцию с понятным названием, и тогда можно было бы в ее реализацию не заглядывать.
По поводу сложности инструкций — я понял вашу мысль. Выше был комментарий, и я с ним согласен, что для небольших фрагментов кода можно считать не скроллы и переходы, а время потраченное на анализ кода.
Я не совсем это имел ввиду. Зависимости — это другая грань качества кода. Предложенная же метрика ориентированна именно на понятность для человека. Хотя, скорее всего, код с небольшим числом зависимостей будет и достаточно понятным
Нет, конечно! Если программа большая, то какого же размера будет эта функция, и сколько в ней будет переменных! Листать и переходить в ней придется много, из-за чего метрика уменьшится.
Говоря про главную функцию я имел ввиду, что если она понятно написана, то не обязательно нужно будет смотреть вызываемые функции. Из вызова (названия и параметров) будет понятно их назначение.
Я думал об этом. Но способ со временем подойдет только для небольших фрагментов кода, так как при анализе большого объема кода человек может отвлечься и забыть поставить таймер на паузу.
Спасибо за ссылку! Прогнал Rails-проект, получил интересные результаты :)
Когда мы эту статью обсуждали с друзьями на работе, родилась идея для автоматической оценки читабельности имен переменных и функций: проверять их на соответствие английским словам, переменные должны быть существительными и быть больше некоторой минимальной длины, функции состоять из связки английских глагола-существительного. В случае несоответствия слова можно подчеркивать красным, как в Word'е.
Если такое возникает, и решить вопрос сходу не получается, то нужно вынести его на обсуждение с друзьями. Может оказаться, что проблема надумана, или друзья подскажут красивое решение, или вместе придем к выводу, что проблема действительно важная, но нужно пока отложить ее решение. У меня бывало, что тратил кучу времени и сил, и не мог решить проблему, а через некоторое время находил красивое решение. Так было, например, с scm-manager.
Часто возникает вопрос, до какой степени качества доводить систему. Должен быть разумный баланс, и я думаю, что помочь в этом могут заранее заданные критерии качества. Они могут существовать для кода, для интерфейса, для документации и т.п. Прохождение этих критериев снимает с человека психологическую нагрузку, повышается доверие к разрабатываемому продукту.
Еще пользуюсь таким приемом: после того, как сделаю основу, пробегаюсь по результатам и записываю все, что мне не очень нравится. Часто оказывается, что многие недостатки можно устранить «малой кровью», это не отнимает много времени, но делает программу эстетичнее.
Выше в комментариях говорили про внешние обязательства, например, регулярные релизы. Тоже хороший метод. Я, например, для себя составляю оперативные планы в Redmine, и пусть они носят для меня рекомендательный характер, но внутренне структурируют, позволяют сохранять направление на курс.
Лучшее — враг хорошего, нужно давать системе пространство для роста. Как у меня друзья сегодня сказали, пользователи могут не пользоваться плохим продуктом, но хорошим, но не выпущенным продуктом, они вообще не смогут пользоваться!
И да, понравилась мантра «Make it Work, Make it Right, Make it Fast». Разработка — процесс итеративный. Вселенная по спирали эволюционирует :)
А размер группы не имеет смысла делать более 4-5 человек, а такое количество людей вполне могут договориться
А чтобы помочь будущим разработчикам в анализе кода, можно заранее определиться с терминологией, на подобии того, как заранее продумываются интерфейсы. А то я часто встречал примеры (иногда и сам грешил), когда одна вещь в разных местах называется по-разному, разные вещи называются одинаково, а некоторые названия придумываются мимоходом в процессе кодирования. Мне вообще кажется, что задачи проектирования и реализации должны разграничиваться. Сначала придумываем, что и как хотим сделать, а потом делаем. Если пытаться проектировать «по ходу», получается плохо. Проверял.
По поводу сложности инструкций — я понял вашу мысль. Выше был комментарий, и я с ним согласен, что для небольших фрагментов кода можно считать не скроллы и переходы, а время потраченное на анализ кода.
Говоря про главную функцию я имел ввиду, что если она понятно написана, то не обязательно нужно будет смотреть вызываемые функции. Из вызова (названия и параметров) будет понятно их назначение.
Когда мы эту статью обсуждали с друзьями на работе, родилась идея для автоматической оценки читабельности имен переменных и функций: проверять их на соответствие английским словам, переменные должны быть существительными и быть больше некоторой минимальной длины, функции состоять из связки английских глагола-существительного. В случае несоответствия слова можно подчеркивать красным, как в Word'е.