«Дефрагментация мозга. Софтостроение изнутри» читать онлайн книгу 📙 автора Сергея Тарасова на MyBook.ru
image
  1. Главная
  2. Библиотека
  3. Сергей Тарасов
  4. «Дефрагментация мозга. Софтостроение изнутри»
Дефрагментация мозга. Софтостроение изнутри

Отсканируйте код для установки мобильного приложения MyBook

Премиум

3.83 
(12 оценок)

Дефрагментация мозга. Софтостроение изнутри

214 печатных страниц

2013 год

12+

По подписке
549 руб.

Доступ ко всем книгам и аудиокнигам от 1 месяца

Первые 14 дней бесплатно
Оцените книгу
О книге

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

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

Из текста вы вряд ли узнаете, как правильно склеивать многоэтажные постройки из готовых компонентов в гетерогенной среде, проектировать интерфейсы, синхронизировать процессы или писать эффективные запросы к базам данных. Подобные темы будут лишь фоном для рассказа о софтостроительной «кухне». При определенной доле любопытства вы сможете убедиться, что новое – это хорошо забытое старое, узнать, как устроены некоторые сложные системы, когда следует применять разные технологии, почему специалистам в информатике надо особенно тщательно фильтровать поступающую из множества источников информацию, и многое другое, что вы, возможно, еще не знали или уже знаете, но с другой стороны.

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

читайте онлайн полную версию книги «Дефрагментация мозга. Софтостроение изнутри» автора Сергей Тарасов на сайте электронной библиотеки MyBook.ru. Скачивайте приложения для iOS или Android и читайте «Дефрагментация мозга. Софтостроение изнутри» где угодно даже без интернета. 

Подробная информация
Дата написания: 1 января 2013Объем: 385497
Год издания: 2013Дата поступления: 17 июля 2020
ISBN (EAN): 9785496006064
Правообладатель
1 408 книг

Поделиться

iam_weasel

Оценил книгу

Книга эта - очерки и полевые записки айтишника. Его точка зрения на сложившиееся мироустройство, маленькие заметки о практике и байки из жизни. Если понравился Джоэль Спольски и его книги - блоги, то эта тоже понравится.

4 марта 2014
LiveLib

Поделиться

stupin

Оценил книгу

Судя по книге, автор обладает опытом разработки программ под Windows. Насколько я могу судить, это в основном корпоративные приложения с использованием Microsoft SQL Server, написанные на Delphi, Java и C#. Приятно, что автор знаком с историей отечественных информационных технологий и во многих случаях вместо западной терминологии использует исторически возникшую раньше отечественную технологию. Например, вместо понятия ЦОД - Центр обработки данных, автор предпочитает наше понятие ВЦКП - Вычислительный центр коллективного пользования, которое, пожалуй, даже лучше отражает суть.

В целом книга представляет собой сборник статей на разные темы. Однако, если попытаться изложить лейтмотив этих статей, то получится примерно следующее. В настоящее время отрасль информационных технологий состоит примерно на 10% из собственно разработки и примерно на 90% из сферы услуг, связанной с установкой, развёртыванием, обслуживанием и сопровождением информационных систем. Автоматизация процессов учёта и прогнозирования позволяет крупным компаниям сокращать офисных работников, которые до автоматизации занимались обслуживанием этих процессов. Бывшие офисные работники переквалифицируются в программистов и, как правило, получают рабочие места в тех 90% отрасли, которые заняты в сфере услуг. Таким образом, в сфере информационных технологий появляется большое количество работников с низкой квалификацией. Для того, чтобы получать от этих работников более-менее стабильный результат, компании используют разнообразные технологии, снижающие планку требований к работникам: это в первую очередь сборка мусора вместо ручного управления памятью, разнообразные ORM вместо SQL, веб-приложения вместо компонентных распределённых приложений, гибкие и экстремальные методологии разработки вместо проектирования. Ставка делается на то, чтобы разрабатывать большие и сложные системы путём грубой силы. Цикл разработки при этом растягивается, код систем разбухает от большого количества промежуточных слоёв, работа программ замедляется за счёт уменьшения локальности обработки данных - данные обрабатываются всё дальше от того места, где они хранятся.

Далее кратко расскажу о наиболее запомнившихся статьях.

В статье "Круговорот" на стр. 20-23 делается интересное наблюдение о том, как автоматизация вымывает сотрудников компаний из офисной работы и отделов АСУ компаний в IT-компании в качестве низкоквалифицированной рабочей силы.

В статье "Изгибы судьбы при поиске работы" на стр. 31-34 автор занимается самолюбованием, пытаясь продемонстрировать читателю не только свою востребованность на рынке труда, но и умение находить высокооплачиваемую работу окольными путями и пиратскими тропами.

В статье "Эволюция аппаратуры и скорость разработки" на стр. 40-43 автор делится любопытным наблюдением: несмотря на прогресс в вычислительной мощности компьютеров, развитие языков программирования и прочих инструментов разработки, скорость работы программ не растёт, а скорость их разработки со временем даже снижается. Повсеместное насаждение ООП вымывает из отрасли женщин, которые неплохо справлялись с написанием связующего кода в чисто процедурном стиле, но не смогли вписаться в объектно-ориентированную парадигму.

На стр. 44-54 в статьях "О карманных монстрах", "ASP.NET и браузеры", "Апплеты, Flash и Silverlight" автор раскрывает ещё несколько причин тенденции, описанной в главе "Эволюция аппаратуры и скорость разработки". Если раньше интерфейс программы можно было редактировать в визуальном редакторе, а бизнес-логику поместить в хранимые процедуры в базе данных, то сейчас повсеместное распространение получила веб-разработка с трёхзвенной структурой приложений, при которой интерфейс формируется путём ручного кодирования, а бизнес-логика помещается на сервер приложений, который по совместительству выполняет функции посредника между интерфейсом и базой данных, выполняя необходимые преобразования данных из одного представления в другое. Веб не ориентирован на хранение состояния клиента внутри сессии в оперативной памяти, из-за чего большинство веб-приложений всё состояние между отдельными запросами сохраняет в базу данных или передаёт на сторону клиента в виде большого файла-куки, а перед обработкой очередного запроса вновь восстанавливает.

В статье "Про сборку мусора и агрегацию" на стр. 128-131 высказана правильная мысль о том, что автоматическая сборка мусора расслабляет программистов, давая им возможность не думать не только об освобождении неиспользуемой памяти, но и позволяет им не задумываться о коде, владеющем данными в памяти. Последнее может приводить к ошибкам в проектировании, приводящим впоследствии к трудноуловимым ошибкам, когда в нескольких местах программы объект доступен по ссылке и одна часть программы может изменять объект незаметно для других частей.

В статье "UML и птолемеевские системы" на стр. 135-140 ставится под сомнение ценность UML, т.к. он:
1. не универсальный, а унифицированный, т.к. объединяет несколько разных подходов разных авторов к графическому изображению логики программ,
2. не язык, а графическая нотация,
3. не моделирования, т.к. не позволяет собственно моделировать и верифицировать модель.

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

В статье "Приключения с TFS" на стр. 166-170 рассказана, на мой взгляд, классическая история про развёртывание коммерческого ПО под Windows, когда для удачного развёртывания необходимо соблюсти ряд неочевидных условий и побороться со встроенными в каждую программу средствами автоматизации развёртывания, облегчающими установку программы в типовых случаях, но превращающих задачу в многоэтапный квест в случаях нетиповых.

В статье "Лампа, полная джиннов" на стр. 174-194 рассказывается о двустороннем генераторе кода проекта. Мне эта автоматизация показалась прекрасной иллюстрацией недостаточной гибкости полукомпилируемых языков типа Java или C#. Мне по работе приходится больше всего писать на Python и использовать веб-фреймворк Django. Из моделей Django с минимальными усилиями можно получить готовые веб-формы и административный интерфейс, не прибегая к помощи каких-либо генераторов кода.

Мне приходилось сталкиваться с программированием для Windows лишь в самом начале карьеры. Я писал небольшую программу на Visual Basic для создания трёхмерных моделей зуборезных долбяков (это такой инструмент для изготовления зубчатых колёс или шлицов эвольвентной формы) в SolidWorks. Сейчас я пишу программы в основном на языке Python и иногда использую веб-фреймворк Django. Работа моя непосредственно не связана с программированием, но за мной часто остаётся выбор, каким образом выполнить ту или иную задачу. Если это бывает возможно, то я стремлюсь не делать одноразовой работы, а стараюсь вписывать каждое решение в общую систему, разработкой которой и занимаюсь для автоматизации своей работы. Несмотря на то, что мой опыт работы довольно сильно отличается от опыта автора, большая часть мыслей автора мне хорошо понятна и близка.

Так, я не стремлюсь в веб-разработку, потому что после разработки в Visual Basic или в Delphi нынешняя разработка веб-приложений кажется мне чрезмерно усложнённым способом решения задач. Большую ценность для меня представляет непосредственно сама решённая задача, а получившаяся программа является приятным дополнением. Я рассчитываю, что при необходимости смогу легко переписать программу и не особо дорожу исходниками. Когда я смотрю на современную веб-разработку, то мне кажется, что разного рода фреймворки, движки и библиотеки становятся какой-то самоцелью. Люди, надо полагать с удовольствием, корпят над большим количеством кода, который по сути не делает ничего. При этом код приобретает для них самостоятельную ценность.

Я примерно так же как и автор с некоторым пренебрежением отношусь к UML, ООП, ORM и веб-разработке, хотя и пользуюсь ими. Я рисую прямоугольники на клочке бумаги, когда нужно спроектировать структуру таблиц под какую-то задачу. Я не брезгую сделать класс для того, чтобы поместить в него общие данные нескольких десятков функций - ведь эти функции и так имеют общие используемые данные, так зачем использовать процедурный подход, пытаясь скрыть это? Пользуюсь веб-фреймворком Django и его ORM для того, чтобы как можно меньше программировать веб-интерфейсы и как можно чаще пользоваться готовым административным интерфейсом, встроенным в Django. Мне легче написать SQL-запрос, чем запрос с использованием ORM, но я не вижу смысла писать много SQL-запросов и прочего кода, лишь для того, чтобы сделать простейший CRUD. В то же время, я хорошо понимаю, что на ORM бывает нелегко, а то и вовсе невозможно написать эффективный аналитический запрос, который легко пишется на SQL.

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

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

6 апреля 2020
LiveLib

Поделиться

Этюды для программистов» [17].
12 мая 2021

Поделиться

Чарльза Уэзерелла «Этюды для программистов» [17].
8 августа 2015

Поделиться

солдаты от софтостроения не должны рассуждать. Они несут службу и должны молча овладевать оружием, закупкой которого занимаются генералы в непрозрачном договоре с поставщиками. Экономика потребления обязана крутиться, даже если в ней перемалываются миллиардные бюджеты бесполезных трат на модернизацию, переделку и переобучение.
17 июля 2015

Поделиться