Здравствуйте, мои любимые программисты   !

Понятно, что почти каждый программист рано или поздно сталкивается с чужим кодом, необходимостью его понять и дополнить/модифицировать.
Волнующий меня вопрос состоит в следующем: каковы шансы при желании найти хорошую (!) работу, где не требуется ковыряние в чужих творениях?

Здесь не имеется в виду самое первое время работы на новом месте - понятно, что для полноценного "включения" надо посмотреть, что написали до тебя.
Итак, на работу устроились, в курс дела въехали, тихонько пишите свои кусочки, все отлично. Но если сейчас ковыряние не требуется, то оно может потребоваться позднее... А если вы не хотите этим заниматься? Часто вам приходится принуждать себя это делать? Можно этого избежать без особых потерь?

Поделитесь опытом, пожалуйста   !
(впрочем, есть такая мысль: если ты устроился на хорошую работу, то велика вероятность того, что твои предшественники были профессионалами, делали все вполне неплохо и их код совсем не страшен)


P.S.. Я только что случайно увидела маааааленькую прогу, написанную другим человеком. Такой нечитабельности, такой нерациональной организации и такого количества операторов перехода я еще не встречала! Написавшему это надо руки вырвать и клаву отобрать...
По-любому, когда он пишет что-то более объемное и, скажем так, долгосрочное, он не задумывается о легкой расширяемости в будущем. Нормальные люди после него еще долго будут мучиться.

а я бы не стал так категорично

с одной стороны, мне приходится держать один проект, от которого тоже иногда хочется плеваться. достаточно сказать, что однажды решим поотимизировать я в одном месте сократил количество запросов к базе с 40 до одного, а потом ещё и воспользовался в продолжении, уюрав ещё лишний десяток запросов

с другой стороны, я сам начал один проект, который когда задавался, я сделал его более-менее нормально, но с тех пор, мне пришлось несколько раз на коленках его подправлять орудуя в блокноте на чужих компах, расширить функционал в пять раз и в два раза нарастить объём кода. делалось всё это в течение года, причём по срочному приказу начальства. там такая заплатка на заплатке, что даже я иногда впадаю в депрессию, когда мне надо что-то в нём подправить.

это я к тому, что мы не знаем предысторию того или иного кода, а все эти проекты по сути являются уникальными в своём роде, поэтому очень сильно грешат ошибками
впрочем, если не подкинут работы до нового года, то я собираюсь перебороть его и создать красивую по своей структуре замену предыдущей рванине. а вот если вдруг уволюсь, то предчувствую сколько проклятий произнесёт сменщик мне в спину

bars80080, спасибо за этот комментарий  . Для меня он ценен, потому что опыта работы у меня нет совсем и, соответственно, я плохо представляю, что может делать начальство  .
С теми случаями, когда кто-то будет рассматривать написанное тобой, теперь все понятно    . А меня больше интересует противоположная ситуация    :

Как насчет этого    ??

в данном контексте не вижу. очень велики шансы найти работу, где не потребуется ковыряния - почти любая вэб-студия (ну или подобный программинг, где требуется не разрабатывать что-то новое, а прикручивать пользовательский уникальный скин к готовому отлаженному движку). там становишься на конвеер и клепаешь продукцию одну за другой.

только ничего в конвеере хорошего нет. у этой системы даже есть название "контора седьмого пота". клепать-клепать-клепать и ещё раз клепать. оклад часто низкий, большие премии за проект, но если нет работы - живи впроголодь. а система премий и наценок построена таким образом, чтобы давать тебе ровно столько, чтобы ты не свалил куда-нибудь ещё.

а любую уникальщину приходится поддерживать. простор для творчество, удовольствие от работы, но и конечно легко могут направить на доработку прошлого проекта. хорошо у меня был только один. а следующий после меня столкнётся с семью (пока лишь семью)

кстати, если не поддерживать чужой код, то предполагается, что работа довольно легка для усвоения и не требует большего процесса обучения и больших затрат. а это значит, что платить много не будут, ведь в этом случае текучка кадров большого значения для компании не имеет. не надо боятся, я всегда говорю: дайте ТЗ и время, сделаем всё

KasMP

Скажем так: шансы найти хорошую работу в которой вообще не требуется изучать чужие исходники стремятся к нулю, потому что такой работы практически не существует. Больше (но не так чтобы много) шансов найти работу по разработке (в противоположность саппорту и развитию), где тебе не дадут "монстра", а позволят разработать его самостоятельно. Но это не значит, что если проект - новая разработка, то ковыряться в чужом коде не придется. 
ИМХО основные факторы, требующие изучения чужого кода при разработке новго проекта, это командная работа, и обучение.

1. Командная работа. Если проект рассчитан более чем на одного человека (а в случае если это не двух-трехмесячная наколенная поделка - так и будет), придется сталкиваться с кодом соратников по команде. Стандарты кодирования, гайдлайны и пр. способствуют выработке общих принципов кодирования, но стопроцентной гарантии не дают. Можно попытаться выделить каждому его кусок проекта, но технология промышленного производства требует, чтобы любой кусок кода был известен более чем одному разработчику, так что какая-никакая ротация и пересечения все равно будут присутствовать. В случае отсутствия ротации - после ухода одного из разработчиков подхватывать его кусок скорее всего придется оставшимся членам команды, т.к. врядли новый разработчик (буде такой вовремя принят на работу) сможет сразу взять весь участок.

2. Обучение. Общеизвестно, что изучение чужого кода - важный фактор в процессе обучения программиста. Кроме того, часто это еще и наиболее удобный способ изучения новых технологий или фреймворков - пример использования в виде кода позволяет быстрее понять как именно происходит работа.

Опять же, работа только со своим кодом не обозначает отсутствия негативных эмоций по поводу его качества. На качество кода, как уже упоминалось выше, могут повлиять сжатые сроки, отсутствия полной информации по необходимому функционалу на момент написания кода. К тому же со временем все мы обучаемся, становимся опытнее, и вот уже код, еще недавно выглядевший красивым, мы считаем кривым, подходы - неудобными, комментарии - недостаточными, и вообще все это было давно и неправда.

Так что "свой код хороший, а чужой плохой" - это далеко не аксиома   

Именно так. Не надо бояться ковыряния в чужих исходниках. Можно воспринимать его как собственную творческую работу. Поковырялся в чужом - оно стало твоим. Может быть, тогда и книжки читать не надо, раз они чужие?

Простите но на Ваш вопрос хочеться ответить приблизительно так...
"Срочно читать книги типа Гради Буча по ООА и ООП"

или по другому.
Вы озвучили последствия проблемы правильного ведения проектов, правильного создания логики, кода, кодирования, тестирования и прочее..прочеее..прочее.. скажем так - попробуйте помечтать.т.е. Вы приходите на новое место работы и.... и понимаете всё в полпинка, от кода тащитесь..коментарии старших товарищей стремяться к нулю - и так всё понятно. не плохо? а почему низзя это сделать если Вы сами анжинер? можно... помятуя о том, что нуна начинать с себя - вот и начните с себя создавать то, что будет решать(и нацелено именно на это) именно эти вопросы - т.е. преследовать не сиюминутные цели а задачи решающие проблемы вникания в чужой код, саппорта, тестирования, повторного юзанья и прочее..прочее...прочее...

на мой взгляд ООА и ООП именно та технология которая и решает именно эти задачи. Плюс к тому же она даёт инструментарий правильного создания кода, от теории к решению.


удачи Вам
(круглый)

Копание в чужом коде неизбежно, даже если это будет не Legacy Code, а абсолютно новый проект. Всё равно придётся использовать чужой код в виде компонентов, плагинов, расширений, а то и готовых решений, которые надо подогнать под требования(далеко не всегда адекватные здравому смыслу) заказчика. А как же иначе, если начальство всегда хочет сократить сроки любым доступным способом, и даже если допиливать чьё-то решение будет дольше, чем реализовать своё, всё равно придётся допиливать чьё-то... 
В веб-разработке эти тенденции очень сильно проявляются в вечной войне CMS vs CMF. Большинство разработчиков за CMF, но по факту большиство занимается допиливанием CMS, причём разумных причин на то как правило нет, зато упёртости начальства(в поддержку CMS) хоть отбавляй.

Хорошо написанный код читать легко, приятно и познавательно. 

Основываясь на своём опыте и опыте своих бывших сокурсников по универу, могу с уверенностью сказать, что найти нормальную работу в серьёзной конторе, где нет надобности ИЗУЧАТЬ и ПОДДЕРЖИВАТЬ/РАЗВИВАТЬ чужой код практически невозможно.
Скорее всего это должно быть чтото экзатическое, типа написания прошивок к уникальным(в смысле разрабатываемым для данного конкретного случая) микроконтроллерным устройствам.

Ну или совсем простая работа, типа написания тупых одноокошечных прикладных программок и утилиток. 

Согласен с предыдущими товарищами. Программисту почти всегда приходится копать и отлаживать чужой код. И именно КУЛЬТУРА написания программ определяет профессионализм программиста. 
Сам поддерживаю большой проект, к которому в свое время приложили руку и сопливые студенты и бородатые аксакалы. Иногда сердце кровью обливается... 
Могу дать некоторые совету как облегчить жизнь себе и товарищам в командной работе:
1. Обязательно писать подробные комментарии, излагать идеи, использовать самодокументирование.
2. Придерживаться единого стиля программирования в рамках проекта. (его задает ведущий программист и новичков заставляет читать!)
3. Использовать системы контроля версий, или хотя ставить комментарии кто когда и зачем правил. Вести лог изменения в версиях.
4. Сразу выгонять обезьян практикующих АНТИ-паттерны проектирования.
5. Периодически производить Code Review на наличие плохочитаемых/понимаемых мест.

очень-очень маленький шанс устроится в немолодую стабильную контору и начинать проект с нуля. Расчитывать на то что код будет чистый и читать его будет одно удовльствие не приходится тоже :( Вэтом случае лучше сразу узнавать как все поставлено с тестерами и автоматическим тестирвоанием, ибо любой рефакторинг изначально череват. Уменее пользовать правилдьно контроль версий тоже не маловажно.

не стоит заморачиваться на отдельных аспектах: начальство, график, работа с чужим кодом.
В любом случае, устроившись на работу ты будешь оценивать в комплексе, так зачем себя пугать и накручивать заранее? 
Да, бывает суровое и деревоподобное начальство, но бывают вменяемые и знающие подход к начальству коллеги.
Может быть чужой код, даже ужасный код, но либо связь с предыдущим разработчиком, либо хорошо комментировано.