Раскрутка бизнеса - создание сайтов, SEO, SMO в Киеве Голосов: 0 Адрес блога: http://grnweb.ru/ Добавлен: 2015-01-20 16:04:49

Пишите программу с учетом сопровождения — сопровождаюшим программистом являетесь вы сами

2014-12-22 13:29:15 (читать в оригинале)

Пишите программу с учетом сопровождения — сопровождаюшим программистом являетесь вы сами

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

Одной из причин того, что математические доказательства корректности программ остаются донкихотством, является то, что программ – без ошибок не бывает. Каждая программа не только содержит ошибки, но и требования к ней меняются сразу же с момента ее эксплуатации и у пользователя появляются потребность в каких-то новых свойствах, что вызывает появление новых и усовершенствованных ошибок. Так как ошибки всегда с нами, то мы должны писать наш программный код так, чтобы ошибки всегда можно было легко искать. Вы можете переформулировать это правило: Не умничайте. Изощренный код никогда нельзя сопровождать. Очевидно, что ваша программа непременно должна быть максимально эффективной, но первая из ваших задач — сопровождение, и вы не должны приносить читабельность на алтарь эффективности. Сначала напишите программу с учетом сопровождения, затем запустите отладчик для своей программы и определите ее узкие места. Вооруженные реальной информацией, вы уже знаете, где подменить читаемость скоростью, и можете вернуться и внести изменения.Сохраняйте первоначальный текст в комментариях, либо весь модуль до изменения, чтобы, в случае необходимости, можно было бы вернуться назад. Всегда помните, что любые манипуляции с текстом программы не повысят эффектиность в той мере, как это сделает лучший алгоритм. Простой пример - пузырьковая сортировка идет медленно, вне зависимости от того, насколько хорошо написан код.

---

Вы не можете программировать в изоляции

2014-12-22 13:28:59 (читать в оригинале)

Вы не можете программировать в изоляции

В классической книге Джеральда Уэйнберга Психология программирования для компьютеров (The Psychology of Computer Programming, New York, Van Nostrand Reinhold, 1971) приводится прелестная история об автоматах с газированной водой. Администрация одного вычислительного центра решила, что сотрудники тратят массу времени у автоматов с газированной водой. Люди создают много шума и ничего при этом не делают, поэтому автоматы убрали. Через несколько дней консультанты на местах были настолько перегружены работой, что к ним стало невозможно обратиться. Мораль в том, что люди вовсе не зря тратили время; оказывается, издавая весь этот шум, они помогали друг другу в решении проблем. Изоляция может стать настоящей проблемой в группе объектно-ориентированного проектирования, которая обязательно должна состоять из пользователей, проектировщиков-программистов, специалистов по документации и т.д., работающих совместно. Так как число программистов в этой группе зачастую меньше, чем в более традиционных проектных коллективах, то становится трудно найти кого-то, с кем можно обсудить проблемы; производительность страдает. Подумайте о еженедельных дружеских вечеринках, как средстве повышения производительности.

---

Нельзя измерять свою производительность числом строк

2014-12-22 13:28:47 (читать в оригинале)

Нельзя измерять свою производительность числом строк

Раньше, когда вы изучали в школе литературу, вам никогда не приходило в голову сдавать черновик письменного задания, если вы, конечно, рассчитывали на оценку выше тройки. Тем не менее, многие компьютерные программы являются просто черновиками и содержат столько же ошибок сколько и черновики ваших сочинений. Хороший код программы сначала написан, а затем отредактирован в целях улучшения. (Конечно, я имею в виду «редактировать» в смысле «исправлять».)

Учтите, что редактирование должно быть сделано своевременно, потому что неотредактированный текст программы по сути невозможно сопровождать (точно также, как и ваше неотредактированное сочинение было бы невозможно прочесть). Авторы программы знакомы с ее кодом и могут выполнить редактирование более эффективно, чем программист, занимающийся сопровождением, который сначала должен ее расшифровать, прежде чем окажется возможным выполнить какую-либо реальную работу.

К сожалению, в отчетных документах это выглядит впечатляюще, когда кто-то пишет программу быстро, но не думает при этом о ее сопровождении или элегантности. «Ого, она выдает в два раза больше кода вдвое быстрее». Учтите, что какой-то несчастный программист, сопровождающий задачу, будет затем вынужден потратить в восемь раз больше времени, сокращая первоначальный размер программы наполовину и делая ее пригодной для использования. Число строк кода в день, как мера объема, не является мерилом производительности.

---

Прежде всего, не навреди

2014-12-22 13:28:33 (читать в оригинале)

Прежде всего, не навреди

Это правило касается сопровождения программ. Известно, что в больших компьютерных программах стоит тронуть что-то, кажущееся маловажным, и сразу же весь ее код перестает работать. Объектно-ориентированные методы разработки программ прежде всего служат для решения (или по крайней мере для облегчения решения) этой проблемы в будущем, но ведь есть уже миллионы строк старых кодов, которые сегодня требуют сопровождения.

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

---

Малое это прекрасно. (Большое == медленное)

2014-12-22 13:28:22 (читать в оригинале)

Малое это прекрасно. (Большое == медленное)

Распухание программ является огромной проблемой. В стародавние времена OC’ы работали на 16-разрядной шине с 64Кбайтами внутренней памяти. В наше время большинство операционных систем требуют 32-разрядных машин с минимум 16 Мбайтами оперативной памяти, чтобы работать с приемлемой скоростью. Очевидно, что большая часть этого распухания памяти является результатом небрежного программирования.

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

Третьей проблемой является модульность. Одно из фундаментальных положений гласит — «меньше — лучше». Большие задачи лучше выполняются взаимодействующей системой небольших модульных программ, каждая из которых хорошо исполняет лишь одно задание, но каждая из них может сообщаться с другими компонентами. (Стандарт связи и внедрения объектов Microsoft (OLE) добавляет это свойство в Windows, а OpenDoc— в Macintosh.) Если ваше приложение представляет собой модульную конструкцию из маленьких программ, работающих вместе, то вашу программу очень просто настраивать по заказу путем смены модулей. Если вам не нравится этот редактор, то поменяйте его на новый.

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

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