[Moscow.pm] несколько общих вопросов начинающего "программиста"

[Orlovsky Alexander]

16.11.2011, 12:06, "Тимофей Марков" <timonnius на gmail.com>:
> Добрый день Moscow.pm Поделитесь опытом/советомЕсть небольшой демон(порядка 500 строк), написанный мной на перле, который крутится на моих серверах. В скоре необходимо будет расширять его функционал. И вот взглянул я на этот код и понял что он классический - "быдлокод" потому решил его переписать, благо время есть, работа работается, а я предоставлен себе. Отсюда несколько вопросов:
> -Посоветуйте что почитать (ну или просто совет дайте) о том как писать "качественный" код, я по образованию ниразу не программист и, к сожалению с общими подходами программирования не знаком.

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

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

На практике встретив что-то непонятное – стараться понять, как это "что-то" работает и чем руководствовались авторы, когда писали код.
Книги по теме: "Анализ программного кода на примере проектов Open Source" (переводная), "Идеальный код" (в оригинале вообще-то "Beautiful code"). Еще могу порекомендовать "Практику программирования" от Кернигана и Пайка.

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

Как минимум надо очень хорошо знать свой основной инструментарий (на это уходят годы) и не забывать посматривать по сторонам (чтобы не видеть все проблемы как "гвозди")


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

Чем проще он будет, тем надежнее. Но вот только "простота" реализации – может быть очень сложной задачей.
Хорошая статья про сложность: http://www.rsdn.ru/article/philosophy/Complexity.xml

Книга по теме: "Искусство программирования в UNIX". 
Философия UNIX — Википедия: http://ru.wikipedia.org/wiki/%D4%E8%EB%EE%F1%EE%F4%E8%FF_UNIX

Есть инженерные практики типа TTD & etc, но это скорее "вишенка на торте" в плане обеспечения качества и надежности. 

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

это нормально, ибо "There are only two hard things in Computer Science: cache invalidation and naming things."(с) :)
но вообще нужно практиковаться и со временем будет проще, немного )

книжки по теме Фаулер "Рефакторинг", Макконелл "Совершенный код" 

общие советы: давать говорящие названия переменным, не слишком усердствовать в этом (иначе появляются монстры типа my_private_super_puper_variable_with_some_magic_and_unicorns), не бояться коротких имен (i, n, tmp) подробности – в книжках выше

полезные ресурсы:
+ http://perldoc.perl.org/perlstyle.html
+ книжка "Perl Best Practices"
+ perltidy

> -Среда разработки и система управления версиями: на данный момент я программирую в редакторе vim (я ведь администратор на самом деле). Хотелось бы узнать, есть ли смысл использовать систему управления версиями в моих масштабах, и если да то какую и с какой стороны подступиться, и что б не отходить от любимого vim-а?

Используй git (ему не обязателен центральный репозиторий и это наиболее распространенный "промышленный" стандарт среди DVCS)
Потраченное время на изучение git – хорошая инвестиция и наверняка пригодится на практике. Кроме того, что сохраняется история кода, гораздо удобнее управлять его конфигурацией (по сути удобство поддержки различных версий) 

vim + vim plugins + CLI- годный набор инструментов для Perl-разработки