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