├── README.md
├── img
└── ok.svg
├── eng.md
└── rus.md
/README.md:
--------------------------------------------------------------------------------
1 | Когда-то фронтенд-разработчику достаточно было умения справляться с капризами
2 | IE6 и добиваться пиксельного соответствия в разных браузерах, чтобы считать себя
3 | профессионалом, но те времена давно прошли. Что нужно знать и уметь сегодня, чтобы
4 | считать себя продвинутым разработчиком?
5 |
--------------------------------------------------------------------------------
/img/ok.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/eng.md:
--------------------------------------------------------------------------------
1 | # A Baseline for Front-End Developers
2 |
3 | I wrote a README the other day for a project that I’m hoping other developers
4 | will look at and learn from, and as I was writing it, I realized that it was the
5 | sort of thing that might have intimidated the hell out of me a couple of years
6 | ago, what with its casual mentions of Node, npm, Homebrew, git, tests, and
7 | development and production builds.
8 |
9 | Once upon a time, editing files, testing them locally (as best as we could,
10 | anyway), and then FTPing them to the server was the essential workflow of a
11 | front-end dev. We measured our mettle based on our ability to wrangle IE6 into
12 | submission or achieve pixel perfection across browsers. Many members of the
13 | community – myself included – lacked traditional programming experience. HTML,
14 | CSS, and JavaScript – usually in the form of jQuery – were self-taught skills.
15 |
16 | Something has changed in the last couple of years. Maybe it’s the result of
17 | people starting to take front-end dev seriously, maybe it’s browser vendors
18 | mostly getting their shit together, or maybe it’s front-end devs – again, myself
19 | included – coming to see some well-established light about the process of
20 | software development.
21 |
22 | Whatever it is, I think we’re seeing the emphasis shift from valuing trivia to
23 | valuing tools. There’s a new set of baseline skills required in order to be
24 | successful as a front-end developer, and developers who don’t meet this baseline
25 | are going to start feeling more and more left behind as those who are sharing
26 | their knowledge start to assume that certain things go without saying.
27 |
28 | Here are a few things that I want to start expecting people to be familiar with,
29 | along with some resources you can use if you feel like you need to get up to
30 | speed. (Thanks to Paul Irish, Mike Taylor, Angus Croll, and Vlad Filippov for
31 | their contributions.)
32 |
33 | ## JavaScript
34 |
35 | This might go without saying, but simply knowing a JavaScript library isn’t
36 | sufficient any more. I’m not saying you need to know how to implement all the
37 | features of a library in plain JavaScript, but you should know when a library is
38 | actually required, and be capable of working with plain old JavaScript when it’s
39 | not.
40 |
41 | That means that you’ve read [JavaScript: The Good Parts][1] – hopefully more
42 | than once. You understand data structures like objects and arrays; functions,
43 | including how and why you would `call` and `apply` them; working with prototypal
44 | inheritance; and managing the asynchronicity of it all.
45 |
46 | If your plain JS fu is weak, here are some resources to help you out:
47 |
48 | * [Eloquent Javascript][2]: A wonderful book (also available in print) that
49 | takes you back to JavaScript basics
50 | * [A Test-Driven JS Assessment][3]: A set of failing tests that cover various
51 | JavaScript topics; can you write code to make the tests pass?
52 | * [10 things I learned from the jQuery Source][4] is an oldie but goodie from
53 | Paul Irish that shows what you can learn by reading other people’s code.
54 |
55 | ## Git (and a Github account)
56 |
57 | If you’re not on Github, you’re essentially unable to participate in the rich
58 | open-source community that has arisen around front-end development technologies.
59 | Cloning a repo to try it out should be second-nature to you, and you should
60 | understand how to [use branches on collaborative projects][5].
61 |
62 | Need to boost your git skills?
63 |
64 | * [help.github.com][6]
65 | * [Github git cheat sheet][7]
66 | * [More cheat sheet][8]
67 | * [More git links][9]
68 |
69 | ## Modularity, dependency management, and production builds
70 |
71 | The days of managing dependencies by throwing one more script or style tag on
72 | the page are long gone. Even if you haven’t been able to incorporate great tools
73 | like [RequireJS][10] into your workflow at work, you should find time to
74 | investigate them in a personal project or in a project like [Backbone
75 | Boilerplate][11], because the benefits they convey are huge. RequireJS in
76 | particular lets you develop with small, modular JS and CSS files, and then
77 | concatenates and minifies them via its optimization tool for production use.
78 |
79 | Skeptical of AMD? That’s no excuse to be doing nothing. At the very least, you
80 | should be aware of tools like [UglifyJS][12] or [Closure Compiler][13] that will
81 | intelligently minify your code, and then concatenate those minified files prior
82 | to production.
83 |
84 | If you’re writing plain CSS – that is, if you’re not using a preprocessor like
85 | Sass or Stylus – RequireJS can help you keep your CSS files modular, too. Use
86 | `@import` statements in a base file to load dependencies for development, and
87 | then run the RequireJS [optimizer][14] on the base file to create a file built
88 | for production.
89 |
90 | ## In-Browser Developer Tools
91 |
92 | Browser-based development tools have improved tremendously over the last couple
93 | of years, and they can dramatically improve your development experience if you
94 | know how to use them. (Hint: if you’re still using `alert` to debug your code,
95 | you’re wasting a lot of time.)
96 |
97 | You should probably find one browser whose developer tools you primarily use –
98 | I’m partial to [Google Chrome’s Developer Tools][15] these days – but don’t
99 | dismiss the tools in other browsers out of hand, because they are constantly
100 | adding useful features based on developer feedback. Opera’s [Dragonfly][16] in
101 | particular has some features that make its developer tools stand out, such as an
102 | (experimental) CSS profiler, customizable keyboard shortcuts, remote debugging
103 | without requiring a USB connection, and the ability to save and use custom color
104 | palettes.
105 |
106 | If your understanding of browser dev tools is limited, [Fixing these jQuery][17]
107 | is a great (and not particularly jQuery-centric) overview of debugging,
108 | including how to do [step debugging][18] – a life-altering thing to learn if you
109 | don’t already know it.
110 |
111 | ## The command line
112 |
113 | Speaking of the command line, being comfortable with it is no longer optional –
114 | you’re missing out on way too much if you’re not ready to head over to a
115 | terminal window and get your hands dirty. I’m not saying you have to do
116 | *everything* in the terminal – I won’t take your git GUI away from you even
117 | though I think you’ll be better off without it eventually – but you should
118 | absolutely have a terminal window open for whatever project you’re working on.
119 | There are a few command line tasks you should be able to do without thinking:
120 |
121 | * `ssh` to log in to another machine or server
122 | * `scp` to copy files to another machine or server
123 | * `ack` or `grep` to find files in a project that contain a string or pattern
124 | * `find` to locate files whose names match a given pattern
125 | * `git` to do at least basic things like `add`, `commit`, `status`, and `pull`
126 | * `brew` to use Homebrew to install packages
127 | * `npm` to install Node packages
128 | * `gem` to install Ruby packages
129 |
130 | If there are commands you use frequently, edit your `.bashrc` or `.profile` or
131 | `.zshrc` or whatever, and create an [alias][19] so you don’t have to type as
132 | much. You can also add aliases to your `~/.gitconfig` file. Gianni Chiappetta’s
133 | [dotfiles][20] are an excellent inspiration for what’s possible.
134 |
135 | *Note: If you’re on Windows, I don’t begin to know how to help you, aside from
136 | suggesting [Cygwin][21]. Right or wrong, participating in the open-source
137 | front-end developer community is materially more difficult on a Windows machine.
138 | On the bright side, MacBook Airs are cheap, powerful, and ridiculously portable,
139 | and there’s always Ubuntu or another *nix.*
140 |
141 | ## Client-side templating
142 |
143 | It wasn’t so long ago that it was entirely typical for servers to respond to
144 | XHRs with a snippet of HTML, but sometime in the last 12 to 18 months, the
145 | front-end dev community saw the light and started demanding pure data from the
146 | server instead. Turning that data into HTML ready to be inserted in the DOM can
147 | be a messy and unmaintainable process if it’s done directly in your code. That’s
148 | where [client-side templating libraries][22] come in: they let you maintain
149 | templates that, when mixed with some data, turn into a string of HTML. Need help
150 | picking a templating tool? Garann Means’ [template chooser][23] can point you in
151 | the right direction.
152 |
153 | ## CSS preprocessors
154 |
155 | Paul Irish [noted][24] the other day that we’re starting to see front-end devs
156 | write code that’s very different from what ends up in production, and code
157 | written with CSS preprocessors is a shining example of this. There’s still a
158 | vocal crowd that feels that pure CSS is the only way to go, but they’re
159 | [starting to come around][25]. These tools give you features that arguably
160 | should be in CSS proper by now – variables, math, logic, mixins – and they can
161 | also help smooth over the CSS property prefix mess.
162 |
163 | ## Testing
164 |
165 | One of the joys of writing modular, loosely coupled code is that your code
166 | becomes vastly easier to test, and with tools like [Grunt][26], setting up a
167 | project to include tests has never been easier. Grunt comes with QUnit
168 | integration, but there are a host of testing frameworks that you can choose from
169 | – [Jasmine][27] and [Mocha][28] are a couple of my current favorites – depending
170 | on your preferred style and the makeup of the rest of your stack.
171 |
172 | While testing is a joy when your code is modular and loosely coupled, testing
173 | code that’s not well organized can be somewhere between difficult and
174 | impossible. On the other hand, forcing yourself to write tests – perhaps before
175 | you even write the code – will help you organize your thinking and your code. It
176 | will also let you refactor your code with greater confidence down the line.
177 |
178 | * A short [screencast][29] I recorded about testing your jQuery with Jasmine.
179 | * An example of [unit tests][30] on the jquery-bbq plugin.
180 |
181 | ## Process automation (rake/make/grunt/etc.)
182 |
183 | Grunt’s ability to set up a project with built-in support for unit tests is one
184 | example of process automation. The reality of front-end development is that
185 | there’s a whole lot of repetitive stuff we have to do, but as a friend once told
186 | me, a good developer is a lazy developer: as a rule of thumb, if you find
187 | yourself doing the same thing three times, it’s time to automate it.
188 |
189 | Tools like `make` have been around for a long time to help us with this, but
190 | there’s also `rake`, `grunt`, and others. Learning a language other than
191 | JavaScript can be extremely helpful if you want to automate tasks that deal with
192 | the filesystem, as Node’s async nature can become a real burden when you’re just
193 | manipulating files. There are lots of task-specific automation tools, too –
194 | tools for deployment, build generation, code quality assurance, and more.
195 |
196 | ## Code quality
197 |
198 | If you’ve ever been bitten by a missing semicolon or an extra comma, you know
199 | how much time can be lost to subtle flaws in your code. That’s why you’re
200 | running your code through a tool like [JSHint][31], right? It’s
201 | [configurable][32] and has lots of ways to integrate it into your [editor or
202 | build process][33].
203 |
204 | ## The fine manual
205 |
206 | Alas, there is no manual for front-end development, but [MDN][34] comes pretty
207 | close. Good front-end devs know to prefix any search engine query with `mdn` –
208 | for example, `mdn javascript arrays` – in order to avoid the for-profit plague
209 | that is w3schools.
210 |
211 | ## The End
212 |
213 | As with anything, reading about these things won’t make you an expert, or even
214 | moderately skilled – the only surefire way to get better at a thing is to [do
215 | that thing][35]. Good luck.
216 |
217 | [1]: http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742
218 | [2]: http://eloquentjavascript.net/
219 | [3]: https://github.com/rmurphey/js-assessment
220 | [4]: http://paulirish.com/2010/10-things-i-learned-from-the-jquery-source/
221 | [5]: http://nvie.com/posts/a-successful-git-branching-model/
222 | [6]: http://help.github.com/
223 | [7]: http://help.github.com/git-cheat-sheets/
224 | [8]: http://cheat.errtheblog.com/s/git
225 | [9]: http://pinboard.in/u:rmurphey/t:git/
226 | [10]: http://requirejs.org/
227 | [11]: https://github.com/tbranyen/backbone-boilerplate
228 | [12]: https://github.com/mishoo/UglifyJS
229 | [13]: https://developers.google.com/closure/compiler/
230 | [14]: http://requirejs.org/docs/optimization.html#onecss
231 | [15]: https://developers.google.com/chrome-developer-tools/
232 | [16]: http://my.opera.com/dragonfly/blog/
233 | [17]: http://fixingthesejquery.com/#slide1
234 | [18]: https://developers.google.com/chrome-developer-tools/docs/scripts-breakpoints
235 | [19]: http://tldp.org/LDP/abs/html/aliases.html
236 | [20]: https://github.com/gf3/dotfiles
237 | [21]: http://www.cygwin.com/
238 | [22]: http://www.slideshare.net/garann/using-templates-to-achieve-awesomer-architecture
239 | [23]: http://garann.github.com/template-chooser/
240 | [24]: https://twitter.com/#!/paul_irish/status/188329390822801409
241 | [25]: http://www.stuffandnonsense.co.uk/blog/about/less
242 | [26]: https://github.com/cowboy/grunt
243 | [27]: https://github.com/pivotal/jasmine/wiki
244 | [28]: http://visionmedia.github.com/mocha/
245 | [29]: http://vimeo.com/20457625
246 | [30]: https://github.com/cowboy/jquery-bbq/blob/master/unit/unit.js
247 | [31]: http://www.jshint.com/
248 | [32]: http://www.jshint.com/options/
249 | [33]: http://www.jshint.com/platforms/
250 | [34]: https://developer.mozilla.org/en-US/
251 | [35]: http://rmurphey.com/blog/2011/05/20/getting-better-at-javascript/
--------------------------------------------------------------------------------
/rus.md:
--------------------------------------------------------------------------------
1 | # Необходимый минимум для фронтенд-разработчика
2 |
3 | На днях я подготовила README для одного проекта, который, надеюсь,
4 | будет
5 | интересен и поучителен для других разработчиков. Так вот, когда я его писала, я
6 | поняла, что несколько лет назад испугалась бы до смерти, если бы наткнулась на
7 | нечто подобное, со всякими упоминаниями о Node и его пакетном менеджере,
8 | системах Homebrew и Git, всевозможных тестах, тестовых и финальных сборках.
9 |
10 | Когда-то основная часть рабочего процесса фронтенд-разработчика состояла в редактировании
11 | файлов, их локальном тестировании (в меру возможностей) и пересылке на
12 | сервер через FTP. Мы измеряли свою крутость умением подчинить своей воле IE6
13 | или
14 | добиться пиксельного соответствия в различных браузерах. Многим членам нашего
15 | сообщества — и мне тоже — не хватало опыта традиционного
16 | программирования.
17 | HTML, CSS и JavaScript — обычно в виде jQuery — осваивались самостоятельно.
18 |
19 |
20 | За последние несколько лет кое-что изменилось. Возможно, причиной этому стало
21 | то,
22 | что люди начали воспринимать фронтенд-разработку серьезно; может быть, то, что
23 | разработчики браузеров в большинстве своем наконец-то навели порядок в своих
24 | творениях; а, может, просто фронтенд-разработчики, опять же, включая меня,
25 | в конце концов постигли суть процесса разработки ПО.
26 |
27 | Что бы там ни было, думаю, мы стали свидетелями смещения акцента с ценности
28 | различных мелочей на ценность инструментов. Теперь, чтобы быть успешным
29 | фронтенд-разработчиком, нужно обладать набором базовых навыков, а те
30 | разработчики, которые не соответствуют этим требованиям, скоро начнут
31 | всё сильнее чувствовать насколько сильно они отстали, по мере того как
32 | источники
33 | информации начинают подразумевать наличие некоторых знаний как само
34 | собой разумеющееся.
35 |
36 | Вот некоторые вещи, с которыми хотелось бы, чтобы все были знакомы и некоторые
37 | источники, которые можно использовать, чтобы подтянуть свои навыки. (Спасибо
38 | Полу Айришу (Paul Irish), Майку Тейлору (Mike Taylor), Ангусу Кролу (Angus
39 | Croll) и Владу Филипову (Vlad Filippov) за их вклад.)
40 |
41 | ## JavaScript
42 |
43 | Возможно это понятно и без слов, но простого знания библиотеки на JavaScript
44 | больше не достаточно. Я не говорю, что вы обязаны уметь реализовать все
45 | возможности библиотеки с помощью простого JavaScript, однако вы должны понимать
46 | в каких случаях применение библиотеки действительно уместно, и уметь работать
47 | со старым добрым JavaScript, если это потребуется.
48 |
49 | Это значит, что вы прочитали «[JavaScript: Сильные стороны][1]», желательно
50 | больше одного раза. Что вы понимаете принцип работы структур данных вроде
51 | объектов и массивов; функции, в том числе как и почему их нужно *вызывать* и
52 | *применять*; умеете работать с наследованием через прототипы; и можете
53 | справиться с асинхронностью.
54 |
55 | Если ваши навыки работы с простым JavaScript оставляют желать лучшего, вот
56 | некоторые ресурсы, которые вас выручат:
57 |
58 | * [«Красноречивый JavaScript»][2]: Замечательная книга (также доступна печатная
59 | версия), посвящённая основам JavaScript
60 | * [Тестовая оценка владения JS][3]: подборка тестов с ошибками на
61 | различные темы по JavaScript; сможете ли вы переписать код тестов так, чтобы он заработал?
62 | * [10 вещей, которым я научился из исходного кода jQuery][4] — старенькая, но
63 | мощная вещь от Пола Айриша, демонстрирующая чему можно научиться, читая чужой
64 | код.
65 |
66 | ## Система управления версиями файлов Git (и профиль на GitHub)
67 |
68 | Если вас нет на GitHub, в общем и целом вы не можете участвовать в жизни
69 | крупного сообщества с открытым исходным кодом, которое выросло вокруг
70 | технологий
71 | фронтенд разработки. Клонирование репозитория с целью испробовать его
72 | возможности должно стать для вас привычным делом и вы должны понимать как
73 | [использовать ветки в совместных проектах][5].
74 |
75 | Хотите повысить свои навыки работы с Git?
76 |
77 | * [help.github.com][6]
78 | * [шпаргалка по GitHub][7]
79 | * [Ещё одна шпаргалка][8]
80 | * [Больше ссылок по Git][9]
81 |
82 | ## Модульный принцип организации, управление зависимостями и тестовые сборки
83 |
84 | Те дни, когда управление зависимостями сводилось к добавлению дополнительного
85 | скрипта или тега стилей на страницу, давно прошли. Даже если у вас не было
86 | возможности внедрить замечательные инструменты вроде [RequireJS][10] в процесс
87 | разработки на работе, вам стоит найти время изучить их в своем личном проекте
88 | или проекте вроде [Backbone Boilerplate][11], так как преимущества, которые
89 | они
90 | в себе несут, трудно переоценить. RequireJS, в частности, делает возможной
91 | разработку с использованием небольших модульных файлов JS и CSS, а затем
92 | конкатенирует и минифицирует их с помощью своего инструмента оптимизации для
93 | дальнейшего использования.
94 |
95 | Скептически настроены относительно разработки на основе модулей? Это не
96 | причина
97 | ничего не делать. По крайней мере, вам должны быть знакомы инструменты вроде
98 | [UglifyJS][12] или [Closure Compiler][13], которые грамотно сжимают ваш код, а
99 | затем конкатенируют эти сжатые файлы перед выдачей результата.
100 |
101 | Если вы пишете на чистом CSS - то есть не используете препроцессор вроде Sass
102 | или Stylus – RequireJS также поможет организовать ваши CSS файлы по модульному
103 | принципу. Используйте операторы `@import` в основном файле, чтобы загрузить
104 | зависимости для разработки и затем запустите [средство оптимизации][14]
105 | RequireJS для основного файла чтобы создать готовый для использования файл.
106 |
107 | ## Инструменты разработчика, встроенные в браузер
108 |
109 | За последние несколько лет инструменты для разработчиков, встроенные в
110 | браузеры, ощутимо усовершенствовались и теперь они могут существенно улучшить
111 | ваш опыт разработки, если вы научитесь ими правильно пользоваться. (Подсказка:
112 | если вы все еще отлаживаете код, используя `alert`, вы зря убиваете время.)
113 |
114 | Вам наверняка стоит выбрать один браузер, чьи инструменты разработчика вы
115 | будете использовать на постоянной основе — на данный момент я склоняюсь к
116 | [инструментам разработчика в Google Chrome][15] - но не отказывайтесь полностью
117 | от инструментов в других браузерах, так как в них время от времени на основе
118 | откликов разработчиков добавляются новые полезные возможности. В [Dragonfly][16]
119 | от Opera, в частности, были добавлены некоторые возможности, выделяющие её
120 | инструменты разработчика на фоне других, например: (экспериментальный) CSS-
121 | профилировщик, настраиваемые горячие клавиши, удалённая отладка без
122 | необходимости USB-подключения, а также возможность сохранять и использовать
123 | пользовательские цветовые палитры.
124 |
125 | Если вы не очень хорошо разбираетесь в браузерных инструментах разработчика,
126 | презентация [«Чиним код jQuery»][17] послужит отличным (и не слишком
127 | сфокусированным на jQuery) обзором отладки, который включает в себя описание
128 | процесса пошаговой отладки — того, что изменит вашу жизнь, если вы с этой презентацией
129 | ещё не знакомы.
130 |
131 | ## Командная строка
132 |
133 | Если говорить о командной строке, её уверенное использование уже является
134 | обязательным - вы непозволительно много упускаете, если не готовы тут же
135 | зайти в окно терминала и погрузиться в работу. Я не говорю, что вам следует
136 | делать *всё* через терминал - можете продолжать пользоваться графическим
137 | интерфейсом Git, хотя думаю, в конце концов, вам же будет лучше, если вы от него
138 | откажетесь - однако, несомненно, окно терминала должно быть постоянно открыто
139 | для проекта, над которым вы работаете. Есть несколько задач, которые вы должны
140 | выполнять через командную строку не задумываясь:
141 |
142 | * `ssh` для подключения к другой машине или серверу
143 | * `scp` для копирования файлов на другую машину или сервер
144 | * `ack` или `grep` для поиска файлов в проекте по строке или шаблону
145 | * `find` для обнаружения файлов, чьи названия совпадают с данным шаблоном
146 | * `git` для выполнения хотя бы базовых действий вроде `add`, `commit`, `status`
147 | и `pull`
148 | * `brew` для использования Homebrew для установки пакетов
149 | * `npm` для установки пакетов Node
150 | * `gem` для установки пакетов Ruby
151 |
152 | Если какими-то командами вы пользуетесь особенно часто, отредактируйте свой `.bashrc`,
153 | `.profile` или `.zshrc` (или что у вас там) и создайте для них [альтернативные
154 | имена][19] чтобы не набирать команды руками каждый раз. Также можно добавить альтернативные
155 | имена в файл `~/.gitconfig`. [Файлы с точками][20] от Джанни Чиаппетта (Gianni
156 | Chiappetta) могут послужить отличным источником вдохновения.
157 |
158 | *Примечание: Если вы пользуетесь Windows, я не знаю, как вам помочь, разве что
159 | могу посоветовать [Cygwin][21]. Возможно, я не права, но принимать участие в
160 | жизни сообщества фронтенд-разработчиков с открытым кодом на машине с Windows
161 | существенно сложнее. Если посмотреть на вещи оптимистически, ноутбуки MacBook
162 | Air не очень дорогие, мощные и на удивление портативные, кроме того существуют
163 | Ubuntu или Unix.*
164 |
165 | ## Шаблонизация на стороне клиента
166 |
167 | Не так давно для серверов было обычным делом отвечать на запрос XHR фрагментом
168 | HTML-кода, однако за последние 12-18 месяцев сообщество фронтенд разработчиков
169 | прозрело и начало требовать данных от сервера в чистом виде. Преобразование
170 | таких данных в HTML, который затем можно добавить в дерево документа, может
171 | оказаться трудоёмким и неудобным процессом, если иметь дело непосредственно с кодом.
172 | Вот когда в дело вступают [библиотеки шаблонизации на стороне клиента][22]: они
173 | позволяют использовать шаблоны, которые после добавления данных
174 | превращаются в строку HTML. Вам нужна помощь в подборе инструмента для
175 | шаблонизации? [Схема для выбора шаблона][23] от Герен Минс (Garann Means)
176 | поможет вам найти подходящий.
177 |
178 | ## CSS-препроцессоры
179 |
180 | На днях Пол Айриш [отметил][24], что мы стали свидетелями того, что фронтенд-
181 | разработчики пишут код, сильно отличающийся от того, который в результате
182 | оказывается в готовой сборке и ярким примером тому является код, написанный с
183 | помощью CSS-препроцессоров. Всё еще есть крикливая компания, которая считает,
184 | что только чистый CSS имеет право на жизнь, но они [начинают менять
185 | мнение][25]. Эти инструменты дают нам возможности, которые, по мнению некоторых,
186 | уже должны были быть добавлены в CSS — переменные, математические выражения,
187 | логику, миксины, а также они могут помочь справиться с префиксами свойств.
188 |
189 | ## Тестирование
190 |
191 | Одна из радостей написания модульного, свободно сопряжённого кода состоит в
192 | том, что такой код намного легче тестировать, а с инструментами вроде
193 | [Grunt][26],
194 | подготовка проекта со встроенными тестами вообще стала проще простого. В Grunt
195 | интегрирован QUnit, однако существует много фреймворков для тестирования, из
196 | которых вы можете выбрать те, что вам по душе — моими любимыми на данный
197 | момент являются [Jasmine][27] и [Mocha][28] — в зависимости от стиля, который
198 | вы предпочитаете, и остальных составляющих вашей подборки.
199 |
200 | В то время, как тестирование модульного, свободно сопряжённого кода является
201 | приятным, тестирование плохо организованного кода может быть чем-то средним
202 | между сложным и невозможным. С другой стороны, если принудить себя написать
203 | тесты, возможно, даже до того, как вы напишете код - это поможет вам
204 | систематизировать свой подход и код. Это также даст вам возможность
205 | перестроить код с большей уверенностью в будущем.
206 |
207 | * Короткий [скринкаст][29], записанный мной о тестировании jQuery-кода с
208 | помощью Jasmine.
209 | * Пример [модульного тестирования][30] на плагине jQuery BBQ.
210 |
211 | ## Автоматизация процессов (rake/make/grunt/и т.д.)
212 |
213 | Возможность с помощью Grunt настроить проект со встроенной поддержкой модульного
214 | тестирования — это один из примеров автоматизации процессов. Реальность
215 | фронтенд-разработки такова, что нам приходится выполнять множество
216 | повторяющихся действий, но, как однажды сказал мне друг: хороший разработчик —
217 | ленивый разработчик. Советую придерживаться золотого правила:
218 | если вы выполняете какое-либо действие больше трёх раз, пора его
219 | автоматизировать.
220 |
221 | Уже довольно давно нам в этом помогают инструменты вроде `make`, кроме него
222 | существуют также `rake`, `grunt` и другие. Если вы хотите автоматизировать
223 | выполнение заданий связанных с файловыми системами, исключительно полезно
224 | будет изучить язык, отличный от JavaScript, так как асинхронная природа Node
225 | может стать неподъемным грузом, если вы умеете только управлять файлами.
226 | Существует также множество других инструментов автоматизации, созданных под
227 | конкретные задачи: инструменты для развёртывания, генерирования сборки,
228 | проверки качества кода, и др.
229 |
230 | ## Качество кода
231 |
232 | Если вам когда-либо приходилось ощущать негативные последствия от пропущенной
233 | точки с запятой или лишней запятой, вы знаете сколько времени можно потерять
234 | из-за мелких ошибок в коде. Поэтому вы пропускаете свой код через инструмент
235 | вроде [JSHint][31], верно? Он [поддаётся настройке][32] и может быть
236 | интегрирован в ваш [редактор или процесс сборки][33] несколькими способами.
237 |
238 | ## Хорошее руководство
239 |
240 | К сожалению, руководства по фронтенд-разработке не существует, однако [ресурс
241 | MDN][34] вполне подходит на эту роль. Хорошие фронтенд разработчики знают, что
242 | в каждый поисковый запрос нужно добавлять префикс `mdn` — например, `mdn
243 | массивы javascript` — чтобы избежать коммерческой чумы, которой является ресурс
244 | w3schools.
245 |
246 | ## Конец
247 |
248 | Как всегда, просто почитав обо всех этих инструментах, вы не научитесь ими
249 | пользоваться на уровне эксперта или хотя бы любителя, единственный верный
250 | способ научиться что-то делать — [начать пробовать это делать][35]. Удачи вам.
251 |
252 |
253 |
254 |
255 |
256 |
Статья переведена благодаря спонсорской поддержке компании «Одноклассники».
255 |
256 |