- PVSM.RU - https://www.pvsm.ru -
В этой публикации я хотел бы представить на суд уважаемого читателя некоторые принципы, которыми я руководствуюсь, исполняя свои обязанности в роли Python-разработчика.
С одной стороны хотелось быть поделиться накопленным опытом, который может оказаться полезным для начинающих разработчиков, а с другой стороны получить обратную связь от более опытных разрабочиков, руководителей и специалистов смежных областей.
Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.
Далее дано развернутое пояснение каждому из перечисленных принципов. Для некоторых принципов в круглых скобках указанны постулаты Zen of Python, которые на мой взгляд имеют отношение к данным принципам, либо их частям.
Любое техническое решение должно быть обосновано: начиная от используемых синтаксических конструкций в коде и заканчивая архитектурными решениям самого высокого уровня. Для меня обоснованность технического решения означает наличие аргументов, подтверждающих его преимущеста, неизбежность такого решения, либо иную целесообразность данного решения. Обоснование должно сопровождаться наличием знаний о недостатках данного решения и планом их преодоления, либо обоснованием их несущественности. Кроме того, должны быть рассмотрены альтернативные решения с обоснованием их меньшей привлекательности по сравнению с выбранным решением. В обосновании должны быть учтены как технические, так организационные аспекты, связанные с конкретным техническим решением. Если различные аргументы вступают в противоречие друг с другом, то следует руководствоваться экономическим эффектом того или иного решения для бизнеса, учитывая краткосрочную и долгосрочную перспективы.
В нетехнических, в том числе организационных, вопросах этот принцип должен применяться аналогично.
Данный принцип противопоставлен шаблонному принятию решений, а также необдуманному принятию первого попавшегося решения без должного анализа альтернатив.
Этот принцип направлен на повышение качества принимаемых решений и противопоставлен бессистемному принятию решений.
Следует учитывать какое влияние окажет то или иное решение как в краткосрочном, так и в долгосрочном периоде, а также является ли данное техническое решение полезным для бизнеса в этих периодах.
Данный принцип противопоставлен однобокому принятию решений с концетрацией результатов только в краткосрочном периоде, либо только в долгосрочном периоде, а также без учета потребностей бизнеса и учета влияения на бизнес данных решений с концетрацией исключительно на технических преимуществах решения.
Под эффективность в данном вопросе я понимаю отношение ценности полученного результата для бизнеса к объему требуемых для этого затрат.
Данный принцип противопоставлен подходу, который учитывает только ценность полученного результата безотносительно требуемым затратам.
Правила, методологии, шаблоны и иные ограничение — это обобщение предыдущего опыта с целью получения стабильного результата деятельности в определенных условиях. Однако, в конкретных случаях условия могут отличаться, поэтому необходимо осознано подходить к использованию накопленного опыта и вносить свои коррективы при необходимости.
Данный принцип противопоставлен догматичному следованию правилам, методологиям, шаблонам и прочим принятым ограничениям без учета окружающей действительности.
Бывают ситуации, в которых необходимо в короткие сроки реализовать определённую функциональность или исправить дефект, и при этом существуют альтернативные решения: быстрое и хорошее. От быстрого эффект можно получить сразу, но в долгосрочной перспективе оно может создать сложности и привести к дополнительным затратам. А хорошее решение делать долго и затратно в краткосрочной перспективе, но в долгосрочной перспективе оно окупится и принесёт существенно больше пользы, чем потребовало затрат. В этом случае эффективным будет комбинация обоих решений, а именно: делаем быстрое решение сейчас и в плановом порядке делаем хорошее решение. Суммарно это окажется, чуть более затратно, чем реализация только одного из решений, но эффект от их комбинации, окупит затраты.
Данный принцип противопоставлен попытке сделать все сразу идеально.
Без комментариев
Гибкость — это возможность адаптировать техническое решение под новые условия, которые могут появиться в будущем. Универсальность — это фактическая адаптация технического решения под возможность использования для набора условий. Часто обеспечение универсальности требует больших трудозатрат, чем обеспечение гибкости, так как учитывает большее количество условий, с которыми должно быть совместимо техническое решение. Также обеспечение универсальности может оказаться неэффективным, так как требует адаптации к условиям, которые еще не наступили и возможно никогда не наступят. Кроме того, иногда унификация требует сложно реализуемых обобщений. Поэтому гибкость технических решений крайне желательна, а универсальность не обязательна.
Данный принцип противопоставлен попытке сразу делать универсальные решения, которые в последующем оказываются невостребованными из-за изменения внешних условий.
Мой базовый приоритезированный состав критериев оптимизации выглядит следующим образом (при необходимости следует скорректировать под конкретные условия):
Приоритезация критериев заключается в следующем: во-первых, в первую очередь трудозатраты расходуются на обеспечение критериев с более высоким приоритетом; во-вторых, если критерии вступают в противоречие друг с другом, то применяется решение, соответствующее критерию с более высоким приоритетом.
Данный принцип противопоставлен хоатичной оптимизации качества кода, а также использованию несогласованных между членами команды разработки критериев оптимизации и их приоритетов.
Иногда имеется несколько функционально эквивалентных конструкций кода, но имеющих разную производительность. Как правило достаточно однократно выяснить какая конструкция имеет бОльшую производительность или требования к памяти и использовать ее во всех аналогичных случаях. Однако следует учитывать, что некоторые подобные конструкции могут ухудшать читабельность кода и увеличивать сроки разработки как в момент написания кода, так и при его поддержке и модификации в будущем. Это следует учитывать, чтобы не столкнуться с недостатками преждевременной оптимизации.
Иногда комментарии помогают понять сложный код, однако одновременно они являются индикатором низкой читабельности кода. Поэтому в случаях, когда возникает потребность в написании комментария следует подумать какие изменения возможно внести в код, чтобы потребность в комментарии исчезла.
Вот типичные, на мой взгляд, случаи, когда можно обойтись без комменария:
Случаи, когда комментарии следует написать:
Комментарии могут не только помогать, но мешать разработке поскольку требуют дополнительного времени на написание, занимают место, снижая количество одновременно видимых на экране строк кода, требуют синхронизации при изменении кода, отнимают дополнительное время на прочтение. Поэтому комментрирование должно быть разумным.
Данный принцип противопоставлен избыточному использованию комментариев.
Не всё и не всегда имеет смысл делать в момент написания конкретного участка кода, особенно это касается рефакторинга и внесения изменений, актуальность которых находится вопросом. В таких случаях разумно написать TODO- или FIXME-комментарий в коде, на которым можно будет поработать в более подходящий момент. Желательно при этом сразу назначать примерный приоритет данному комментарию, чтобы упростить планирование в дальнейшем.
Данный принцип противопоставлен написанию идеального кода без учета реальной потребности и затрат на такой код в конкретный момент времени.
Экономия длины названий не может быть сделана в ущерб понятности кода.
Существуют исследования, из которых следует, что количество допущенных ошибок в коде в среднем прямо пропорционально длине кода и числу строк кода в частности. Объясняется это следующим образом: во-первых, чем меньшая часть кода помещается одновременно на экране, тем больше требуется усилий по запоминанию невидимых в данный момент участков кода при разработке, а во-вторых, чем длинее код, тем больше в нем может быть допущено опечаток и других ошибок, связанных с человеческим фактором.
Кроме непосредственного предназначения инспекция кода отлично служит для выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде. В идеальном случае в общую ветку должен попадать только код, прошедший инспекцию кода.
Данный принцип следует из DRY-принципа. Для того, чтобы успешно применять этот принцип необходимо хорошо владеть кодовой базой, а в этом помогает применение инспекции кода всеми членами команды разработки.
При необходимости решить какую-либо задачу (например, отправить email по smtp), следует ознакомиться с наличием готовых библиотек для этой задачи и изучить возможности их использования. Отказ от использования специализированных решений должен быть обоснован, поскольку специализированные решения имеют ряд преимуществ перед новой разработкой.
Специализированные решения уже разработаны и протестированы. Это означает экономию времени на разрабтку, тестирование и исправление дефектов. Иногда кажется, что проще разработать свой код, выполняющий необходимую функцию, так как для использования готового решения требуется потратить время на изучение и имеется риск того, что оно будет потрачено впустую, потому что окажется, что решение не подходит. Однако такое впечатление часто оказывается обманчевым во-первых, из-за недооценки сложности задачи, а во-вторых из-за наличия других преимуществ.
Особенность специализированных решений состоит в том, что они специально разработны для решения конкретной задачи. Это означает, что в них учтены особенности, которые сложно учесть, решая специфичискую задачу попутно основной. Следует понимать, что кроме функциональности решение должно удовлетворять и нефункциональным требования, таким как требования к производительности, безопасности, удобству обслуживания, совеместимости и другим. Все эти особенности требуют глобокого погружения в задачу и в случае своей разработки могут быть упущены из виду в виду ограниченного времени.
Часто специализированные решения публичны и поэтому используются многими разработчиками. Это означает в них уже выявлены и устранены недостатки, с которыми они столкнулись ходе практического использования. Таким образом, специализированные решения позволяют использовать чужой опыт без дополнительных трудозатрат.
Публичные специализированные решения часто имеют окрытый искохный код. Фактически таковыми являются большинство библиотек на языке Python. Такие решения постоянно развиваются сообществом разработчиков, поэтому появляется возможность повышать качество своего программного обеспечения без дополнительных трудозатрат за счет обновления используемых версий.
Часто разные публичные решения легко интегрируются друг с другом (например Spyne и SQLAlchemy), что позволяют существенно сократить затраты на разработку.
Существует ряд обоснованных причин для отказа от использования специализированных решение. Примеры таких причин:
В современных условиях стоимость человеческих ресурсов как правило выше стоимости аппаратного обеспечения, поэтому для меня производительность разработки кода (выраженная в объеме разработанной функциональности за единицу времени) имеет приоритет над производительностью исполнения кода.
Данный принцип противопоставлен преждевременной оптимизации производительности исполнения кода.
Обснование состоит в формировании требований к производительности, которые основаны на практическом или плановом масштабе использования информационной системы, и последующем выявлении несоответствия информационной системы этим требованиям.
Данный принцип противопоставлен преждевременной оптимизации производительности исполнения кода.
Для этого необходимо выявить узкие места, оценить вклад каждого узкого места в снижение производительности и производить оптимизацию наиболее узкого места в первую очередь.
Данный принцип противопоставлен хоатичной оптимизации производительности исполнения кода.
Эффективность методов оптимизации представляет собой отношение доли прироста производительности к общим затратам на выполнение работ по оптимизации. Для меня базовым является следующий приоритезированный список методов оптимизации:
Приоритезация методов заключается том, что в первую очередь осуществляются затраты трудовых и иных ресурсов на использование более приоритетных методов, а переход к следующему методу осуществляется когда возможности оптимизации оказываются исчерпанными, либо эффективность менее приоритетного метода оказывается выше.
Данный принцип противопоставлен хоатичной оптимизации производительности исполнения кода.
Часть принципов я нарочно исключил из публикации, так как они в большей степени относятся к управлению людьми, коммуникациям между людьми и построению процессов разработки, чем непосредственно к написанию исходного кода. Некоторые принципы я просто не смог выявить, либо хорошо сформулировать, так как перевод неосознованного знания в осознанное знание — это довольно сложный процесс. Поэтому я возлагаю большие надежды на то, что комментарии к статье окажутся не менее интересными, чем сама статья, и позволят мне написать продолжение, которое будет включать упущенную информацию.
Автор: dmugtasimov
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/67752
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/233699/
Нажмите здесь для печати.