Вы спорите с утверждением, что "юнит-тесты должны писаться", хотя автор написал, что "если на проекте пишутся юнит-тесты, то это должны делать разработчики, а не тестировщики".
А если вы захотите сделать рефакторинг модуля, вы четырежды подумаете, поскольку придется юнит тесты переписывать, при том что логика самого функционала не поменялась ни на йоту.
Вот из этого видно, что Вы юнит-тесты никогда не писали. Они пишутся на API класса, а при рефакторинге API не меняется, соответственно, тесты переписывать не нужно.
Более того, при рефакторинге юнит-тесты гарантируют, что ничего не сломалось — ибо поведение класса для внешнего мира не изменилось.
Зато теперь понятно, что Peek() является частью получения кодировки файла. Отсюда вытекает вывод, что убирать его нельзя.
Как я уже написал выше, внутрь метода GetFileEncoding() читатель будет проваливаться лишь в том случае, если есть баг с получением кодировки. А т.к. бага нет — то никогда. Вряд ли разработчик будет бродить по коду системы и читать его из чистого любопытства.
У меня ситуация обратная — везде, где я работал, было чёткое разделение ролей аналитика и разработчика. Аналитики являются специалистами в бизнес-анализе (и психологии, без этого работать с заказчиками невозможно :) ) и практически ничего не знают о внутреннем устройстве системы.
И это отлично работает.
Тестировщики — ручное тестирование + автоматизированное (кроме модульного).
Делать по такой картине выводы о необходимости или нет комментариев нельзя. В Вашем случае они скорее всего нужны — просто потому, что аналитики/тестировщики не умеют писать самодокументированный код.
Но не нужно эти выводы экстраполировать на всю отрасль, в основном в ней всё по-другому. :)
Практика показывает, что разделение труда эффективнее, чем найм штучных гениев и мастеров на все руки.
Так о том и речь — постановку задачи должен делать аналитик, код писать — программист. Как из Вашего комментария следует, что отлаживать код должны аналитики или тестировщики — непонятно.
Следующий шаг в такой логике — аналитики не нужны, всё будут делать программисты.
Я бы выстроил это как единую шкалу: менеджеры не нужны < аналитики не нужны < комментарии не нужны < документацию надо изучать по остаточному принципу < тестировщики не нужны < документация не нужна < свои баги нельзя признавать < проект должен состоять только из сеньорных программистов-дедов.
Странно как-то это у Вас вытекает из утверждения "Аналитик или тестировщик не должен заниматься отладкой кода."
Нет, не лень. Но нет никакой гарантии, что, изменив код, программист обязательно изменит комментарий. Возможные причины этого:
аврал, второпях просто не вспомнил, что надо;
конец рабочего дня, усталость, опять же не вспомнил;
просто невнимательный/забывчивый человек;
пофигист — к сожалению, и таких хватает; они просто забивают на такие вещи;
и т.д.
Пока код пишут люди, а не роботы, это будет происходить.
Так что про лень редактировать — это опять-таки Ваша фантазия. Прекращайте уже оправдывать свою позицию, навешивая ярлыки на оппонентов.
Нежелание комментировать код это, почти всегда, лень и самоуверенность, а не что-то ещё.
Ну вот опять :(
В комментариях к этой статье уже дважды люди, ничего обо мне не знающие, записали меня (и еще стотыщ программистов) в ленивого, неспособного писать комментарии и самоуверенного типа.
Это в Вашем придуманном мире. А в реальном я не пишу комментарии (хотя из этого правила есть исключения) потому, что считаю, что от них больше вреда, чем пользы.
Это как? Если я поменял код, то автоматически актуализируется документация?
Если нет (а мы с Вами знаем, что нет :) ), то мы получаем человекозависимый процесс и далее по тексту моего комментария выше.
В девяносто девяти случаях из ста читатель даже не будет проваливаться в метод GetFileEncoding.
Смысл самодокументируемого кода как раз и состоит в том, чтобы давать кускам кода осмысленные имена.
Про причину №2: автор утверждает, что непоследовательно исполняющийся код не может быть понятен по определению, не приводя никаких доказательств. Нет фактов — обсуждать нечего.
Про причину №3.
если взглянуть на это глазами программиста-новичка или не-программиста
Всё, занавес.
Код не пишется для чтения поварами или астрономами. Мы должны писать код, понятный другим программистам. И исходя из этого, код не только может быть самодокументированным, но и должен быть таким.
И пару слов по основному посылу статьи: тут уже написали, что главная проблема документации в том, что её надо поддерживать в актуальном состоянии. Плюсую.
А т.к. эта поддержка человекозависима, то никогда не будет работать стопроцентно качественно, а значит, вы никогда не будете иметь абсолютно актуальную документацию.
Самодокументированный код возможен, документированный — нет.
Я вот тоже перестаю читать такие статьи, правда, по другой причине.
Если человек не привёл в порядок свой текст — это показатель непрофессионализма. Т.е. отсутствия ответственного отношения к тому, что человек делает.
Оффтопик: а ещё, на мой взгляд, это неуважительное отношение автора к читателям.
Это пока.
У программиста будет аврал при починке бага на проме, и он быстро поменяет код, даже не взглянув на комментарий — всё, ваша документация врёт.
Не обязательно аврал: просто может быть невнимательный человек; конец десятичасового рабочего дня; просто пофигист и т.д.
Проблема такой «документации» в том, что она человекозависима, а значит — ненадёжна, а значит — ей нельзя доверять и мало кто её будет читать, а значит — и писать её не стоит.
Есть, конечно, исключения, когда комментарии писать нужно: если изменения в данном месте могут аукнуться совсем в другом (читатель кода может не знать этого) и если разработчик выбрал какой-то нестандартный/нелогичный подход: надо объяснить будущим поколениям — почему (Ваш пример, как я понимаю, как раз про это).
Всё, других резонов написания комментариев/документации нет.
Почему же только в C++? У нас в команде (C#) тоже действует правило: «Переменная должна объявляться максимально близко к месту первого использования». И множественные return приветствуются.
В 90-е (до Windows 95) подрабатывал написанием небольших бизнес-программ (складской учёт, кадровый и т.д.), использовал Turbo Pascal + Turbo Vision. Но вот однажды в руки попала книга Григория Зельднера по QuickBasic 4.5, и так мне этот Бейсик в душу запал, что следующую программу (расчёт зарплаты для госучреждения) я на на нём и написал )))).
С окнами, менюшками и прочими интерфейсностями в текстовом режиме.
Эх, жаль, хороший был язык…
Evernote.
Десктопное приложение устанавливать необязательно — можно работать онлайн.
Спасибо!
Видеозаписи выступлений выкладывать не планируете?
Вы спорите с утверждением, что "юнит-тесты должны писаться", хотя автор написал, что "если на проекте пишутся юнит-тесты, то это должны делать разработчики, а не тестировщики".
Вот из этого видно, что Вы юнит-тесты никогда не писали. Они пишутся на API класса, а при рефакторинге API не меняется, соответственно, тесты переписывать не нужно.
Более того, при рефакторинге юнит-тесты гарантируют, что ничего не сломалось — ибо поведение класса для внешнего мира не изменилось.
Peek()является частью получения кодировки файла. Отсюда вытекает вывод, что убирать его нельзя.GetFileEncoding()читатель будет проваливаться лишь в том случае, если есть баг с получением кодировки. А т.к. бага нет — то никогда. Вряд ли разработчик будет бродить по коду системы и читать его из чистого любопытства.У меня ситуация обратная — везде, где я работал, было чёткое разделение ролей аналитика и разработчика. Аналитики являются специалистами в бизнес-анализе (и психологии, без этого работать с заказчиками невозможно :) ) и практически ничего не знают о внутреннем устройстве системы.
И это отлично работает.
"По такой картине" — я имею в виду Вашу ситуацию.
Вот в том-то и дело, что у Вас сейчас на проекте все роли перемешаны. Не должен аналитик предлагать способы реализации.
Делать по такой картине выводы о необходимости или нет комментариев нельзя. В Вашем случае они скорее всего нужны — просто потому, что аналитики/тестировщики не умеют писать самодокументированный код.
Но не нужно эти выводы экстраполировать на всю отрасль, в основном в ней всё по-другому. :)
Так о том и речь — постановку задачи должен делать аналитик, код писать — программист. Как из Вашего комментария следует, что отлаживать код должны аналитики или тестировщики — непонятно.
Странно как-то это у Вас вытекает из утверждения "Аналитик или тестировщик не должен заниматься отладкой кода."
Да, протухают.
Чужие или свои — вообще не важно.
Нет, не лень. Но нет никакой гарантии, что, изменив код, программист обязательно изменит комментарий. Возможные причины этого:
Пока код пишут люди, а не роботы, это будет происходить.
Так что про лень редактировать — это опять-таки Ваша фантазия. Прекращайте уже оправдывать свою позицию, навешивая ярлыки на оппонентов.
Ну вот опять :(
В комментариях к этой статье уже дважды люди, ничего обо мне не знающие, записали меня (и еще стотыщ программистов) в ленивого, неспособного писать комментарии и самоуверенного типа.
Это в Вашем придуманном мире. А в реальном я не пишу комментарии (хотя из этого правила есть исключения) потому, что считаю, что от них больше вреда, чем пользы.
Это как? Если я поменял код, то автоматически актуализируется документация?
Если нет (а мы с Вами знаем, что нет :) ), то мы получаем человекозависимый процесс и далее по тексту моего комментария выше.
del
Простите, но автор ерундой болтает.
Про причину №1.
В девяносто девяти случаях из ста читатель даже не будет проваливаться в метод
GetFileEncoding.Смысл самодокументируемого кода как раз и состоит в том, чтобы давать кускам кода осмысленные имена.
Про причину №2: автор утверждает, что непоследовательно исполняющийся код не может быть понятен по определению, не приводя никаких доказательств. Нет фактов — обсуждать нечего.
Про причину №3.
Всё, занавес.
Код не пишется для чтения поварами или астрономами. Мы должны писать код, понятный другим программистам. И исходя из этого, код не только может быть самодокументированным, но и должен быть таким.
И пару слов по основному посылу статьи: тут уже написали, что главная проблема документации в том, что её надо поддерживать в актуальном состоянии. Плюсую.
А т.к. эта поддержка человекозависима, то никогда не будет работать стопроцентно качественно, а значит, вы никогда не будете иметь абсолютно актуальную документацию.
Самодокументированный код возможен, документированный — нет.
Если человек не привёл в порядок свой текст — это показатель непрофессионализма. Т.е. отсутствия ответственного отношения к тому, что человек делает.
Оффтопик: а ещё, на мой взгляд, это неуважительное отношение автора к читателям.
У программиста будет аврал при починке бага на проме, и он быстро поменяет код, даже не взглянув на комментарий — всё, ваша документация врёт.
Не обязательно аврал: просто может быть невнимательный человек; конец десятичасового рабочего дня; просто пофигист и т.д.
Проблема такой «документации» в том, что она человекозависима, а значит — ненадёжна, а значит — ей нельзя доверять и мало кто её будет читать, а значит — и писать её не стоит.
Есть, конечно, исключения, когда комментарии писать нужно: если изменения в данном месте могут аукнуться совсем в другом (читатель кода может не знать этого) и если разработчик выбрал какой-то нестандартный/нелогичный подход: надо объяснить будущим поколениям — почему (Ваш пример, как я понимаю, как раз про это).
Всё, других резонов написания комментариев/документации нет.
С окнами, менюшками и прочими интерфейсностями в текстовом режиме.
Эх, жаль, хороший был язык…