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

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

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

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

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

Использование “$”для переменной цикла в подобной среде плохая идея, впрочем, ничем не лучше

Использование “$”для переменной цикла в подобной среде плохая идея, впрочем, ничем не лучшеНе следует втолковывать очевидное посредством многословных имен переменных.

С теми же проблемами мы сталкиваемся и в комментариях, сообщающих очевидную информацию, например // Constructor next to a class constructor (Конструктор, следующий за конструктором класса). К сожалению, комментарии такого сорта весьма распространены: обычно они вставляются в код чересчур заботливой средой разработки (IDE). В лучшем случае, они добавляют шуму в исходный текст кода. В худшем со временем они становятся просто неверными.

Многие комментарии просто не сообщают никакой полезной информации. Например, какая польза вам от комментария:

method allows you to passthrough”(Данный метод позволяет вам пересылать данные) к методу под названием passth rough()? Комментарии такого рода лишь отвлекают внимание и со временем могут стать неуместными (если вы мотом измените название метода на sendToHost()).

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

Если код труден для чтения, ему требуются комментарии, Подробно объясняй, строчка за строчкой, что ты делаешь.

Если код труден для чтения, ему требуются комментарии, Подробно объясняй, строчка за строчкой, что ты делаешь.Обычно программисты ненавидят писать документацию. Это потому, что документация, как правило, хранится отдельно от кода, и постоянно обновлять ее параллельно с кодом довольно трудно. Как результат, нарушается принцип DRY (Donl Repeat Yourself He повторяйтесь) [HTOO]), а сама документация может лишь вводить пользователей в заблуждение, а этот обычно хуже, чем полное отсутствие документации.

Более эффективное описание кода достигается комбинированием следующих двух приемов: говорить языком самого кода и использовать комментарии для сообщения не кодовой информации.

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

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

Вместо того чтобы писать слишком интеллектуально и туманно, следуйте принципу PIE

Вместо того чтобы писать слишком интеллектуально и туманно, следуйте принципу PIEНарушение принципа PIE может не только снизить читаемость и ясность кода оно также может негативно сказаться на правильности работы. Автор данного кода хотел определить критическую секцию, чтобы в любой момент времени только один поток мог исполнять код в секции (т.е. “действие”). Для этого он пытается блокировать экземпляр класса Cof feeMaker. Поток сможет исполнять данный метод, только если он не заблокирован в данный момент (в Java вместо lock используется synchronized, но смысл тот же).

Хотя данный фрагмент кода покажется вполне разумным любому программисту на Java или .NET, он скрывает в себе две коварные проблемы. Во-первых, критическая секция имеет слишком широкий охват, а во-вторых, делается попытка заблокировать объект, имеющий глобальную область действия (вся программа). Рассмотрим обе проблемы более подробно.

Предположим, наша кофеварка может готовить также просто кипяток для тех, кто утром предпочитает пить чай с бергамотом. Допустим, нам хочется синхронизовать метод GetWater() и мы ставим lock(this) внутри него. Это обеспечит синхронизацию для любого кода, который использует блокировку экземпляра Cof feeMaker с помощью lock. Это приведет к тому, что нельзя готовить кофе и наливать кипяток одновременно. Может, этого мы и добивались, но, вполне вероятно, мы заблокировали больше, чем требуется. Из самого текста кода этого не понять, и его пользователям остается лишь недоумевать.

Проектировании программного обеспечения

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

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

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

tel-icq