Самое страшное — когда какой-то мелкий баг, почти не значительный. Но чтобы его устранить — будет потрачено очень очень много времени. И глубинная причина — что все изначально писалось с целью как можно скорее показать результат выполнения текущей задачи и в перспективе уволиться — без рефакторинга и пр. Т.е. на первых порах это работает, потом начинается хаос в системе.
Правильное решение — провести рефакторинг, но т.к. это слово не понятное и как бы не имеет измеряемого результата для бизнеса — его не проводят.
Здравствуйте, Shmj, Вы писали:
S>Самое страшное — когда какой-то мелкий баг, почти не значительный. Но чтобы его устранить — будет потрачено очень очень много времени.
Ты о чем? Если баг мелкий, то какое очень много времени?
Ты уж определись
Здравствуйте, SergeyIT, Вы писали:
SIT>Ты о чем? Если баг мелкий, то какое очень много времени? SIT>Ты уж определись
Мелкий может быть по значимости и возможно его уже долго откладывали. И возможно для устранения всего лишь одну строчку придется подправить — но никто не знает какую.
Здравствуйте, Shmj, Вы писали:
S>Самое страшное — когда какой-то мелкий баг, почти не значительный. Но чтобы его устранить — будет потрачено очень очень много времени. И глубинная причина — что все изначально писалось с целью как можно скорее показать результат выполнения текущей задачи и в перспективе уволиться — без рефакторинга и пр. Т.е. на первых порах это работает, потом начинается хаос в системе.
S>Правильное решение — провести рефакторинг, но т.к. это слово не понятное и как бы не имеет измеряемого результата для бизнеса — его не проводят.
Нет. Правильно — это быстро-быстро написать, получить бабла и уволится А поддержку оставить лохам
Здравствуйте, Shmj, Вы писали:
S>Самое страшное — когда какой-то мелкий баг, почти не значительный. Но чтобы его устранить — будет потрачено очень очень много времени.
Существуют вполне конкретные методы локализации багов до функции и до строчки. Это не страшно.
Страшно, когда пользователь/заказчик захотел функцию, которая ему кажется естественной и простой, а на самом деле потребует дохрена кодинга. Например, Undo-Redo. Непрограммисту может показаться это естественными двумя кнопочками, но если это не было заранее обговорено, то их добавление может вызвать лютый геморрой
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, SergeyIT, Вы писали:
SIT>>Ты о чем? Если баг мелкий, то какое очень много времени? SIT>>Ты уж определись
S>Мелкий может быть по значимости и возможно его уже долго откладывали. И возможно для устранения всего лишь одну строчку придется подправить — но никто не знает какую.
Дык только одну строчку поправить, или полноценный рефакторинг? Как то нужно определяться.
Если для фикса бага требуется одну строчку поправить, то с архитектурой всё норм. А то что никто не знает, какая именно это строчка —
то это проблема другого вида. Никто не знает код проекта. Тут не про рефакторинг надо думать, а про то, как передавать знания о проекте.
Здравствуйте, Shmj, Вы писали:
S>Самое страшное — когда какой-то мелкий баг, почти не значительный. Но чтобы его устранить — будет потрачено очень очень много времени. И глубинная причина — что все изначально писалось с целью как можно скорее показать результат выполнения текущей задачи и в перспективе уволиться — без рефакторинга и пр. Т.е. на первых порах это работает, потом начинается хаос в системе. S>Правильное решение — провести рефакторинг, но т.к. это слово не понятное и как бы не имеет измеряемого результата для бизнеса — его не проводят.
Мне больше всего не нравятся проблемы, которые случаются "иногда" (типа раз в месяц) у "некоторых пользователей".
IMHO такие очень тяжко искать. Если что-то где-то удалось залогировать, то уже хорошо, а если просто пользователь говорит — дескать,
вот, так мол и так, "иногда" программа показывает не то что должна — пойди разберись.
Здравствуйте, Shmj, Вы писали:
S>Правильное решение — провести рефакторинг, но т.к. это слово не понятное и как бы не имеет измеряемого результата для бизнеса — его не проводят.
Правильное решение уволиться и никогда больше не работать. А то о чём ты говоришь это другое.
У программирования много определений, например.
1. Программирование это составление инструкций исполнителю.
2. Математика это наука о соотношении величин.
И так далее.
В программировании применяется множество наук. Но в конечном итоге всё сводится к преобразованию битов в архитектуре фон Неймана.
Рефакторинг как и тестирование измеряемые величины. Неизмеряемые они для тех у кого недостаточно квалификации их измерить.
Что касается бизнеса, то это ни о чём не говорит. Бизнес переводится на русский как дело. А рефакторинг давай переведём как переработка.
Получаем. S>Правильное решение — провести переработку, но т.к. это слово не понятное и как бы не имеет измеряемого результата для дела — его не проводят.
Способы переработки кода известны и описаны в книжках. По сути всё сводится к тому, что программисты имеют низкое качество знаний и умений. Когда я вижу метод переработки кода я его понимаю, но это не значит, что я запомнил как всё это использовать.
В итоге программисты должны повышать практикой и чтением умной литературы свои знания и умения. А за чей счёт и откуда у них мотивация?
Для бизнеса о котором ты говоришь программист это просто расходный материал, как какой-нибудь картридж в принтере. Кончился, выкинул его, поставил новый.
То что кто-то использует компьютер в работе не значит, что его бизнес завязан на компьютеры. Те же банки, не было бы компьютеров просто бы работали по старому и всё. И так куча бизнесов.
В книгах по программированию любят задавать вопросы на то правильно ли читатель понял тему после прочтения, и вот тебе вопросы.
1. В каких областях программирования важна переработка кода?
2. В каких видах деятельности важна переработка кода?
Первый вопрос связан непосредственно с самим программированием, таким как инструментарий и моделируемые системы. Второй вопрос завязан на бизнес, который будут обслуживать эти системы.
Если ты отвечаешь на них, что переработка кода не нужна, вот тебе и ответ. Значит этому бизнесу это действительно не нужно. Или вот ещё вопрос.
3. Какова цель переработки кода?
У меня есть свои ответы, вроде улучшения быстродействия или улучшение понимания. Просто это тебе нужно задавать вопросы, если ты считаешь, что с точки зрения бизнеса переработка кода не нужна. Так напрашиваются противоположные вопросы.
4. В каких областях программирования не важна переработка кода?
5. В каких видах деятельности не важна переработка кода?
А если ответ, — "И так сойдёт". Может быть и сойдёт, кто спорит.
Здравствуйте, bnk, Вы писали:
bnk>Мне больше всего не нравятся проблемы, которые случаются "иногда" (типа раз в месяц) у "некоторых пользователей". bnk>IMHO такие очень тяжко искать. Если что-то где-то удалось залогировать, то уже хорошо, а если просто пользователь говорит — дескать, bnk>вот, так мол и так, "иногда" программа показывает не то что должна — пойди разберись.
Это из той же оперы — нет логирования в нужных местах и добавить его не просто, т.к. архитектуры нет.
Здравствуйте, Shmj, Вы писали:
S>Чего вы боитесь в работе?
Когда всякие дилетанты, с помощью манипуляций, используя неглубокие знания технологий высокого начальства, начинают ему пихать какие-то супер новые идеи, не проверив то, что мы уже поддерживаем, и не предложив как это будет решаться. И это высокое начальство соглашается. И потом тратим время на всякую херню.
Хорошо, если есть бюджетный буфер, а если нет — конец компании. Но виноваты будут те, кто был против.
Здравствуйте, Shmj, Вы писали:
S>Самое страшное — когда какой-то мелкий баг, почти не значительный. Но чтобы его устранить — будет потрачено очень очень много времени. И глубинная причина — что все изначально писалось с целью как можно скорее показать результат выполнения текущей задачи и в перспективе уволиться — без рефакторинга и пр. Т.е. на первых порах это работает, потом начинается хаос в системе.
Все что связано с кодом это не страшно
Организационные вещи гораздо более противные для меня а такой херни только болше становится на позициях разного рода лидов
Даже не хотел отвечать, т.к. ошибки ваши почти для всех очевидны.
J>Дык только одну строчку поправить, или полноценный рефакторинг? Как то нужно определяться.
Строчка решит проблему, если ее найти. Но найти ее — это как искать иголку в стоге сена. Так понятнее?
J>Если для фикса бага требуется одну строчку поправить, то с архитектурой всё норм.
Для решения проблемы в теории можно было бы найти проблемную строку (никто не знает где ее искать в спагетти-коде). Но на практике таких проблем много и искать каждую очень долго, т.к. спагетти-код.
J>А то что никто не знает, какая именно это строчка — J>то это проблема другого вида. Никто не знает код проекта. Тут не про рефакторинг надо думать, а про то, как передавать знания о проекте.
Что вам сказать... Когда есть карта города, архитектура проектировалась с умом — вы легко найдете путь по нужному адресу. Когда же нет ни названий улиц ни номеров домов ни координат а просто все как бы само собой образовалось — то найти что-либо (даже если это место имеет некое примерное описание) — задача совсем другой сложности.
Самое страшное это порой осознавать что твой проект нужен лишь для демок высокому начальству для выколачивания очередного бюджета, а в реале нафиг никому не сдался.
Или после 10 лет работы твой проект превращают в зомби потому что "контора уходит из РФ" и все закрывает.
Вон в Abby, например, некоторые люди там жизнь положили, а в итоге все в стол.
Здравствуйте, syrompe, Вы писали:
S>Самое страшное это порой осознавать что твой проект нужен лишь для демок высокому начальству для выколачивания очередного бюджета, а в реале нафиг никому не сдался.
Не. Если мой проект принёс мне кучу денег с зарплатой, я буду всё равно доволен. Даже если его закроют.
S>Или после 10 лет работы твой проект превращают в зомби потому что "контора уходит из РФ" и все закрывает. S>Вон в Abby, например, некоторые люди там жизнь положили, а в итоге все в стол.
Если опыт старой работы пойдёт мне на пользу. Поможет хорошо устроиться на новой работе — контору тоже не жалко.
Здравствуйте, syrompe, Вы писали:
S>Самое страшное это порой осознавать что твой проект нужен лишь для демок высокому начальству для выколачивания очередного бюджета, а в реале нафиг никому не сдался.
Тут, кстати, одно вытекает из другого — когда нет цели растить проект, развивать, веры в будущее проекта — то и нужно сделать видимость, качество кода и поддержка не нужна.
Здравствуйте, SkyDance, Вы писали:
SD>В работе можно бояться только одного: осознания, что проработал всю жизнь, и ничего, кроме работы, по сути и не увидел.
сильно зависит что за работа
например полярники, или моряки или у меня есть знакомый налаживаший радиосвязь из ранзных точек мира начиная от северного полюча и заканчивая южной америкой
я думаю многи интроверты счатливы рыботать челыми днями в фоисе и зарабатывать деньги
я встречал американцев которые не когда не выезжали за пределы New England и они счатливы
S>я думаю многи интроверты счатливы рыботать челыми днями в фоисе и зарабатывать деньги S>я встречал американцев которые не когда не выезжали за пределы New England и они счатливы
Так я про это и пишу: представь, что в один прекрасный момент, лет так в 65, они осознают, что все это время ничего кроме работы не видели.
Вот этого-то, думаю, и надо бояться. Не того, что ты делал всю жизнь, а понимания, что ты хотел другого — но уже поздно!
Здравствуйте, SkyDance, Вы писали:
SD>Так я про это и пишу: представь, что в один прекрасный момент, лет так в 65, они осознают, что все это время ничего кроме работы не видели. SD>Вот этого-то, думаю, и надо бояться. Не того, что ты делал всю жизнь, а понимания, что ты хотел другого — но уже поздно!
Вы смешиваете в кучу две разные ситуации. В первой речь о том, что человек потратил всю свою жизнь на работу, отказывая себе в хобби, путешествиях и пр. удовольствиях.
Вторая же о том, что человек всю жизнь условно крутил гайки на заводе, хотя мечтал заниматься разведением племенных скакунов.
И одно с другим не обязательно должно пересекаться. В первой ситуации может быть, например, врач, который дневал и ночевал на работе, помог тысячам самых разных людей, никогда не был в настоящем отпуске и не путешествовал. Но у которого и близко нет мысли о бесцельно потраченном времени.
А поддержку оставить лохам
