Всем доброго времени суток!
Прежде всего спасибо тем, кто движимый любопытством, всё-таки решил подписаться на эту рассылку. Буду надеяться, что материалы этой рассылки окажутся для Вас полезными и поучительными. А если у Вас будут свои мнения и взгляды по тем или иным аспектам программирования в Delphi (и не только в Delphi) - милости прошу! Завязывайте дискуссии, делитесь опытом, задавайте вопросы, а то просто расскажите потешную историю. Для знакомства и общения Вы сможете воспользоваться чатом http://ChatWorld.ru/delpher. Сообщения и материалы, присланные на e-mail, будут публиковаться в рассылке.
Выпуск 1
Всё течет, всё меняется, но...
Замечено, что в процессе своей жизнедеятельности человек строит некую духовную опору в виде каких-то незыблемых, абсолютных принципов – то ли в виде трех правил, то ли в виде семи заповедей… С одной стороны всё это с разными наворотами облекается в форму «жизненной философии», а с другой – такого рода принципы помогают в разных жизненных ситуациях, компенсируя при случае наши незнания.
Компьютерные программисты в этом смысле не составляют исключения. Но жизнь, как говорится, не стоит на месте, а темпы развития и обновления информационной технологии таковы, что иногда может показаться эфемерным сам процесс накопления опыта, знаний и навыков: порой они быстро устаревают и спустя два-три года становятся ненужными. В этом IT-архипелаге уже нельзя объять необъятного, и все мы как-то незаметно оказываемся «чайниками» на большинстве его территорий. Программисты, если работают в разных средах и разными инструментальными средствами, уже с трудом понимают друг друга, а присутствуя при разговоре специалистов по 3D-графике, многие из нас в состоянии только с умным видом кивать головой.
В свое время один мудрый китаец во время разборки с другим китайцем (а может и не китайцем) изрек не совсем обычное пожелание: "Чтоб жилось тебе в интересные времена!".
Если не считать такого социального потрясения как развал Союза, то нынешним ветеранам программирования пришлось пережить за короткое время несколько интересных эпох: переход от процедурного программирования к структурному, а от него - к объектно-ориентированному (ООП). Эти переходы сопровождались духовным подъемом от новых веяний, волнениями и нестабильностью.
Сейчас философия ООП стала для разработчиков "общим местом", потому что является базовой идеей всех современных систем разработки приложений. А ведь лет 10-12 назад во времена царствования в нашей стране MS DOS она воспринималась скорее как экзотика, без которой можно было вполне обходиться. Теперь, кажется, мы на пороге нового переходного периода: все громче слышны голоса, что ООП исчерпало свой потенциал. Как говорится, «мавр сделал свое дело - мавр может уходить».
Естессно возникает вопрос: существуют ли какие-то островки стабильности в изменчивом мире Software Engineering, достойные занять место в наших принципах и заповедях? Конечно же есть (и довольно много), если под термином "программирование" понимать не только непосредственное использование языка и кодирование, но и такие вещи как постановка, проектирование, надежность, взаимоотношение с пользователем, стиль и др. Являясь продуктом практики, а не теории, они, подобно деловым инструкицям, ограждают нас от многих ошибок и неприятностей, помогая нам стать настоящими профессионалами.
По моему мнению, каждый разработчик прежде всего должен выработать свой стиль, т.е манеру употребления используемого им языка программирования. Стиль программирования основывается на следующем простом правиле (которое я называю Правилом №1):
Правило №1: «Текст программы следует писать в расчете на людей, а не на машину».
Это правило требует уделения большего внимания ясности, простоте и доступности текста за счет игнорирования машинной эффективности. Ясность и простота необходимы прежде всего для самого себя, чтобы просматривая текст через месяц, не продираться через завалы забытого и потому не совсем понятного собственного кода и логики.
Это правило имеет несколько полезных следствий:
«Используйте по возможности осмысленные имена». «Избегайте сходных имен». «На одной строке располагайте не более одного оператора». « Во избежание неоднозначности не экономьте на скобках». «Не ленитесь писать краткие комментарий». «Избегайте трюков».
В заключение этого выпуска я позволю себе привести один интересный, на мой взгляд, отрывок из книги Гленфорда Майерса "Надежность программного обеспечения". Есть в этом отрывке отдельные спорные моменты, но в целом изложенные в нем мысли будут полезны для начинающих разработчиков.
Г.Майерс
ПОЗИЦИЯ ПРОГРАММИСТА
Среди множества идей, которые касаются надежности программного обеспечения, не нужно забывать о важном и часто недооцениваемом факторе: позиции (или психологии) программиста. Нас особенно интересуют следующие два аспекта этого вопроса: позиция программиста по отношению к продукту его труда и его точка зрения на роль процесса компиляции.
Вопрос о позиции программиста по отношению к продукту его труда связан с принципами безличного программирования и когнитивного диссонанса. Когнитивный диссонанс - это психологический принцип, который руководит действиями человека, чьи представления о себе оказались под угрозой. Поведение программиста, который рассматривает свою
программу как продолжение себя и подсознательно считает недостатки программы проявлением своих недостатков, может быть изменено вследствие когнитивного диссонанса.
Программист, который искренне считает программу продолжением своего «я», не будет пытаться найти все ошибки в ней. Напротив, он постарается показать, что программа правильна, даже если это означает не замечать ошибок, чудовищных для постороннего взгляда... Человеческий глаз имеет почти безграничную способность не видеть то, чего он видеть не желает.
Спасти в такой ситуации может безличное программирование. Вместо того чтобы быть скрытным и защищать свою программу, программист занимает противоположную позицию: его программа в действительности - часть общей работы над проектом, и он открыто приглашает других программистов читать и конструктивно критиковать ее. Когда кто-то находит ошибку в его программе, программист, конечно, не должен радоваться, что ошибся; его позиция примерно такова: «О! Мы нашли ошибку в нашей программе! Хорошо, что мы нашли ее сейчас, а не позже! Поучимся на этой ошибке, а заодно посмотрим, не найдем ли еще!» Программист, обнаруживший ошибку в чужой программе, не кричит: «Посмотри на свою идиотскую ошибку!», а реагирует примерно так: «Как любопытно! Интересно, не сделал ли и я такой ошибки в написанном мной модуле?» Заметьте в
последнем предложении тонкую деталь, связанную с когнитивным диссонансом: я использовал оборот «написанный мной модуль» вместо «мой модуль».
Вторая важная сторона позиции программиста - это его отношение к точности. Ни одна другая дисциплина не требует такой степени точности, как программирование. Хирург, несомненно, не беспокоится о том, чтобы делать разрез обязательно между клетками тела. Программирование не знает понятия допуска, пользуясь которым инженер говорит: «Я буду представлять двоичное значение I потенциалом в 5 вольт плюс-минус 1 вольт»; каждый участок программы либо правилен, либо неправилен, и промежуточного положения нет. Поэтому и важно отношение программиста к точности, и сказывается оно во взглядах на процесс компиляции программы. Часто можно услышать такое мнение: «Вместо того чтобы тратить время, добиваясь совершенства мвего модуля, я прогоню его через компилятор, и пусть им занимается машина». Заставить работать машину - это, конечно, идея, лежащая
в основе всей индустрии обработки данных. Однако как только «работа» отождествляется с программированием, нужно поставить точку, потому что «знания» ЭВМ в области программирования весьма ограниченны.
Экспериментирование с компилятором, компиляция наскоро написанного модуля, чтобы посмотреть, «что получится», - нездоровая позиция, поскольку противоречит требованию точности. Я считаю, что профессиональный программист должен ориентироваться на успешную компиляцию его программы с первого раза. Он должен сам сделать все возможное, чтобы исключить синтаксические ошибки, а также дать свою программу просмотреть еще кому-нибудь, прежде чем приступать к компиляции. Имеется четыре довольно убедительных довода в пользу этого.
1. Одна из причин синтаксических ошибок - недопонимание синтаксиса языка. Если у вас есть упущения в синтаксисе, то вы, вероятно, недопонимаете и семантику. Компилятор, однако, найдет лишь очень немногие из ваших семантических ошибок.
2. Вторая причина синтаксических ошибок - небрежность. Здесь можно повторить прежние рассуждения. Если вы небрежны в синтаксисе, вы, вероятно, также небрежны в семантике.
3. Ни один из компиляторов, известных мне, не обнаруживает всех синтаксических ошибок. Чем больше их сделано, тем больше вероятность того, что какая-то из них не будет обнаружена и приведет, таким образом, к логической ошибке.
4. Тише едешь - дальше будешь. Я заметил, что первая компиляция модуля является всегда интересным поворотным моментом: внезапно и быстро возрастает давление, оказываемое программистом на самого себя. До компиляции он обычно тратит значительное время на обдумывание каждого изменения или улучшения программы. После первой компиляции модуля возникает определенное психологическое давление, вынуждающее вносить изменения как можно
быстрее, чтобы наконец «заставить его работать» или «заставить его скомпилироваться». Изменения, которые делаются под таким давлением, обычно изобилуют ошибками.
