Переубедить новичка., правильно оформлять код. Опции

[gormih]

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

[Unno]

в чужих проектах всегда проблематично разбираться...
проще забить на это дело, пусть сам переделывает работу =)

[GLUK]

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

[gormih]

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

Метод эффективный, но не в гос. конторах. Деньги и время привыкли считать там, где их платят из своего кармана.
Вообще эффективность работы 80% сотрудников отдела у меня вызывает весьма большие сомнения, но к сожалению, в этом коллективе есть сложившийся костяк "стариков", которые привыкли работать своими дедовскими методами, и эти старики обладают весьма значительным авторитетом. (В отличии от новых сотрудников). Мозговой штурм в таком коллективе не катит, все на уровне "Дали команду - бегом исполнять".
Лишаться обязанностей ведущего как то не очень хочется, но и убедить человека в том что он не прав тоже как то надо.

[GLUK]

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

[Foxhound]

Вообще эффективность работы 80% сотрудников отдела у меня вызывает весьма большие сомнения

где-то говорили 30% людей делают 70% работы

[gormih]

Так как русло беседы перешло в сторону от вопросов программирования - перемещаю в другой раздел :-)

[GLUK]

Психология и непознанное? Гениально

[gormih]

Психология и непознанное? Гениально

Не в том смысле, что не познанное. В том смысле, что психология
Во всем виновато странное название раздела.

[leah]

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

Существуют такие понятия как соглашение на кодирование кода. Такие соглашения обязательно нужно вводить в любой организации, которая начинает писать код, который планируется использовать долгое время. Данные соглашения позволяют формировать культуру производства ПО.

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

Теперь к стандартам на кодирование - этому должны учить в институтах, в любой книжке по программированию говорится как СЛЕДУЕТ именовать переменные, функции и документировать код. Если человек этого не делает, то он просто не выполняет свою работу, или проще говоря - не убирает на рабочем месте.
Стандарты есть практически для всех языков (для примера):
- для явы - ]]>http://www.oracle.com/technetwork/java/codeconv-138413.html]]> или ]]>http://java.sun.com/docs/codeconv/CodeConventions.pdf]]>
- для С/С++ ]]>http://www.cs.rice.edu/~dwallach/CPlusPlusStyle.html]]> или ]]>http://www.possibility.com/Cpp/CppCodingStandard.html]]>

Ну и обзорная статья - ]]>http://en.wikipedia.org/wiki/Coding_conventions]]>


Для проверки качества кодирования есть куча разных утилит, например вот - сам пользовался будучи С-программистом (и их руководителем) ]]>http://splint.org/]]> и ]]>http://en.wikipedia.org/wiki/Splint_(programming_tool)]]>
Обзор по другим тулзам ]]>http://en.wikipedia.org/wiki/List_of_tools...c_code_analysis]]>

где-то говорили 30% людей делают 70% работы

Увы, это действительно так. А еще есть правило 80/20: на написание 80% кода требуется 20% времени, а на остальные 20: кода остальные 80% времени

Так как русло беседы перешло в сторону от вопросов программирования - перемещаю в другой раздел :-)

Я так думаю, что зря переместили, как раз про программирование в прямом смысле слова...

Сообщение отредактировано leah - 5.09.2010 - 22:56

[gormih]

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

Вот в этом духе я и приводил доводы руководству. Бесполезно Для них сроки разработки важны, а завтра хоть конец света. Кто то из "стариков" их убедил, что на то, чтобы писать читаемый код нет времени. Тем не менее, времени на программирование с использованием нечитаемого исходника увеличивается ровно на скорость создания этих исходников с нуля другим человеком.
Вообщем, прав GLUK - валить надо с этой конторы - одна деградация, никакого роста как специалисту там не будет.


P.S.: Я уже неделю рассылаю резюме

[GLUK]

Только я вот что-то не понял: тема называется "переубедить новичка", а ты пишешь, что "он в этой конторе на годик подольше меня". Где правда?

[gormih]

Только я вот что-то не понял: тема называется "переубедить новичка", а ты пишешь, что "он в этой конторе на годик подольше меня". Где правда?

Имеется ввиду новичек-самоучка в программировании. У самоучек стиль программирования может вообще не появляться всю жизнь :-)

[leah]

Имеется ввиду новичек-самоучка в программировании. У самоучек стиль программирования может вообще не появляться всю жизнь :-)

Валить действительно нужно - развития никакого не будет.
Ну а насчет самоучек, тут не согласен. Я сам самоучка

У этих товарищей просто неправильное представление о их нужности. Делая запутанный код, они таким образом пытаются поднять свою значимость и добиться своей незаменимости.
Но со временем приходит понимание, что незаменимых людей не бывает.

Вали нафиг оттуда.

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

Вот в этом духе я и приводил доводы руководству. Бесполезно Для них сроки разработки важны, а завтра хоть конец света. Кто то из "стариков" их убедил, что на то, чтобы писать читаемый код нет времени. Тем не менее, времени на программирование с использованием нечитаемого исходника увеличивается ровно на скорость создания этих исходников с нуля другим человеком.

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

Увы, ввести новые правила в ЛЮБОЙ команде очень сложно, но это приносит свои плоды в будущем.

Я бы начал именно с соглашения. И писал бы новый код по новым правилам, а старый переписывал бы по мере необходимости.
Я думаю, что на это согласится и руководство и "старые" программисты.

Сообщение отредактировано leah - 6.09.2010 - 07:21

[Beckham]

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

[gormih]

У этих товарищей просто неправильное представление о их нужности. Делая запутанный код, они таким образом пытаются поднять свою значимость и добиться своей незаменимости.
Но со временем приходит понимание, что незаменимых людей не бывает.

Да не всегда оно приходит, это понимание Я ведь тоже самоучка, ко мне вот пришло. Но знаю человека, который всю жизнь программировал системы, никто в его код никогда не совался ... Но вышло так, что в возрасте 76 лет он умер, а его код ввиду непригодности к правке просто переписали заново. Как бы опыт у него был не 1 и не 10 лет... а стиль так и не сформировался.

[leah]

Да не всегда оно приходит, это понимание Я ведь тоже самоучка, ко мне вот пришло. Но знаю человека, который всю жизнь программировал системы, никто в его код никогда не совался ... Но вышло так, что в возрасте 76 лет он умер, а его код ввиду непригодности к правке просто переписали заново. Как бы опыт у него был не 1 и не 10 лет... а стиль так и не сформировался.

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

Если такого человека нет, то на код регулярно натравливают всякие тулзы типа splint, pc-lint и прочие автоматические проверяльщики кода. По результатам натравливания всем рассылается почтой результат работы проверяльщика.

Кстати, рекомендую натравить на код doxygen - выгод как минимум две:
1) получите хоть какую-то документацию + зависимости + граф вызовов и т.д.;
2) получите список того, что нужно документировать.