Да, я понимаю ваше разочарование глупым правилом. Я прочитал много программ с бесполезными комментариями, такими как
x = x + 1; // add 1 to x
И я говорю себе: так вот что значит знак плюс !! Вау, спасибо, что сказал мне, я этого не знал.
Но при этом клиент оплачивает счет. Поэтому вы даете им то, что они хотят. Если бы я работал в автосалоне, а покупатель сказал, что ему нужен пикап, я бы не стал спорить с ним о том, действительно ли ему нужен пикап, и опрашивал его о том, что он ожидает от него. Я бы продал ему пикап.
Хорошо, бывают моменты, когда клиенты говорят, что он хочет, и то, что ему действительно нужно, настолько далеко друг от друга, что я пытаюсь обсудить с ним этот вопрос, возможно, убедить его согласиться на что-то более рациональное. Иногда это работает, иногда нет. В конце концов, если я не смогу передумать, я дам ему то, что он хочет. Если он вернется позже и скажет: «О, это действительно не удовлетворяло моим бизнес-требованиям, то мы можем поручить ему больше делать то, что мы сказали ему делать в первый раз. То, сколько вы можете договориться с заказчиком, зависит от того, насколько он доверяет вашей экспертизе, как их контракт с вами вписывается в организацию, и, честно говоря, насколько они сумасшедшие.
Это был бы очень редкий случай, когда, если бы это зависело от меня, я бы потерял контракт, потому что думал, что требования были непродуманными.
Помните, что люди, с которыми ваша компания ведет переговоры, могут или не могут быть теми, кто изобрел это правило 25%. Это может быть правило, наложенное на них сверху.
Я вижу пять возможных ответов:
Один. Убедите своего босса или того, кто ведет переговоры с клиентом, спорить об этом. Скорее всего, это ничего не даст, но вы можете попробовать.
Два. Откажитесь это сделать. Это, вероятно, приведет к увольнению или, если компания с вами согласится, приведет к потере контракта. Это кажется непродуктивным.
Три. Напишите бесполезные комментарии, чтобы заполнить пространство, такие комментарии, которые просто повторяют то, что находится в коде, и что любой программист, способный изменить код, мог видеть за 2 секунды. Я видел много комментариев, как это. Несколько лет назад я работал в компании, где мы должны были ставить блоки комментариев перед каждой функцией, в которой перечислены параметры, например:
/*
GetFoo function
Parameters:
name: String, contains name
num: int, the number
add_date: date, the date added
Returns:
foo code: int
*/
int GetFoo(String name, int num, Date add_date)
Возражение, что такие комментарии являются бременем обслуживания, потому что вы должны держать их в актуальном состоянии, является недействительным. Нет необходимости держать их в курсе, потому что ни один серьезный программист никогда не будет смотреть на них. Если есть какие-либо вопросы по этому поводу, не забудьте прояснить всем членам команды, что ненужные, лишние комментарии следует игнорировать. Если вы хотите знать, каковы параметры функции или что делает строка кода, прочитайте код, не смотрите на бесполезные комментарии.
Четыре. Если вы собираетесь добавить лишние бесполезные комментарии, возможно, стоит потратить время на написание программы для их создания. Что-то вроде инвестиций заранее, но может сэкономить кучу печатных машин в будущем.
Когда я только начинал в этом бизнесе, компания, в которой я работал, использовала программу, которая рекламировалась как «Пишет вашу документацию для вас! Полная документация для каждой программы!» Система требовала, чтобы мы давали всем переменным по существу бессмысленные имена, а затем имели таблицу, в которой содержалось бы значащее имя для каждой переменной, поэтому в основном то, что «автоматическая документация» делало, заменяло бессмысленное имя, которое оно заставляло нас использовать значимым именем. Так, например - это работало с COBOL - в вашей программе была бы строка
MOVE IA010 TO WS124
и они сгенерируют строку «документации», в которой сказано
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
Во всяком случае, можно было бы написать программу для генерации одинаково бесполезной документации довольно легко. Читать строку как
a=b+c
и сгенерировать комментарий
// add b to c and save result in a
И т.п.
5. Сделай лучшее из глупого правила. Попробуйте написать полезные и содержательные комментарии. Эй, это может быть хорошим упражнением.
О, кстати, могу ли я добавить, что вы всегда можете сыграть в метрику.
Я помню, как однажды работодатель сказал, что они собираются начать измерять производительность труда программистов по тому, сколько строк кода мы производим в неделю. Когда нам сказали это на собрании, я сказал: Отлично! Я могу легко повысить свой счет. Не надо больше писать
x=x+4;
Вместо этого я напишу:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Loops? Забудьте об этом, я скопирую и вставлю код десять раз. И т.п.
Итак, здесь, если они собираются считать строки комментариев, сделайте каждую строку короткой и продолжите идею на следующей строке. Если в комментариях есть изменения, не обновляйте существующий комментарий. Поместите дату, затем скопируйте весь текст и напишите «Обновлено» и новую дату. Если клиент спрашивает об этом, скажите им, что вы думали, что необходимо сохранить историю. И т. Д.