Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
В Разработке не лучшее место для этой статьи. Есть «Управление проектами», «GTD».
контроль, контроль и только контроль
Любимое слово моего напарника. Он хочет все контроллировать, от того, сколько клавиш нажмет программист, заканчивая количеством выпитого кофе. Ему кажется, что имея тотальный контроль за всем и вся, можно получить максимум выигрыша. Я ему постоянно кайф ломаю, внося частички хаоса в разработку. :)
у нас разное понимание контроля :)
для меня контроль — это постоянный code review, соответствие кода стандартам, поиск и оптимизация неоднозначных мест
для меня контроль — это постоянный code review, соответствие кода стандартам, поиск и оптимизация неоднозначных мест
Да я пишу именно об этом контроле, но никак не о висении над головой человека.
Не у нас. У меня слово контроль вообще отсутствует в лексиконе. Контроль является затратной частью для компании. Стоит заметить, что я не говорю, что его вообще не должно быть. Нет, напротив, контроль должен быть, но на уровне самоконтроля (не умение держать себя в руках, а контролирование своих действий и решений).
> Не у нас. У меня слово контроль вообще отсутствует в лексиконе. Контроль является затратной частью для компании.
С очень похожим доводом у нас на предприятии (не связано с разработкой ПО) на последнем совещании вообще запретили использовать слово «контроль» — теперь только «сопровождение»! О как!
Хотя лично мне не понятно, как это может положительно повлиять на процесс изготовления продукции, если функциональные обязанности у всех остались прежние…
Просто, мысли в слух…
С очень похожим доводом у нас на предприятии (не связано с разработкой ПО) на последнем совещании вообще запретили использовать слово «контроль» — теперь только «сопровождение»! О как!
Хотя лично мне не понятно, как это может положительно повлиять на процесс изготовления продукции, если функциональные обязанности у всех остались прежние…
Просто, мысли в слух…
>> «но на уровне самоконтроля»
Как раз я и пишу о том что это не работает. Для отдельно взятого человека это может и будет работать, но когда в команде десяток разработчиков уповать на их ответственность не стоит. Всегда по возможности нужно исключать человеческий фактор и автоматизировать. Конечно если человек совершенно игнорирует любые требования и продолжает гнуть свою линию, то может быть стоит отказаться от такого программиста, потому что никакие ограничения не помогут.
Как раз я и пишу о том что это не работает. Для отдельно взятого человека это может и будет работать, но когда в команде десяток разработчиков уповать на их ответственность не стоит. Всегда по возможности нужно исключать человеческий фактор и автоматизировать. Конечно если человек совершенно игнорирует любые требования и продолжает гнуть свою линию, то может быть стоит отказаться от такого программиста, потому что никакие ограничения не помогут.
Это не работает в вашем случае. Но это не значит, что это вообще не работает.
Вы не можете исключить человеческий фактор. Парное программирование убирает все проблемы с использованием библиотек, незнанием, распространением информации в коллективе. Как и любая саморегулирующаяся система, коллектив быстро найдет среднее по эффективности решение. Оно может быть не лучшим на данный момент времени, но станет таковым через время. С каждой итерацией уровень среднего будет все выше и выше. Естественный отбор в коде оставит то, что нужно, а что не нужно будет выброшено.
Вы не можете исключить человеческий фактор. Парное программирование убирает все проблемы с использованием библиотек, незнанием, распространением информации в коллективе. Как и любая саморегулирующаяся система, коллектив быстро найдет среднее по эффективности решение. Оно может быть не лучшим на данный момент времени, но станет таковым через время. С каждой итерацией уровень среднего будет все выше и выше. Естественный отбор в коде оставит то, что нужно, а что не нужно будет выброшено.
>> Естественный отбор в коде оставит то, что нужно, а что не нужно будет выброшено.
Очень странное утверждение. С ростом энтропия проектов только увеличивается. И чем дальше тем будет хуже если для этого не предпринимать конкретных шагов.
>> Как и любая саморегулирующаяся система, коллектив быстро найдет среднее по эффективности решение.
Далеко не любой коллектив саморегулирующаяся систем. Существуют еще удаленные команды, сотрудники.
>> Вы не можете исключить человеческий фактор
Никто с этим не спорит. Нужно стремиться его исключать там где это возможно иначе самолеты бы не летали и поезда не ездили.
>> Парное программирование убирает все проблемы с использованием библиотек, незнанием, распространением информации в коллективе.
Серебряной пули не существует, а парное программирование я сам очень люблю.
Очень странное утверждение. С ростом энтропия проектов только увеличивается. И чем дальше тем будет хуже если для этого не предпринимать конкретных шагов.
>> Как и любая саморегулирующаяся система, коллектив быстро найдет среднее по эффективности решение.
Далеко не любой коллектив саморегулирующаяся систем. Существуют еще удаленные команды, сотрудники.
>> Вы не можете исключить человеческий фактор
Никто с этим не спорит. Нужно стремиться его исключать там где это возможно иначе самолеты бы не летали и поезда не ездили.
>> Парное программирование убирает все проблемы с использованием библиотек, незнанием, распространением информации в коллективе.
Серебряной пули не существует, а парное программирование я сам очень люблю.
Все косячат. И как не прокачивай скилл самоконтроля, от ошибки это не страхует. Я всегда отдаю код на ревью после коммита — это мой же спокойный сон и уверенность. Так что секрет в адекватном к нему (контролю) отношении, пожалуй.
Соглашения работают, если они не требуют сверх-усилий.
Если разработчик игнорирует какую-то библиотеку, то для меня это верный признак того, что эта библиотека не нужна, и от нее нужно отказываться.
Если тестирование не было заложено в самом начале как обычный процесс разработки, то требовать от работников ее внедрения в середине проекта вообще бессмысленно. У него и без дополнительных финтифлюшек работы хватает.
Интересная ситуация и с первым кодом. Обычно первый код не является эталоном. Это всего лишь первое приближенное решение задачи. Идеалом он может стать только на третьем-десятом рефакторинге. Отмечать эталонными нужно подходы к решению, а не сам код.
Если разработчик игнорирует какую-то библиотеку, то для меня это верный признак того, что эта библиотека не нужна, и от нее нужно отказываться.
Если тестирование не было заложено в самом начале как обычный процесс разработки, то требовать от работников ее внедрения в середине проекта вообще бессмысленно. У него и без дополнительных финтифлюшек работы хватает.
Интересная ситуация и с первым кодом. Обычно первый код не является эталоном. Это всего лишь первое приближенное решение задачи. Идеалом он может стать только на третьем-десятом рефакторинге. Отмечать эталонными нужно подходы к решению, а не сам код.
>эта библиотека не нужна, и от нее нужно отказываться.
Поддерживаю, но уточнил бы:
в текущем виде эта библиотека не нужна.
Может быть идея и хорошая, но требует доработки.
Хотя всегда есть вероятность, что и идея была неудачной:)
Поддерживаю, но уточнил бы:
в текущем виде эта библиотека не нужна.
Может быть идея и хорошая, но требует доработки.
Хотя всегда есть вероятность, что и идея была неудачной:)
> Если разработчик игнорирует какую-то библиотеку, то для меня это верный признак того, что эта библиотека не нужна, и от нее нужно отказываться.
зависит от опыта разработчика, вполне возможно что разработчик не представляет как ее использовать и ему нужно объяснить
зависит от опыта разработчика, вполне возможно что разработчик не представляет как ее использовать и ему нужно объяснить
>> Если разработчик игнорирует какую-то библиотеку, то для меня это верный признак того, что эта библиотека не нужна, и от нее нужно отказываться.
А если нужна? Можно, например, написать адаптер.
>> Если тестирование не было заложено в самом начале как обычный процесс разработки, то требовать от работников ее внедрения в середине проекта вообще бессмысленно. У него и без дополнительных финтифлюшек работы хватает.
Абсолютно не согласен. Это из серии про мужика который косит поле тупой косой и на вопрос «почему ты ее не наточишь» обводит рукой поле и говорит «посмотрите сколько у меня еще работы, мне некогда».
>> Интересная ситуация и с первым кодом. Обычно первый код не является эталоном. Это всего лишь первое приближенное решение задачи. Идеалом он может стать только на третьем-десятом рефакторинге. Отмечать эталонными нужно подходы к решению, а не сам код.
Здесь речь о том что новый разработчик или тот который решает эту задачу впервые, в первую очередь откроет файлы проекта где что то подобное делалось и будет делать по образу и подобию. Естественно что с точки зрения архитектуры этот код может поменяться, но для текущего момента времени он должен быть эталонным.
А если нужна? Можно, например, написать адаптер.
>> Если тестирование не было заложено в самом начале как обычный процесс разработки, то требовать от работников ее внедрения в середине проекта вообще бессмысленно. У него и без дополнительных финтифлюшек работы хватает.
Абсолютно не согласен. Это из серии про мужика который косит поле тупой косой и на вопрос «почему ты ее не наточишь» обводит рукой поле и говорит «посмотрите сколько у меня еще работы, мне некогда».
>> Интересная ситуация и с первым кодом. Обычно первый код не является эталоном. Это всего лишь первое приближенное решение задачи. Идеалом он может стать только на третьем-десятом рефакторинге. Отмечать эталонными нужно подходы к решению, а не сам код.
Здесь речь о том что новый разработчик или тот который решает эту задачу впервые, в первую очередь откроет файлы проекта где что то подобное делалось и будет делать по образу и подобию. Естественно что с точки зрения архитектуры этот код может поменяться, но для текущего момента времени он должен быть эталонным.
Ответил не туда(
А если нужна? Можно, например, написать адаптер.
Если была бы нужна, то ее бы использовали. Я не хочу показаться КО, но это так.
Абсолютно не согласен. Это из серии про мужика который косит поле тупой косой и на вопрос «почему ты ее не наточишь» обводит рукой поле и говорит «посмотрите сколько у меня еще работы, мне некогда».
Неправильный пример. Вы не добавляете в нем мужику работы. Правильный пример звучит так: «Мужик, два раза махнул косой, пару раз погреб граблями»
Естественно что с точки зрения архитектуры этот код может поменяться, но для текущего момента времени он должен быть эталонным.
Если вы не заставляете работника улучшать код, то да. Если ваша задача на каждой итерации его улучшать, то оставлять средний по качеству код опасно, ведь все последующие куски будут такими же средними по качеству.
1. Всем присуща инертность — зачастую неиспользование библиотеки кроется не в ней, а в людях.
2. По-моему оба примера равнозначны — и в жизни будут встречаться оба.
2. По-моему оба примера равнозначны — и в жизни будут встречаться оба.
>> Если была бы нужна, то ее бы использовали. Я не хочу показаться КО, но это так.
Я говорю о проектировании интерфейсов. То есть библиотека нужна, но она неудобная. Дальше вариантов несколько: меняем библиотеку, пишем адаптер, пишем свое решение (если целесообразно) и т.п.
Я говорю о проектировании интерфейсов. То есть библиотека нужна, но она неудобная. Дальше вариантов несколько: меняем библиотеку, пишем адаптер, пишем свое решение (если целесообразно) и т.п.
Есть еще проблема велосипедостроения — человек со здоровым чувством лени всегда будет писать максимально просто, а о подводных камнях на тот момент он может и не знать.
Библиотека может решать многие неявные проблемы, о которых разработчик узнает только впоследствии, но быть по его мнению оверкилом или просто «быстрее написать на коленке так». Поэтому и предлагается для таких участков энфорсить соглашения перекрыванием возможности написать по-другому
Библиотека может решать многие неявные проблемы, о которых разработчик узнает только впоследствии, но быть по его мнению оверкилом или просто «быстрее написать на коленке так». Поэтому и предлагается для таких участков энфорсить соглашения перекрыванием возможности написать по-другому
По моему это просто неправильно поставленные цели. Разработчики считают что их дело — писать код, а тестирование воспринимают как помеху. Нужно перенацелить команду на качественный код и убедить что тестирование — необходимый этап.
Или сменить цикл разработки что бы команда его приняла.
Или сменить цикл разработки что бы команда его приняла.
И мы придем к тому о чем я написал: «ребята давайте договоримся». Естественно нужно общаться с командой, мотивировать, объяснять и поощрять. Но все мы люди, кто-то забыл, было лень, нужно было быстро задеплоить, а недавно пришел еще один разработчик увидел неправильный вариант и начал делать по нему.
Подход должен быть комплексным. Следить за качеством кода нужно и это для этого есть ревью, программирование в парах и тесты, но для того чтобы тесты писали всегда, нужно следить, как минимум на начальных этапах, да и в процессе тоже иногда приходится. А статья о том как сделать так чтобы оно «следилось само» по возможности.
Подход должен быть комплексным. Следить за качеством кода нужно и это для этого есть ревью, программирование в парах и тесты, но для того чтобы тесты писали всегда, нужно следить, как минимум на начальных этапах, да и в процессе тоже иногда приходится. А статья о том как сделать так чтобы оно «следилось само» по возможности.
Вы не поняли.
Помимо системных или «внутренних» как Вы их называете и «внешних» или административных, есть по настоящему внутренний контроль — сам разработчик. Он же не забывает сохраниться!
Мало получить согласие — как правило командные игроки соглашаются со всем против чего у них нет возражений. Нужно что бы человек признал это правильным, отвел ему внутренний приоритет и стремился выполнить. Для этого нужно сделать эти действия выгодными.
Оставлять все на ревью конечно можно, то тим лиду и без этого полно работы.
«Само» оно как бы не делается. Это должна очень продуманная архитектура что бы она была простой и понятной, но при этом гибкой, а еще и устойчивой от неправильных действий.
Помимо системных или «внутренних» как Вы их называете и «внешних» или административных, есть по настоящему внутренний контроль — сам разработчик. Он же не забывает сохраниться!
Мало получить согласие — как правило командные игроки соглашаются со всем против чего у них нет возражений. Нужно что бы человек признал это правильным, отвел ему внутренний приоритет и стремился выполнить. Для этого нужно сделать эти действия выгодными.
Оставлять все на ревью конечно можно, то тим лиду и без этого полно работы.
«Само» оно как бы не делается. Это должна очень продуманная архитектура что бы она была простой и понятной, но при этом гибкой, а еще и устойчивой от неправильных действий.
Review Board, извините
правда придется отвлечь умных людей для контроля над творческими
правда придется отвлечь умных людей для контроля над творческими
— Пользуйтесь моками в тестах только в случае острой необходимости (внешняя служба), иначе на каждую строчку в реальном коде придется менять несколько строк в тесте, и в конце концов это станет невыносимым бременем для всей команды.
И для каждого теста создавать кучу связанных объектов и фактически повторно и их тестировать? Зачем?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Человеческий фактор или «соглашения не работают»