Бля вот так вот пишешь хуету, потому что на начальной стадии проекта тебя наняли хуярить за еду, а потом ведь это кому-то дорабатывать придется, и кто-то ведь так вечно будет работать над говном мамонта. И никакой хуе-летний опыт ему не поможет быстро и качественно дорабатывать твои высеры, потому что тупо ногу сломишь. Да еще и в глазах начальства этот бедняга будет тупым медленым пиздоболом, который говорил что умеет дохуя, а по факту нихуя не может, не то что тот шустрый джун-молодчага, который всё быстро и задешего делал. Эх, не хотет такое делать.
> - КАК БЛЯДЬ С ЭТИМ РАБОТАТЬ?
Молча. Если тебя привлекает это предприятие, и ты хочешь на нем работать, то берешь себя в руки и познаешь как все это легаси говно работает. Со временем сможешь обосновать, что ту или иную часть стоит переписать. Чем больше ты погрузишься во все это, тем больше зп сможешь просить, т.к. начальнику будет невыгодно нанимать нового раба, который будет разбираться во всем этом полгода.
Молча. Если тебя привлекает это предприятие, и ты хочешь на нем работать, то берешь себя в руки и познаешь как все это легаси говно работает. Со временем сможешь обосновать, что ту или иную часть стоит переписать. Чем больше ты погрузишься во все это, тем больше зп сможешь просить, т.к. начальнику будет невыгодно нанимать нового раба, который будет разбираться во всем этом полгода.
дык делаешь то что тебе скажут
только если у вас вообще глушняк с поставленными процессами разработки (те тупо нет даже багтрекера), то проводишь всю постановку задач через почту хотя бы - те чтобы все поставленные тебе задачи проходили через нее
никогда не выполняй указания со слов, требуй чтобы хотя бы письмом дублировали их
только если у вас вообще глушняк с поставленными процессами разработки (те тупо нет даже багтрекера), то проводишь всю постановку задач через почту хотя бы - те чтобы все поставленные тебе задачи проходили через нее
никогда не выполняй указания со слов, требуй чтобы хотя бы письмом дублировали их
Переписывать кусками (в основном экстрактить методы поначалу), чтобы понять логику.
- слушать этого.
Когда поймешь логику, начать кусками переписывать.
фантазии. он так и проработает 1,5-2 года так и не особенно поняв как оно работает
И меня это пиздец печалит. Вокруг одни мартыханы, которые бездумно копируют существующий код, плодя говномодули один за одним. А потом их хуй спилишь.
Одно запомни, благодарности ты от этих людей не дождёшься.
Сам охреневаю с легализовали и удивляюсь где они за бешеные деньги набирают обезьян, которые делают говно, которое потом надо чистить и доделывать за копейки? Мне ниразу с нуля ничего не давали делать зато от этих доработок чужого говна я охереваю
Вот этот вроде не совсем дебил.
>проработает 1,5-2 года так и не особенно поняв как оно работает
Самую суть ухватил. Только я нихуя не уверен а скорее даже уверен в обратном, что и отработав 3-5 лет не особенно буду понимать как оно работает.
На всякий случай напомню основные вопросы
> - Есть ли какие методики, книги, etc?
> - Как вообще в идеале должна быть построена работа когда уже написаны килотонны кода и приходит новый человек?
> - Как управлять сложностью в таких случаях?
+1
вообще есть шанс, что никто не оценит, какой труд ты проделал разбираясь (просто не поймут), ведь все остальные участники срать хотели на это говно, их время слишком дорого им самим чтоб думать об этой "системе". им важнее свое, личное, ну и крысиная возня.
- если действительно хочешь разобраться тебе надо сначала понимать _что_ оно делает, а потом уже _как_ (_как_ - это уже в коде пытаться понять)
- можешь даже взяться документацию на нее на всю написать (но на то, что при увольнении ты сможешь ее "продать" не рассчитывай даже, дохлый номер, не те времена, не те люди). т.е. писать ее нужно только для себя. (и никому не показывать)
- еще можно пытаться систему эту гробить дальше просто переписывая ее частями, но как правило это малореально
>в основном экстрактить методы поначалу
к примеру ты ПОТРАТИЛ 2 недели чистого времени чтобы экстракнуть два метода и гарантировано(кхм-кхм..) ничего не сломать.
ты сэкономил топливо, сырье деньги конечной конторе? нет.
ты ускорил процессы конечной конторе? нет.
ты облегчил труд пользователям чтоб им было чуть легче жить("та женщина тебе будет успевать и ее не уволят")? нет.
ты улучшил удовлетворил шизо-мазо желания своего менеджера чтоб он больше тебя любил и не нанял тебе другого программиста-конкурента? нет.
ты уменьшил колическо багов чтоб не ломалось так часто? нет.
ты добавил новый "функционал"? нет.
2 пресс-хаты этому отрицале.
Что значит экстрактить методы?
из лапши и говна макаки-предшественника выделять логические части и создавать методы.
Несколько советов
1) Выполняй задачи по принципу минимального вмешательства. Меняй/добавляй только тот код без которого не обойтись. Чем меньше будет diff твоего merge request'а, тем проще ревьюверу и спокойнее вам обоим. Есть личности, которые любят "рефакторить" все подряд. Они чинят один баг и добавляют десяток новых. Никогда так не делай.
2) Верь только тому что сам видел и проверял. Документации и комментариев к коду обычно нет, или они устарели. Проверяй все сомнительные места.
3) Используй поиск в IDE, отладчик, профайлер, логи, ассерты и т.д. Ты должен в совершенстве владеть техникой "копания" (обычно в вакансиях этот скилл называют "умение разбираться в чужом коде"). Бывает что задачу можно решить правкой одного конфига, но если ты не знаешь про этот конфиг - ты потратишь неприлично много времени на это.
1) Выполняй задачи по принципу минимального вмешательства. Меняй/добавляй только тот код без которого не обойтись. Чем меньше будет diff твоего merge request'а, тем проще ревьюверу и спокойнее вам обоим. Есть личности, которые любят "рефакторить" все подряд. Они чинят один баг и добавляют десяток новых. Никогда так не делай.
2) Верь только тому что сам видел и проверял. Документации и комментариев к коду обычно нет, или они устарели. Проверяй все сомнительные места.
3) Используй поиск в IDE, отладчик, профайлер, логи, ассерты и т.д. Ты должен в совершенстве владеть техникой "копания" (обычно в вакансиях этот скилл называют "умение разбираться в чужом коде"). Бывает что задачу можно решить правкой одного конфига, но если ты не знаешь про этот конфиг - ты потратишь неприлично много времени на это.
Правда жизни. Попытки чего-то там вникать, рефакторить всегда быстрее приводят к увольнению.
Попробуй сказать менеджеру как есть: Проект большой, требует понимания программистом предметной области, бизнес-логики/бизнес-правил, код проекта не наивысшего качества. На одно только изучение мне потребуется 5 месяцев в течение которых никакой код вообще писаться не будет, но будет получено понимание и документация. Только после этого я смогу выполнять задачи, прикидывать как-то строки и сложность. Сразу же будешь уволен, хотя это и правда.
>экстрак
хуевый совет. совсем хуевый.
- ОП не может проверить ничего (и хуюнит-хуирование тут не помогло бы ни грамма на самом деле). он точно будет ее ломать, т.к. даже если он будет понимать что оно делает, у него не будет возможности запустить эти процессы тестово, не отправив деньги не нарушив балансы, не отправив не тех писем и т.д.
- иногда экстрактинг работает и вообще рулит. но бывает что весь экстрактинг в итоге осуществляется скорее на уровне синтакса и семантики языка. компилятор вот тоже манипулирует как угодно кодом в процессе оптимизации, но он что-то там понимает? вот ОП так же будет экстрактить. это просто мартышкин труд, причем крайне дорогой.
obscureExtractedFunction(obscureParam1, obscureParam2, obscureParam3, obscureParam4, obscureParam5, obscureParam6, obscureParam7, obscureParam8, obscureParam9, obscureParam10, obscureParam11)
Зачем ты туда пришел вообще, лол, судя по ОП-посту еще и осознанно. Блять бывают же уебаны.
- КАК БЛЯДЬ С ЭТИМ РАБОТАТЬ?
- Есть ли какие методики, книги, etc?
- Как вообще в идеале должна быть построена работа когда уже написаны килотонны кода и приходит новый человек?
- Как управлять сложностью в таких случаях?
- Советы, охуительные истории как ты анон с честью выходил из ситуаций когда оказывался без вины виноват?