Untitled

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

Некоторые не столь очевидные правила, к которым привел меня мой опыт выглядят так.

1. Мертвый код должен быть удален. 
Если код не делает ничего полезного, нигде не используется (современная IDE поможет вам это определить) -  его нужно убить. Его нужно убить физический, не закомментировать, не задепрекейтить, а стереть. Потому-что никогда нельзя быть уверенным, что кто-то из членов комманды (в том числе и ты сам) не захочет его воскресить в будущем. Последствия таких действия оказываются самыми печальными.

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

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

3. Рефакторинг - это постоянный процесс.
Любой код со временем можно сделать лучше. Я имею в виду не только его работоспособность, но и простоту, изящество и читаемость. С каждым днем не только условия и требования меняются, но и вы сами становитесь все опытнее, аккуратнее и остроумнее. Ваш взгляд на код сегодня и через месяц может отличаться кардинально. Поэтому именно сегодня вы должны сделать код лучше.

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

Рефакторить нужно постоянно, каждый день. Код, который никто не трогает начинает со временем обрастать тиной и в конце концов начинает гнить. Не нужно выделять для этого отдельные часы, выпрашивать у руководителя - этого времени все-равно никогда нет и не будет, потому-что заказчик  как правило, не представляет за что он платит в этом случае. Просто при планировании задач сразу учитывайте, что, скажем, каждый час из 8 уходит у вас на рефакторинг.

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

5. Автоматизируй все.
Если нечто может быть автоматизировано - это должно быть автоматизировано. Здесь и сейчас. Будь это некий скрипт деплоя, миграция базы данных, или даже просто включение компьютера с автостартом всех нужных программ. Это должно быть сделано. Потому-что это экономит время и потому-что это избавляет нас от ошибок. Поэтому надо заставлять себя учить скриптовые языки и работать с linux. Потраченное на это время с лихвой окупается в ближайшие же сроки.

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

Если бы я проводил собеседование по JavaScript, вот вопросы, которые я бы непременно задал.

1. Какова модель наследования в JS?
2. Почему глобальные объекты это плохо? Как можно избежать лишних глобальных объектов?
3. Что интересного в ECMAScript 5?
4. Какие возможны способы вызова функции? Чем они отличаются?
5. Что такое замыкание (Closure)? 
6. Могут быть ли у объектов приватные методы? Как это можно организовать?
7. Возможно ли модульное программирование в JS? Как?

Для начала надо понимать, что в JS у функции есть скоуп (причем, только у нее). Это означает, что все сущности объявленные внутри функции никогда не выйдут за ее пределы, только если непосредственно не написать что-нибудь в “глобальный” объект (window для браузеров). Собственно на этом инкапсуляция и строится.

(function() {
   var a = 256;
   var test= {};
   test.getA = function() {
      return a;
   }
   window.test = test;
})();

   test.a // undefined
   test.getA() // 256

В данном примере мы создаем и тут же вызываем анонимную функцию. Внутри нее мы объявляем переменную a и объект test. При этом обе переменные не могут покинуть область видимости функции, однако мы непосредственно указываем, что test нужно сделать глобальным. Благодаря замыканиям, test видит все переменные, которые объявлены в теле функции, а мы, будучи снаружи уже нет. В результате test.a - вернет, разумеется, undefined, однако метод getA даст 256.

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

Обязательно к просмотру, даже если вы далеки от web-программирования. Для общего развития, очень интересные лекции.

Я слушаю Земфиру с раннего, так сказать, отрочества. С “Ромашек”, с “Нашего радио” заслушивал до дыр практически каждый альбом. Правда последние 3-4 релиза слушаю, конечно, внимательно, но скорее по инерции. Какая-то надежда теплится, что ли… Но все тщетно.




В ночь на сегодня (14 февраля) Земфира опубликовала свой новый альбом. Между прочим,  первый полноценный альбом за последние 5 лет. На этот раз через Yandex.Music. Завтра же начинается гастрольный тур, который вроде как обещает стать очень крутым шоу (на практике, повесят экран, где будут крутить “арт-хаусные” ролики Литвиновой, очень круто, да).


Что можно сказать в этот раз? В общем, все болезни те же самые. Г-жа Рамазанова глубоко в себе и не хочет от них лечиться. Критиков посылает, как обычно самоуверенно, но уже совсем не обосновано.

Сравнивая (а куда деваться?) “новую Земфиру” и “старую” (в смысле, good old), непременно приходишь к неутешительным выводам. Ранняя Земфира задорная, энергичная, много слушает, не стесняется заимствовать, но делает это, как хороший художник. Она вспыльчивая, конечно, но не столь напыщенная и замкнутая на себе, как сейчас. Новая Земфира совсем не уделяет внимания мелодиям, текста ее стали прямолинейными и настолько личными, что никого уже, кроме толпы ее преданных фанаток, это не трогает. В общем, сравнение явно не в пользу “новой Земфиры”.

Кстати, в каком-то интервью, Земфира упорно утверждала, что ритмические рисунки у нас, дескать, в стране, делать не умеют. Но вот она-то в новом альбоме покажет, как надо. Ну и где? В какой именно песне? И где рифы? Нету. Ни ритма, ни мелодий, ни рифов, ни текстов, ничего. И это, на самом деле, грустно.

Ну что ж, будем ждать следующей пластинки. Деваться-то некуда…

Пытаюсь установить дружеские или хотя бы приятельские отношения с JavaScript. Вот пока некоторые мои открытия, которые, быть может, сэкономят вам время.

1. Операций равенства в языке две. == и ===. Первая, помимо собственно сравнения, пытается еще и привести объекты к общему типу и, поэтому, априори более затратная. Если вы точно уверены в типе объекта, то хороший тон использовать ===.

2. В Javascript есть всего один числовой тип. И этот тип - 64-битный float. Поэтому, в частности, 1 всегда === 1.000. NaN, ровно как и Infinity это тоже число (number), по крайней мере, если судить по результату  typeof. Последнее получается, если увеличить максимально-возможное число 1.79769313486231570e+308

3. Кстати, о типах. Понятия класса в Javascript нету в принципе. Но зато есть так называемая Prototype-based объектная модель. Вообще, это тема проблемная и непростая. Выражение “взрыв мозга” хорошо подходит для её поверхностного описания. По очевидной причине язык не является строго-типизированным.

4. Блок кода, который {…}, не открывает никакого скоупа. В том смысле, что если вы создали в таком блоке некоторую переменную, то она будет видна всем и после этого блока. Минимально возможный скоуп в Javascript - это скоуп функции. Поэтому классическая “рекомендация хорошего стиля” объявлять переменные в как можно меньшем (глубоком) блоке здесь теряет всякий смысл.

5. Все сущности могут быть истолкованы как логические true или false. К последним относится false, null, undefined, пустая строка ”, 0, NaN. К “правдивым” - все остальные. Включая пустой массив [] и строку ‘undefined’ (а это, кстати, именно то, что возвращает typeof несуществующего объекта).

6. Операция логическое или (||) может легко быть использована (и это распространенная практика) в качестве присваивания дефолтных значений. Например,

a = b || ‘Baloon’

Дело в том, что эта операция возвращает первый операнд, если он резолвится в true (см. пункт 5) и второй, иначе. Таким образом, если b undefined, то в a запишется ‘Baloon’. Аналогичным образом работает и операция && (логическое и), только она возвращает первый элемент, если он резолвится в false.

7. Оператор [] может применяться к любому объекту. При этом операнд, переданный внутрь квадратных скобок, преобразуется к строке его методом toString(), после чего производит выдачу соответствующего поля. Массив - это просто объект имеющий натуральные (плюс ноль, если угодно) числа в качестве названий полей.


8. Еще немного о массивах. Как вы уже поняли, массив в Javascript это не совсем полноценный массив. Буквально, это просто оболочка над объектом. Массив [1, 2, 3] отличается от объекта {0: 1, 1: 2, 2: 3}  наличием свойства под названием length, которое работает слегка не так, как от него ожидают и набором дополнительных утилитарных методов вроде push(). То самое length - это вовсе не длина массива, это максимальное целочисленное название поля +1. Рассмотрим пример,

arr = []; arr[10] = 15;

Угадайте, чему в данном случае равна длина массива? Правильно, 11.

Продолжение, в том или ином виде, обязательно следует…

Deep down, JavaScript has more in common with Lisp and Scheme than with Java. It is Lisp in C’s clothing.

Вот так вот.