Legacy projekt jako junior

Legacy projekt jako junior
ML
  • Rejestracja:ponad 2 lata
  • Ostatnio:prawie 2 lata
  • Postów:2
0

Cześć,
Od jakiegoś czasu męczy mnie moja aktualna sytuacja w firmie. Zacząłem karierę w tamtym roku i właśnie prawie rok czasu jestem w projekcie który jest starą utrzymaniówką. Składa się z parunastu serwisów, ja jako programista .NET głównie odpowiadam za ...Jenkinsa, Azure i Confluence i czasem zadania maintenance typu zmiana czegoś w bazie. Krótko mówiąc - rzeczy DevOpsowe, programowania brak. Robię progres prywatnie, uczę się nowych rzeczy (design patterny, ci/cd, bazy danych już umiałem, asp.net core mvc czy webapi nie sprawa mi problemów) i wiem że wciaż długa droga przede mną zanim będę się swobodnie czuł w tych technologiach, ale co mi po nauce ich skoro komercyjnie nie moge tego wykorzystać. Co byście zrobili na moim miejscu?

edytowany 1x, ostatnio: MichuLFC
ZP
Można zmienić pracę ale czy to coś zmieni? Jeśli produkt działa, jest żywy to siłą rzeczy głównym zajęciem jest utrzymanie go przy życiu.
Uśpiony wiosenny but
Zmieniłbym pracę, teraz tyle pracy nawet dla juniorów.
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:2 dni
  • Lokalizacja:Wrocław
17

Nie, jak masz Azure, to nie masz legacy.
Tak, zmień pracę, skoro robisz nie to, czego chcesz.
I pamiętaj, że doświadczenie przy utrzymywaniu większego systemu, który działa i ma użytkowników jest warte więcej niż klepanie nowego kodu, którego nikt nie widzi i nie używa.


Po dopracowaniu rozwiązania każdy będzie mógł założyć własny drzewiasty wątek.
FR
Ale on z tego Azure'a to ma pewnie Azure DevOps Server, także legacy soft przeniesiony na to coś dalej jest legacy :(
WeiXiao
  • Rejestracja:około 9 lat
  • Ostatnio:około 4 godziny
  • Postów:5105
3

Rozważałeś pogadać z przełożonym?

N0
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Gdańsk
  • Postów:647
6

Projekt z Azure i CI/CD to legacy? :P Myślałem że legacy to raczej webformsy, jQuery, logika w procedurach T-SQL, push do mastera jako sposób pracy, no i oczywiście ręczne deploymenty przez rdp :)

edytowany 1x, ostatnio: nobody01
Zobacz pozostałe 2 komentarze
N0
No częściowo tak :P Ale się uczepiliscie. Jeśli ktoś wziął i wrzucił to legacy na azure, to znaczy, że są świadomi że legacy jest i trzeba coś z tym zrobić. OP wymienił tylko 2 technologie w stacku i żadna z nich nie jest legacy. Do tego dla niektórych legacy oznacza API w .net framework plus nie najnowszy angular. Pomijam jakość kodu
Riddle
Czyli "Legacy code" == "przestażałe zależności", niezależnie od tech debtu?
N0
Dla wielu tak. Pomijam właściwą definicje
Riddle
Czyli np kod z funkcjami na 1000 linijek, 0 testów, jednoliterowy nazwy zmiennych, w projekcie gdzie są najnowsze zależności to już nie jest "Legacy"?
N0
Michael Feathers introduced a definition of legacy code as code without tests, which reflects the perspective of legacy code being difficult to work with in part due to a lack of automated regression tests. Ale znowu Wikipedia podaje: Legacy code is old computer source code. It could simply refer to an organization's existing code base which has been written over many years, or it could imply a codebase that is in some respect obsolete or supporting something obsolete.
T3
  • Rejestracja:ponad 4 lata
  • Ostatnio:5 miesięcy
  • Postów:687
1

Ale po co nas pytasz o zdanie? Już podjąłeś decyzję, że to legacy i w tym pracować nie chcesz, no to sprawa jest prosta - zmiana firmy

ML
  • Rejestracja:ponad 2 lata
  • Ostatnio:prawie 2 lata
  • Postów:2
0
nobody01 napisał(a):

Projekt z Azure i CI/CD to legacy? :P Myślałem że legacy to raczej webformsy, jQuery, logika w procedurach T-SQL, push do mastera jako sposób pracy, no i oczywiście ręczne deploymenty przez rdp :)

ci/cd i azure nie istnieje od 2 lat tylko dobrę parę/parenaście :D

somekind napisał(a):

Nie, jak masz Azure, to nie masz legacy.
Tak, zmień pracę, skoro robisz nie to, czego chcesz.
I pamiętaj, że doświadczenie przy utrzymywaniu większego systemu, który działa i ma użytkowników jest warte więcej niż klepanie nowego kodu, którego nikt nie widzi i nie używa.

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

N0
Może i kilkanaście, ale ile legacy projektów może się pochwalić ci cd? To samo Azure
WeiXiao
  • Rejestracja:około 9 lat
  • Ostatnio:około 4 godziny
  • Postów:5105
0

@MichuLFC:

bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

nie wiem, ciężko dyskutować nt. takich ogólników, a jako że "robiący development" oraz "odpowiedzialny za utrzymanie" właściwie mogą znaczyć wszystko, to jeszcze ciężej.

To inaczej - innych rzeczy uczysz się gdy nagle trafiasz do projektu gdzie jest react i redis których nigdy nie używałeś, a innych gdy 2 lata pisałeś projekt, od pół roku siedzi na prodzie i nagle pojawiają się "dziwne problemy" - ktoś przekopiował dziwny znaczek z łorda do pola tekstowego i wyszło że encoding w całej appce jest skopany :D

klient się skarży że coś długo mieli, a tu jakieś query będące zwykłym N+1 lub może nawet czymś ciekawszym

bugi pokroju "u jednego usera nie działa"

może jakiś wyścig?

a może nagle klient chce przerobić jakiś core_feature i wychodzi jak wszystko jest ze sobą pohakowane trytytkami i ifkami

Ja oczywiście nie twierdzę że nie masz racji co do swojego przypadku i może faktycznie powinieneś uciekać.

edytowany 3x, ostatnio: WeiXiao
N0
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Gdańsk
  • Postów:647
0

Warto też pamiętać że development to często klepanie crudow. Jeśli nie trafisz do jakiegoś projektu z zaawansowaną architektura, skomplikowana domena i mocnymi ludźmi w zespole, to z tym rozwojem raczej nie będzie lepiej.

Zobacz pozostałe 21 komentarzy
N0
Developer sam sobie niczego nie wymyśli przeciez
WeiXiao
ale nie zawsze potrzebuje się zapoznać z jakąś ogromną specyfikacją na 500 stron, bo czasem domena jest relatywnie łatwa. Chodzi mi cały czas o to, że złożoność domeny sama w sobie nie musi oznaczać niczego fajnego
N0
No ok, można mieć wymagająca technicznie apke o prostej domenie. Ale chyba lepiej mieć doświadczenie przy pracy przy złożonych domenach? I to chyba kwestia organizacji pracy. Gdzie w tym wszystkim miejsce na analityków biznesowych? Dlaczego developer ma czytać 500 stron dokumentacji żeby dodać jakiegoś ifa? Mamy chyba jakieś testy napisane i można zmieniać kod bez obawy, że na prod pójdzie błąd. Do tego zmiana będzie też przetestowana przez testerów i innych ludzi znających dokładnie domenę.
WeiXiao
@nobody01: Ale chyba lepiej mieć doświadczenie przy pracy przy złożonych domenach? jeżeli ma być złożona domena, a od technicznej strony bieda, to nie widzę jakiejkolwiek wartości w czymś takim. Bo o ile nie poświęcisz na to bardzo dużo czasu/wysiłku lub nie będziesz pracował w niej wiele lat, to prawdopodobnie tej domeny dobrze nie ogarniesz i/lub ta wiedza będzie ci po prostu zbędna. Jeżeli ci się podoba dana domena albo możesz się coś ciekawego dowiedzieć, co zwykły śmiertelnik spoza tej branży nie wie, to spoko.
WeiXiao
I miałem okazje doświadczyć obu tych przypadków - domena dla mnie ciężka i bezużyteczna, a innym razem ciekawa, ale też bardzo obszerna.
GA
  • Rejestracja:ponad 9 lat
  • Ostatnio:12 miesięcy
  • Postów:57
3
MichuLFC napisał(a):

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

Dziwnym trafem jednak jak już to więcej płacą za pracę przy "legacy", niż przy fancy super hiper nowym greenfieldzie. ;) I też jednak umiejętność developmentu w istniejącym kodzie na produkcji, bez dorzucania tony bugów jest bardziej pożądana, niż doklejanie na ślinie kolejny featurów do nieprodukcyjnej apki.

S9
  • Rejestracja:około 4 lata
  • Ostatnio:około 2 lata
  • Lokalizacja:Warszawa
  • Postów:1092
12

Powiedzmy sobie to jasno - legacy nie jest wprost powiązane ze starością projektu. Może być projekt 10 letni który jest odpowiednio utrzymywany i być nie legacy (mimo że nie ma najnowszej wersji frameworka i Kafki) i może byc projekt napisany pół roku temu kijowy, nie utrzymywalny spaghetti i w ogóle. Człowiek który ma trochę ekspa już (na ogół) nie jara się tym ktora wersja frejmłorka jest w aplikacji.


Zobacz pozostałe 4 komentarze
CW
Zgodzę się co do czytelności projektu oraz większych kosztów jego utrzymania bo niestety niesie to za sobą np. konieczność dodatkowych aktualizacji baz danych, a nie tylko aplikacji. Natomiast w procedurze przechowywanej możesz zastosować dość złożone konstrukcje np. wykorzystując tabele tymczasowe, które pozwalają na znacznie szybsze wykonywanie zapytań. Z punktu widzenia użytkownika czekanie na wyniki zapytania np. 30s, a nie 5 min robi ogromną różnicę. Oczywiście mówię tu o tabelach z wieloma milionami rekordów, a nie takimi co zawierają kilka tysięcy rekordów..
N0
Racja, czasami procedura będzie szybsza i wtedy należy jej użyć. Raczej chodziło mi o to, żeby używać ich tylko wtedy, kiedy naprawdę nie da się inaczej lub jest dużo trudniej. No i broń boże nie wrzucać tam żadnej logiki biznesowej. Jedynie odczyty :P
N0
Moja niechęć do procedur może wynikać z tego że raz byłem w takim projekcie gdzie procedury były domyślną opcja. Nigdy więcej.
Miang
moja niechęć do logiki w kodzie wynika z tego że juniorzy nie widzą różnicy między logiką w kodzie na serwerze a przerzuceniem wszystkich danych do frontu żeby sumę policzyć
CR
  • Rejestracja:ponad 8 lat
  • Ostatnio:ponad 2 lata
  • Postów:116
0

Lepsze stabilne legacy, niż greenfield w pośpiechu i nerwach.

PR
gorzej jak masz do legacy featury dolepić w pośpiechu i nerwach :D
somekind
Moderator
  • Rejestracja:około 17 lat
  • Ostatnio:2 dni
  • Lokalizacja:Wrocław
1
MichuLFC napisał(a):

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

Ok, a z czego ta większa wartość miałaby wynikać?


Po dopracowaniu rozwiązania każdy będzie mógł założyć własny drzewiasty wątek.
Zobacz pozostałe 3 komentarze
stivens
Wiec zalezy kto co ma na mysli po prostu
somekind
pisanie od 0 wymaga wiecej wysilku - wątpię. Nie ma bugów, nie ma problemów z wydajnością, nie ma brakujących logów, nie ma żadnych wyzwań ani realnych problemów.
ZD
@somekind: na poziomie kodowania, czy wyznaczenia dobrej, stabilnej architektury ? tak / nie (nie ma wyboru)
somekind
@ZrobieDobrze: ale czego dotyczy Twoje pytanie o poziom?
ZD
@somekind: Koment "na greenfieldzie jest lepiej"
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:14 minut
  • Postów:8397
4
MichuLFC napisał(a):

Nie mogę się z tym zgodzić (ze swojego braku doświadczenia mogę się mylić oczywiście), bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie

Trochę dziwne założenia robisz w tym zdaniu.

  • W kontekście tego, co piszesz w pierwszym wątku, wpadłeś w jakieś dev opsy i je nazywasz "utrzymaniem". I teraz tak - co do devopsów, to nie chcę się wypowiadać ile są warte (to już by trzeba sprawdzić patrząc na widełki dla devopsów), natomiast w tym momencie przestajesz de facto pełnić obowiązki programisty, jeśli jedyne, co robisz, to Jenkins
  • Natomiast "utrzymanie" może również polegać na pisaniu kodu (i czytaniu! Bo to jest często większym wyzwaniem i więcej czasu zajmuje. Gdzie spędzasz godziny na czytaniu kodu, żeby raptem parę linijek zakodzić swoich), więc jak najbardziej programista odpowiedzialny za utrzymanie może programować.
  • bo programista programujący w nowych projektach, robiący development jest jednak więcej warty niż programista mający tyle samo lat doświadczenia ale nie programujący nic, tylko odpowiedzialny za utrzymanie - fikołek logiczny trochę jak u Matiego, ale zasmucę cię, żaden z nich nie będzie członkiem elity narodu polskiego ;) to, ile ktoś będzie warty na rynku zależy od wielu czynników (rzeczywiste umiejętności, wpasowanie się w potrzeby rynku, umiejętność sprzedania się, umiejętności negocjacyjne itp.), tym niemniej utrzymanie jest z reguły trudniejsze. Napisać greenfield każdy umie, bo skala jest mniejsza i mniej ograniczeń. To utrzymanie istniejącego projektu jest trudne.

edytowany 2x, ostatnio: LukeJL
CW
Dodam tylko jeszcze od siebie, że jak w nowym projekcie na etapie dev coś się sypnie to po prostu można wyzerować dane i próbować dalej, natomiast w utrzymaniu jak się pomylisz i funkcja nie zadziała prawidłowo np. źle przeliczając jakieś dane to dopiera zaczyna się karuzela. W utrzymaniu każdy ruch, każda nowa funkcja muszą być bardzo przemyślane i przetestowane bo tu nie ma miejsca na pomyłki, a poziom stresu to jest x100 razy tego co na czystym dev gdzie chyba tylko nierealne terminy mogą podnieść ciśnienie.
LukeJL
dokładnie, jak są prawdziwi użytkownicy (tudzież klienci, którzy oczekują zmian na już), to trochę inaczej niż jak jest sobie greenfield, po którym nikt nie będzie oczekiwał, że będzie nawet się uruchamiał i działał prawidłowo.
CR
  • Rejestracja:ponad 8 lat
  • Ostatnio:ponad 2 lata
  • Postów:116
0

Moim zdaniem w takim legacy jakbyś chciał to byś się więcej rzeczy nauczył aniżeli zmiana pracy i pójście na greenfield. Pomyśl nad automatyzacją powtarzalnych zadań, na refactoringiem kodu, jakością, skanowaniem pod podatność na ataki, nad usprawnieniem środowisk, monitoringiem/alertami, dobrą dokumentacją. Podejrzewam że tam jest robiony co niemiara. Ja bym pracy nie zmieniał.

edytowany 2x, ostatnio: crx
Bronzebeard
  • Rejestracja:ponad 4 lata
  • Ostatnio:4 miesiące
  • Postów:15
5

@scibi_92 i @LukeJL mają dużo racji.

Dodam swoje trzy grosze.

Sam kilka lat temu myślałem, że czym nowszy frejmłork, tym lepszy projekt. Przecież w ogłoszeniach wymagają znajomości takich rzeczy! Potem raz czy dwa zdarzyło mi się trafić do ekipy, która do komunikacji asynchronicznej brała Kafkę, bo tak, a koncepcja partycji w tejże była dla nich czarną magią. Podobnie jak takie podstawowe rzeczy, jak: monitorowanie pól wątków i liczby otwartych deskryptorów albo ustawianie timeoutów w klientach do komunikacji synchronicznej po HTTP (socket, request, connection timeout, itd.). Nie żebym ja był jakimś wybitnym fifa-rafa.

Człowieku, a kto tak robi?! Przecież działa.

:)

może byc projekt napisany pół roku temu kijowy, nie utrzymywalny spaghetti i w ogóle

Potwierdzam. Warto mieć to na uwadze. Różne są greenfieldy. Jedne typu rewrite, inne typu rośnie nam biznes lub platforma i potrzeba coś z tym zrobić.

Jeśli rewrite, to dobrze trzymać się z dala od produktów, gdzie nie ma w ekipie analityków i programistów, którzy znają bolączki tego, co jest do przepisania. Mnie nigdy nie sprawdziła się rewolucja. Za to sprawdzała się ewolucja.

Jeśli rośnie biznes lub platforma i potrzeba coś z tym zrobić, to dobrze, jeśli w ekipie jest ktoś kto zna istniejący biznes lub platformę. Słabo, jeśli cały zespół przychodzi z zewnątrz.

Z mojego doświadczenia, żeby greenfield po poł roku nie skończył jako spaghetti, potrzeba minimum:

  • CI,
  • statycznej analizy kodu, która na poziomie CI będzie wykrywać code smells, wymuszać formatowanie oraz pilnować złożoności cyklomatycznej czy przestrzegania reguł, na które umówił się zespół,
  • automatycznych testów architektury spiętych z CI (np. ArchUnit), żeby ustalenia co do konwencji w kodzie były automatycznie egzekwowane,
  • monitoringu i systemu alertowania spiętego z Pager Duty,
  • dziennika ważnych decyzji, żeby te był podejmowane świadomie,
  • pokory w ekipie,
  • mądrego i zaangażowanego lidera, który będzie ogarniać ludzi, którzy:
    -- ciągną w dół,
    -- proponują wyłączyć alerty w Pager Duty,
    -- są interesariuszami i chcą przekonać do fake it till you make it.

Niemniej, może to tylko mój jednostkowy przypadek i możesz to potraktować jako dowód anegdotyczny.

Znajdziesz wiele legacy, w którym te rzeczy są. Znajdziesz też wiele legacy, gdzie tego nie ma. Podobnie z greenfieldami.

Jeśli jesteś Juniorem i szukasz dla siebie dobrego miejsca, to zamiast pytać o to czy dużo programują reaktywnie, lepiej zapytać o to jak ekipa rozwiązała problem logowania z MDC programując reaktywnie. Dobrze jest też poprosić, żeby pokazali Ci jak wdrażają zmiany na produkcję. Czy mają testy, automatyczny provisioning... Już samo to dużo mówi.


"Delve Deeper Dwarves" by Lunar Giant is licensed under CC BY-SA 3.0.
edytowany 7x, ostatnio: Bronzebeard
Miang
łapka za pierwszą połowę posta ;)
N0
A co jest nie tak w drugiej?
Miang
wyliczanka;)
N0
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 2 lata
  • Lokalizacja:Gdańsk
  • Postów:647
1

@MichuLFC: jakie konkretnie technologie masz w projekcie? Wspomnienie o Azure i ci / cd spowodowało zamieszanie.

Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)