×

Посоветуйте книги по структурованию кода

Я джун web-разработчик, работаю в небольшой ИТ компании. И так получается, что приходиться работать и на бэкенде и на фронтэнде и версткой заниматься тоже. Не так давно пересел с C# на JS(с бэкенда на фронтенд), углубляюсь сейчас в замечательный фреймворк AngularJS, jQuery, также тесно работаем с kendo ui и др. Я по образованию не программист и как таковой базы у меня нету, опыт работ в ИТ сфере тоже небольшой.

Учился по книгам Троелсен, Рихтер по C# и Фленаган по JS и кроме статьи, консультации у своих синеор сотрудников и практика — из всего этого я почерпул понимание основных принциров программирование, ООП, синтаксис, архитектура. Но чувствуется что не хватает знаний по структурированию кода. Если по C# есть хоть какое-то понимание как проектировать классы(разбивать по функциональности и «области ответсвенности») и то основые сведения по этому вопросу я получил из статей и этот вопрос в них упоминался вскольз, то в JS все плохо — понимания нету.

Хочется изучить этот вопрос, основные принципы. Есть стремление писать код логично, упорядочено, читабельно, так чтобы его легко можно было поддерживать, писать на него тесты.

Посоветуйте книги для изучения этого вопроса, было бы классно если бы примеры в ней были на JS.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

совершенный код стива макконнела (собственно сама ссылка) cafe-aristokrat.nethouse.ru/...102/102807.m0nldixuku.pdf
видео, где дядька рассказывает о ней
www.youtube.com/watch?v=ttB8iravAjE
ну и гради буч"ОО анализ"

Кстати, в соседней теме dou.ua/...ms/topic/11215 один очень хороший человек продает несколько очень полезных книг, в том числе упомянутые ниже Макконнелл и Буч.

Secrets of the JavaScript Ninja by John Resig — применительно к базовому JS, позволяет наконец-то понять что происходит и правильно структурировать.
AngularJS in Action MEAP Edition — по вашему фреймворку.
Чистый Код от Роберта Мартина — по крайней мере половину книги, применима к любому ЯП
Шаблоны тестирования xUnit от Д. Месарош — лучшей книги о тестах не существует.
Также есть монументальная зеленая книга с Носорогом по JS, но я ее ниасилил.

А что говорит тимлилд, есть кто-то, кто потом смотрит и анализирует код? У большинства компаний есть и свои правила оформления, написания, наименования.

А вот что говорит тимлид — потом и делается на рефакторинге. Но надо сначала сделать и потом послушать. А не сначала послушать и сделать вид что понял.

Стив Макконнел — Совершенный код
Программист-прагматик. Путь от подмастерья к мастеру

по JS
Learning JavaScript Design Patterns it-ebooks.info/book/724

Пиши код так, чтобы компьютер понял. А для структурирования есть IDE которое тебе в 1 клик развернёт в «общепринятый» формат.

И маленький секрет: стиль написания каждой новой скобки с новой строчки придумали программисты в 80-е в ответ на моду менеджеров платить за количество строк кода. Эта практика давно покрылась илом, а вот мода писать код размазанно — осталась.

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

Пиши код так, чтобы компьютер понял.
Худший совет из всех, что может быть. Может сразу посоветуете классы называть A, A1, A2 ??

Сомневаюсь что автору так легче. Но факт что после сборки проекта на первой же удачной компиляции делается первый рефакторинг — переименование объектов. Только потому что им было дано неудачное имя.

Над первым именованием долго думать не нужно. В месте первого объявления пишется что это за хрень. А если её потом хочется как-то назвать иначе — пишется TODO.

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

Почему так: сырой код имеет очень много «закомментированных» участков. То есть альтернативные ветки кода, или временно исключённые с целью тестирования. К моменту выхода в бету ото всех таких хвостов желательно избавиться. К альфе — от большинства.

Аналогично с параллельными алгоритмами, когда формируются тестовые переменные непосредственно в самом коде — вот они как раз могут называться A1, A2. Львиная доля из них отсеется, оставшиеся будут переименованы и открыты для общения тестов с кодом.

Совет новичку именно такой — писать чтобы компьютер понял. А потом уже делать рефакторинг. Ибо ВСЁ ПОЗНАЁТСЯ В СРАВНЕНИИ. Нельзя научиться писать правильный код, не выполнив этого преобразования от хорошего к лучшему.

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

Очень обширная тема.
Книги именно по структурированию (и не только) кода:
1) Макконнелл — Совершенный код — www.ozon.ru/...ail/id/3159814 — это классика
2) Фаулер — Рефакторинг. Улучшение существующего кода — www.ozon.ru/...ail/id/1308678
3) Мартин — Чистый код. Создание, анализ и рефакторинг — www.ozon.ru/...ail/id/5011068
Но примеры тут везде будут не на js!
Именно по js:
4) Стефанов, JavaScript. Шаблоны (www.bookzone.com.ua/...ogue_32758.html ), -хорошая книга, но она довольно непростая.
5) Alex MacCaw, JavaScript Web Applications (shop.oreilly.com/...636920018421.do) — тут правда не совсем по структурированию кода и тоже не для начального уровня.
Может еще есть смысл посмотреть классические книги по проектированию и шаблонам:
6) Буч — Объектно-ориентированный анализ и проектирование с примерами приложений.
7) GoF — Design Patterns.

Спасибо Тарас, это как раз то что я искал.

Есть стремление писать код логично, упорядочено, читабельно, так чтобы его легко можно было поддерживать, писать на него тесты.
Практика, практика и еще раз практика!
.
Тема не особо специфична для конкретной платформы, поэтому за основу можно, например, взять bit.ly/1vH9YFE

в целом пиши точно так же как и в любом друге языке. а если детальнее то — классы, примеси, объекты, для асинхронности промисы, single responsibility princip, DRY, KISS

а вообще, у тебя же там синьоры на работе, задай им этот вопрос

На работе подробный расжованный ответ не получишь и кроме бывает их мнение разнится, а хочется изучить этот вопрос — «обглодать» и жить своей головой. А то делай так и так потому что это хорошо и «я так тебе сказал» и я должен на слово верить — это не вариант. Хочется развиваться.

Спасибо за принципы, так как для меня даже слово примеси является новым, к моему стыду. Обязательно всех их просмотрю и изучу.

На работе разжёванный ответ получить можно. Сначала сделай как получится, а уже потом покажут что нужно исправить. Внести исправления в готовый код с помощью инструментов IDE — проще пареной репы! Освоение этих инструментов гораздо важнее, чем обучение делать идеально с первого раза. Зачем делать за компьютер его работу?

Внести исправления в готовый код с помощью инструментов IDE — проще пареной репы!
это про замену табы-пробелы или про декомпоизицию в publisher-subscriber?

Підписатись на коментарі