Наверно каждому из программистов приходилось сталкиваться на новом или на не новом месте работы с необходимостью поддерживать «чужой» проект.
Программисту удается написать код компилилируемый или интерепретиуемый, но не каждому понятный.
Все реагируют на «чужой» код по разному. Одних бросает в холодный пот, другие стиснув зубы разбираются. Так получилось, что я наблюдал этот процесс изнутри, как сторонний наблюдатель, как team leader и как специалист передающий свой код «новичку»
Ситуация. К вам в команду пришел «новенький». Абстрагируемся от его возможностей, так как есть зубры, которые свернут горы, но таких немного, и им я тоже предпочитаю помогать.
Сидеть рядом и объяснять — не очень эффективно. Заставить читать документацию или багтрекер с несколькими тысячами репортов, чтоб понять предысторию, невозможно.
И дело тут не в лени… не дело именно в ней. Кто-то пытается бороться с этим, а я считаю, что хороший программист должен быть ленив, но не глуп.
Да и каждый «новенький» приходит, как правило, с огромным потенциалом и с энтузиазмом. Грех не использовать!
Поэтому первое задание, которое я даю пришедшему работать в мою команду — Code Review. Если не забываю, то я предупреждаю, что приходится исправлять баги самостоятельно.
Второе задание — исправить или написать unit — тесты для основных операций или дополнить существующие. А если у вас они уже все есть, то удостовериться, проверяют ли они все ситуации.
Таким образом, через одну-две недели я получаю полноценный аудит написанного кода, написанные unit test'ы и полностью «въехавшего» специалиста у которого есть понимание того, с чем он имеет дело и огромные планы по рефакторингу.
Тихо, мирно и без революций :)
Оказавшись на новом месте любой испытывает много стрессов. Новый коллектив, новое здание, нелепые вопросы («а где у вас туалет?» :)) и неизвестный код :)
Бывают идеальные случаи, когда коллектив покидает зубр, и вы встаете на его место — тут главное не испортить… и всё же чаще бывает наоборот — код похож на бородинское поле после битвы. Запутанный, повторяющийся, часто написанный наспех под дедлайны, без тестов, документации, багтрекера. Рядом бегает менеджер рвет на себе волосы и говорит, что нужно быстрее, а ведь хочется себя показать, не завязнуть в изучении и не накуралесить.
Хорошо если team leader поступит благоразумно, даст вам время и простые задания на то, чтоб вы освоились. И так тоже бывает не всегда.
Как я поступал в таких случаях. Я честно предупреждал, что мне нужно не менее двух недель на понимание того, что уже сделано и как оно работает, сразу знакомясь и с тех. Заданием, и с планами развития.
«Заводил» если нет багтрекер, описывал функционал (карточки) в wiki, писал unit тесты, делал code review.
В итоге я получал инструменты контроля себя от неправильных шагов, работодатель видел конкретные результаты моей работы.
Для меня готовиться передавать код, это как дышать или делать постоянный рефакториг… Дело не только во внутренней философии воина — постоянной готовности к смерти, я не сжигаю мостов, мне нравится иметь в своём резюме людей со старой работы, которые могут меня порекомендовать.
Я не комментирую код, я пишу его понятным. Давно взял правило: если хочется написать комментарий, я выделяю код в метод с адекватным названием.
Я практикую парное программирование при написании нового функционала или рефакторинге старого с наиболее сильным программистом из своей команды. Это позволяет писать код понятным.
Я пишу юнит тесты на новый функционал, а потом приступаю к разработке кода.
Перед тем как начать писать код я пишу статью (тех. задание) о том как будет работать новая фича.
Разбиваю задачу на подзадачи не более чем по 20ть часов работы, выставляю зависимости в багтрекере.
Оставляю ссылку на «главный» баг в wiki, там где описываю фичу. В багтрекере описываю хаки, если они есть :)
Всё это делает переход с работы на работу приятным, есть время купить торты старой команде и оставить о себе добрую память :)
Отпраздновать приход в новую команду, хорошо себя зарекомендовать, не испортить репутацию.
Я люблю свою работу :)
Программисту удается написать код компилилируемый или интерепретиуемый, но не каждому понятный.
Все реагируют на «чужой» код по разному. Одних бросает в холодный пот, другие стиснув зубы разбираются. Так получилось, что я наблюдал этот процесс изнутри, как сторонний наблюдатель, как team leader и как специалист передающий свой код «новичку»
Помогаем познать кунг-фу чужого кода «новичку»
Ситуация. К вам в команду пришел «новенький». Абстрагируемся от его возможностей, так как есть зубры, которые свернут горы, но таких немного, и им я тоже предпочитаю помогать.
Сидеть рядом и объяснять — не очень эффективно. Заставить читать документацию или багтрекер с несколькими тысячами репортов, чтоб понять предысторию, невозможно.
И дело тут не в лени… не дело именно в ней. Кто-то пытается бороться с этим, а я считаю, что хороший программист должен быть ленив, но не глуп.
Да и каждый «новенький» приходит, как правило, с огромным потенциалом и с энтузиазмом. Грех не использовать!
Поэтому первое задание, которое я даю пришедшему работать в мою команду — Code Review. Если не забываю, то я предупреждаю, что приходится исправлять баги самостоятельно.
Второе задание — исправить или написать unit — тесты для основных операций или дополнить существующие. А если у вас они уже все есть, то удостовериться, проверяют ли они все ситуации.
Таким образом, через одну-две недели я получаю полноценный аудит написанного кода, написанные unit test'ы и полностью «въехавшего» специалиста у которого есть понимание того, с чем он имеет дело и огромные планы по рефакторингу.
Тихо, мирно и без революций :)
Изучаем чужой код
Оказавшись на новом месте любой испытывает много стрессов. Новый коллектив, новое здание, нелепые вопросы («а где у вас туалет?» :)) и неизвестный код :)
Бывают идеальные случаи, когда коллектив покидает зубр, и вы встаете на его место — тут главное не испортить… и всё же чаще бывает наоборот — код похож на бородинское поле после битвы. Запутанный, повторяющийся, часто написанный наспех под дедлайны, без тестов, документации, багтрекера. Рядом бегает менеджер рвет на себе волосы и говорит, что нужно быстрее, а ведь хочется себя показать, не завязнуть в изучении и не накуралесить.
Хорошо если team leader поступит благоразумно, даст вам время и простые задания на то, чтоб вы освоились. И так тоже бывает не всегда.
Как я поступал в таких случаях. Я честно предупреждал, что мне нужно не менее двух недель на понимание того, что уже сделано и как оно работает, сразу знакомясь и с тех. Заданием, и с планами развития.
«Заводил» если нет багтрекер, описывал функционал (карточки) в wiki, писал unit тесты, делал code review.
В итоге я получал инструменты контроля себя от неправильных шагов, работодатель видел конкретные результаты моей работы.
Готовимся передавать код
Для меня готовиться передавать код, это как дышать или делать постоянный рефакториг… Дело не только во внутренней философии воина — постоянной готовности к смерти, я не сжигаю мостов, мне нравится иметь в своём резюме людей со старой работы, которые могут меня порекомендовать.
Я не комментирую код, я пишу его понятным. Давно взял правило: если хочется написать комментарий, я выделяю код в метод с адекватным названием.
Я практикую парное программирование при написании нового функционала или рефакторинге старого с наиболее сильным программистом из своей команды. Это позволяет писать код понятным.
Я пишу юнит тесты на новый функционал, а потом приступаю к разработке кода.
Перед тем как начать писать код я пишу статью (тех. задание) о том как будет работать новая фича.
Разбиваю задачу на подзадачи не более чем по 20ть часов работы, выставляю зависимости в багтрекере.
Оставляю ссылку на «главный» баг в wiki, там где описываю фичу. В багтрекере описываю хаки, если они есть :)
Всё это делает переход с работы на работу приятным, есть время купить торты старой команде и оставить о себе добрую память :)
Отпраздновать приход в новую команду, хорошо себя зарекомендовать, не испортить репутацию.
Я люблю свою работу :)
