… И есть даже информация про Украинские компании, хотя, очень мало. Работа сайта базируется на анонимных анкетах пользователей. Можно оценить компанию, дать отзыв, рассказать о зарплате и.т.д. Такие анонимные анкеты, по моему субъективному мнению, могут быть довольно точными.
В начале, был один ярус, и это было хорошо . В бородатых восьмидесятых, был один мейнфрейм и тысячи «немых» терминалов пользователей, которые были подключения к одной и только одной Большой Железяке. Эти 3270 терминалов называли «немыми», потому что у них была только клавиатура и монитор. Без процессора. Это было просто устройство ввода / вывода.Приложение клиента запускается локально, оно имеет локальное хранилище, что позволяет работать как в онлайн, так и в офлайн режиме. И данных и код находятся настолько близко к пользователю, насколько это возможно. Вы думаете, почему Microsoft Excel является наиболее популярным программным обеспечением среди бизнес-пользователей на предприятиях? Потому что Excel позволяет пользователю иметь свой маленький кусочек данных и любительский, но рабочие код (формулы) очень близко. Прямо на рабочем столе. Нет необходимости просить этих Всемогущих Админов о милости и помощи. Нет зависимости от сетевого подключения или каких-то таинственных серверов, которые могут работать медленно или падать. Наиболее продвинутые пользователи даже научиться работать с базами данных MS Access, чтобы уменьшить зависимость от отдела IT. Так держать!
Оригинал: The Unofficial History of Software Engineering
Про эту замечательную статью я узнал из подкаста автора статьи Якова Файна (Будама). За что что ему спасибо. ;)
Перевод статьи с английского на русский: Дмитрий Жарий
Эта мысль, без сомнения, на том или ином этапе жизни посещает каждого из нас. В какой-то момент вы чувствуете, что подошли к перекрестку судьбы, и задаете себе вопрос: “Должен ли я углубить свои знания и навыки в моем любимом языке программирования или фреймворке и изучить в нем каждую мелочь?” Или я должен расширить свой кругозор и изучить смежные инструменты и технологии или даже изучить новые языки программирования и платформы? Этот вопрос может, действительно, ввести вас в заблуждения при поиске правильного пути. Есть слишком много аргументов за и против. Даже если вы обратитесь к кому-нибудь за советом, этого не сделает дорогу ясной для вас, и, более того, перед вами откроется ряд новых путей, которые усложнят выбор.
Давайте рассмотрим аргументы в поддержку этих альтернатив более детально.
Рассматривая возможность стать специалистом, вы, вероятно, думаете о превращении в какого-то гуру, который будет знать все о какой-либо технологии, фреймворке или продукте. Специалистов не много, так что вы могли бы, потенциально, найти высокооплачиваемую работу в компании, которая не может жить без вашего опыта. Правильно? Ну… теоретически да, логика здесь есть. Но, реальность, конечно же, сильно отличается от теории. Истинна заключается в том, что большинство компаний никогда не доводят свои проекты до такой степени сложности и размера, что присутствие гуру на проекте становиться жизненно необходимым. Чем более вы позиционируете себя как специалиста, тем более сужается выбор мест, куда вы потенциально можете идти. И, возможно, что в регионе, в котором вы живете, такой ниши может не оказаться вовсе.
Это не означает, что вы не должны изучать ваши инструменты в глубину, а должны знать их только поверхностно. Совсем наоборот, вы должны знать все, что вам необходимо сейчас, и даже за пределами своих сегодняшних потребностей. Это увеличит ваше понимание внутренней работы инструментов. Вы будете писать лучший код. Вы найдете ошибки более легко. Вы сможете найти выход из нестандартных ситуаций. Вы будете знать больше способов того, как забить гвоздь вашим молотком. Но в какой-то момент, вам придется прекратить копать и посмотреть вокруг. Ведь есть много других, интересных и не менее полезных вещей для изучения.
Есть еще одна очевидная опасность для специалиста. В сфере разработки ПО все меняется чрезвычайно быстро. Новые великолепные языки и фреймворки появляются из ниоткуда, вспыхивают как яркая звезда и, погружаются в небытие. Инструменты стареют, заменяются новыми версиями, которые, в свою очередь, стареют и, в итоге, выходят из употребления. Все движется вперед. Если вы делаете ставку не на ту лошадь, если вы вкладываете все время в обучение одной конкретной технологии, вы рискуете потерять ставку, если лошадь не победит.
Так что, генералистом быть лучше? Ответ обычный: все зависит от ситуации, от рынка, и от вас. Однако этот подход имеет свои сильные стороны.
Во-первых, подход генералиста расширит границы ваших знаний. Вас не загонит в тупик ситуация, когда конкретная технология начинает доставлять массу проблем. Знание различных технологий и инструментов дает возможность сравнить возможные решения, которые позволяет реализовать каждая из них, и выбрать ту технологию, которая наилучшим образом соответствует вашим задачам. Если мы говорим не о сопоставимых либо конкурирующих технологиях, а про различные навыки, которые находят свое применение в рамках одного проекта, это даст вам возможность увидеть проблему в различных слоях технологии и проанализировать ее на различных уровнях абстракции. Вы можете сравнить варианты реализаций, и сделать вывод: где и как необходимо решать конкретную проблему. Предположим, мы говорим о классическом многоуровневом приложении, где есть база данных, уровень бизнес-логики и слой пользовательского интерфейса. Если вы будете компетентны в разработке каждого их этих слоев – это позволит решить проблему намного быстрее и легче. Вместо оптимизации каждого байта приложения, вы можете посмотреть на проблему с другой точки зрения: просто собрать и настроить готовое приложения, которое просто выполняет свою задачу. Вам не всегда жизненно необходимо настраивать сверх оптимальное кеширование на стороне сервера? А как на счет тонкой настройки пользовательского интерфейса, чтобы избежать запуска сложных запросов несколько раз? Или это надуманная проблема, и, скорее всего, ваш пользователь совершенно не нуждается в этой фиче? Видите? Вы можете думать о различных условиях, в которых будет работать ваше приложение, и это дает вам определенную свободу духа, чтобы найти наиболее эффективное и элегантное решение.
Но, давайте пойдем дальше. Если вы являетесь специалистом по различным технологиям, то ваш набор знаний и навыков становиться все более отшлифованным. И это превращает вас в эффективную команду из одного человека. Вы самодостаточны, знакомы со всеми аспектами текущего проекта, вы способны завершить практически самостоятельно, без посторонней помощи со стороны специалистов и гуру. И это уже является минимальным требованием для веб-разработчиков: каждому необходимо иметь практические знания всех составных частей веб-проекта. Вы должны знать ваш фреймворк, быть знакомым с базами данных и иметь возможность создавать HTML разметку для пользовательского интерфейса. У нас есть данные, которые необходимо собирать и хранить? Вот, здесь я разработал модель данных, создал индексы, написал необходимые запросы и оптимизировал работу с базой данных для нашего конкретного сценария. Нам необходимо приложение для взаимодействия с базой данных? Подождите минутку, вот код, реализация ввода данных, их проверка, бизнес-правила и разграничение уровня доступа к данным – все готово. Чудесно. А где же наш яркий и сияющий пользовательский интерфейс? Всё тут же, это валидный HTML и CSS. Хотите еще Ajax? Дайте мне пять минут. Готово, проверяйте!
Узнали себя? Вы можете делать все это и многое другое, и вам это нравиться. Либо вы один и тех, кто посвятил большую часть своей жизнь тому, чтобы стать гуру базы данных? Или вы интерфейсный разработчик, владеющий HTML, CSS и семантической разметкой, но вы никогда не работали с базами данных. Что? Вы боитесь баз данных? Нет, это действительно не страшно, обязательно попробуйте, когда ни будь.
Поймите меня правильно. Я очень уважаю специалистов и профессионалов. Их глубокие знания технологий, могут оказаться очень полезными. Иногда они могут дать вам такое решение, к которому вы бы не пришли самостоятельно. Я всегда чувствую, небольшое, но в то же время просвещения после получения совета от них. И я бесконечно благодарен им за откровенность и затраченное на меня время.
Несмотря на это, я понимаю, что большая часть проектов может быть завершена без этих продвинутых знаний. И мы не приносим в жертву качество приложения или создаем уродливые хаки для исправления того, что мы не могли обойти нормальным путем. У нас все в порядке. У нас просто не было каких-либо серьезных проблем. Не в этом проекте. И не в прошлом. И серьезных проблем не было даже в том проекте, который мы завершили в прошлом году. И мы можем уверенно сказать, что мы не ожидаем серьезных проблем и в нашем следующем проекте.
Ладно, вы не можете быть настолько уверены в будущем. Но, знаете что? Вы всегда можете узнать все, что вам необходимо тогда, когда это вам потребуется. Зачем же раньше времени бить тревогу? Рядом со мной есть необходимая книга. Когда я чувствую, что мне не хватает знаний в некоторых конкретных областях – я прочитаю необходимые главы. Или просто найду ответ в Google. Сегодня, вы сможете найти почти все в Интернете. И это быстро. И очень часто вы найдете ответ быстрее, чем волосатый парень Боря, гуру, сидящий за столом в углу, допьет свою чашку кофе и соблаговолит подойти к вам.
Кроме того, в Сети храниться колоссальный объем знаний и опыта других разработчиков. С большой вероятностью, вы можете наткнуться на такое, уже готовое решение, которое вам не вычитать и в двух тысячах страниц умной книги. Да, гуру тоже появляются в Интернете. Последний раз я принимал участие в одной технической дискуссии, так один опытный парень из Microsoft появился из ниоткуда и принес нам неожиданное, но столь необходимое просветление.
И можете не беспокоиться по поводу путей развития вашей карьеры. Быть генералистом может быть действительно лучше. Есть много небольших и средних компаний, которым необходим человек, имеющий делать многое. И это не значит, что они просто хотят заменить целый отдел разработчиков на одного многофункционального разработчика для того, чтобы сократить расходы. Скорее всего, для их проектов вполне достаточно человека с широкими навыками, у которого руки растут из правильного места. Там нет настолько нетипичных ситуаций, необычных сценариев или граничных случаев, в которых может работать только гуру. По сути, эти компании не могут предоставить работу необходимой сложности для столь высококвалифицированных специалистов. И, если гуру попадет в такую компанию, без работы особой сложности, то, скорее всего первый месяц ему будет очень скучно, а со следующего – он просто уволиться. Вы – универсальный разработчик, и вы можете решить очень широкий круг задач. На самом деле, будучи универсальным разработчиком, вы свободно можете оставить свое сегодняшнее место и стать контрактером, фрилансером, или даже открыть свою собственную небольшую компанию по разработке ПО. Это не сложно теперь, когда вы ознакомились со всем аспектам разработки продукта.
Когда я вспоминаю свои первые годы в программировании, моим самым интересным и в то же время депрессивным периодом было именно начало. Я просто знал слишком мало. Я мог писать программы, которые работали, но, потом я застревал в чем-то таком, что я действительно не знал. Я хотел бы сохранить некоторые данные в базу данных, но у меня не было опыта работы с базами данных. Хорошо было бы хранить настройки в XML, но я никогда не работал с ним. Собственно, аппаратное ускорение может дать нам прорыв, но я еще не программировал 3D-графику. Создать свой собственный сетевой протокол? Это же настолько сложно, могу ли я это сделать? Создание веб-сайта? Я знаю только несколько HTML тегов. Да, мне было действительно сложно сделать что-либо.
Теперь, программирование приносит мне намного больше удовольствия, ведь я могу сделать много разных вещей. Что более важно, я могу начать и решить задачи без постоянной помощи на каждом шагу. Я могу играть свою игру. GDI работает слишком медленно? Я сделаю это через 3D. Да, с полигонами, освещением и текстурами, они все будут там. Необходимо сохранить и извлечь информацию, введенную пользователем? Я сделаю это по средствам базы данных. Вот, я разработал модель данных для этого. Создать новое нужное приложение? Конечно, прямо сейчас же возьмусь, со всеми теми слоями, ООП, и еще много чем. Создать пользовательский интерфейс? Вот, валидный HTML, CSS, безтабличная верстка и семантическая разметка. А вот тут необходимо сделать слишком много действий, это может отвлекать пользователей. И чтобы добраться до непроходимого места, они должны нажать эту кнопку для открытия диалога. Но все они, вероятно, будут пользоваться такой-то фичей довольно часто. Давайте поставим ее прямо на главной странице. Подумайте о юзабилити. Кто-то нарисовал ярко-красной кнопки рядом с голубой панелью инструментов с серым фоном вокруг? На не приятно смотреть, это не вписывается в нашу цветовую схему. Исправьте дизайн. Где мы находимся, если кто-то ищет эти конкретные ключевые слова в Google? Недостаточно высоко. Давайте подвинем эти слова ближе к началу страницы и удалим ненужные ключевые слова из названия страницы. Мы можем сделать немного поисковой оптимизации собственными силами.
Работа доставляет огромное удовлетворение, когда вы можете многое сделать сами. Вы разрабатываете гибкую архитектуру и пишите качественный код. Когда вы открываете базу данных – для вас все известно и знакомо. Нет необходимости в эксперте по базам данных. Вы можете создать пользовательский интерфейс и без эксперта по фронт-энд разработке. Вы даже можете создать приятный дизайн и выбрать набор цветов и без тех дорогих веб-студий. Нет, ваш дизайн не получит премию «Дизайн года». Но это будет выглядеть красиво и будет достаточно хорошим. Вы можете организовать элементы управление и структуру меню так, чтобы интерфейс был простым и интуитивно понятным для пользователей. И да, вы можете сделать это сами, без тех юзабилити экспертов, которые будут стоить вам в половину бюджета.
Пока вы любите то, что вы делаете и стремитесь быть лучше – вы сможете реализовать любое ваше желание.
Я также верю, что хороший разработчик должен быть квалифицированным в различных техниках. Не существует веских причин для того, чтобы вы застревали в вопросах баз данных и игнорировали архитектуру приложения. Вы, конечно же, не знаете всего по вопросу производительности баз данных. Но, нет оправдания для системного программиста, если он смеется над front-end разработчиками. Конечный пользователь не увидит ваши фантастические методы распределения памяти. А разработчик интерфейсов не должен прибывать полной темноте, по отношению к тому, как действительно работает программное обеспечение, какие алгоритмы и структуры данных используются и каким образом мы могли бы повысить эффективность наших запросов. Или должен ли веб-программист выбрасывать из внимания аспекты SEO и маркетинга, как несущественные? Нет, конечно же! Это ваша задача: разрабатывать веб-приложение с учетом SEO. А насколько нормально для прикладного программиста создавать сумасшедший пользовательский, который будет отпугивать нормальных пользователей? Нет, спасибо тебе, пожалуйста, отложили свои диаграммы классов и шаблоны проектирования и какое-то время подумай о юзабилити, что и как нужно сделать либо переделать.
Я часто жалел тех разработчиков, которые закрылись своим футляром и не желают смотреть вокруг или признаться, что есть еще важные и интересные вещи.
Вы не можете делать все самое лучшее, пока вы не видите всю картину в целом. И если вы действительно не видите всего, то ваша работа и близко не будет настолько хорошей, как могла бы быть.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Collections.Specialized;
using System.Data;
public class BasePage : System.Web.UI.Page
{
protected override void OnPreRender(EventArgs e)
{
base.OnPreRender(e);
DoEnableDisableControls();
SetTitleFromCMS();
SetMetaTagsFromCMS();
}
public string PageID
{
get;
set;
}
/// <summary>
/// Overwrite this method to enable or disable controls
/// depending on the state of the page.
/// </summary>
protected virtual void DoEnableDisableControls()
{
}
private void SetTitleFromCMS()
{
if (String.IsNullOrEmpty(PageID))
return;
//Queries the CMS for the page title
this.Title = "Whatever we got from the CMS";
}
private void SetMetaTagsFromCMS()
{
//Queries the CMS for the MetaTags
//add the meta tags
}
}
<% @ Page Language = "C #" PageID = "DefaultPage" AutoEventWireup = "True" CodeBehind = "Default.aspx.cs" Inherits = "% ExtRefWebApp._Default">
Такой тип программиста может успешно сыграть роль Гэндальфа во "Властелине колец". У него (или у нее! :) длинная борода по колено, глупая шляпа; может носить плащ или накидку зимой. К счастью для команды, на рабочем месте, это адепт белой магии, прямо как Гэндальф. К несчастью для команды, они должны будут терпеть часы рассказов Гэндальфа о том, как он или она шел в гору, по снегу, чтобы доставить перфокарты в далекий вычислительный центр. Гэндальф ¬¬– это ваш наилучший ударник IT-шного труда, но если вы попробуйте оставить его позади команды – это вызовет отчаяние.
В любой другой профессии, Мученик – это обычный "трудоголик". Но в области разработки, мученик выходит за эти рамки в другое измерение. По крайней мере, трудоголики уходят домой, в душ – и спать. А мученики гордятся тем, что просыпаться на рабочем столе среди пустых коробок из-под пиццы. Проблема в том, что никто не просил Мученика так работать. И он или она пытается заставить остальную часть команды почувствовать себя виноватыми, такими фразами как: "Да, пойду я домой, хотя бы пообедаю. Сегодня ночью закончил с участком кода, на который отводились ближайшие три недели.
Следите за Фанатиком. Если он или она настигнет вас врасплох, и прижмет в угол, то вы будете обречены, прослушать трехчасовую лекцию о превосходстве Opera по сравнению с Firefox, или почему Playstation 3 лучше, чем XB 360. На рабочем столе Фанатика разложены плакаты, фигурки и другие безделушки, связанные с его навязчивыми идеями, скорее всего, привезенные из Японии. С фанатиками невозможно иметь дело, они тратят настолько много времени на свою одержимость (внутри и вне офиса), что они совершенно не понимают, когда нужно выполнять работу, для которой их наняли.
Это человек около сорока лет, который живет в далеком к 1984 году. Длинные волосы, потертые стираные джинсы и бандана. На протяжении рабочего дня, Винс сидит в офисе, напевая мелодии Bon Jovi и Def Leppard. И, в принципе, все не так уж и плохо, если бы песня "Pour Some Sugar On Me" не была бы так чертовски заразительной.
Ниндзя это самый ценный человек в вашей команде, хотя об этом никто и не знает. Подобно легендарным самураям, вы не знаете находиться ли он в офисе, работает ли он, но вы обнаруживаете доказательства, представленные в первой половине дня. Вы проверяете систему управления версиями и видите, что в 4 утра Ниндзя решил ту проблему в коде, на которую вы планировали потратить всю следующую неделю, и вы даже не знаете, что Ниндзя было известно о проекте! Видите ли, пока вы были на еще одном совещании, Ниндзя работал.
Теоретик знает все, что нужно знать о программировании. Он или она может посвятить четыре часа лекции об истории непонятного языка программирования или предоставление доказательств того, что код, который вы написали не совсем оптимальной и вполне может потратить три лишние наносекунд для запуска. Проблема в том, что теоретик не знает ничего о процессе разработки программного обеспечения. Теоретик пишет код, который настолько изыскан, что простые смертные просто не могут найти в нем смысл. Его или ее любимая техника программирования – это рекурсия, и каждый блок кода настолько разогнан до максимума... в ущерб срыва сроков и нечитабельности.
Ковбой – это стихия, которую нельзя остановить. Он или она – это почти всегда эффективный программист, который может сделать работу два или три раза быстрее, чем кто-либо еще. Проблема в том, что, по крайней мере, половину всей этой скорости происходит путем срезания углов. Ковбой считает, что заливка кода в систему контроля версий занимает слишком много времени, хранения конфигурационных данных вне самого кода занимает слишком много времени, общение с кем-либо занимает слишком много времени ... ну, вы поняли идею.
Вы видели фильмы, где единственным Коммандос, сброшенный с воздуха в глубокий тыл противника, выходит оттуда с секретными стратегическими документами, планами противника, и спасает сотни военнопленных? В команде разработчиков ПО -- это Десантник. Десантник -- это последняя надежда, чтобы спасти умирающий проект. У десантников не хватает терпения для того, чтобы работать на долгосрочной основе, но их лучшие качество -- это способностью, быстро изучить незнакомый код и как работать с ним. Другие программисты могут потратить недели или месяцы для того, чтобы изучить все необходимое о проекте для эффективной работы над ним. У Десантника это займет несколько часов или дней. Десантники могут не изучать всего необходимого для работы с основным кодом, но их скорость и высокая обучаемость помогут преуспеть там, где вся команда может потерпеть неудачу.
"Достаточно хорошо" это лучшее, что вы можете получить от Посредственного Человека. Он или она всегда тратят больше времени для создания худшего кода, чем у кто-либо в команде. "Тише едешь – дальше будешь" – так можно описать проекты П.Ч. Но П.Ч. всегда просто "достаточно хорош" чтобы не быть уволенным.
Независимо от того в какой среде вы работаете , евангелист настаивает на том, что он может быть улучшена путем выброса всех ваших текущих инструментов и процессов и замены их на что-то другое. Евангелист – это противоположность Теоретика. Евангелиста откровенен, знает очень много о разработке программного обеспечения, но, программирует очень мало .
.NET ate my MOSK;. Powered By Blogger © 2009 Bombeli | Theme Design: ooruc
