Умение разбираться в чужом коде реквестед[1]
«Умение разбираться в чужом коде» — строка-детектор, которая содержится чуть более, чем во всех вакансиях на должность программиста и смежные должности. Чаще всего акцент на этой фразе делается для вакансий разработчика на C++ и PHP, где «чужой» не только код.
Значение фразыВроде как компания ищет высококлассного специалиста.Этот специалист должен быть настолько хорошим, что мог бы даже разбираться в чужом коде.
На самом деле никакого такого умения не существует. Любой человек, способный писать, может и читать. Другое дело, что можно писать так, что потом сам хрен прочитаешь. Усугубляется это тем, что в сравнении с натуральными языками языки программирования, на человеческий взгляд, перегружены «пунктуацией», которая в них крайне важна и не терпит ошибок, а небольшие «слова» могут иметь очень большую (и неочевидную) смысловую нагрузку.
Потому и существуют гайдлайны, они же правила оформления. Например, не лениться использовать «говорящие» названия переменных и функций, даже если они длинноваты, оставлять комментарии в ключевых местах (то есть почти везде), не использовать goto-подобные операторы и так далее. И если подобных единых правил придерживаешься, то код хоть немного, но можно читать. Однако код, написанный в спешке, почему-то получается нечитабельным у большинства разработчиков.
Настоящее значение фразыНужен идиот, который согласен разгребать это дерьмо.Руководитель свято верит, что причина получающегося дерьма в нерадивых программистах, а не в нём.
Разгрести это дерьмо у тебя не получится при любом желании, так как от тебя будут требовать писать всё больше и больше кода, который непонятно как придётся прикручивать к уже существующему, на вдумчивое разгребание времени не останется совсем.
В разработке архитектуры ПО используется метод «снизу вверх», требования меняются постоянно в зависимости от настроения левой пятки руководителя.
С 2011 года среди Java-разработчиков фраза приобрела новый оттенок: программисту подсовывают («посмотреть», доделать, переделать, заставить работать…) под видом собственной разработки довольно качественный код, декомпилированный из какого-нибудь коммерческого продукта. Ну и…
Что мы узнаём об организации по такой вакансииБольшая текучка кадров.
Некому толком поставить процесс разработки в верную позу (при грамотной организации процесса разработки ПО код получается таким, что разобраться в нём не составит труда для любого программиста).
Темпы разработки постоянно подгоняются начальством, качество кода ужасно, переписывать приходится больше, чем писать.Качество ПО, производимого этой конторой — дерьмо.Вам будут перманентно ебать мозг.Что мы узнаём о работникеЕсли фраза встречается в резюме, то означает симметричное:я готов копаться в любом дерьме;я буду писать такой код, разобраться в котором можно, только обладая данным умением;я умею заставить работать то, что накодили разработчики.Когда сабж оправдан
Встречаются случаи, когда такое требование размещают в вакансиях оправданно. Это могут сделать после опыта работы с ковбоями-идеалистами. Когда такие люди сталкиваются с любой программой, они сразу же начинают истерить и пытаться переписать всё с нуля по своим лекалам. Тем не менее «умение разбираться в чужом коде» — это OCHE плохая формулировка. Годная альтернатива — это «терпимое отношение к чуждому коду». И всё равно строка, скорее всего, лишняя, так как должна подразумеваться в каждой вакансии программиста по умолчанию, что-то вроде столь же неимоверно популярного в вакансиях «умения работать в команде», которое на деле означает лишь «не быть мудаком» или «быть податливым мудаком».
Также есть конторы, специализирующиеся на поддержке чужих программ. Обычно востребованы в случаях, когда:за давностью лет авторов нельзя найти, или они отказываются от работы;документация армейски проёбана, и никто не знает, как оно работает;реверс-инжиниринг с целью сделать свой аналог с чем положено.
Здесь уже сабж действительно один из ключевых навыков. Но это уже, скорее, компетенция программиста-аналитика 80-го уровня, а не школьника-быдлокодера, и написано в таких терминах, что не сразу узнаешь, что это оно.
А на самом деле
А на самом деле это базовый навык, без которого нельзя работать программистом. Даже если чужой код был написан твоим коллегой буквально вчера и вы вместе работаете над одним проектом. Кстати, даже если с этим коллегой тесно общаетесь, то вам всё равно придётся разбираться в его коде без него хотя бы потому, что чисто физически тяжело запомнить все правки и то, зачем они были сделаны, особенно если проект большой. Вообще, умение разбираться в чужих наработках свойственно всем профессиям со времён индустриализации общества: новый разработчик твоего кредитного фокуса выкурил много старых чертежей перед тем, как сделать в них свои правки.
См. такжеReverse EngineeringКорпоративная культураИстория успехаЖРАТПримечания↑ На самом деле, код из книжки Александреску и из либы Loki и при вдумчивом чтении всё совершенно понятно.— Я делаю особую, шаблонную магию— Не-не-не, Андрей Александреску, не-не-неАнекдотСсылкиЧто делать, если сотрудник не пишет комментарии к коду.Любой программист без словаря поймёт, что такое Умение разбираться в чужом кодеЯзыки программирования
Промышленные: 1С • BAT • C# • C • C++ • Java • JavaScript (AJAX) • Pascal • Perl • PHP • Python • Ruby • ABAP • Ассемблер • Васик • Фортран
Эзотерические: BrainFuck • Erlang • Forth • Haskell • LISP (My other car) • Prolog • Tcl • TeXПрофессииБыдлокодер • Программист • Тестировщик • Хакер • Хеллоуворлдщик
Методы и стилиReverse Engineering • Анти-паттерн • Выстрелить себе в ногу • Грязный хак • Код (индусский) • Костыль • Метод научного тыка • Помолясь • Свистелки и перделкиПрочее++i + ++i • Deadline • %s • 640 килобайт • CMS • Dummy mode • ЕГГОГ • Foobar • God is real, unless explicitly declared as integer • GOTO • Ifconfig • KISS • RegExp • SICP • sql.ru • Xyzzy • Дискета • Инжалид дежице • КОИ-8 • Лог • Ман • Рекурсия • СУБД • Тест Тьюринга • Умение разбираться в чужом коде • Фаза Луны • Фатальный недостаток