Здравствуйте, Ikemefula, Вы писали:
I>У разработчика вообще говоря основная обязанность — читать чужой код. Комментарии, которые описывают код, не нужны.
Основной обязанностью прежде всего является разработка, чтение кода — это необходимость.
Комментарии обязательны в контракте класса — это точно такая же необходимость. Именно благодаря этому я не лезу каждый раз в мсдн в поисках "а что же там входе и выходе у этой функции".
I>В одном месте сменил сигнатуру функции или сделал какой инлайн — и в 50 местах надо сменить каменты. И то руками, руками, руками.
Это явно какой-то дефективный код(либо избыток комментов, либо излишняя связанность), если подобное происходит.
Здравствуйте, Khimik, Вы писали:
K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой. K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода. K>Как вы для себя решаете эти проблемы?
Если у вас неограниченное количество времени и работодатель готов вам его оплачивать, то почему бы и не переписать всё с нуля. По-моему, такое случается редко, а если и случается, то решения принимает не разработчик и проблемы "принятия решения" у него никакой нет.
С другой стороны, в какой-то книжке читал совет типа "если у вас есть gut feeling, что для выполнения вашей работы надо переписать всё, но начальник не даёт денег — переписывайте! (на свой страх и риск)".
Здравствуйте, IncremenTop, Вы писали:
IT>Основной обязанностью прежде всего является разработка, чтение кода — это необходимость.
Ага, а еще более основной обязанностью является хождение на работу.
IT>Комментарии обязательны в контракте класса — это точно такая же необходимость. Именно благодаря этому я не лезу каждый раз в мсдн в поисках "а что же там входе и выходе у этой функции".
I>>В одном месте сменил сигнатуру функции или сделал какой инлайн — и в 50 местах надо сменить каменты. И то руками, руками, руками.
IT>Это явно какой-то дефективный код(либо избыток комментов, либо излишняя связанность), если подобное происходит.
Это нормально, когда используют полезную функцию или класс.
Здравствуйте, tdiff, Вы писали:
T>С другой стороны, в какой-то книжке читал совет типа "если у вас есть gut feeling, что для выполнения вашей работы надо переписать всё, но начальник не даёт денег — переписывайте! (на свой страх и риск)".
Так и хочется добавить "... за свой счет (в свое свободное время)"
Здравствуйте, IncremenTop, Вы писали:
IT>Не надо играть в демагогию. Нанимают программистов для разработки, а не для чтения кода.
Вы нанимаете отдельных людей для чтения кода и пересказа программистам?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Khimik, Вы писали:
K>>Как вы для себя решаете эти проблемы? 0>Согласен с точкой зрения Спольски: http://www.joelonsoftware.com/articles/fog0000000069.html
0>На практике видел последствия попыток сделать big band rewrite, последствия всегда были печальные.
а я ксати был в мс свидетелем глобального переписывания. случилось все то, что здесь и говорят
— в результате переписывания возникла просто еше одна параллельная куча говнокода
— нафигачившие говнокод быстро свалили с повышением в другие отделы (я с тех пор отношусь подозрительно ко всем кто в мс быстро продвигается )
— было просрано очень много денег
— проект потом вообще закрыли, всех разогнали, в том числе и руководство
Здравствуйте, IncremenTop, Вы писали:
I>>Ага, а еще более основной обязанностью является хождение на работу.
IT>Не надо играть в демагогию.
Начни с себя, покажи пример.
>Нанимают программистов для разработки, а не для чтения кода.
Новое слово в разработке — писать не читая
I>>Это нормально, когда используют полезную функцию или класс. IT>Ненормально, когда правят внешние обязательства множества полезных функции при рефакторинге.
Вот это и есть демагогия. Ранее ты предложил коментировать не только внешние обязательства, но и "что она делает". Вот это "что она делает" как раз и меняется рефакторингом на раз.
Кроме того, ты предложил фактически заменить чтение кода чтением каментов. Это значит, что вообще все важные моменты должны быть в каментах. И снова даже небольшой рефакторин заводит в тупик.
Ну и до кучи — внешние обязательства так же могут измениться. Например пропадут или появятся побочные эффекты. Если наблюдаемое поведение не изменилось — плевать.
Здравствуйте, Ikemefula, Вы писали:
I>Новое слово в разработке — писать не читая
Ок, раз не перестаешь играть в демагогию, то тоже передерну.
Новое слово в разработке — исключительно чтение кода. Открой отдельную библиотеку читающих программистов, зачем писать код, когда можно его просто читать?
I>Вот это и есть демагогия. Ранее ты предложил коментировать не только внешние обязательства, но и "что она делает". Вот это "что она делает" как раз и меняется рефакторингом на раз.
Мое:
"Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно."
Поздравляю с тем, что нагло переврал мои слова.
I>Кроме того, ты предложил фактически заменить чтение кода чтением каментов. Это значит, что вообще все важные моменты должны быть в каментах.
Я предложил сократить чтение кода по-возможности, ибо это глупость во всех случаях читать код. Глупость в квадрате, когда программист по фронтенду будет лезть в бэкенд для чтения кода и будет тратить время на это. Также глупо и обратно — когда программист бэкенда будет делать обратное.
Потому что люди приходят и становятся программистами не для того, чтобы читать чужой код. И платят им не за это. Это — издержка, а издержки принято сокращать.
И да — действительно важные моменты должны быть в комментах, а не в голове у разработчика.
I>Ну и до кучи — внешние обязательства так же могут измениться. Например пропадут или появятся побочные эффекты. Если наблюдаемое поведение не изменилось — плевать.
До кучи изменять название функции и переменных точно также придется. Особенно пикантно выглядят названия, которые не умещаются даже в строчку.
Еще более пикантно, что ни во всех библиотечных функциях почему-то есть комментарии, не смотря на говорящие названия. Вокруг дураки(с).
Здравствуйте, Khimik, Вы писали:
K>У меня время от времени появляется необходимость добавить новый функционал к коду, написанному лет восемь назад. И тогда довольно часто возникает дилемма: переписывать ли старый код целиком, либо добавлять к нему одну заплатку за другой.
Тесты хоть есть? K>Старый код написан неграмотно, и если его переписывать с нуля, избегаешь прошлых ошибок – это как строить город по заранее составленному проекту, с большими проспектами. Но переписывание кода с нуля – большая работа, и поэтому часто я выбираю просто добавление к коду разных заплаток. И чем больше этих заплаток, тем легче в них окончательно запутаться. Проблему частично решает изобильное написание комментариев, которые служат “картой” в лабиринтах запутанного кода.
Такова жизнь. K>Как вы для себя решаете эти проблемы?
Тесты.
Как только покрыли — переписываем.
IT>Уже не первый раз встречаю подобное заблуждение. Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно. И даже если код написан идеально — для разработчика это является потерей времени читать чужой код, когда все нужная для него информация должна быть в комментарии, еще лучше — писать комментарии на языке, на котором думает команда.
Всё классно, кроме того, то команда может думать на разных языках.
I>Есть много способов радикально изменить структуру кода, сделать его более гибким, понятным и дешевым в майнтенансе и при этом достаточно надежным для применения в продакшне. Переписывание сюда никак не вписывается. Это, фактически, обнуление накопленого экспириенса.
Не всегда.
Есть случаи, и я с такими сталкивался, когда переписали 80% кода, те же люди, что и начинали. И никакой экспириенс никто не обнулил, наоборот, сделали относительно нормально, т.к. знали в чём трудности.
После того как поняли, что бороться с багами бесполезно.
Да, заняло порядочно времени, пришлось таки заняться тестированием, составить хоть какие-то требования.
Но это окупилось в итоге.
И да, проект не на одного человека.
Пока переписывали — правили баги в старом коде и документировали тщательнейшим образом.
Здравствуйте, dr. Acula, Вы писали:
I>>Есть много способов радикально изменить структуру кода, сделать его более гибким, понятным и дешевым в майнтенансе и при этом достаточно надежным для применения в продакшне. Переписывание сюда никак не вписывается. Это, фактически, обнуление накопленого экспириенса. DA>Не всегда. DA>Есть случаи, и я с такими сталкивался, когда переписали 80% кода, те же люди, что и начинали. И никакой экспириенс никто не обнулил, наоборот, сделали относительно нормально, т.к. знали в чём трудности. DA>После того как поняли, что бороться с багами бесполезно.
Может просто нечего было обнулять ?
Сразу возникает вопрос — рефакторинг пробовали ?
DA>Да, заняло порядочно времени, пришлось таки заняться тестированием, составить хоть какие-то требования. DA>Но это окупилось в итоге.
Не ясно, что это значит. Порядочно — это больше чем на предыдущую версию или меньше ?
И что значит 'составить хоть какие то требования' ?
Окупилось — это не аргумент. Могло ли быть, что рефакторинг получился более эффективным ?
Здравствуйте, IncremenTop, Вы писали:
I>>Новое слово в разработке — писать не читая
IT>Ок, раз не перестаешь играть в демагогию, то тоже передерну. IT>Новое слово в разработке — исключительно чтение кода.
Никто и не предлагает заниматься исключительно чтением кода. Бизнес-логику например нужно читать. А вот внешнюю либу совсем необязательно.
Вообще все что непосредственно код твоего приложения, нужно читать в обязательном порядке.
Из этого следует неочевидный момент — код нужно писать так, что бы его было легко прочесть. А ты предлагаешь на этом не заморачиваться и заменить это каментами, на том основании что их легче читать.
I>>Вот это и есть демагогия. Ранее ты предложил коментировать не только внешние обязательства, но и "что она делает". Вот это "что она делает" как раз и меняется рефакторингом на раз.
IT>Мое: IT>"Название даже функции в 20 строчек порой не отображает то, что она делает, а мне именно это и нужно." IT>Поздравляю с тем, что нагло переврал мои слова.
Название и не должно отображать что делает функция. Название — filterBy, и отсюда никак не следует, что именно делает функция.
IT>Я предложил сократить чтение кода по-возможности, ибо это глупость во всех случаях читать код.
Ты предложил заменить чтение кода чтением каментов. Это жосткое требование — слишком много работы без гарантии какого либо результата
IT>До кучи изменять название функции и переменных точно также придется. Особенно пикантно выглядят названия, которые не умещаются даже в строчку.
Ну так дай правильное имя. Глядишь, каменты и не понадобятся.
IT>Еще более пикантно, что ни во всех библиотечных функциях почему-то есть комментарии, не смотря на говорящие названия. Вокруг дураки(с).
Публичный АПИ библиотек — единственное исключение. Каменты здесь выполняют совсем другую функцию. Точнее — докумнтация делается за счет каментов.
Не любой камент есть документация.
Здравствуйте, Ikemefula, Вы писали:
I>Вообще все что непосредственно код твоего приложения, нужно читать в обязательном порядке.
Верно лишь для маленьких проектов или для зеленых на первых стадиях. В остальных случаях — бред сивой кобылы.
I> А ты предлагаешь на этом не заморачиваться и заменить это каментами, на том основании что их легче читать.
Я не предлагал это.
Не надо вешать свою булевскую логику на все случаи жизни.
Если снова не смог прочесть мои слова, то переведу проще — "комментарии нужны, чистый код никогда их не заменит полностью". Твои фантазии меня не интересуют, выше можешь прочесть, что я действительно сказал, а не ты выдумал.
I>Название и не должно отображать что делает функция. Название — filterBy, и отсюда никак не следует, что именно делает функция.
Еще прелестнее.
I>Ну так дай правильное имя. Глядишь, каменты и не понадобятся.
Комментарии понадобятся, ибо читать, что делает внешняя в рамках данной работы функция необязательно и затратно.
I>Публичный АПИ библиотек — единственное исключение. Каменты здесь выполняют совсем другую функцию. Точнее — докумнтация делается за счет каментов.
Я приводил выше пример — не должен программист бэкенда лазить во фронтенде. У них разные специализации и это потеря времени. Точно также какой-нибудь математик-алгоритмист не должен лазить в бэкенде. Это глупо и нерациональное расходование средств.
Здравствуйте, Ikemefula, Вы писали:
I>Например indexOf это хорошее имя, а вот что именно делает функция, что бы найти индекс, совершенно не актуально.
Сдается мне, indexOf точно отражает, что именно делает функция. А вот то, как она это делает, пользователя не интересует. Если же внутри что-то хитро вывернутое, то в начале функции пишем комментарий, содержащий ссылку на документ, описывающий алгоритм, используемый в функции.
Здравствуйте, IncremenTop, Вы писали:
I>>Вообще все что непосредственно код твоего приложения, нужно читать в обязательном порядке.
IT>Верно лишь для маленьких проектов или для зеленых на первых стадиях. В остальных случаях — бред сивой кобылы.
Наоборот. В остальных случаях всегда накапливаются частные, вырожденные и разные неочевидные кейсы, результаты многочисленных фиксов и тд и тд и тд. Все это описывать текстом мягко говоря дорого.
Скажем, даже при серьезных инвестициях в документацию в ней будет вагон пробелов, разночтений и тд и тд. С комментариями все обстоит еще хуже.
IT>Я не предлагал это. IT>Не надо вешать свою булевскую логику на все случаи жизни.
Предлагаешь вообще логикой не пользоваться а верить тебе на слово ?
IT>Если снова не смог прочесть мои слова, то переведу проще — "комментарии нужны, чистый код никогда их не заменит полностью". Твои фантазии меня не интересуют, выше можешь прочесть, что я действительно сказал, а не ты выдумал.
Наоборот. Сначала — чистый код. А вот в некоторых частных случаях — комментарии. И нужно отделять документацию от комментариев
I>>Ну так дай правильное имя. Глядишь, каменты и не понадобятся.
IT>Комментарии понадобятся, ибо читать, что делает внешняя в рамках данной работы функция необязательно и затратно.
Перечитай своё "Еще прелестнее", про filter и прочее.
IT>Я приводил выше пример — не должен программист бэкенда лазить во фронтенде. У них разные специализации и это потеря времени. Точно также какой-нибудь математик-алгоритмист не должен лазить в бэкенде. Это глупо и нерациональное расходование средств.
Правильно ! И мне для работы с бакендом нужны только правильный АПИ. А тебе нжны, внимание, каменты. Где находятся каменты ? Правильно — вмест с кодом. Итого — именно у тебя и нужно лезть в код бекенда за комментариями, ибо из апи и тестов нихрена не ясно.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Ikemefula, Вы писали:
I>>Например indexOf это хорошее имя, а вот что именно делает функция, что бы найти индекс, совершенно не актуально.
P>Сдается мне, indexOf точно отражает, что именно делает функция.
indexOf отражает ожидания пользователя, сам результат.
>А вот то, как она это делает, пользователя не интересует. Если же внутри что-то хитро вывернутое, то в начале функции пишем комментарий, содержащий ссылку на документ, описывающий алгоритм, используемый в функции.
Здесь самое интересное — посмотри, на основании чего ты переименовываешь функции.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Khimik, Вы писали: K>>Как вы для себя решаете эти проблемы? S>Ничего нельзя переписывать. Вам кажется, что вы "избежите старых ошибок".
Если я правильно помню, Эвернот был переписан нс С++ с чего-то другого и выиграл от этого. Местный проектородел дрВано тоже переписывал свой протектор нс С++.
K>Как вы для себя решаете эти проблемы?
С помощью рефакторинга. Как тут уже писали, нужно постепенно покрывать код тестами и рефакторить. Правда забыли добавить что легаси код часто бывает невозможно покрыть тестами,так как он плохо написан. Тут уже возникает проблема, которая сродни квантовой физике, измерение изменяет состояние. Чтобы написать тест, нужно сначала немного порефакторить и переписать. Тут могут помочь всевозможные функциональные тесты, но даже с ними — процесс весьма непростой. Есть неплохая книжка на эту тему — http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
