Давайте и я добавлю про Ростелеком (простите, люди добрые, — кипит, не могу удержаться!).
Подключил их интернет (вынуждено), при работе в Личном кабинете полезли проблемы. Написал на их сайте два обращения в техподдержку — ответа так и не дождался! Вообще.
И это ещё не всё.
Проблему удалось прояснить (не решить, а только выяснить) другим путём.
Как оказалось, если вы хотите иметь N услуг от Ростелекома, вам нужно иметь N разных почтовых адресов. Занавес...
Ещё такой вопрос.
Единственный способ каталогизации заметок — это разделы, и заметка может находиться только в одном из них? Если да, то это плохо.
Допустим, у меня есть заметка по теме "Безопасность локальных сетей на основе Linux" и разделы "Информационная безопасность", "Локальные сети", "ОС Linux" — куда я должен её поместить?
В контексте организации информации иерархия — зло, теги — наше всё.
Вы спорите с утверждением, что "юнит-тесты должны писаться", хотя автор написал, что "если на проекте пишутся юнит-тесты, то это должны делать разработчики, а не тестировщики".
А если вы захотите сделать рефакторинг модуля, вы четырежды подумаете, поскольку придется юнит тесты переписывать, при том что логика самого функционала не поменялась ни на йоту.
Вот из этого видно, что Вы юнит-тесты никогда не писали. Они пишутся на API класса, а при рефакторинге API не меняется, соответственно, тесты переписывать не нужно.
Более того, при рефакторинге юнит-тесты гарантируют, что ничего не сломалось — ибо поведение класса для внешнего мира не изменилось.
Зато теперь понятно, что Peek() является частью получения кодировки файла. Отсюда вытекает вывод, что убирать его нельзя.
Как я уже написал выше, внутрь метода GetFileEncoding() читатель будет проваливаться лишь в том случае, если есть баг с получением кодировки. А т.к. бага нет — то никогда. Вряд ли разработчик будет бродить по коду системы и читать его из чистого любопытства.
У меня ситуация обратная — везде, где я работал, было чёткое разделение ролей аналитика и разработчика. Аналитики являются специалистами в бизнес-анализе (и психологии, без этого работать с заказчиками невозможно :) ) и практически ничего не знают о внутреннем устройстве системы.
И это отлично работает.
Тестировщики — ручное тестирование + автоматизированное (кроме модульного).
Делать по такой картине выводы о необходимости или нет комментариев нельзя. В Вашем случае они скорее всего нужны — просто потому, что аналитики/тестировщики не умеют писать самодокументированный код.
Но не нужно эти выводы экстраполировать на всю отрасль, в основном в ней всё по-другому. :)
Практика показывает, что разделение труда эффективнее, чем найм штучных гениев и мастеров на все руки.
Так о том и речь — постановку задачи должен делать аналитик, код писать — программист. Как из Вашего комментария следует, что отлаживать код должны аналитики или тестировщики — непонятно.
Следующий шаг в такой логике — аналитики не нужны, всё будут делать программисты.
Я бы выстроил это как единую шкалу: менеджеры не нужны < аналитики не нужны < комментарии не нужны < документацию надо изучать по остаточному принципу < тестировщики не нужны < документация не нужна < свои баги нельзя признавать < проект должен состоять только из сеньорных программистов-дедов.
Странно как-то это у Вас вытекает из утверждения "Аналитик или тестировщик не должен заниматься отладкой кода."
Нет, не лень. Но нет никакой гарантии, что, изменив код, программист обязательно изменит комментарий. Возможные причины этого:
аврал, второпях просто не вспомнил, что надо;
конец рабочего дня, усталость, опять же не вспомнил;
просто невнимательный/забывчивый человек;
пофигист — к сожалению, и таких хватает; они просто забивают на такие вещи;
и т.д.
Пока код пишут люди, а не роботы, это будет происходить.
Так что про лень редактировать — это опять-таки Ваша фантазия. Прекращайте уже оправдывать свою позицию, навешивая ярлыки на оппонентов.
Нежелание комментировать код это, почти всегда, лень и самоуверенность, а не что-то ещё.
Ну вот опять :(
В комментариях к этой статье уже дважды люди, ничего обо мне не знающие, записали меня (и еще стотыщ программистов) в ленивого, неспособного писать комментарии и самоуверенного типа.
Это в Вашем придуманном мире. А в реальном я не пишу комментарии (хотя из этого правила есть исключения) потому, что считаю, что от них больше вреда, чем пользы.
Это как? Если я поменял код, то автоматически актуализируется документация?
Если нет (а мы с Вами знаем, что нет :) ), то мы получаем человекозависимый процесс и далее по тексту моего комментария выше.
Спасибо!
Подскажите, пожалуйста, почему к этому конкретно видео доступ закрыт, хотя все другие открыты?
Как граммар-наци насчёт слога не соглашусь. В моей точки зрения "неплохой слог" не может сочетаться с достаточно низкой грамотностью текста.
А запись не планируете выкладывать?
Давайте и я добавлю про Ростелеком (простите, люди добрые, — кипит, не могу удержаться!).
Подключил их интернет (вынуждено), при работе в Личном кабинете полезли проблемы. Написал на их сайте два обращения в техподдержку — ответа так и не дождался! Вообще.
И это ещё не всё.
Проблему удалось прояснить (не решить, а только выяснить) другим путём.
Как оказалось, если вы хотите иметь N услуг от Ростелекома, вам нужно иметь N разных почтовых адресов. Занавес...
Метки (это теги) можно выстраивать в иерархию любой глубины вложенности.
Ещё такой вопрос.
Единственный способ каталогизации заметок — это разделы, и заметка может находиться только в одном из них? Если да, то это плохо.
Допустим, у меня есть заметка по теме "Безопасность локальных сетей на основе Linux" и разделы "Информационная безопасность", "Локальные сети", "ОС Linux" — куда я должен её поместить?
В контексте организации информации иерархия — зло, теги — наше всё.
Evernote.
Десктопное приложение устанавливать необязательно — можно работать онлайн.
Спасибо!
Видеозаписи выступлений выкладывать не планируете?
Вы спорите с утверждением, что "юнит-тесты должны писаться", хотя автор написал, что "если на проекте пишутся юнит-тесты, то это должны делать разработчики, а не тестировщики".
Вот из этого видно, что Вы юнит-тесты никогда не писали. Они пишутся на API класса, а при рефакторинге API не меняется, соответственно, тесты переписывать не нужно.
Более того, при рефакторинге юнит-тесты гарантируют, что ничего не сломалось — ибо поведение класса для внешнего мира не изменилось.
Peek()является частью получения кодировки файла. Отсюда вытекает вывод, что убирать его нельзя.GetFileEncoding()читатель будет проваливаться лишь в том случае, если есть баг с получением кодировки. А т.к. бага нет — то никогда. Вряд ли разработчик будет бродить по коду системы и читать его из чистого любопытства.У меня ситуация обратная — везде, где я работал, было чёткое разделение ролей аналитика и разработчика. Аналитики являются специалистами в бизнес-анализе (и психологии, без этого работать с заказчиками невозможно :) ) и практически ничего не знают о внутреннем устройстве системы.
И это отлично работает.
"По такой картине" — я имею в виду Вашу ситуацию.
Вот в том-то и дело, что у Вас сейчас на проекте все роли перемешаны. Не должен аналитик предлагать способы реализации.
Делать по такой картине выводы о необходимости или нет комментариев нельзя. В Вашем случае они скорее всего нужны — просто потому, что аналитики/тестировщики не умеют писать самодокументированный код.
Но не нужно эти выводы экстраполировать на всю отрасль, в основном в ней всё по-другому. :)
Так о том и речь — постановку задачи должен делать аналитик, код писать — программист. Как из Вашего комментария следует, что отлаживать код должны аналитики или тестировщики — непонятно.
Странно как-то это у Вас вытекает из утверждения "Аналитик или тестировщик не должен заниматься отладкой кода."
Да, протухают.
Чужие или свои — вообще не важно.
Нет, не лень. Но нет никакой гарантии, что, изменив код, программист обязательно изменит комментарий. Возможные причины этого:
Пока код пишут люди, а не роботы, это будет происходить.
Так что про лень редактировать — это опять-таки Ваша фантазия. Прекращайте уже оправдывать свою позицию, навешивая ярлыки на оппонентов.
Ну вот опять :(
В комментариях к этой статье уже дважды люди, ничего обо мне не знающие, записали меня (и еще стотыщ программистов) в ленивого, неспособного писать комментарии и самоуверенного типа.
Это в Вашем придуманном мире. А в реальном я не пишу комментарии (хотя из этого правила есть исключения) потому, что считаю, что от них больше вреда, чем пользы.
Это как? Если я поменял код, то автоматически актуализируется документация?
Если нет (а мы с Вами знаем, что нет :) ), то мы получаем человекозависимый процесс и далее по тексту моего комментария выше.
del