Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что такое баг? В смысле — что конкретно ты понимаешь под этим словом? Так вот, когда ты сформулируешь это для себя, то поймёшь, что окружающие, как правило, думают иначе.
Баг — все то, что прийдется исправлять. ( Не считая того, когда просто меняются требования ).
TT>>То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости.
К счастью пока такого не было... И честно, совсем не хочется
TT>>И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
ГВ>Правильно понимаешь. Иногда это придётся делать вопреки всем без исключения окружающим. Даже авторитетным. Так что, готовься, никто не обещает, что будет легко. Если, конечно, ты не хочешь стать "ещё одним из миллионов и миллионов" (тогда разговаривать с тобой — пустая трата времени).
Я так уже 14 лет живу, при том, что мне сейчас 19. Знаю как это иногда бывает больно, когда прав, и это точно знаешь, а человек, ответственный — не знает, и тебя ругает... Пришлось научиться объяснять на пальцах, и ломать маску "страшный начальник".
По поводу чего хочу — хочу быть лучшим.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, TafT, Вы писали:
TT>>... без багов.
TT>>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Д>рассказывали мне про одного программиста, который работал в фирме до меня. Так он действительно никогда не делал багов! Правда, работал он настолько невообразимо медленно, что в конце концов его уволили
Да дело в том, что у меня в команде (но на другом проекте, то есть на большую команду 3 несвязанный проекта, которые образуют комплекс), есть человек такой.. Баги он делает, но так мало! И по скорости не отстает. И код его просто прелесть... На вопрос "как?" отвечает — а ты баги не пиши.....
А еще спросил что у меня по русскому в школе было... Тут меня осенило, но это надо лечить (невнимательность? забывчивать? хз). Вопрос как лечить?
Здравствуйте, Дарней, Вы писали:
Д>рассказывали мне про одного программиста, который работал в фирме до меня. Так он действительно никогда не делал багов! Правда, работал он настолько невообразимо медленно, что в конце концов его уволили
Знаю противоположный случай. Один программист писал код с множеством багов. В конце концов его уволили. И тут оказалось что в группе из 5 человек — 70 процентов кода написал именно он. Приглашали его за дополнительные деньги консультировать.
Тоже ситуация не очень хорошая.
А вообще код без ошибок может писать только сама ЭВМ. И то, до тех пор пока в метапрограмме программисты не сделали ошибки.
Здравствуйте, GlebZ, Вы писали:
GZ>Знаю противоположный случай. Один программист писал код с множеством багов. В конце концов его уволили. И тут оказалось что в группе из 5 человек — 70 процентов кода написал именно он. Приглашали его за дополнительные деньги консультировать. GZ>Тоже ситуация не очень хорошая.
Багов за ним числилось тоже 70% от общего количества?
Здравствуйте, TafT, Вы писали: TT>Я так уже 14 лет живу, при том, что мне сейчас 19. Знаю как это иногда бывает больно, когда прав, и это точно знаешь, а человек, ответственный — не знает, и тебя ругает... Пришлось научиться объяснять на пальцах, и ломать маску "страшный начальник".
"Лёлик, только без рук — я всё исправлю!" (c) "Бриллиантовая рука".
Здравствуйте, TafT, Вы писали:
TT>Баг — все то, что прийдется исправлять. ( Не считая того, когда просто меняются требования ).
А ещё поменяться могут несуществующие требования, которые казались очевидными. Здесь нет другого способа, кроме как трясти постановщика задачи для начала и много-много думать. Ну и... учитывать всё, что можно учесть.
TT>>>То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. TT>К счастью пока такого не было... И честно, совсем не хочется
Ну, что ж. Если случится — не пугайся.
TT>По поводу чего хочу — хочу быть лучшим.
Что это такое — "быть лучшим"? Где? В чём? Когда?
У тебя есть баг в начальных посылках. Исправь его, остальные сами исправятся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ArtemGorikov, Вы писали:
AG>Здравствуйте, VladD2, Вы писали:
VD>>К тому же, слава богу, на дворе не 20-й век, а 21. В наших руках автоматизированный рефакторинг, визуальные дизайнеры классов и т.п. А значит можно улучшать код не выкидывая все на помойку, а постепенно.
AG>А что, автоматический рефакторинг и визуальные дизайнеры классов уже научились выявлять логические ошибки?
А что, смена темы уже стала аргументацией считаться?
AG>Так и представляю себе невинную импалу (код на C#) и крадущегося в высокой траве леопарда (злой кул-хацкерский код на С++) . Всем известно, что реинтерпретация памяти считается в C++ дурным тоном.
Серьезно? Жаль мужики не знают. (с)
Большинство С++-программ напичканы опасными конструкциями. Если даже программист их избегает, они все равно появятся благодаря библиотечным вызвом и т.п.
AG> Это не мешает ее интерпретировать произвольно, но то же самое можно делать и в C# в небезопасном коде.
1. Не совсем тоже самое. В C# ты явно выделяшь код занимающийся химией.
2. Правда в том, что для 99% программ небезопасный режим не нужен.
AG>IMHO частота таких падений больше зависит от аккуратности программиста, а уже потом от среды.
Надежда на аккуратность — это самое плохое дизайнерское решение. Человеку свойственно ошибаться и для построения надежной системы нужно продумывать механимы гарантирующие отсуствие ошибок.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Anton Batenev, Вы писали:
AB>Э... Поясни, плз... Пусть у меня есть код. Его критическая оценка говорит мне о том, что его надо выбросить и написать заново — мне самому себе на него смотреть стыдно... Однако, у него есть одна особенность — этот код работает уже 3 года и работает так как надо. Сколько ему еще потребуется работать и через сколько времени он станет неподдерживаемым я не могу сказать. Это во первых.
Если приходится править код, то во время правки производи рефакторинг изменяемых участков кода... и будет тебе щастье.
AB>Во вторых, если при проектировании системы изначально допустили некоторую логическую ошибку, то тут о постепенном рефакторинге речи не идет — ибо начинать надо с самого верхнего уровня иерархи (классов например или структуры данных таблиц в базе).
Это почему же "не идет"? Очень даже идет.
AB>Но ведь все равно рано или поздно наступим на грабли ибо не допускать ошибок невозможно...
Грабли != ошибки. Грабли — это заранее известные провоцирующие на ошибки обстоятельства.
Грабли конечно можно научиться объходить, перепрыгивать, на худой конце, уварачиваться от них. Есть не мало мастеров этого дела. Они уже достигли такой искусности, что могут идти прямо через поле граблей и получить всего 1-2 раза по кумполу.
Но куда лучше просто убрать грабли и не бояться получить по кумполу каждую минуту.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, TafT, Вы писали:
TT>Да, это точно... причем через 2 недели после написания свой же код читать противно...
Это значит, что не просто есть куда рости, но и нужно рости по быстрее.
Я все же говорил о сроке в пол года- год.
TT>Да нет, там есть свои грабли... у нас напимер была утечка памяти... 600Мб/неделю.. .NET
Понимаш ли?... Ошики бываюр разного порядка. Просто утечка памяти при некотором объеме знаний и наличии средств отладки ловится без проблем. А вот испорченная память может породить ошибку второго или даже третьего порядка. Когда ошибка в одном месте портит памят в другом, а вылетает вообще в третьем.
Что же касается утечек памяти. То достаточно завести глобальный массив или глобальный объект с собитиями и набить их мусором.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если приходится править код, то во время правки производи рефакторинг изменяемых участков кода... и будет тебе щастье.
Это что же тогда получается... Одни модули, которые часто изменяемые, показать не стыдно, а над базовыми, написаными на заре проекта, от которых и начались все пляски, хоть плачь?
Я понял твою точку зрения, логикой понимаю, что ты прав и другого выхода, меньшего по затратам, наверное, нет и быть не может, однако, сердце противится этому А противится оно по следующией причине: через некоторое время, при таком подходе, другой человек, читающий этот код, будет подобен археологу, на глазах которого рождается, становится и (не дай бог) умирает цивилизация — люди меняются, стиль программирования меняется как почерк, приходят одни, уходят другие. Даже при наличии соглашения о стилях кодирования, исходный код зрелого продукта будет представлять собой винигрет из смешания культур и вероисповеданий помноженый на время.
AB>>Во вторых, если при проектировании системы изначально допустили некоторую логическую ошибку, то тут о постепенном рефакторинге речи не идет — ибо начинать надо с самого верхнего уровня иерархи (классов например или структуры данных таблиц в базе). VD>Это почему же "не идет"? Очень даже идет.
Тогда, вероятно, речь идет о создании новой ветки в репозитории, ломании всего старого и построении заново?
AB>>Но ведь все равно рано или поздно наступим на грабли ибо не допускать ошибок невозможно... VD>Но куда лучше просто убрать грабли и не бояться получить по кумполу каждую минуту.
Здравствуйте, Anton Batenev, Вы писали:
AB>Я понял твою точку зрения, логикой понимаю, что ты прав и другого выхода, меньшего по затратам, наверное, нет и быть не может, однако, сердце противится этому А противится оно по следующией причине: через некоторое время, при таком подходе, другой человек, читающий этот код, будет подобен археологу, на глазах которого рождается, становится и (не дай бог) умирает цивилизация — люди меняются, стиль программирования меняется как почерк, приходят одни, уходят другие. Даже при наличии соглашения о стилях кодирования, исходный код зрелого продукта будет представлять собой винигрет из смешания культур и вероисповеданий помноженый на время.
Не знаю, плакать надо или смеяться — но обычно так оно и есть
Здравствуйте, Геннадий Васильев, Вы писали:
TT>>И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
ГВ>Ну, это сильно нервирует обычно только поначалу. Потом быстро учишься таких ошибок избегать. Ты ведь уже называешь такие ошибки "тупыми"? Кстати, это далеко не самый неприятный и опасный класс ошибок. В конце концов, падение программы — это диагностика ошибки, когда другие средства не помогают.
Самые простые баги это когда GPF вылетает. Это как правило легко трассируется, ловится и исправляется.
А вот когда все работает но где-то порой что-то ... это труба дело.
Например отладка HTML renderera на каком-нибудь сайте типа New York Times.
Он склеен из всяких мелких кусков из разных источников и все в таблицах.
Здравствуйте, TafT, Вы писали:
TT>... без багов.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
TT>У кого какие соображения на этот счет? Я так понимаю, это исключительно работа над собой, может какие то методики/философии, обязательно применимые в реале!!! Желательно проверенные.
Кто-то мне говорил что у Word примерно 5000 незакрытых багов висит. По жизни.
Наличие багов есть индикация факта что программа кем-то востребована.
Может быть и спорное утверждение, но тем не менее.
По определению в той программе что лежит у меня на полочке так и не распакованная багов нет. Для меня.
Латентные баги есть всегда.
А вот последствия от них должны быть минмальны по возможности.
Но это уже вопрос архитектуры.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что это такое — "быть лучшим"? Где? В чём? Когда?
Если я правильно понял TafT,то у меня такое же желание.
В принципе, стремиться стать лучшим в своём деле нужно всегда и везде. Тогда если даже самым лучшим не станешь, то успеха всё равно добьёшься.
TT>В идеале хочу <= 1 баг/месяц. То есть, что бы к тому что я пишу нельзя было придраться не с точки зрения читабильности, логичности, скорости. И самое главное избегать тупых багов в когда все падает/рушится/ломается и т.д.
Проверенная методика — писать код раз в месяц.
Шутка злая естественно, но в ней намёк.
Волков бояться — в лес не ходить
Не стоит заморачиваться на философии, для начала стоит научится писать так, чтобы найденные баги исправлялись максимально быстро, следующий этап, чтобы гайденные баги исправлялись максимально быстро не только автором кода, но и любым программистом из команды автора кода.
Здравствуйте, VladD2, Вы писали:
.
VD>Со временем ты поймешь, что это невозможно. Чем больше ты понимашь в программировании, тем больше и больше тебе начинает казаться, что написанный ранее код крив, многословен, опасен и медленнен. Если ты перестал замечать этого, то значит твое развитие остановилось.
Я знаю человека который пишет без багов Так че там не возможно?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, __SPIRIT__, Вы писали:
__S>>Я знаю человека который пишет без багов Так че там не возможно? WH>А он случайно по воде ходить не умеет?
Нет хотя кто его знает ...
Он мне как то одну вещь в проекте объяснял я просто с открытым ртом сидел и слушал...
Описания что и как доходчиво и внятно + описания почему именно так т.е. вот так то будет то то
Этот человек пишет чуть ли не пол проекта так что скорость дай боже
Здравствуйте, nNeitrino, Вы писали:
N>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Что это такое — "быть лучшим"? Где? В чём? Когда?
N>Если я правильно понял TafT,то у меня такое же желание. N>В принципе, стремиться стать лучшим в своём деле нужно всегда и везде. Тогда если даже самым лучшим не станешь, то успеха всё равно добьёшься.
