Pull to refresh

Comments 42

В Разработке не лучшее место для этой статьи. Есть «Управление проектами», «GTD».
Да, Вы правы. Переместил
Любимое слово моего напарника. Он хочет все контроллировать, от того, сколько клавиш нажмет программист, заканчивая количеством выпитого кофе. Ему кажется, что имея тотальный контроль за всем и вся, можно получить максимум выигрыша. Я ему постоянно кайф ломаю, внося частички хаоса в разработку. :)
у нас разное понимание контроля :)
для меня контроль — это постоянный code review, соответствие кода стандартам, поиск и оптимизация неоднозначных мест
Да я пишу именно об этом контроле, но никак не о висении над головой человека.
Не у нас. У меня слово контроль вообще отсутствует в лексиконе. Контроль является затратной частью для компании. Стоит заметить, что я не говорю, что его вообще не должно быть. Нет, напротив, контроль должен быть, но на уровне самоконтроля (не умение держать себя в руках, а контролирование своих действий и решений).
> Не у нас. У меня слово контроль вообще отсутствует в лексиконе. Контроль является затратной частью для компании.

С очень похожим доводом у нас на предприятии (не связано с разработкой ПО) на последнем совещании вообще запретили использовать слово «контроль» — теперь только «сопровождение»! О как!

Хотя лично мне не понятно, как это может положительно повлиять на процесс изготовления продукции, если функциональные обязанности у всех остались прежние…

Просто, мысли в слух…
>> «но на уровне самоконтроля»

Как раз я и пишу о том что это не работает. Для отдельно взятого человека это может и будет работать, но когда в команде десяток разработчиков уповать на их ответственность не стоит. Всегда по возможности нужно исключать человеческий фактор и автоматизировать. Конечно если человек совершенно игнорирует любые требования и продолжает гнуть свою линию, то может быть стоит отказаться от такого программиста, потому что никакие ограничения не помогут.
Это не работает в вашем случае. Но это не значит, что это вообще не работает.
Вы не можете исключить человеческий фактор. Парное программирование убирает все проблемы с использованием библиотек, незнанием, распространением информации в коллективе. Как и любая саморегулирующаяся система, коллектив быстро найдет среднее по эффективности решение. Оно может быть не лучшим на данный момент времени, но станет таковым через время. С каждой итерацией уровень среднего будет все выше и выше. Естественный отбор в коде оставит то, что нужно, а что не нужно будет выброшено.
>> Естественный отбор в коде оставит то, что нужно, а что не нужно будет выброшено.

Очень странное утверждение. С ростом энтропия проектов только увеличивается. И чем дальше тем будет хуже если для этого не предпринимать конкретных шагов.

>> Как и любая саморегулирующаяся система, коллектив быстро найдет среднее по эффективности решение.
Далеко не любой коллектив саморегулирующаяся систем. Существуют еще удаленные команды, сотрудники.

>> Вы не можете исключить человеческий фактор

Никто с этим не спорит. Нужно стремиться его исключать там где это возможно иначе самолеты бы не летали и поезда не ездили.

>> Парное программирование убирает все проблемы с использованием библиотек, незнанием, распространением информации в коллективе.

Серебряной пули не существует, а парное программирование я сам очень люблю.
Рефакторинг нужно делать для уменьшения энтропии. Рефакторинг как раз и оставит самые удачные решения.

Пока человек будет писать программы, человеческий фактор не исключить.
Вы меня не слышите). Я уже написал про человеческий фактор, а Вы опять туда же.
Я вас прекрасно слышу :) Я согласен с приведенными вами аргументами, но они не перекрывают причину возникновения ошибок, это всего лишь способы минимизации влияния ЧФ.
Все косячат. И как не прокачивай скилл самоконтроля, от ошибки это не страхует. Я всегда отдаю код на ревью после коммита — это мой же спокойный сон и уверенность. Так что секрет в адекватном к нему (контролю) отношении, пожалуй.
Соглашения работают, если они не требуют сверх-усилий.

Если разработчик игнорирует какую-то библиотеку, то для меня это верный признак того, что эта библиотека не нужна, и от нее нужно отказываться.

Если тестирование не было заложено в самом начале как обычный процесс разработки, то требовать от работников ее внедрения в середине проекта вообще бессмысленно. У него и без дополнительных финтифлюшек работы хватает.

Интересная ситуация и с первым кодом. Обычно первый код не является эталоном. Это всего лишь первое приближенное решение задачи. Идеалом он может стать только на третьем-десятом рефакторинге. Отмечать эталонными нужно подходы к решению, а не сам код.
>эта библиотека не нужна, и от нее нужно отказываться.
Поддерживаю, но уточнил бы:
в текущем виде эта библиотека не нужна.

Может быть идея и хорошая, но требует доработки.
Хотя всегда есть вероятность, что и идея была неудачной:)
> Если разработчик игнорирует какую-то библиотеку, то для меня это верный признак того, что эта библиотека не нужна, и от нее нужно отказываться.

зависит от опыта разработчика, вполне возможно что разработчик не представляет как ее использовать и ему нужно объяснить
Если из текущей доктрины разработки не понятно как использовать библиотеку, то скорее всего она не нужна. Или нужна новая доктрина разработки.
UFO landed and left these words here
UFO landed and left these words here
Соблюдение соглашений делается правилами или методикой разработки. Если вы не сможете написать ни строчки кода, который не соблюдает соглашений, то шанс на ошибку будет минимальным, и следить не придется.
>> Если разработчик игнорирует какую-то библиотеку, то для меня это верный признак того, что эта библиотека не нужна, и от нее нужно отказываться.

А если нужна? Можно, например, написать адаптер.

>> Если тестирование не было заложено в самом начале как обычный процесс разработки, то требовать от работников ее внедрения в середине проекта вообще бессмысленно. У него и без дополнительных финтифлюшек работы хватает.
Абсолютно не согласен. Это из серии про мужика который косит поле тупой косой и на вопрос «почему ты ее не наточишь» обводит рукой поле и говорит «посмотрите сколько у меня еще работы, мне некогда».

>> Интересная ситуация и с первым кодом. Обычно первый код не является эталоном. Это всего лишь первое приближенное решение задачи. Идеалом он может стать только на третьем-десятом рефакторинге. Отмечать эталонными нужно подходы к решению, а не сам код.

Здесь речь о том что новый разработчик или тот который решает эту задачу впервые, в первую очередь откроет файлы проекта где что то подобное делалось и будет делать по образу и подобию. Естественно что с точки зрения архитектуры этот код может поменяться, но для текущего момента времени он должен быть эталонным.
А если нужна? Можно, например, написать адаптер.

Если была бы нужна, то ее бы использовали. Я не хочу показаться КО, но это так.

Абсолютно не согласен. Это из серии про мужика который косит поле тупой косой и на вопрос «почему ты ее не наточишь» обводит рукой поле и говорит «посмотрите сколько у меня еще работы, мне некогда».

Неправильный пример. Вы не добавляете в нем мужику работы. Правильный пример звучит так: «Мужик, два раза махнул косой, пару раз погреб граблями»

Естественно что с точки зрения архитектуры этот код может поменяться, но для текущего момента времени он должен быть эталонным.

Если вы не заставляете работника улучшать код, то да. Если ваша задача на каждой итерации его улучшать, то оставлять средний по качеству код опасно, ведь все последующие куски будут такими же средними по качеству.
1. Всем присуща инертность — зачастую неиспользование библиотеки кроется не в ней, а в людях.
2. По-моему оба примера равнозначны — и в жизни будут встречаться оба.
2. Если программист не стремится улучшать и автоматизировать свой труд, то это очень плохо.
А что делать? Уволить и весь бюджет спустить на зарплаты каким-нибудь гениям? Люди не идеальны и приходится работать не с идеальными сферическими программистами в вакууме, а с обычными людьми.
Повышать его мотивацию. Учить его.
>> Если была бы нужна, то ее бы использовали. Я не хочу показаться КО, но это так.
Я говорю о проектировании интерфейсов. То есть библиотека нужна, но она неудобная. Дальше вариантов несколько: меняем библиотеку, пишем адаптер, пишем свое решение (если целесообразно) и т.п.
Вам не библиотека нужна, а решение своих проблем :) Так точнее формулировка.
Исходя из этого вы будете искать библиотеку, писать свое, писать адаптер или все что угодно. Но если решение не будет принято единогласно, то ваш выбор будет ошибочным. Про это я и писал.
Есть еще проблема велосипедостроения — человек со здоровым чувством лени всегда будет писать максимально просто, а о подводных камнях на тот момент он может и не знать.

Библиотека может решать многие неявные проблемы, о которых разработчик узнает только впоследствии, но быть по его мнению оверкилом или просто «быстрее написать на коленке так». Поэтому и предлагается для таких участков энфорсить соглашения перекрыванием возможности написать по-другому
По моему это просто неправильно поставленные цели. Разработчики считают что их дело — писать код, а тестирование воспринимают как помеху. Нужно перенацелить команду на качественный код и убедить что тестирование — необходимый этап.
Или сменить цикл разработки что бы команда его приняла.
И мы придем к тому о чем я написал: «ребята давайте договоримся». Естественно нужно общаться с командой, мотивировать, объяснять и поощрять. Но все мы люди, кто-то забыл, было лень, нужно было быстро задеплоить, а недавно пришел еще один разработчик увидел неправильный вариант и начал делать по нему.

Подход должен быть комплексным. Следить за качеством кода нужно и это для этого есть ревью, программирование в парах и тесты, но для того чтобы тесты писали всегда, нужно следить, как минимум на начальных этапах, да и в процессе тоже иногда приходится. А статья о том как сделать так чтобы оно «следилось само» по возможности.
Вы не поняли.
Помимо системных или «внутренних» как Вы их называете и «внешних» или административных, есть по настоящему внутренний контроль — сам разработчик. Он же не забывает сохраниться!
Мало получить согласие — как правило командные игроки соглашаются со всем против чего у них нет возражений. Нужно что бы человек признал это правильным, отвел ему внутренний приоритет и стремился выполнить. Для этого нужно сделать эти действия выгодными.

Оставлять все на ревью конечно можно, то тим лиду и без этого полно работы.

«Само» оно как бы не делается. Это должна очень продуманная архитектура что бы она была простой и понятной, но при этом гибкой, а еще и устойчивой от неправильных действий.
>> «Само» оно как бы не делается. Это должна очень продуманная архитектура что бы она была простой и понятной, но при этом гибкой, а еще и устойчивой от неправильных действий.

Хм, а вы прочитали статью? Я именно об этом и написал.
Review Board, извините

правда придется отвлечь умных людей для контроля над творческими
— Пользуйтесь моками в тестах только в случае острой необходимости (внешняя служба), иначе на каждую строчку в реальном коде придется менять несколько строк в тесте, и в конце концов это станет невыносимым бременем для всей команды.

И для каждого теста создавать кучу связанных объектов и фактически повторно и их тестировать? Зачем?
Only those users with full accounts are able to leave comments. Log in, please.