Правила программирования на PHP (14 правил). Правила программирования и автоматизации Правила хорошего программирования
В последнее время я видел мало действительно хорошего кода, много посредственного и очень много - плохого. (Много того, что я писал раньше - особенно, когда я только начинал - относится к последним, увы.) Читая случайные статьи в интернете и профессиональные книги, я пришел к выводу, что писать хороший код - легко. Невероятно трудно, но в то же время легко. На самом деле, это настолько просто, что сводится к трем правилам.
- Пишите код для людей, а не машины.
- Каждый фрагмент кода должен выполнять одну задачу.
Пишите код для людей, а не машины
Это самое важное из трех правил, лежащее в основе двух других. Пишите код, который прост для человека; оставьте тяжелую работу компьютеру. Используйте осмысленные имена переменных и методов. Не создавайте запутанных логических цепочек там, где можно применить и простые. Не пытайтесь уместить в одной строке как можно больше. Соблюдайте единый стиль написания кода, в котором есть осмысленные отступы. Если ваши файлы настолько громоздкие, что их становится сложно прокручивать, разбейте их на несколько небольших.Многие программисты пытаются писать то, что на их взгляд работает быстрее, уменьшает размер приложения - словом, “облегчает” работу компьютера. Это замечательно, но не забывайте, что гораздо важнее писать код, который будет легко читать и поддерживать другим людям.
Ваш компилятор (или интерпретатор) может обрабатывать абсолютно разные стили кода. Для него n и numberOfObjects - это одно и тоже. Для людей - нет. Они будут долго вчитываться в код, даже если предназначение переменной кажется вам очевидным.
Представьте, что вы сделали для себя маленький скрипт, и через несколько лет вам понадобилось немного изменить его. Что бы вы предпочли увидеть: хорошо структурированный скрипт, с комментариями и понятным наименованием, или одну функцию без единого комментария и с переменными, предназначение которых понять практически невозможно?
Если вы делаете что-то неочевидное, чтобы оптимизировать часть кода, опишите в комментарии, что именно она делает. Но не забывайте, что в большинстве случаев вы не сможете оптимизировать программу лучше, чем компилятор. Реальность такова, что он умнее вас. Это факт: компиляторы улучшались в течение десятилетий тяжелой работы профессионалов. Бывают и исключения, но они лишь подтверждают правило.
Пишите код, понятный людям.
Не повторяйте себя
Я не могу сосчитать, сколько раз один и тот же фрагмент кода встречался мне в разных частях программы. Как раз сегодня я работал над большой функцией в устаревшем коде и увидел одинаковые условия в двух разных частях условного выражения. Мне пришлось потратить время на то, чтобы убедиться, что это просто ошибка программиста.Когда вы повторяете один и тот же фрагмент в нескольких местах, вам рано или поздно придется к нему вернутся, чтобы исправить какую-нибудь ошибку или добавить что-нибудь новое. Это затрудняет поддержку кода. Вместо того, чтобы повторять себя, поместите фрагмент в отдельный класс или функцию, к которой можно будет обратиться, как только она понадобится. Если вы в различных местах вызываете несколько методов в одном и том же порядке, оберните его в отдельную функцию.
Подумайте, что будет легче понять при знакомстве с кодом: фрагмент длиной в 30 строк, освобождающий блок памяти, или вызов функции clearMapVariableMemory()
?
Возможно, вам понадобится изучить фрагмент позже, но даже в этом случае работать с отдельной функцией будет легче.
Этот же принцип может быть применен и к данным. Если вы часто используете одни и те же переменные, перенесите их в отдельный класс или тип данных.
Если соблюдать это правило, все изменения будут универсальными - вам не придется перерабатывать десятки мест, чтобы внести небольшую поправку.
Не повторяйте себя.
Каждый фрагмент кода должен выполнять одну задачу
Последнее правило основано на двух предыдущих: каждый фрагмент вашего кода должен выполнять только одну задачу. Оно верно на всех уровнях: для выражений, функций и методов, классов и объектов.Несколько лет назад один разработчик показал мне неработающий фрагмент кода. Для того, чтобы разобраться в нем, программисту потребовалось несколько часов. В итоге проблема обнаружилась в пост-инкрементальных операторах C (в особых случаях их поведение разнится от компилятора к компилятору). Впоследствии, читая одну книгу по разработке, я отметил, что истинная проблема заключается не в операторах, а в том, что один фрагмент отвечал за выполнение множества разных задач.
Насколько я помню, строка, содержащая ошибку, была частью тернарной операции . Та, в свою очередь, выполняла несколько операций над указателями, чтобы посчитать условие, и еще несколько, в зависимости от результата условного выражения. Это был хороший пример написания кода в первую очередь для машины, а не для человека: никто, кроме автора фрагмента, не поймет, что именно делает строка, даже прочитав ее несколько раз. Если бы программист, написавший код, разбил логику на несколько частей, на решение проблемы ушло бы куда меньше времени.
Не стоит извлекать, обрабатывать и изменять данные в одном и том же методе. Словесное описание каждой функции должно помещаться в одно предложение. Предназначение каждой строки должно быть ясно. Это делает код понятным людям. Никто из нас не может хранить в голове функцию длиной в несколько тысяч строк. Нет и существенного основания создавать такие функции вместо нескольких небольших методов, используемых вместе.
Надо отметить, что это не так сложно: для выполнения одной большой задачи необходимо всего лишь разбить ее на несколько меньших, каждая из которых находится в отдельной функции. Важно следить за тем, чтобы предназначение каждой функции оставалось понятным, иначе код становится слишком запутанным.
Каждый фрагмент вашего кода должен выполнять одну задачу.
Заключение
Написание хорошего кода - это тяжелый труд. Я занимаюсь программированием в течение четырех лет - не так долго, но вполне достаточно, чтобы увидеть довольно много проблем, в том числе и своих. Мне стало понятно, что мы усложняем разработку, не соблюдая этих простых правил. Соблюдать их правильно - сложно: не всегда ведь очевидно, где нужен отдельный класс или метод. Это навык. На то, что бы стать хорошим программистом, требуется много времени. Но если мы не будем следовать этим правилам, написание и поддержка кода станут еще сложнее.Перевод статьи
Все мы люди и нам свойственно ошибаться. И даже компьютеры ошибаются, если программа, за счет которой они работают, была написана с ошибкой. Чтобы помочь Вам избежать некоторых ошибок при написании программ на любом языке программирования я расскажу о некоторых правилах используемых при написании программ и о методах программирования. Соблюдение ниже описанных методов поможет не только избежать некоторых ошибок, но также предупредит их появление и упростит отладку Вашей программы. Все ниже приведенные примеры и код программ написаны на языке Visual Basic 6.0. Вы можете использовать материал данной статьи и для других языков программирования. Статья не привязывает Вас к какому-либо конкретному языку и является универсальной.
Метод проектирования программных средств
Для решения задач программирования используется "Метод проектирования программных средств". Этот метод состоит из нескольких этапов:
1. Определение условий задачи.
2. Анализ задачи.
3. Создание алгоритма решения задачи.
4. Реализация алгоритма.
5. Тестирование и отладка готовой программы.
6. Поддержка и обновление готовой программы.
На первом этапе определяются условия задачи и необходимо ясно понять, что требуется для её решения. Основная цель в данном случае - отсеять второстепенные аспекты от основной сути задачи.
На втором этапе определяются входные данные, выходные, промежуточные и какие дополнительные трудности могут возникнуть при решении поставленной задачи.
На третьем этапе создается алгоритм - запись пошаговых процедур, а затем обеспечение таких условий, чтобы этот алгоритм решал задачу должным образом. Алгоритм может быть написан и в виде блок-схем.
Наверное, всем кто изучал программирование или информатику в учебных заведениях рассказывали, как нужно чертить блок-схемы. И наверняка большинство не любит их чертить. Ваш покорный слуга также относится к их числу. Но не стоит думать, что блок-схемы абсолютно бесполезны в программировании. Лично я никогда не черчу блок-схемы при разработке программ, но я умею хорошо это делать. И настоятельно советую Вам, научится чертить их лучше всех. Если Вы не научитесь самостоятельно и правильно чертить блок-схемы, Вы не сможете осознать суть того, как работает программа! Именно блок-схема позволяет наглядно и понятно (схематически) показать, как пошагово (построчно) выполняется программа. Ведь блок-схема это и есть алгоритм выполнения самой программы. А что такое алгоритм?
Алгоритм - это описание точного, пошагового выполнения действий решающих поставленную задачу должным образом. Поэтому если Вы сможете написать алгоритм выполнения программы, Вы сможете написать и саму программу, причем на любом языке программирования (который конечно будете знать). Научившись чертить блок-схемы, Вы научитесь построчно анализировать код программы, обрабатывая его в голове, так как это делает компьютер. Это очень важно при отладке программы (пятый этап).
Когда перед Вами стоит решение очень сложной задачи, можно (и нужно) применить метод "декомпозиции". Суть метода заключается в разбиении одной сложной задачи на множество взаимосвязанных, маленьких и простых подзадач, решив которые в отдельности Вы получите необходимый результат. Здесь можно привести аналогию с веником. Весь веник целиком сломать очень трудно, но если его ломать по одному прутику, то все получится.
Четвертый этап метода проектирования программных сред заключается в записи созданного алгоритма в виде программы на определенно языке программирования.
На пятом этапе производится тестирование и отладка программы. Он заключается в поиске всевозможных ошибок и позволяет добиться правильности работы программы. В процессе выявления ошибок используется "ручная отладка программы". Она заключается в мысленном выполнении каждого шага алгоритма, решающего свою задачу (так как это в последствии сделает компьютер), и позволяет убедиться, что данный алгоритм будет функционировать должным образом.
Также в процессе тестирования программы используется "эталонное решение". Это решение поставленной задачи другим методом (например, математически), которое позволяет получить заведомо верные результаты вычисления. Причем в эталонном решении используются не единичные данные, а множество различных данных позволяющих охватить все возможные ситуации вычисления. На основе такого "эталонного решения" можно выявить все возможные "подводные камни" и ошибки программы или ситуации, в которых программа не будет работать должным образом. Также необходимо реализовать в своей программе "защиту от дурака". Это когда учитываются такие ситуации, для которых программа в принципе не предназначена. Например, ввод цифр в поле или переменную, предназначенную для хранения фамилии.
Некоторые ситуации и ошибки невозможно выявить даже на основе "эталонного решения". Такие ошибки проявляются только в процессе длительного использования программы с множеством входных данных. Именно на шестом этапе и производится их исправление, а также изменение программы в соответствие изменившимся государственным нормам или политике компании.
При написании программ также необходимо соблюдать и другие правила, речь о которых пойдет ниже.
Переменные
Имена переменных
Почти во всех программах нам приходится использовать переменные, порой даже очень много переменных. Главное чтобы в последствии не запутаться какая переменная, какие данные хранит. Для этого необходимо давать именам переменных содержательные имена. Исключением могут быть только переменные, используемые в циклах, но не участвующие многократно в вычислениях.
For i = 1 to 10 Step 1
For j = 1 to 10 Step 1
dmsTable(i, j) = i * j
Next j
Next i
Если нам нужно сохранить в переменную чей-то год рождения. Назовите переменную "vblYearsBorn", а не "A". Старайтесь чтобы имя переменной отражало суть тех данных для хранения которых она предназначена, чтобы оно было интуитивно понятно. Пусть от этого имя переменной будет немного длинным, но зато это не даст вам запутаться и исключит повторное использования данной переменной в других вычислениях, для которых она не предназначена. Имя переменной желательно обязательно начинать с прописных букв vbl, от английского variable (переменная). Это особенно актуально в Объектно-Ориентированном Программировании (далее ООП). Так как имя переменной можно спутать с названием, какого либо объекта на форме (об этом пойдет речь ниже).
Давайте для понятности назовем эти три начальные буквы - "Идентификатором объекта", так как дальше я буду упоминать о них не однократно.
После идентификатора, без пробелов, следует писать имя переменной. Его нужно начинать с большой буквы, чтобы при просмотре листинга программы Вы видели, что это переменная, или какой-то другой объект, чтобы буквы выделялись, а не сливались в одну строку.
Объявление переменных
Некоторые языки программирования (например, Visual Basic) позволяют работать с переменными не объявляя их в коде программы. Я считаю это большой ошибкой и не солидностью языка программирования (но это не значит что этот язык программирования плох)!
Объявление переменной это определение ее типа и имени.
Dim vblFirstName as String (Visual Basic)
Var vblFirstName: String; (Turbo Pascal)
Char vblFirstName; (C++)
Т.е. мы как бы указываем программе, что будем использовать переменную с именем vblFirstName и тип данных этой переменной String (текстовый/литеральный).
Почему это важно (это касается только тех языков программирования, которые разрешают так делать. Например, если Вы не объявите переменную в С++ или Turbo Pascal-е, при компиляции будет сгенерирована ошибка, что используемая переменная не объявлена)? Все очень просто. Если мы не объявим переменную ей автоматически будет присвоен тип Variant, это значит что в переменную можно будет сохранять данные почти любого типа. Во-первых, мы сможем записать в переменную, которая хранит фамилию числовые данные или наоборот. ЭТО НЕПРАВИЛЬНО! Так как фамилия не может содержать цифры. Мы заведомо делаем в программе брешь, возможность для совершения ошибки. Вот такими ошибками и пользуются хакеры для взлома систем и прочее. Во-вторых, тип, присваиваемый автоматически, очень "много" занимает места в оперативной памяти. А хорошая программа должна как можно меньше весить. И не важно, сколько гигабайт оперативки у Вас на компьютере. В-третьих, явное объявление переменных позволит назначить им тот тип данных, который Вам необходим. И Вам будет намного легче узнать, какие переменные уже используются в программе. Достаточно будет посмотреть в начале программного кода или модуля, какие переменные уже заданы, а не перелопачивать весь код программы. Вы никогда не сможете повторно объявить уже объявленную переменную в одном и том же модуле, или перепутать их имена, а значить не используете переменную в тех вычислениях, для которых она не предназначена.
В ООП разрешается многократно объявлять переменные с одинаковыми именами, притом условии, что эти переменные локальны и используются только в разных модулях. О видимости переменных пойдет речь чуть ниже.
Инициализация переменных
После того как Вы объявили переменную её необходимо инициализировать, т.е. присвоить ей какое либо значение или обнулить. Это очень актуально для переменных используемых в вычислениях. Дело в том, при объявлении переменной для нее выделяется (резервируется) память. Резервирование памяти не отчищает ячейки от значений, которые ранее в них хранились, поэтому если за объявлением переменной не следует её инициализация, то текущее значение этой переменной будет непредсказуемым, а не нулевым, как думают многие. Не обязательно, что именно так и будет, но если это произойдет причину неправильных вычислений порой трудно выявить, так как код программы верен синтаксически и логически, но все равно вычисления идут неверные.
Если это переменная числового типа и используется в накоплении суммы, то достаточно её просто обнулить.
vblSum = 0
For I = 1 to 10 Step 1
vblSum = vblSum + i
Next i
Или присвойте ей единицу, если переменная используется, как множитель или делитель.
vblSum = 1
For I = 1 to 10 Step 1
vblSum = vblSum * i
Next i
Если это строковая переменная просто отчистите ее.
vblFirstName = ""
Лично я всегда инициализирую переменные, даже если в следующей строке присвою ей другое значение.
Глобальные и локальные переменные
Все переменные имеют свою область видимости в зависимости от того, как Вы их объявили. Переменные могут быть локальными и глобальными.
Локальные переменные - это переменные объявленные внутри какой-либо функции (подпрограммы). Они видимы только в пределах данной функции и не могут быть непосредственно вызваны из основного текста программы. Когда выполнение программы возвращается из функции к основному коду программы или другой функции, локальные переменные удаляются из памяти.
Глобальные переменные - это переменные, определенные вне тела какой-либо функции (для ООП, переменные объявленные в модулях проекта). Эти переменные имеют глобальную область видимости и доступны из любой процедуры, функции в подпрограмме.
Очень часто возникают ошибки при использовании глобальных переменных.
В некоторых языках программирования глобальная переменная имя, которой совпадает с именем локальной переменной, могут изменить значения друг друга.
Опасность использования глобальных переменных исходит из их общедоступности, в результате чего одна функция может изменить значение переменной незаметно для другой функции. В таких ситуациях возможно появление ошибок, которые очень трудно выявить.
Используйте глобальные переменные только при крайней необходимости, когда невозможно или проблематично обойтись другими методами.
Константы
О константах буквально в двух словах. С их использованием в программе также необходимо быть внимательным (как и вообще занимаясь программированием). Имена констант лучше всего начинать с трех буков con, от английского constant (константа).
Const conPi = 3.14159265
Помните, что значения констант нельзя изменить в программе (ведь они константы, а значить постоянные), в противном случае будут сгенерированна ошибка. Лучше всего использовать константы, когда есть какое-либо значение, участвующее во многих вычислениях и его значение никогда не меняется в программе. Либо когда необходимо использовать коэффициент (а они, как правило, тоже постоянны).
Структурное программирование
Структурное программирование - дисциплинирующий подход к программированию, обеспечивающий создание легких для понимания программ и снижающий вероятность ошибок. Суть этого подхода состоит в соблюдении общепринятого стиля программирования и обеспечения удобочитаемости исходного текста. Вы наверняка заметили, что весь программный код, приведенный в примерах, написан с определенной структурой. Вот это и есть структурное программирование.
Операторы начала и конца цикла пишутся строго друг под другом, а все операторы внутри цикла чуть правее. Все отступы делаются с помощью табуляции (клавиша Tab). Точно также пишутся логические схемы. Благодаря такому написанию ваша программа становится более читабельной и легкой для восприятия. Также облегчается отладка программы. Вы можете сами сравнить приведенный ниже пример, написания кода по принципу структурированного программирования и без него. Пример приведен на языке Turbo Pascal (часть кода сортировки массива).
Пример "Структурированный код":
For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
vblStuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;
Пример "Обычный код":
For i:=1 to 9 do
begin
vblMin:=A[i];
k:=i;
For j:=1+i to 10 do
begin
If (vblMin>A[j]) Then
begin
vblMin:=A[j];
k:=j;
end;
end;
stuf:=A[i];
A[i]:=vblMin;
A[k]:=vblStuf;
end;
Какой вариант более читабелен и понятен? Несомненно, первый.
Вы должны приучить себя соблюдать все вышеописанные нюансы. Конечно, несоблюдение не критично, но использование этих методов намного упростит Вам написание программ и в будущем их сопровождение.
Ошибки
Программы очень редко работают правильно с первого раза. Закон Мерфи гласящий "Если что-то плохое может случиться, оно непременно случиться", похоже, был написан как раз применительно к компьютерным программам.
Ошибки, возникающие в процессе работы программы можно разделить на несколько типов:
1. Синтаксические ошибки
2. Ошибки времени выполнения
3. Логические ошибки
Синтаксические ошибки имеют место, когда исходный код программы записан с нарушением одного из правил грамматики того языка программирования, на котором Вы пишите программу. Обнаруживается это нарушение при попытке откомпилировать программу.
Ошибки времени выполнения выявляются компьютером во время выполнения программы. Подобные ошибки имеют место, когда программа дает компьютеру указание выполнить неверную операцию (например, деление на ноль или манипулировать неописанными или неверными данными).
Ошибки ввода данных - также являются ошибками времени выполнения. Причиной таких ошибок является попытка ввести данные неверного типа (например, переменной целочисленного типа присваивается строковый параметр или число вещественного типа).
Логические ошибки имеют место, когда программа выполняет неверный алгоритм. Данные ошибки являются самыми коварными, их очень сложно выявить, потому что они не фиксируются при компиляции. Данные ошибки проявляются при выводе неверных результатов программой. Единственно возможные способы выявления таких ошибок это использование методов: "эталонного решения" и "ручной отладки".
Умелое использование всех этих методов и правил: метод декомпозиции, структурное программирование, метод проектирования программных средств, эталонное решение и другие, говорят о профессионализме.
С приобретением опыта программист вырабатывает собственные правила и стиль. При этом совершенно не обязательно наступать на все грабли самому. Разумное следование приведенным ниже рекомендациям поможет избежать многих распространенных ошибок. Конечно, на все случаи жизни советы дать невозможно, ведь не зря многие считают программирование искусством.
Главная цель, к которой нужно стремиться, - получить легко читаемую программу, возможно, более простой структуры. В конечном счете, все технологии программирования направлены на достижение именно этой цели, поскольку только так можно добиться надежности программы и легкости ее модификации.
· Программа должна состоять из максимально обособленных частей, связанных друг с другом только через интерфейсы.. Следует четко отделять интерфейс подпрограммы или модуля от их реализации и ограничивать доступ к информации, ненужной для их использования.
· Каждое законченное действие оформляется в виде подпрограммы.. Размер подпрограммы может быть разным, это зависит от конкретного действия, но желательно, чтобы ее тело помещалось на один-два экрана: одинаково сложно разбираться в программе, содержащей несколько необъятных функций, и в россыпи из сотен подпрограмм по несколько строк каждая. Если какая-либо последовательность операторов используется хотя бы дважды, ее также нужно оформить в виде подпрограммы.
· Все величины, которыми подпрограмма обменивается с вызывающей программой, должны передаваться ей через параметры. Входные параметры предпочтительнее передавать как константы. Обычно в списке параметров сначала записывают все входные параметры, а затем - все выходные. Если подпрограмма возвращает одно значение, лучше оформить ее в виде функции, если несколько - в виде процедуры.
· В подпрограмме полезно предусматривать реакцию на неверные входные параметры и аварийное завершение. Это может быть или печать сообщения, или, что более предпочтительно, формирование признака результата. Этот признак необходимо анализировать в вызывающей программе. Сообщение об ошибке должно быть информативным и подсказывать пользователю, как ее исправить. Например, при вводе неверного значения в сообщении должен быть указан допустимый диапазон.
· Величины, используемые только в подпрограмме, следует описывать внутри нее как локальные переменные. Это упрощает отладку программы. Использовать глобальные переменные в подпрограммах нежелательно, потому что их изменение трудно отследить.
· Имена переменных должны отражать их смысл. Правильно выбранные имена могут сделать программу в некоторой степени самодокументированной. Неудачные имена, наоборот, служат источником проблем. Сокращения ухудшают читаемость, и часто можно забыть, как именно было сокращено то или иное слово. Общая тенденция состоит в том, что чем больше область видимости переменной, тем более длинное у нее имя. Перед таким именем можно поставить префикс типа (одну или несколько букв, по которым можно определить тип переменной). Для счетчиков коротких циклов, напротив, лучше обойтись однобуквенными именами типа i или k.
· Следует избегать использования в программе чисел в явном виде. Константы должны иметь осмысленные имена, заданные в разделе описания const. Символическое имя делает программу более понятной, а, кроме того, при необходимости изменить значение константы потребуется изменить программу только в одном месте. Конечно, этот совет не относится к константам 0 и 1.
· Для записи каждого фрагмента алгоритма необходимо использовать наиболее подходящие средства языка. Например, ветвление на несколько направлений по значению целой переменной более красиво записывается с помощью оператора case, а не нескольких if. Для просмотра массива лучше пользоваться циклом for. Оператор goto применяют весьма редко, например. для принудительного выхода из нескольких вложенных циклов, а в большинстве других ситуаций лучше использовать другие средства языка, такие как процедуры break или exit.
· Программа должна быть «прозрачна». Если какое-либо действие можно запрограммировать разными способами, то предпочтение должно отдаваться не наиболее компактному и даже не наиболее эффективному, а такому, который легче для понимания. Особенно это важно тогда, когда пишут программу одни, а сопровождают другие, что является широко распространенной практикой. «Непрозрачное» программирование может повлечь огромные затраты на поиск ошибок при отладке.
· Не следует размещать в одной строке много операторов. Как и в русском языке, после знаков препинания должны использоваться пробелы:
· Вложенные блоки должны иметь отступ в 3-4 символа, причем блоки одного уровня вложенности должны быть выровнены по вертикали. Форматируйте текст по столбцам везде, где это возможно.
· Помечайте конец длинного составного оператора.
· Для организации циклов пользуйтесь наиболее подходящим оператором. Цикл repeat применяется только в тех случаях, когда тело непременно потребуется выполнить хотя бы один раз, например при проверке ввода. Цикл for используется, если число повторений известно заранее и параметр имеет порядковый тип, цикл while - во всех остальных случаях. При записи итерационных циклов (в которых для проверки условия выхода используются соотношения переменных, формируемых в теле цикла) необходимо предусматривать аварийный выход по достижении заранее заданного максимального количества итераций. Чтобы цикл легче читался, надо стремиться объединять инициализацию, проверку условия выхода и приращение в одном месте.
Несколько советов по записи операторов ветвления:
· Более короткую ветвь if лучше поместить сверху, иначе вся управляющая структура может не поместиться на экране, что затруднит отладку.
· Бессмысленно использовать проверку на равенство true или false.
· Следует избегать лишних проверок условий.
· Если первая ветвь оператора if содержит передачу управления, использовать else нет необходимости:
if i > 0 then exit; { здесь i <= 0 }
· Необходимо предусматривать печать сообщений в тех точках программы, куда управление при нормальной работе программы передаваться не должно.
- Перед началом каких-либо операций проверьте существование всех нужных файлов, папок и переменных. Например, если файл не будет найден, то вы его сможете создать и избавиться от ошибок.
- Проверяйте все входные данные, которые передаются по форме. Например, если в переменной должна прийти дата - проверьте являются ли пришедшие данные датой. Даже если в форме предлагается выбор этих самых дат. Помните, форму всегда можно сохранить локально и поправить ее на свое усмотрение.
- Проверяйте входные данные, чтоб они были только в пределах диапазона, указанного вами. Например, если вы поставили ограничение на 1000 символов в сообщении, а вам написали 2000.
- Длина слов и другие, так как в простую форму можно вести очень много символов, из которых вам нужно будет всего лишь 3-4 десятка с начала, то на форму лучше всего тоже поставить ограничение.
- Длина слов и другое. Если ввести слов 20 без пробела, то на странице это будет выглядеть некрасиво, а вам это не надо, поэтому либо запрещайте ввод таких длинных слов, либо разделяйте длинные слова самостоятельно, либо укорачивайте слова и другое
- Вы знаете, что в поле имени (скрипты: гостевые книги, форумы…) пользователь может ввести что угодно, в том числе и ваше имя. Но так как в интернете не все честные, то некоторые, подписавшиеся вашим именем могут наговорить много всего нехорошего. Чтобы подобного не произошло, создайте список с запрещенными именами и проверяйте не совпадает ли имя пользователя с именем из этого списка.
- Никогда не показывайте в форме пароля его текущее значение. Помните о том, что в этом случае пароль может попасть остаться в компьютере в так называемом каталоге временных файлов Интернета. А если это общественный компьютер? Тогда следующий кто сядет за него может легко узнать пароль. Кроме того форму с паролями обязательно отправляйте по методу POST.
- В вашем скрипте обязательно должно быть предусмотрено модерирование. Согласитесь, гораздо проще и удобнее зайти на сайт, зайти в на страницу модерирования и нажать на пару кнопок и заполнить пару форм, чем заходить по FTP на сайт, открывать нужную страницу и ковыряться в HTML коде.
- Кавычки. Заменяйте в получаемых данных все кавычки на ESCAPE - последовательность. Например, кавычку ["] на [\"]. Данные в форму можно ввести так, что при отображении может много чего натворить с вашей страницей. Например, можно вставить скрипт на Java, изменить оформление. Кроме того если это у вас форум или гостевая, можно заменять два пробела на пробел, для того чтоб количество пробелов отображалось верное.
- Храните пароли в закодированном виде. Ведь если какой-нибудь пользователь и сумеет скопировать себе этот файл с паролями, то он пароль не сможет расшифровать. Если пользователь забыл пароль - меняйте его на абракадабру и отправляйте на Email. При этом обязательно выдавайте вначале ссылку для подтверждения, чтобы никто не узнал пароль.
- Всегда заменяйте метки и разделители, которые вы используете для сохранения информации или отображения, на что-то подобное. Иначе имеется какой-то шанс, что его пользователь введет в форму ваш разделитель и на странице появится целый список ошибок.
- Никогда не забываете ставить error_reporting (0) в начало страницы, благодаря этому параметру все ошибки, если они будут, не будут отображаться на странице и злоумышленник не сможет узнать слабое место в вашем скрипте.
- При подгрузке какого-нибудь файла сначала удостоверьтесь в его существовании, а если он и вправду существует, то подгружайте его с помощью функции require, а не include, потому что в 1 случае если будет ошибка то файл совсем не будет подгружаться, а во 2 он подгрузится с ошибками.
- Проверяйте откуда пользователь пришел. Потому что пользователь может сохранить форму ввода у себя на компьютере и подправить ее, но если он попытается отправить через нее данные, то ничего не получится, так как он его запрос придет не с той страницы, с которой нужно.
Большинство статей, написанных на тему найма программистов, звучит более или менее одинаково. Как правило, такие статьи рекомендуют «нанимать только самых лучших». Признаюсь, я не в восторге от этого совета, потому что он звучит слишком неопределенно. Это все равно, что если бы вы пришли в автосалон и спросили бы у продавца какую бы он машину вам порекомендовал, а он вам бы ответил что «Лучшую» при этому не указан ни на какую находящуюся в автосалоне.
Пожалуйста, поймите меня правильно, я вовсе не советую намеренно выискивать посредственных программистов. Разумеется, все хотят нанимать только самых талантливых и опытных программистов. В решениях о найме ставки высоки. Ваше решение повлияет на работу всей команды и ее отдельных участников. Как говорят:
«Отвергнуть хорошего кандидата гораздо лучше, чем принять плохого… Если у вас возникнут хотя бы малейшие сомнения - Не нанимайте»
Но стандартный совет все равно меня раздражает. Дело даже не столько в самом совете, сколько в том, что люди склонны понимать его неверно. Если применять его без дополнительных поправок, эта практика в основном формирует чувство собственного превосходства. Этот эффект особенно часто распространен среди программистов, поскольку элитарность так или иначе присуща нам. Когда мы слышим, что нанимать нужно только «самых лучших», этот совет проходит подсознательное преобразование:
«Самых лучших?» Но это же я! Я «самый лучший». Разумеется, я должен нанимать людей, таких же одаренных, таких умных и симпатичных, как я сам. Да и зачем засорять мою прекрасную команду всяким сбродом?
Кто они, самые лучшие программисты?
Само собой, такой подход создает не лучшие условия для принятия решений. Стандартное правило работает гораздо лучше, если понимать его несколько иначе:
«Я хочу сформировать как можно более эффективную команду. Нанимая дополнительного работника, я стремлюсь не только к численному расширению штата. Каждый нанимаемый человек должен улучшать мою команду в определенном отношении. Я вовсе не ищу такого же одаренного человека, как я сам. Скорее, мне нужен человек, одаренный более меня по крайней мере в одном важном направлении».
Начальник
Худший начальник - тот, который ощущает угрозу со стороны своей команды. Сознательно или нет, он опасается «самых лучших», и поэтому постоянно нанимает людей, на фоне которых он будет смотреться выигрышно.
Наверное, в крупной компании с таким подходом можно прожить. Я сильно подозреваю, что Лохматый Начальник в комиксах про Дилберта был срисован с натуры.
Но в мире мелких фирм-разработчиков дело обстоит совершенно иначе. Если вы являетесь основателем или «главным гуру» в маленькой фирме, постарайтесь осторожно, честно и объективно взглянуть на самого себя. Если вы относитесь к числу людей, чувствующих угрозу со стороны собственных работников, остановитесь и задумайтесь. Пока вам не удастся решить эту проблему, шансы на построение эффективной команды будут равны нулю.
Кадры программистов
Истинный смысл стандартного правила заключается не в том, чтобы потешить наше самолюбие - оно должно напоминать, чтобы мы не боялись искать лучших работников. И все же необходимо более точно выяснить, что на самом деле означает слово «лучший».
Ищите людей, склонных к самоанализу
«Самые лучшие» работники никогда не перестают учиться.
Одним из важнейших критериев при оценке кандидатов я считаю то, что я про себя называю «первой производной». Учится ли этот человек? Движется ли он вперед или стоит на месте? (Некоторые мои размышления на эту тему опубликованы в статье «Career Calculus» в моем блоге).
Люди, серьезно настроившиеся на свой будущий успех, с большой вероятностью добиваются успеха. Часто этот настрой является самым сильным признаком для принятия решений при найме.
Это не означает, что нанимать нужно только тех людей, которые желают добиться успеха. Все люди хотят добиться успеха. Я советую нанимать людей, серьезно относящихся к постоянному обучению. Такие люди не тратят время на попытки убедить вас в том, как много они знают. Они сосредоточены не на прошлом, а не будущем. Пока вы проводите с ними собеседование, они проводят собеседование с вами, пытаясь узнать, чему они смогут у вас научиться.
Как найти такого человека?
По одному хорошо заметному признаку: люди, настроенные на постоянное обучение, хорошо знают, чего они не знают. Они знают свои слабости и не боятся говорить о них.
На собеседованиях кандидату часто предлагается описать свою основную слабость. Хотя этот вопрос до ужаса традиционен, он мне нравится.
К сожалению, многие кандидаты пытаются уклониться от ответа. Они идут в книжный магазин и покупают книгу о прохождении собеседования. Книга предупреждает, что я задам им этот вопрос, и предлагает «творческие» способы уклониться от искреннего ответа:
- Иногда я слишком много работаю.
- Иногда мое внимание к деталям раздражает других участников группы.
Когда я прошу кандидата рассказать о своих слабостях, я надеюсь на умный, искренний и уверенный ответ. Когда я слышу, что кандидат признает свою слабость, это производит впечатление. Но если кандидат дает уклончивый ответ, взятый прямо из книги, я начинаю думать о следующем кандидате.
Нанимайте разработчиков, а не программистов
В мелкой фирме «самыми лучшими» программистами являются те, которые не ограничиваются собственно программированием. Старайтесь нанимать разработчиков, а не программистов. Хотя эти слова часто используются как синонимы, я их различаю. Речь идет о различиях между простым программированием и участием в группе работы над продуктом. Приведу цитату из статьи, которую я написал на эту тему в своем блоге:
«В этой статье «программистом» называется тот, кто занимается исключительно кодированием новых функций и [если повезет] исправлением ошибок. Программисты не пишут спецификации. Они не создают автоматизированные контрольные примеры. Они не помогают поддерживать автоматизированные системы сборки в актуальном состоянии. Они не помогают клиентами решать технические проблемы. Они не помогают писать документацию, не участвуют в тестировании и даже не читают код. Все, что они делают, - это написание нового кода. В мелкой фирме таких людей держать не стоит.
Вместо «программистов» (людей, специализирующихся на написании кода) вам необходимы «разработчики» (люди, вносящие многосторонний вклад в успех продукта)».
Что же означает стандартное правило? Какой именно атрибут нужно измерить, чтобы определить, является ли кандидат «самым лучшим»?
Обычно это правило понимается применительно только к навыкам кодирования. Но по-настоящему хорошие программисты отличаются сообразительностью. Они понимают то, чему обычно не учат, и могут работать раз в 10 эффективнее среднего программиста. Конечно, было бы разумно поискать одну из таких «десятикратных» личностей, особенно в больших организациях, где специалисты вроде «чистых» программистов оказываются вполне уместными. Но в маленькой фирме нужна универсальность. Нередко требуется, чтобы участники команд выполняли несколько функций, не ограничиваясь написанием кода. В таких случаях очень важно найти лучшего разработчика, и этот человек вовсе не обязательно окажется лучшим программистом.
Итак, стандартное правило работает вполне нормально, но от общих рекомендаций необходимо перейти к более конкретным. Чтобы подвести итог тому, о чем говорилось в предыдущих разделах, я предлагаю 10 вопросов, которые следует задать себе при рассмотрении кандидата на должность разработчика:
- Способен ли этот кандидат сделать для группы то, что не сможет никто другой?
- Находится ли он в процессе постоянного обучения?
- Знает ли этот кандидат о своих слабостях и может ли спокойно обсуждать их?
- Насколько этот кандидат универсален и способен сделать «все, что потребуется», чтобы обеспечить коммерческий успех продукта?
- Принадлежит ли кандидат к числу «десятикратных» программистов?
- Обладает ли он степенью бакалавра, полученной в одном из уважаемых университетов?
- Если кандидат обладает докторской степенью, имеются ли другие признаки, свидетельствующие о его способностях к разработке коммерческих продуктов?
- Имеется ли у кандидата опыт работы в группах, занимавшихся разработкой коммерческих продуктов?
- Может ли кандидат представить примеры хорошего кода?
- Любит ли кандидат программирование настолько, чтобы писать код в свободное время?
Положительный ответ на все 10 вопросов не обязателен. Я даже не собираюсь указывать максимальное количество положительных ответов, необходимых для принятия кандидата. Наем - это лотерея, и каждый вопрос может послужить признаком для оценки пригодности кандидата.
В конечном счете, любое решение из области найма осуществляется волевым решением, и никакие гарантии здесь невозможны. И все же если уделить внимание этим вопросам, они повысят вероятность того, что вам не придется позднее пожалеть о принятом решении.